MODULE – I:

CONCEPTUAL MODELING
INTRODUCTION
Introduction of Data Bases
• A database-management system (DBMS) is a collection of interrelated data and a set of
programs to access those data.

• A DBMS is a software system that is designed to manage and organize data in a structured
manner. It allows users to create, modify, and query a database, as well as manage the
security and access controls for that database.

• The collection of data, usually referred to as the database, contains information relevant to an
enterprise.

• The primary goal of a DBMS is to provide a way to store and retrieve database information
that is both convenient and efficient. Database systems are designed to manage large bodies
of information.
• Management of data involves both defining structures for storage of information and
providing mechanisms for the manipulation of information.

• In addition, the database system must ensure the safety of the information stored, despite
system crashes or attempts at unauthorized access.

• If data are to be shared among several users, the system must avoid possible anomalous
results.

• Because information is so important in most organizations, computer scientists have

developed a large body of concepts and techniques for managing data.
Database-System Applications
Enterprise Information

• Sales: For customer, product, and purchase information.

• Accounting: For payments, receipts, account balances, assets and other accounting
information.

• Human resources: For information about employees, salaries, payroll taxes, and benefits, and
for generation of paychecks.

• Manufacturing: For management of the supply chain and for tracking production of items in
factories, inventories of items in warehouses and stores, and orders for items.

• Online retailers: For sales data noted above plus online order tracking, generation of
recommendation lists, and maintenance of online product evaluations.
Banking and Finance

Banking: For customer information, accounts, loans, and banking transactions.

Credit card transactions: For purchases on credit cards and generation of monthly statements.

Finance: For storing information about holdings, sales, and purchases of financial
instruments such as stocks and bonds; also for storing real-time market data to enable online
trading by customers and automated trading by the firm.
Universities:

For student information, course registrations, and grades (in addition to standard enterprise
information such as human resources and accounting).

Airlines:

For reservations and schedule information. Airlines were among the first to use databases
in a geographically distributed manner.

Telecommunication:

For keeping records of calls made, generating monthly bills, maintaining balances on
prepaid calling cards, and storing information about the communication networks.
Purpose of Databases

• It is a collection of tools that enable users to create and manage databases. In other words, it
is general-purpose software that allows users to create, manipulate, and design databases for
a number of purposes.

• Database systems are design to deal with large volumes of data. Data management comprises
both the construction of data storage systems and the provision of data manipulation
methods.

• Furthermore, the database system must maintain the security of the information held despite
system crashes or attempts at unauthorized access. The system must avoid any unexpected
effects if data is to be shared across multiple users.

• The database applications were built on top of the file system.

The goal of a database management system (DBMS) is to transform the following:

1. Data into information.

2. Information into knowledge.

3. Knowledge of the action.

Characteristics of DBMS
• Firstly, It manages and stores information in a server-based digital repository.

• Secondly, It can logically and visibly represent the data transformation process.

• Automatic backup and recovery techniques are built into the database management
system.

• It has ACID features, which ensure that data is safe even if the system fails.

• It has the ability to make complex data connections more understandable.

• It’s utilize to help with data manipulation and processing.

• It is utilize to keep information safe.

• Lastly, It can examine the database from a variety of perspectives, depending on the
Advantages of DBMS
• Data Independence: Application programs should not, ideally, be exposed to details of
data representation and storage. The DBMS provides an abstract view of the data that hides
such details.

• Efficient Data Access: A DBMS utilizes a variety of sophisticated techniques to store and
retrieve data efficiently. This feature is especially important if the data is stored on external
storage devices.

• Data Integrity and Security: If data is always accessed through the DBMS, the DBMS
can enforce integrity constraints. For example, before inserting salary information for an
employee, the DBMS can check that the department budget is not exceeded. Also, it can
enforce access controls that govern what data is visible to different classes of users.
• Data Administration: When several users share the data, centralizing the
administration of data can offer significant improvements. Experienced professionals
who understand the nature of the data being managed, and how different groups of
users use it, can be responsible for organizing the data representation to minimize
redundancy and for fine-tuning the storage of the data to make retrieval efficient.

• Concurrent Access and Crash Recovery: A DBMS schedules concurrent accesses to

the data in such a manner that users can think of the data as being accessed by only
one user at a time. Further, the DBMS protects users from the effects of system
failures.
• Reduced Application Development Time: Clearly, the DBMS supports important
functions that are common to many applications accessing data in the DBMS. This, in
conjunction with the high-level interface to the data, facilitates quick application
development. DBMS applications are also likely to be more robust than similar stand-
alone applications because many important tasks are handled by the DBMS (and do not
have to be debugged and tested in the application).
Disadvantages of DBMS
• Hardware and software costs:

To operate DBMS software, you’ll need a fast data processor and a lot of memory.

• Size:

To run them efficiently, it takes up a lot of disc space and RAM.

• Complexity:

The database system adds to the complexity and demands.

• Failure has a greater impact on the database since most organizations keep all of their
data in a single database, and if the database is damage due to an electric outage or
database corruption, the data might lost permanently.
File system vs Database System
View of Data
• Abstraction is one of the main features of database systems. Hiding irrelevant details from
user and providing abstract view of data to users, helps in easy and efficient user-
database interaction.

• To fully understand the view of data, you must have a basic knowledge of data abstraction
and instance & schema.

1.Data abstraction:

Database systems are made-up of complex data structures. To ease the user interaction with
database, the developers hide internal irrelevant details from users. This process of hiding
irrelevant details from user is called data abstraction.
2. Instance and schema:

• Design of a database is called the schema. Schema is of three types: Physical schema,
logical schema and view schema.

• The data stored in database at a particular moment of time is called instance of database.

• Database schema defines the variable declarations in tables that belong to a particular
database; the value of these variables at a moment of time is called the instance of that
database.
Data Abstraction

• Database systems are made-up of complex data structures.

• To ease the user interaction with database, the developers hide internal irrelevant details
from users.

• This process of hiding irrelevant details from user is called data abstraction.

• The term “irrelevant” used here with respect to the user, it doesn’t mean that the hidden
data is not relevant with regard to the whole database.

• It just means that the user is not concerned about that data.
For example:

When you are booking a train ticket, you are not concerned how data is processing at
the back end when you click “book ticket”, what processes are happening when you
are doing online payments.

You are just concerned about the message that pops up when your ticket is
successfully booked.

This doesn’t mean that the process happening at the back end is not relevant, it just
means that you as a user are not concerned what is happening in the database.
Three levels of abstraction
Physical level/Internal level:

• The physical or the internal level schema describes how the data is stored in the

hardware. It also describes how the data can be accessed.

• The physical level shows the data abstraction at the lowest level and it has complex data

structures.

• Only the database administrator operates at this level.

Logical level/Conceptual level:

• This is the middle level of 3-level data abstraction architecture. It describes what data is
stored in database.

• It is a level above the physical level. Here, the data is stored in the form of the entity
set, entities, their data types, the relationship among the entity sets, user
operations performed to retrieve or modify the data and certain constraints on the data.

• Well adding constraints to the view of data adds the security. As users are restricted to
access some particular parts of the database.

• It is the developer and database administrator who operates at the logical or the conceptual
level.
View level/User level/ External level:

• Highest level of data abstraction and exhibits only a part of the whole database.

• This level describes the user interaction with database system.

• The view level can describe many views of the same data.

• Here, the user retrieves the information using different application from the database.
• We have to create a database of a college. Now, what entity sets would be
involved? Student, Lecturer, Department, Course and so on…

• Now, the entity sets Student, Lecturer, Department, Course will be stored in the storage as
the consecutive blocks of the memory location. This is the physical or internal level and
is hidden from the programmers but the database administrator is it aware of it.

• At the logical level, the programmers define the entity sets and relationship among these
entity sets using a programming language like SQL. So, the programmers work at the
logical level and even the database administrator also operates at this level.

• At the view level, the users have the set of applications which they use to retrieve the data
they are interested in.
• Example: Let’s say we are storing customer information in a customer table. At physical
level these records can be described as blocks of storage (bytes, gigabytes, terabytes etc.)
in memory. These details are often hidden from the programmers.

• At the logical level these records can be described as fields and attributes along with their
data types, their relationship among each other can be logically implemented. The
programmers generally work at this level because they are aware of such things about
database systems.

• At view level, user just interact with system with the help of GUI and enter the details at
the screen, they are not aware of how the data is stored and what data is stored; such
details are hidden from them.
Instance and schema in DBMS
DBMS Schema
Design of a database is called the schema. For example: An employee table in database
exists with the following attributes:

This is the schema of the employee table. Schema defines the attributes of tables in the
database.
Schema is of three types: Physical schema, logical schema and view schema.
• Schema represents the logical view of the database. It helps you understand what data needs to
go where.

• Schema can be represented by a diagram as shown below.

• Schema helps the database users to understand the relationship between data.

• This helps in efficiently performing operations on database such as insert, update, delete, search
etc.

• In the following diagram, we have a schema that shows the relationship between three tables:
Course, Student and Section.

• The diagram only shows the design of the database, it doesn’t show the data present in those
tables.

• Schema is only a structural view(design) of a database as shown in the diagram below.

• The design of a database at physical level is called physical schema, how the data stored
in blocks of storage is described at this level.

• Design of database at logical level is called logical schema, programmers and database
administrators work at this level, at this level data can be described as certain types of
data records gets stored in data structures, however the internal details such as
implementation of data structure is hidden at this level (available at physical level).

• Design of database at view level is called view schema. This generally describes end
user interaction with database systems.
DBMS Instance
• The data stored in database at a particular moment of time is called instance of database.

• Database schema defines the attributes in tables that belong to a particular database.

• The value of these attributes at a moment of time is called the instance of that database.

• For example, we have seen the schema of table “employee” above. Let’s see the table
with the data now. At this moment the table contains two rows (records). This is the
current instance of the table “employee” because this is the data that is stored in this
table at this particular moment of time.
• Let’s say we have a single table student in the database, today the table has 100 records,
so today the instance of the database has 100 records.
• We are going to add another 100 records in this table by tomorrow so the instance of
database tomorrow will have 200 records in table.
• In short, at a particular moment the data stored in database is called the instance, this
changes over time as and when we add, delete or update data in the database.
Data Models

• Data Model is the modeling of the data description, data semantics, and consistency
constraints of the data.

• Data models in DBMS help to understand the design at the conceptual, physical, and logical
levels as it provides a clear picture of the data making it easier for developers to create a
physical database.

• Data models are used to describe how the data is stored, accessed, and updated in a
DBMS.

• A set of symbols and text is used to represent them so that all the members of an organization
can understand how the data is organized.

• It provides a set of conceptual tools that are vastly used to represent the description of data.
Types of Data Models

1.Hierarchical Model

• The hierarchical data model is one of the oldest data models, developed in
the 1950s by IBM.

• In this data model, the data is organized in a hierarchical tree-like structure.

• This data model can be easily visualized because each record has one parent and many
children (possibly 0) as shown in the image given below.
• The above-given image represents the data model of the Vehicle database, vehicle
are classified into two types Viz. two-wheelers and four-wheelers and then they are
further classified.

• The main drawback we can see here is we can only have one too many
relationships under this model, hence the hierarchical data model is very rarely used
nowadays.
2.Network Model
• A network model is nothing but a generalization of the hierarchical data model as
this data model allows many to many relationships therefore in this model a record
can also have more than one parent.

• The network model can be represented as a graph and hence it replaces the
hierarchical tree with a graph in which object types are the nodes and relationships
are the edges.

• For example -
• Here you can see all three departments are linked with the director which was not
possible in the hierarchical data model.

• In the network model, there can be many possible paths to reach a node from the root
node (College is the root node in the above case), therefore the data can be accessed
efficiently when compared to the hierarchical data model. But, on the other hand, the
process of insertion and deletion of data is quite complex.
3.Entity-Relationship Model (ER Model)
• An Entity-Relationship model is a high-level data model that describes the
structure of the database in a pictorial form which is known as ER-diagram.

• In simple words, an ER diagram is used to represent logical structure of the database

easily.

• ER model develops a conceptual view of the data hence it can be used as a blueprint to
implement the database in the future.

• Developers can easily understand the system just by looking at ER diagram. Let's first
have a look at the components of an ER diagram.

• Entity - Anything that has an independent existence about which we collect the data.
• They are represented as rectangles in the ER diagram. For example - Car, house,
employee.

• Entity Set - A set of the same type of entities is known as an entity set. For example - Set
of students studying in a college.

• Attributes - Properties that define entities are called attributes. They are represented by
an ellipse shape.

• Relationships - A relationship is used to describe the association between entities. They

are represented as diamond or rhombus shapes in the ER diagram.
• In the above diagram, the entities are Teacher and Department.

• The attributes of Teacher entity are Teacher_Name, Teacher_id, Age, Salary,

Mobile_Number. The attributes of entity Department entity are Dept_id, Dept_name.

• The two entities are connected using the relationship. Here, each teacher works for a
department.
4.Relational Model

• This is the most widely accepted data model.

• In this model, the database is represented as a collection of relations in the form of

rows and columns of a two-dimensional table.

• Each row is known as a tuple (a tuple contains all the data for an individual record)
while each column represents an attribute.

• For example -
The above table shows a relation "STUDENT" with attributes such as Stu. Id, Name, and
Branch which consists of 4 records or tuples.
5.Object-Oriented Data model
• As suggested by its name, the object-oriented data model is a combination of object-
oriented programming and relational data model.

• In this data model, the data and their relationship are represented in a single structure which
is known as an object.

• Since data is stored as objects we can easily store audio, video, images, etc. in the database
which was very difficult and inconvenient to do in the relational model.

• As shown in the image below two objects are connected with each other through links.
In the above image, we have two objects that are Employee and Department in which
all the data is contained in a single unit (object). They are linked with each other as
they share a common attribute i.e. Department_Id.
6.Object Relational Data Model
• An Object relational model is a combination of a Object oriented database model and a
Relational database model.

• So, it supports objects, classes, inheritance etc. just like Object Oriented models and has
support for data types, tabular structures etc. like Relational data model.

• One of the major goals of Object relational data model is to close the gap between
relational databases and the object oriented practices frequently used in many
programming languages such as C++, C#, Java etc.

• For example -
• It provides data structures and operations used in the relational model and also
provides features of object-oriented models like classes, inheritance, encapsulation
etc.

• The only drawback of this data model is that it is complex and quite difficult to
handle.
7.Semi-Structured Data Model
• A semi-structured data model is a generalized form of the relational model, which allows
representing data in a flexible way, hence we can not differentiate between data and
schema in this model because, in this model, some entities have a missing attribute(s)
and on the other hand, some entities might have some extra attribute(s) which in
turn makes it easy to update the schema of the database.

• For example - We can say a data model is semi-structured if in some attributes we are
storing both atomic values (values that can't be divided further, for example, Roll_No) as
well as a collection of values.

• HTML code, graphs and tables, e-mails, XML documents are examples of semi-structured
data, which are often found in object-oriented databases.
Database Languages/SQL Commands
• A DBMS has appropriate languages and interfaces to express database queries and
updates.

• Database languages can be used to read, store and update the data in the database.

• Types of Database Languages

Data Definition Language (DDL)

• DDL stands for Data Definition Language. It is used to define database structure or
pattern.

• It is used to create schema, tables, indexes, constraints, etc. in the database.

• Using the DDL statements, you can create the skeleton of the database.

• Data definition language is used to store the information of metadata like the number of
tables and schemas, their names, indexes, columns in each table, constraints, etc.

• Here are some tasks that come under DDL:

• Create: It is used to create objects in the database.

• Alter: It is used to alter the structure of the database.

• Drop: It is used to delete objects from the database.

• Truncate: It is used to remove all records from a table.

• Rename: It is used to rename an object.

• Comment: It is used to comment on the data dictionary.

These commands are used to update the database schema that's why they come under
Data definition language.
Data Manipulation Language (DML)
• DML stands for Data Manipulation Language. It is used for accessing and manipulating
data in a database. It handles user requests.

• Here are some tasks that come under DML:

• Select: It is used to retrieve data from a database.

• Insert: It is used to insert data into a table.

• Update: It is used to update existing data within a table.

• Delete: It is used to delete all records from a table.

• Merge: It performs UPSERT operation, i.e., insert or update operations.

• Call: It is used to call a structured query language or a Java subprogram.

• Explain Plan: It has the parameter of explaining data.

• Lock Table: It controls concurrency.

Data Control Language (DCL)
• DCL stands for Data Control Language. It is used to retrieve the stored or saved data.

• The DCL execution is transactional. It also has rollback parameters. (But in Oracle
database, the execution of data control language does not have the feature of rolling back.)

• Here are some tasks that come under DCL:

• Grant: It is used to give user access privileges to a database.

• Revoke: It is used to take back permissions from the user.

• There are the following operations which have the authorization of Revoke:

• CONNECT, INSERT, USAGE, EXECUTE, DELETE, UPDATE and SELECT.

Transaction Control Language (TCL)
• TCL is used to run the changes made by the DML statement. TCL can be grouped into a
logical transaction.

• Here are some tasks that come under TCL:

• Commit: It is used to save the transaction on the database.

• Rollback: It is used to restore the database to original since the last Commit.

• Savepoint: It is used to temporarily save a transaction so that you can rollback to that
point whenever required.
Database Users

• In simple terms, if we understand, any person who uses a database and avails benefits from the
database is known as database user in DBMS.

• Database users in DBMS can access the database and retrieve the data from the database using
applications and interfaces provided by the Database Management System (DBMS).

• We can always provide security to our database from being accessed by the unauthorized users.

• Different database users with different login IDs and passwords can only have unrestricted
access to that part of the database with which they are associated as per the requirements.

• Database users in DBMS can be categorized based on their interaction with the databases.

• According to the tasks performed by the database users on the databases, we can categorize them
into seven categories as follows:
• Database Administrators (DBA)

• Database Designers

• System Analysts

• Application Programmers / Back-End Developers

• Naive Users / Parametric Users

• Sophisticated Users

• Casual Users / Temporary Users

Database Administrators (DBA)

• Database Administrator (DBA) is a person/team who defines the schema and also controls
the 3 levels of database.

• The DBA will then create a new account id and password for the user if he/she need to
access the database.

• DBA is also responsible for providing security to the database and he allows only the
authorized users to access/modify the data base.

• DBA is responsible for the problems such as security breaches and poor system response
time.

• DBA also monitors the recovery and backup and provide technical support.
• The DBA has a DBA account in the DBMS which called a system or superuser account.

• DBA repairs damage caused due to hardware and/or software failures.

• DBA is the one having privileges to perform DCL (Data Control Language) operations such
as GRANT and REVOKE, to allow/restrict a particular user from accessing the database.
Database Designers
• Data Base Designers are the users who design the structure of database which includes
tables, indexes, views, triggers, stored procedures and constraints which are usually
enforced before the database is created or populated with data.

• He/she controls what data must be stored and how the data items to be related.

• It is responsibility of Database Designers to understand the requirements of different user

groups and then create a design which satisfies the need of all the user groups.
Naive Users / Parametric Users
• Naive users also known as Parametric End users, don't have any knowledge of DBMS
but still frequently use the database applications to get the desired results.

• Parametric End Users are the unsophisticated who don’t have any DBMS knowledge but
they frequently use the database applications in their daily life to get the desired results.

• For examples, Railway’s ticket booking users are naive users. Clerks in any bank is a
naive user because they don’t have any DBMS knowledge but they still use the database
and perform their given task.
System Analyst
• System Analysts are the type of database users in DBMS who analyze the requirements of
Naive / Parametric End users.

• It is their responsibility to check whether all the requirements of end users are satisfied or
not.

• Analyzing feasibility, economic and technical aspects are some of the major
responsibilities for a system analyst in DBMS. Sometimes, they are also responsible for the
design, structure & functioning of the database.

• They usually check and gather all the necessary information related to the database, and if
needed, they can change or update the final layout of the database as per requirements.
System Analysts always make sure that the final product should meet all the requirements.
Application Programmers / Back-End Developers
• Application Programmers also known as Back-End Developers, are computer professional users
who are responsible for developing the application programs (C, C++, Java, PHP, Python, etc.) or
the user interface so that other users can use these applications to interact with the database.

• Application Programmers have deep knowledge of DBMS & databases and know everything in
detail.

• They interact with the database using DML (Data Manipulation Language) queries to store data
inside the database and when needed, they can also fetch the data from it.

• When needed, Application Programmers also specify the modifications needed in the database
structure for an application.

• They are efficient enough in designing or developing their database in any language they know.
Sophisticated Users

• Sophisticated users are the type of database users in DBMS who know DBMS (DDL & DML
commands) and are familiar with the database.

• Sophisticated users can be business analysts, engineers, scientists, system analysts, etc.

• Sophisticated users can develop or access their database applications according to the requirements, without
actually writing the program code for it.

• These users are also known as SQL programmers as they can interact with the database directly using
SQL queries using query processors.

• Using SQL queries, they can fetch the data from the database. They can also delete, update or insert new
data into the database.

• For example: Data Engineers & Developers who are familiar with the database, directly access the database
using SQL queries rather than writing programming code for accessing the database again. Hence, they are
termed as sophisticated users.
Casual Users / Temporary Users

• Casual users also known as temporary users, are the type of database users in DBMS who
frequently or occasionally use the database services.

• Whenever these users try to access the database, they want all the information sorted in
place.

• Casual/Temporary users have little knowledge about DBMS and each time they try to
access the database, they require new information.

• For example: High-level management people are casual users who have little knowledge
about DBMS and hence, they can access the database to either fill in new information or
retrieve existing results.
DBMS architecture

• The DBMS design depends upon its architecture. The basic client/server architecture is
used to deal with a large number of PCs, web servers, database servers and other
components that are connected with networks.

• The client/server architecture consists of many PCs and a workstation which are connected
via the network.

• DBMS architecture depends upon how users are connected to the database to get their
request done.
Database architecture can be seen as a single tier or multi-tier. But logically, database
architecture is of two types like: 2-tier architecture and 3-tier architecture.
1-Tier Architecture

• In One-Tier Architecture the database is directly available to the user, the user can
directly sit on the DBMS and use it i.e.; the client, server, and the Database are all
present on the same machine.

• For Example- To learn SQL we set up an SQL server and the database on the local
system.

• This enables us to directly interact with the relational database and execute operations.

• The industry won’t use this architecture they logically go for 2-Tier and 3-Tier
Architecture.
2-Tier Architecture

• The two-tier architecture is similar to a basic client-server model.

• The application at the client end directly communicates with the database at the server side.

• APIs like ODBC and JDBC are used for this interaction. The server side is responsible for
providing query processing and transaction management functionalities.

• On the client side, the user interfaces and application programs are run. The application on the
client side establishes a connection with the server side in order to communicate with the
DBMS.

• An advantage of this type is that maintenance and understanding are easier, and compatible with
existing systems.

• However, this model gives poor performance when there are a large number of users.
3-Tier Architecture

• In this type, there is another layer between the client and the server. The client does not
directly communicate with the server.

• Instead, it interacts with an application server which further communicates with the
database system and then the query processing and transaction management takes place.

• This intermediate layer acts as a medium for the exchange of partially processed data
between server and client.

• This type of architecture is used in the case of large web applications.

Advantages:

• Enhanced scalability due to distributed deployment of application servers. Now,

individual connections need not be made between client and server.

• Data Integrity is maintained. Since there is a middle layer between the client and the
server, data corruption can be avoided/removed.

• Security is improved. This type of model prevents direct interaction of the client with
the server thereby reducing access to unauthorized data.

Disadvantages:

• Increased complexity of implementation and communication. It becomes difficult for this

sort of interaction to take place due to the presence of middle layers.
ER model
• ER model stands for an Entity-Relationship model.

• It is a high-level data model. This model is used to define the data elements and relationship
for a specified system.

• It develops a conceptual design for the database. It also develops a very simple and easy to
design view of data.

• In ER modeling, the database structure is portrayed as a diagram called an entity-relationship

diagram.

• For example, Suppose we design a school database. In this database, the student will be an
entity with attributes like address, name, id, age, etc. The address can be another entity with
attributes like city, street name, pin code, etc and there will be a relationship between them.
Component of ER Diagram
Entity:

• An entity may be any object, class, person or place. In the ER diagram, an entity can be
represented as rectangles.

• Consider an organization as an example- manager, product, employee, department etc. can

be taken as an entity.
a. Strong Entity:

• A strong entity is an entity that is not dependent on any other entity.

• It has a primary key, or a table includes a primary key.

• It is an entity that has its own existence and is independent.

• In the above example, the "Customer" is the

entity type with attributes such as ID,
Name, Gender, and Phone Number.
Customer is a strong entity type as it has a
unique ID for each customer.
b. Weak Entity

• An entity that depends on another entity called a weak entity.

• The weak entity doesn't contain any key attribute of its own.

• The weak entity is represented by a double rectangle.

• In the above example, "Address" is a weak

entity type with attributes such as House No.,
City, Location, and State.
Let us see an example of the relationship between the Strong entity type and weak entity type with the help of ER Diagram:
2. Attribute

• The attribute is used to describe the property of an entity. Ellipse is used to represent
an attribute.

• For example, id, age, contact number, name, etc. can be attributes of a student.
a. Key Attribute

• The key attribute is used to represent the main characteristics of an entity.

• It represents a primary key. The key attribute is represented by an ellipse with the text
underlined.
b. Composite Attribute

• An attribute that composed of many other attributes is known as a composite attribute.

• The composite attribute is represented by an ellipse, and those ellipses are connected with
an ellipse.
c. Multivalued Attribute

• An attribute can have more than one value.

• These attributes are known as a multivalued attribute. The double oval is used to
represent multivalued attribute.

• For example, a student can have more than one phone number.
d. Derived Attribute

• An attribute that can be derived from other attribute is known as a derived attribute.

• It can be represented by a dashed ellipse.

• For example, A person's age changes over time and can be derived from another
attribute like Date of birth.
3. Relationship
• A relationship is used to describe the relation between entities.

• Diamond or rhombus is used to represent the relationship.

Types of relationship are as follows:

a. One-to-One Relationship
When only one instance of an entity is associated with the relationship, then it is known as
one to one relationship
b. One-to-many relationship
• When only one instance of the entity on the left, and more than one instance of an entity
on the right associates with the relationship then this is known as a one-to-many
relationship.

• For example, Scientist can invent many inventions, but the invention is done by the only
specific scientist.
c. Many-to-one relationship
• When more than one instance of the entity on the left, and only one instance of an entity
on the right associates with the relationship then it is known as a many-to-one
relationship.

• For example, Student enrolls for only one course, but a course can have many students.
d. Many-to-many relationship
• When more than one instance of the entity on the left, and more than one instance of an
entity on the right associates with the relationship then it is known as a many-to-many
relationship.

• For example, Employee can assign by many projects and project can have many
employees.
Relational model:

• The relational Model was proposed by E.F. Codd to model data in the form of relations or tables.

• After designing the conceptual model of the Database using ER diagram, we need to convert the
conceptual model into a relational model which can be implemented using any RDBMS language
like Oracle SQL, MySQL, etc.

• The relational model represents how data is stored in Relational Databases.

• A relational database stores data in the form of relations (tables).

• Relational Model (RM) represents the database as a collection of relations.

• A relation is nothing but a table of values.

• Every row in the table represents a collection of related data values. These rows in the table denote
a real-world entity or relationship.
Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE, and
AGE shown in Table 1.
Relational Model Concepts in DBMS

1. Attribute: Each column in a Table. Attributes are the properties which define a relation. e.g., Student_Rollno,
NAME,etc.

2. Tables – In the Relational model the, relations are saved in the table format. It is stored along with its entities. A
table has two properties rows and columns. Rows represent records and columns represent attributes.

3. Tuple – It is nothing but a single row of a table, which contains a single record. The above relation contains 4
tuples, one of which is shown as:

4.Relation Schema: A relation schema represents the name of the relation with its attributes.

e.g.; STUDENT (ROLL_NO, NAME, ADDRESS, PHONE, and AGE) is the relation schema for STUDENT. If a
schema has more than 1 relation, it is called Relational Schema.
5.Degree: The total number of attributes which in the relation is called the degree of the relation.
The STUDENT relation defined above has degree 5.

6.Cardinality: The number of tuples in a relation is known as cardinality. The STUDENT relation defined
above has cardinality 4.

7.Column: The column represents the set of values for a specific attribute.

8.Relation instance – Relation instance is a finite set of tuples in the RDBMS system. Relation instances never
have duplicate tuples.

9.Relation key – Every row has one, two or multiple attributes, which is called relation key.

10.Attribute domain – Every attribute has some pre-defined value and scope which is known as attribute
domain

11. NULL Values: The value which is not known or unavailable is called a NULL value. It is represented by
blank space. e.g.; PHONE of STUDENT having ROLL_NO 4 is NULL.
Constraints Relational Model
• While designing the Relational Model, we define some conditions which must hold for data
present in the database are called Constraints.

• These constraints are checked before performing any operation (insertion, deletion, and
updation ) in the database.

• If there is a violation of any of the constraints, the operation will fail.

• There are many types of Integrity Constraints in DBMS. Constraints on the Relational database
management system is mostly divided into three main categories are:

1. Domain Constraints

2. Key Constraints

3. Referential Integrity Constraints

Domain Constraints

• These are attribute-level constraints.

• An attribute can only take values that lie inside the domain range.

• e.g; If a constraint AGE>0 is applied to STUDENT relation, inserting a negative value of

AGE will result in failure.
Key Integrity:

• Every relation in the database should have at least one set of attributes that defines a tuple
uniquely.

• Those set of attributes is called keys. e.g.; ROLL_NO in STUDENT is a key.

• No two students can have the same roll number. So a key has two properties:

It should be unique for all tuples.

It can’t have NULL values.

Referential Integrity Constraints

• When one attribute of a relation can only take values from another attribute of the same
relation or any other relation, it is called referential integrity.

• Referential Integrity constraints in DBMS are based on the concept of Foreign Keys.

• A foreign key is an important attribute of a relation which should be referred to in other

relationships.

• Referential integrity constraint state happens where relation refers to a key attribute of a
different or same relation. However, that key element must exist in the table.

• Example:
In the above example, we have 2 relations, Customer and Billing.
Tuple for CustomerID =1 is referenced twice in the relation Billing.
So we know CustomerName=Google has billing amount $300
Operations in Relational Model
Four basic update operations performed on relational database model are

Insert, update, delete and select.

• Insert is used to insert data into the relation

• Delete is used to delete tuples from the table.

• Modify allows you to change the values of some attributes in existing tuples.

• Select allows you to choose a specific range of data.

• Whenever one of these operations are applied, integrity constraints specified on the
relational database schema must never be violated.
Insert Operation
• The insert operation gives values of the attribute for a new tuple which should be inserted
into a relation.
Update Operation

You can see that in the below-given relation table CustomerName= ‘Apple’ is updated
from Inactive to Active.
Delete Operation

To specify deletion, a condition on the attributes of the relation selects the

tuple to be deleted.
• In the above-given example, CustomerName= “Apple” is deleted from the table.

• The Delete operation could violate referential integrity if the tuple which is deleted is
referenced by foreign keys from other tuples in the same database.
Select Operation

In the above-given example, CustomerName=”Amazon” is selected

Advantages of Relational Database Model
• Simplicity: A Relational data model in DBMS is simpler than the hierarchical and network model.

• Structural Independence: The relational database is only concerned with data and not with a structure.
This can improve the performance of the model.

• Easy to use: The Relational model in DBMS is easy as tables consisting of rows and columns are quite
natural and simple to understand

• Query capability: It makes possible for a high-level query language like SQL to avoid complex
database navigation.

• Data independence: The Structure of Relational database can be changed without having to change any
application.

• Scalable: Regarding a number of records, or rows, and the number of fields, a database should be
enlarged to enhance its usability.
Disadvantages of Relational Model
• Few relational databases have limits on field lengths which can’t be exceeded.

• Relational databases can sometimes become complex as the amount of data grows, and
the relations between pieces of data become more complicated.

• Complex relational database systems may lead to isolated databases where the
information cannot be shared from one system to another.
Types of keys in relational model

• Keys are one of the basic requirements of a relational database model.

• It is widely used to identify the tuples(rows) uniquely in the table.

• We also use keys to set up relations amongst various columns and tables of a relational database.

• Different Types of Keys in the Relational Model

1. Candidate Key

2. Primary Key

3. Super Key

4. Alternate Key

5. Foreign Key

6. Composite Key
.

1. Candidate Key: The minimal set of attributes that can uniquely identify a tuple is known as a candidate key.
For Example, STUD_NO in STUDENT relation.

• It is a minimal super key. It is a super key with no repeated data is called a candidate key.

• The minimal set of attributes that can uniquely identify a record.

• It must contain unique values.

• It can contain NULL values.

• Every table must have at least a single candidate key.

• A table can have multiple candidate keys but only one primary key (the primary key cannot have a NULL
value, so the candidate key with a NULL value can’t be the primary key).

• The value of the Candidate Key is unique and may be null for a tuple.

• There can be more than one candidate key in a relationship.

• Example: STUD_NO is the candidate key for relation STUDENT

2. Primary Key: There can be more than one candidate key in relation out of which one
can be chosen as the primary key. For Example, STUD_NO, as well as STUD_PHONE, are
candidate keys for relation STUDENT but STUD_NO can be chosen as the primary key
(only one out of many candidate keys).

• It is a unique key.

• It can identify only one tuple (a record) at a time.

• It has no duplicate values, it has unique values.

• It cannot be NULL.

• Primary keys are not necessarily to be a single column; more than one column can also be
a primary key for a table.
4. Alternate Key: The candidate key other than the primary key is called an alternate key.
• All the keys which are not primary keys are called alternate keys.

• It is a secondary key.

• It contains two or more fields to identify two or more records.

• These values are repeated.

• Eg:- SNAME, and ADDRESS is Alternate keys

5. Foreign Key: If an attribute can only take the values which are present as values of some other
attribute, it will be a foreign key to the attribute to which it refers.

The relation which is being referenced is called referenced relation and the corresponding attribute
is called referenced attribute the relation which refers to the referenced relation is called
referencing relation and the corresponding attribute is called referencing attribute.

The referenced attribute of the referenced relation should be the primary key to it.

• It is a key it acts as a primary key in one table and it acts as

secondary key in another table.

• It combines two or more relations (tables) at a time.

• They act as a cross-reference between the tables.

• For example, DNO is a primary key in the DEPT table and a non-key in EMP
• It may be worth noting that, unlike the Primary Key of any given relation, Foreign Key
can be NULL as well as may contain duplicate tuples i.e. it need not follow uniqueness
constraint.

• For Example, STUD_NO in the STUDENT_COURSE relation is not unique.

• It has been repeated for the first and third tuples. However, the STUD_NO in STUDENT
relation is a primary key and it needs to be always unique, and it cannot be null.
6. Composite Key: Sometimes, a table might not have a single column/attribute that
uniquely identifies all the records of a table.

To uniquely identify rows of a table, a combination of two or more columns/attributes can

be used.

It still can give duplicate values in rare cases. So, we need to find the optimal set of
attributes that can uniquely identify rows in a table.

• It acts as a primary key if there is no primary key in a table

• Two or more attributes are used together to make a composite key.

• Different combinations of attributes may give different accuracy in terms of identifying

the rows uniquely.
Anomalies in Relational model
• Anomalies in the relational model refer to inconsistencies or errors that can arise when
working with relational databases, specifically in the context of data insertion, deletion,
and modification.

• There are different types of anomalies that can occur in referencing and referenced
relations which can be discussed as:

• These anomalies can be categorized into three types:

1.Insertion Anomalies

2.Deletion Anomalies

3.Update Anomalies.
How Are Anomalies Caused in DBMS?

• Database anomalies are the faults in the database caused due to poor management of
storing everything in the flat database.

• It can be removed with the process of Normalization, which generally splits the database
which results in reducing the anomalies in the database.
• Insertion anomaly: If a tuple is inserted in referencing relation and referencing attribute
value is not present in referenced attribute, it will not allow insertion in referencing relation.

Example: If we try to insert a record in STUDENT_COURSE with STUD_NO =7, it will not
allow it.

• Deletion and Updation anomaly: If a tuple is deleted or updated from referenced relation
and the referenced attribute value is used by referencing attribute in referencing relation, it
will not allow deleting the tuple from referenced relation.

Example: If we want to update a record from STUDENT_COURSE with STUD_NO =1, We

have to update it in both rows of the table. If we try to delete a record from STUDENT with
STUD_NO =1, it will not allow it.

• To avoid this, the following can be used in query:

• ON DELETE/UPDATE SET NULL: If a tuple is deleted or updated from referenced
relation and the referenced attribute value is used by referencing attribute in referencing
relation, it will delete/update the tuple from referenced relation and set the value of
referencing attribute to NULL.

• ON DELETE/UPDATE CASCADE: If a tuple is deleted or updated from referenced

relation and the referenced attribute value is used by referencing attribute in referencing
relation, it will delete/update the tuple from referenced relation and referencing relation
as well.
How these Anomalies Occur

• Insertion Anomalies: These anomalies occur when it is not possible to insert data into a database
because the required fields are missing or because the data is incomplete. For example, if a database
requires that every record has a primary key, but no value is provided for a particular record, it
cannot be inserted into the database.

• Deletion anomalies: These anomalies occur when deleting a record from a database and can result in
the unintentional loss of data. For example, if a database contains information about customers and
orders, deleting a customer record may also delete all the orders associated with that customer.

• Update anomalies: These anomalies occur when modifying data in a database and can result in
inconsistencies or errors. For example, if a database contains information about employees and their
salaries, updating an employee’s salary in one record but not in all related records could lead to
incorrect calculations and reporting.