Unit II Relational Model

ER and EER diagrams: Components of ER model,

Conventions, Converting ER diagrams into tables
Relational Model: Basic concepts, Attributes and
Domains, Codd’s rules
Relational Integrity: Nulls, Entity, Referential
integrities, Enterprise constraints, Views, Schema
diagram
ER & EER
1. Entities are objects or concepts that represent important data. Also known
as strong entities or parent entities, these entities will often have weak
entities that depend on them.
2. Attributes are characteristics of an entity (i.e., many-to-many or
one-to-one). The primary key is crucial in establishing unique
identification and relational schema.
3. Relationships are associations between entities.
4. Weak entities depend on another entity.
5. Multivalued attributes are attributes that can have more than one value.
6. Weak relationships are the connections between a weak entity and its
parent.
Steps to Create an ERD (E-R Digram)

In a university, a Student enrolls in Courses. A student must be assigned to at

least one or more Courses. Each course is taught by a single Professor. To
maintain instruction quality, a Professor can deliver only one course.

Step 1) Entity Identification

We have three entities : Student, Course, Professor

Step 2) Relationship Identification

We have the following two relationships —

1. The student is assigned a course 2. Professor delivers a course

2.
3.
4.

Step 3) Cardinality Identification

For them problem statement we know that,

● A student can be assigned multiple courses

● A Professor can deliver only one course
Step 4) Identify Attributes

You need to study the files, forms, reports, data currently maintained by the organization
to identify attributes. You can also conduct interviews with various stakeholders to
identify entities. Initially, it's important to identify the attributes without mapping them to a
particular entity.

Once, you have a list of Attributes, you need to map them to the identified entities.
Ensure an attribute is to be paired with exactly one entity. If you think an attribute should
belong to more than one entity, use a modifier to make it unique.

Once the mapping is done, identify the primary Keys. If a unique key is not readily
available, create one.
 For Course Entity, attributes could be
Duration, Credits, Assignments, etc.
For the sake of ease we have
considered just one attribute.

Step 5) Create the ERD

A more modern representation of ERD Diagram

 Best Practices for Developing Effective ER Diagrams

● Eliminate any redundant entities or relationships

● You need to make sure that all your entities and relationships are properly labeled
● There may be various valid approaches to an ER diagram. You need to make sure
that the ER diagram supports all the data you need to store
● You should assure that each entity only appears a single time in the ER diagram
● Name every relationship, entity, and attribute are represented on your diagram
● Never connect relationships to each other
● You should use colors to highlight important portions of the ER diagram
Summary
● The ER model is a high-level data model diagram
● ER diagrams are a visual tool which is helpful to represent the ER model
● ER diagram displays the relationships of entity set stored in a database
● ER diagrams help you to define terms related to entity relationship modeling
● ER model is based on three basic concepts: Entities, Attributes & Relationships
● An entity can be place, person, object, event or a concept, which stores data in the
database
● Relationship is nothing but an association among two or more entities
● A weak entity is a type of entity which doesn't have its key attribute
● It is a single-valued property of either an entity-type or a relationship-type
● It helps you to defines the numerical attributes of the relationship between two
entities or entity sets
● ER- Diagram is a visual representation of data that describe how data is related to
each other
● While Drawing ER diagram you need to make sure all your entities and relationships
are properly labeled.
Generalization
Generalization is a process in which the common attributes of more than one entities form a
new entity. This newly formed entity is called generalized entity.
Generalization Example: Suppose 2 entities
Student and Teacher.
Attributes of Entity Student are: Name, Address & Grade
Attributes of Entity Teacher are: Name, Address & Salary
The ER diagram before generalization looks like this:
These two entities have two common attributes:
Name and Address,
we can make a generalized entity with these common attributes.
The ER model after generalization
A new generalized entity Person and this entity has the common attributes of both the
entities. Student and Teacher only has the specialized attributes Grade and Salary
respectively and their common attributes (Name & Address) are now associated with a
new entity Person which is in the relationship with both the entities (Student &
Teacher).
Note: 1. Generalization uses bottom-up approach where two or more lower level entities
combine together to form a higher level new entity. 2. The new generalized entity can
further combine together with lower level entity to create a further higher level
generalized entity.
Specialization Example
“Employee” - “Technician”, “Engineer” & “Accountant”

All of these are just an employee of a company, however their role is completely different
and they have few different attributes. Just for the example, I have shown that
Technician handles service requests, Engineer works on a project and Accountant
handles the credit & debit details. All of these three employee types have few attributes
common such as name & salary which we had left associated with the parent entity
“Employee” as shown in the diagram.
Aggregation
Aggregation is a process in which a single entity alone is not
able to make sense in a relationship so the relationship
of two entities acts as one entity.
A manager not only manages the employee
working under them but he has to manage the project as well.
In such scenario if entity “Manager” makes a “manages”
relationship with either “Employee” or “Project”
entity alone then it will not make any sense because
he has to manage both. In these cases the relationship
of two entities acts as one entity. In this, the relationship
“Works-On” between “Employee” & “Project” acts as one entity
that has a relationship “Manages” with the entity “Manager”.
Strong and Weak Entities
Strong entity
● Strong Entity is independent of any other entity in the schema

Example – A student entity can exist without needing any other entity in the schema or a course entity can exist without needing any other entity in the
schema

● A Strong entity is nothing but an entity set having a primary key attribute or a table that consists of a primary key column

Representation

○ The strong entity is represented by a single rectangle.

○ The relationship between two strong entities is represented by a single diamond.

Examples for the strong entity

○ Consider the ER diagram which consists of two entities student and course

○ Student entity is a strong entity because it consists of a primary key called student id which is enough for accessing each record

uniquely

○ In the same way, the course entity contains of course ID attribute which is capable of uniquely accessing each row.
Weak entity
● A weak entity is an entity set that does not have sufficient attributes for Unique Identification of its records.

Example 1 – A loan entity can not be created for a customer if the customer doesn’t exist

Example 2 – A dependents list entity can not be created if the employee doesn’t exist

● Simply a weak entity is nothing but an entity that does not have a primary key attribute

● It contains a partial key called a discriminator which helps in identifying a group of entities from the entity set

● A discriminator is represented by underlining with a dashed line

Representation

○ A double rectangle is used for representing a weak entity set

○ The double diamond symbol is used for representing the relationship between a strong entity and a weak entity which is known as

identifying relationship
Example for weak entity
○ In the ER diagram, we have two entities Employee and Dependents.

○ Employee is a strong entity because it has a primary key attribute called Employee number (Employee_No) which is capable of

uniquely identifying all the employee.

 Strong entity Weak entity

Strong entity always has a primary key. It will not have a primary key but it has partial discriminator
key.

It is not dependent on any other entity. Weak entity is dependent on the strong entity.

Represented by a single rectangle. Represented by double rectangle.

Relationship between two strong entities is Relationship between a strong entity and the weak entity is
represented by a single diamond. represented by double Diamond.

A strong entity may or may not have total It has always total participation.
participation.
What is an EER diagram?

Enhanced entity-relationship (EER) diagrams are a more expansive version of ER diagrams.

An EER diagram provides you with all the elements of an ER diagram while adding:

● Attribute or relationship inheritances

● Category or union types
● Specialization and generalization
● Subclasses and superclasses

Overall, an EER diagram builds off of an ER diagram by including elements that allow for aggregation,
generalization, and specialization.
Keys - A key is a way to categorize attributes in an E-R diagram
 EER Diagram
An EER diagram provides you with all the elements of an ER diagram while adding:

● Attribute or relationship inheritances

● Category or union types
● Specialization and generalization
● Subclasses and superclasses

Generalization and specialization act as opposites of one another. Generalization combines lower-level
entities into one of a higher level. Meanwhile, specialization divides high-level entities into lower levels.
With aggregation, two entities are treated as a single one.
Types of Keys
1. Candidate Key
2. Primary Key
3. Foreign Key
4. Super Key
5. Alternate Key
6. Composite Key
7. Unique Key
1. Primary Key

The primary key refers to a column or a set of columns of a table that helps us
identify all the records uniquely present in that table. A table can consist of just one
primary key. Also, this primary key cannot consist of the same values
reappearing/repeating for any of its rows. All the values of a primary key have to
be different, and there should be no repetitions.

The PK (PRIMARY KEY) constraint that we put on a column/set of columns won’t

allow these to have a null value or a duplicate. Any table can consist of only a
single primary key constraint. A foreign key (explained below) that refers to it can
never change the values present in the primary key.
2. Super Key

A super key refers to the set of all those keys that help us uniquely identify
all the rows present in a table. It means that all of these columns present in
a table that can identify the columns of that table uniquely act as the super
keys.

A super key is a candidate key’s superset (candidate key has been

explained below). We need to pick the primary key of any table from the
super key’s set so as to make it the table’s identity attribute.
3. Candidate Key
The candidate keys refer to those attributes that identify rows uniquely in a table. In a
table, we select the primary key from a candidate key. Thus, a candidate key has
similar properties as that of the primary keys that we have explained above. In a
table, there can be multiple candidate keys.

4. Alternate Key
As we have stated above, any table can consist of multiple choices for the primary
key. But, it can only choose one. Thus, all those keys that did not become a primary
key are known as alternate keys.
5. Foreign Key

We use a foreign key to establish relationships between two available tables. The foreign key
would require every value present in a column/set of columns to match the referential table’s
primary key. A foreign key helps us to maintain data as well as referential integrity.

6. Composite Key

The composite key refers to a set of multiple attributes that help us uniquely identify every
tuple present in a table. The attributes present in a set may not be unique whenever we
consider them separately. Thus, when we take them all together, it will ensure total
uniqueness.
7. Unique Key

A unique key refers to a column/a set of columns that identify every record uniquely
in a table. All the values in this key would have to be unique. Remember that a
unique key is different from a primary key. It is because it is only capable of having
one null value. A primary key, on the other hand, cannot have a null value.
Key Type Definition Example

Primary Key Uniquely identifies a record, Employee ID, Student Roll

no duplicates. Number

Super Key A combination of attributes that Employee ID + Name

can uniquely identify records.

Candidate Key A minimal super key that can act Employee ID, Email Address
as a primary key.

Alternate Key A candidate key is not chosen as Email Address (if Employee ID is
the primary key. primary)

Foreign Key Links tables by referencing a Department ID in Employee Table

primary key from another table.

Composite Key Multiple columns are used Course ID + Student ID

together to identify records
uniquely.

Unique Key Ensures uniqueness in a column Email Address, Phone Number

but allows one null value.
1. Primary Key
Properties of a Primary Key

● The Primary Key field shouldn’t be left NULL; the Primary Key column must contain
a value.
● In that column, no two rows in the table may contain identical values.
● If a foreign key in a DBMS refers to the primary Key, no value may be altered or
modified in this primary key column

In this example, the student ID is the primary key.

StudID Roll No First Name Last Name Email

1 11 Tom Prince [email protected]

2 12 Nick Wright [email protected]

3 13 Dana Natan [email protected]

2. Candidate Key
Candidate keys play a vital role in upholding the integrity and consistency of a database.
Candidate keys enforce relationships between tables, ensuring data integrity and
maintaining overall database consistency.
Properties of a candidate key
● It must have distinct values.
● A candidate key in SQL can have a variety of qualities, but it must not include null
values and must have at least the bare minimum of fields to guarantee uniqueness.
● Create a unique identifier for each table record.
Differences Between Primary and Candidate keys
Primary Key Candidate Key

A primary key is a column that allows each entry in a A column that can uniquely identify each record in a
database to be identified only once. It is selected as database is sometimes referred to as a candidate key.
the primary key for the table from the list of potential It might be used as the primary key.
keys.

A primary key is a unique identifier for a record in a A candidate key is also a unique identifier for a record
database table. in a database table.

There can be only one primary key in a table. There can be multiple candidate keys in a table.

The primary key enforces entity integrity, Candidate keys are potential candidates

The primary key is chosen by the database designer or A candidate key can be chosen from the set of
administrator. candidate keys for a table.
Importance of candidate keys in DBMS
These keys in DBMS are essential for preserving a database’s consistency and integrity. They are used to enforce connections
between tables and guarantee that each row in a database is distinct and can be recognized independently.
3. Super Key
The collection of all keys enabling us to recognize every row in the table is a super key.
This type of key in DBMS specifies that all the table columns that may identify the
columns uniquely function as the super keys.
Properties of a super key
● A super key must ensure that each record in a table is unique.
● Nevertheless, the minimal collection of characteristics that can guarantee
uniqueness should be a super key.
● Multiple subsets that are likewise regarded as super keys can exist for a super key.
Patients Table

Patient ID Patient Name Sex Age MedInsuranceNo AadharNo

01 Sheela F 23 Med0291 839292319012

02 Rehan M 21 Med8421 123456789012

03 Anay M 56 Med4203 848298469201

04 Mahira F 42 Med4792 724723021922

05 Nishant M 12 Med8419 472038311099

Checkup Details Table

Patient ID AnnualCheckupMonth Fees

03 Feb2022 6700

04 Apr2022 8900

03 Feb2022 6700

04 Apr2022 8900
Super Key

Super Key is a set of attributes that can uniquely identify a table. A single table can have multiple super keys. A
candidate key, primary key and a unique key can be a super key, but the reverse does not hold true.

Example:

In our above example we have chosen the PatientID, MedInsuranceNo and Aadhar No to uniquely identify tuples. So
the super key set will be as follows:

{PatientID}

{MedInsuranceNo}

{AadharNo}

{PatientID, MedInsuranceNo}

{PatientID, AadharNo}

{MedInsuranceNo, AadharNo}

{PatientID, MedInsuranceNo, AadharNo}

4. Foreign Key
To create connections between two accessible tables, we employ a foreign key. Every
value in a column or collection must match the primary key in the referential table for the
foreign key to function. We can preserve referential integrity and data integrity with the
aid of a foreign key.
Primary Key is a set of attributes that can take values referenced to the values of
another table.
Properties of a foreign key
● It is a key that serves as both a secondary key and a primary key in two different
tables.
● At any given time, it combines two or more relations.
● They serve as cross-references for the tables.
OrderNo EmployeeNo CustomerNo Supplier Price Item

1 1 42 Harrison $235 Desk

2 4 1 Ford $234 Chair

3 1 68 Harrison $415 Table

4 2 112 Ford $350 Lamp

5 3 42 Ford $234 Chair

6 2 112 Ford $350 Lamp

7 2 42 Harrison $235 Desk

 SsecurityNo EmployeeNo FirstName LastName DateOfBirth DateEmployed

AF-23432334 1 Manny Tomanny 12 Apr 1966 01 May 1999

DQ-65444444 2 Rosanne Kolumns 21 Mar 1977 01 Jan 2000

GF-54354543 3 Cas Kade 01 May 1977 01 Apr 2002

JK-34333432 4 Norma Lyzation 03 Apr 1966 01 Apr 2002

VB-48565444 5 Juan Tomani 12 Apr 1966 01 Apr 2002

FG-23566553 6 Del Eats 01 May 1967 01 May 2004

The Social Security number is actually the primary key of the table, but we also issue each person an employee
number that is unique. Under these circumstances, ORDERS.EmployeeNo can be a foreign key pointing to
EMPLOYEES.EmployeeNo, even though the latter column is not a primary key. So, the actual rule is slightly more
5. Alternate key
An alternate key is essentially all the keys in a data table that are not the primary key.
Remember that only one key can be set as the primary key. Once the primary key is
established, all others are now considered alternate keys. In the example above, the
Social Security number is the identified primary key and all other keys are alternate.
6. Surrogate key

A surrogate key is an artificial key that is created strictly for the purposes of data analysis. It's sometimes also called a

synthetic key or a pseudokey because it isn't derived from any application data. Instead, it is used to identify each

record in the database.

7. Composite key

A composite key is a key that has more than one attribute. Any super key, primary key or candidate key can be a

composite key as long as it meets the requirement of having more than one attribute. By combining two or more

columns in a table into a key, it guarantees that the key refers to a specific row of data. This is the primary use of
8. Compound key

A compound key is a particular type of composite key in which each attribute is a

foreign key -- for example, a table tracking student enrollment. Tables for student
ID and course ID may already exist, with both combining to make the compound
key for enrollment.
https://www.upgrad.com/blog/types-of-keys-in-dbms/
ER diagram Examples

Construct an E-R diagram for a hospital with a set of patients and a set of medical
doctors. Associate with each patient a log of the various tests and examinations
conducted.
Construct an ER Diagram for Car Insurance Company whose customers own one
or more cars each. Each car has associated with it zero to any number of
recorded accidents.
Design an ER Diagram for keeping track of the exploits of your favorite sports
team. You should store the matches played, the scores in each match, the players
in each match and individual player statistics for each match. Summary statistics
should be modeled as derived attributes.
ER Diagram Assignment

College offers course in different stream. In each stream, various students are
enrolled. Each stream is divided into 8 semesters and each semester is divided
into two sections. In each semester various subjects are taught. One subject is
taught by at most one lecturer and one lecturer can teach more than one subjects.
ER Diagram Assignment
A publishing company produces books on various subjects. The books are written
by authors who specialize in one particular subject. The company employs editors
who, not necessarily being specialists in a particular area, each take sole
responsibility for editing one or more book publications. Every book require some
items for publication. These items supplied by suppliers. One supplier can supply
many items. Shop owner buys books from the publisher. Shop owner can buy
many books but one book can be bought by one shop owner only. Books are
uniquely identified by Bookid.
 ER Diagram to Tables
Following rules are used for converting an ER diagram into the tables-
Rule-01: For Strong Entity Set With Only Simple Attributes-
A strong entity set with only simple attributes will require only one table in relational
model.
● Attributes of the table will be the attributes of the entity set.
● The primary key of the table will be the key attribute of the entity set.
Schema : Student ( Roll_no , Name , Sex )
Roll_no Name Sex
Rule-02: For Strong Entity Set With Composite Attributes-
● A strong entity set with any number of composite attributes will require only
one table in relational model.
● While conversion, simple attributes of the composite attributes are taken into
account and not the composite attribute itself.
Roll_no First_name Last_name House_no Street City

Schema : Student ( Roll_no , First_name , Last_name , House_no , Street , City )

Rule-03: For Strong Entity Set With Multi Valued Attributes-

A strong entity set with any number of multi valued attributes will require two tables
in relational model.

● One table will contain all the simple attributes with the primary key.
● Other table will contain the primary key and all the multi valued attributes.

Roll_no City

Roll_no Mobile_no
Rule-04: Translating Relationship Set into a Table-
A relationship set will require one table in the relational model.
Attributes of the table are-
● Primary key attributes of the participating entity sets
● Its own descriptive attributes if any.
Set of non-descriptive attributes will be the primary key.
Emp_no Dept_id since Schema : Works in ( Emp_no , Dept_id , since )

NOTE-

If we consider the overall ER diagram, three tables will be required in relational model-

● One table for the entity set “Employee”

● One table for the entity set “Department”
● One table for the relationship set “Works in”
Rule-05: For Binary Relationships With Cardinality Ratios-

The following four cases are possible-

Case-01: Binary relationship with cardinality ratio m:n

Case-02: Binary relationship with cardinality ratio 1:n

Case-03: Binary relationship with cardinality ratio m:1

Case-04: Binary relationship with cardinality ratio 1:1

Case-01: For Binary Relationship With Cardinality Ratio m:n
three tables will be required[1]1. A ( a1 , a2 ) 2. R ( a1 , b1) 3. B ( b1 , b2 )

Case-02: For Binary Relationship With Cardinality Ratio 1:n

Here, two tables will be required A ( a1, a2 ) 2. BR ( a1 , b1 , b2 )
NOTE- The combined table will be drawn for entity set B and relationship set R.

Case-03: For Binary Relationship With Cardinality Ratio m:1

Here, two tables will be required AR ( a1 , a2 , b1 ) 2. B ( b1 , b2 )
NOTE- Combined table will be drawn for the entity set A and relationship set R.

Case-04: For Binary Relationship With Cardinality Ratio 1:1

Here, two tables will be required. Either combine ‘R’ with ‘A’ or ‘B’
Way-01: AR ( a1 , a2 , b1 ) 2. B ( b1, b2 )

Way-02: A ( a1 , a2 ) 2. BR ( a1 , b1 , b2 )
Rule-06: Convert Binary Relationship With Both Cardinality Constraints and
Participation Constraints into the table.
The total participation constraint acquires NOT NULL constraint foreign key.

Case-01: In Binary Relationship (Cardinality Constraint and Total Participation Constraint) From One Side (cardinality ratio
= 1 : n)
FInd the minimum number of tables required for the
following ER diagram in relational model.
Codd’s Rules
Codd's 12 rules are used to determine whether a relational database management
system is a true relational database management system or not.

Codd's 12 rules form the foundation for evaluating a true relational database
management system.

These rules ensure consistency, accessibility, and integrity of data within the database.

Compliance with these rules guarantees the reliability and effectiveness of the database
management system.

Understanding and implementing Codd's rules are crucial for database designers and
administrators to build robust and efficient relational databases.
Rule 0: The Foundation Rule
For a system to be qualified as a relational database management system, it must be able to manage databases
entirely through its relational capabilities.

Rule 1: The Information Rule

The information in a relational database must be stored in columns or rows of a table, i.e., a cell.

Rule 2: The Guaranteed Access Rule

Each and every datum in a relational database must be logically accessible using the combination of the table
name, primary key value, and column name.

Rule 3: Systematic Treatment Of NULL Values

NULL values are fully supported in a relational database and represent missing information or inapplicable
information in a systematic way, independent of the data type. NULL values are different from empty strings, blank
spaces, and 0

Rule 4: Active/Dynamic Online Catalog Based On The Relational Model

Database Description (Catalog) of a complete database must be stored online. The rules of the rest of the
database must also apply to the Catalog. The query language used to query the database should be used for the
catalog also.
Rule 5: The Comprehensive Data Sublanguage Rule
Relational systems can support multiple languages and different modes of using terminals, such as
fill-in-the-blanks mode. However, there must be at least one language whose statements are expressible
according to a well-defined syntax.

Rule 6: The View Updating Rule

Theoretically, updatable views are also practically updatable by the database system.

Rule 7: High-Level Insert, Update & Delete Rule

The database system must follow high-level relational operations such as insertion, updation, and deletion at each
level or row by row. It also supports the union, intersection, and subtraction operations in database systems.

Rule 8: Physical Data Independence

The working of a database system should be independent of the physical storage of its data. If a file is modified
(renamed or moved to another location), it should not interfere with the working of the system.

Rule 9: Logical Data Independence

If there is a change in the logical structure (table structure) of the database, the user view of the data must not
change.
Say a table is partitioned into two tables, the new view should give the result as the join of the two tables.
Rule 10: Integrity Independence
Integrity constraints specific to a particular relational database must be defined in the relational data sub-language
and stored in the catalog and not in the application.

Rule 11: Distribution Independence

A database should work properly regardless of its distribution across a network. The end-user should not be able
to see that the data is distributed over many locations, they should always get the impression that the data is
located at a single site only.

Rule 12: The Non-subversion Rule

If a relational system allows low-level access, that low cannot be used to subvert or bypass the integrity rules to
modify the data. This can be achieved with some sort of looking or encryption.
What is Integrity Constraints in DBMS?
● Integrity constraints maintainins the quality and integrity of information in a
database management system (DBMS).
● These constraints act as a set of rules that ensure data insertion, updating,
and other processes are performed in a way that does not compromise the
integrity of the data.
● Example -
○ Bank Customer age should not be less than 18
○ No two customers can have same customer ID
○ One customer can have only 1 savings account
● Incorrect data
○ Employee assigned with non-existing department
○ Inconsistency is introduced due to system failures.
Types of Relational Integrity
Domain Constraint
1. Required data in domain Integrity
a. Some attributes are not allowed NULL values – NULL means unknown,
unassigned or missing attribute values.
b. Student Name - should not be NULL
c. Create table Student (Name char(10) NOT NULL);
2. Simple validity checking in Domain Integrity
a. Prevent users from inserting other than allowed data values in a column.
b. Roll Number- integer and greater than 1
c. Create table Student (Age Int CHECK(Age>18));
3. Domain constraints define the permissible set of values for a column,
ensuring that data entered into the database is valid. This constraint restricts
the types and formats of data, ensuring that only meaningful and acceptable
values are stored.
Entity Constraint
Entity integrity ensures that each row in a table can be uniquely identified by a primary key.

This constraint prevents any row from having duplicate or null values in the primary key column,
which is essential for data accuracy and integrity.

Example: Employee Information

Employee_ID Name Dept Salary

101 Amit Gupta HR 55000

102 Sanya Reddy IT 60000

103 Rajesh Kumar Finance 65000

Practical Application:

In the Employee_ID column, an entity integrity constraint ensures that each employee has a unique
identifier. This prevents two employees from sharing the same Employee_ID, which could lead to data
confusion.

Entity integrity is crucial in scenarios like payroll processing, where each employee must be easily
distinguishable by their unique ID.
Referential Integrity Constraint
Referential integrity constraints manage relationships between tables using foreign keys. These
constraints ensure that a foreign key value in one table matches a primary key value in another
table. This maintains consistent relationships between tables and prevents DBMS anomalies.

Example: Employee and Department

Employee_ID Name Dept_ID Dept_ID Dept_Name

101 Amit Gupta D01 D01 Human Resources

102 Sanya Reddy D02 D02 Information Technology

103 Rajesh Kumar D01

Practical Application:
The Dept_ID in the Employee table is a foreign key that references the Dept_ID in the
Department table. Referential integrity ensures that every Dept_ID in the Employee table must
exist in the Department table.

This prevents situations where an employee is assigned to a non-existent department. It’s

especially useful in HR systems, where the relationships between employees and departments are
vital for organizational structure.
Key Constraint
Key constraints ensure that no two rows in a table have duplicate values in the primary or unique key columns.
This is critical for preventing redundancy in your database and ensuring data integrity.

Practical Application:
Roll_No Name Course The Roll_No column is a primary key, ensuring that every
student has a unique registration number. This prevents two
1001 Aarav Sharma Math students from being assigned the same roll number, which
could create confusion during exams or grades tracking.
1002 Priya Patel Science
Key constraints prevent duplication, keeping your student
1003 Rohan Verma English database accurate and reliable.
 Enterprise Constraints

Enterprise constraints – sometimes referred to as semantic constraints – are additional

rules specified by users or database administrators and can be based on multiple
tables.

● A class can have a maximum of 30 students.

● A teacher can teach a maximum of four classes per semester.
● An employee cannot take part in more than five projects.
● The salary of an employee cannot exceed the salary of the employee’s manager.
Business Rules
Business rules are obtained from users when gathering requirements. The
requirements-gathering process is very important, and its results should be verified by
the user before the database design is built. If the business rules are incorrect, the
design will be incorrect, and ultimately the application built will not function as
expected by the users.
Some examples of business rules are:
A teacher can teach many students.
A class can have a maximum of 35 students.
A course can be taught many times, but by only one instructor.
Not all teachers teach classes.
Schema Diagrams and Views
A schema is a namespace within a database where tables, functions, views, etc.
reside. A view is a pre-generated query, useful for clarity and ease-of-use during
advanced query composition.

A "schema diagram" is a visual representation of the structure of a database,

showing the tables, columns, and relationships between them, while a "view" is a
virtual table derived from the base tables, providing a specific subset of data
based on a defined query, essentially acting as a customized perspective on the
database for users with specific access needs.
Schema diagram:
Represents the overall logical design of a database, including all tables, columns, data types, primary keys,
foreign keys, and relationships between tables.
Often depicted using an entity-relationship diagram (ERD).
Useful for understanding the data organization and relationships within a database.

View:
A virtual table that does not physically store data but rather generates data on-demand based on a SQL query.
Allows users to see a customized subset of data from the base tables, potentially hiding sensitive information
or simplifying complex data access.
Can be used to restrict access to specific data based on user permissions.
A schema can be defined as the design of a
database. The overall description of the database
is called the database schema. It can be
categorized into three parts. These are:

Physical Schema

Logical Schema

View Schema
Example 1: Online Shopping System

Entities: Customer, Order, Product, Category, OrderDetail.

Relationships: Customer 'places' Order, Order 'contains' Product,

Product 'belongs to' Category, OrderDetail 'connects' Order and
Product.
In this schema:

● The Customer table represents the customers who place orders.

● The Category table represents the categories to which products belong.
● The Product table represents the products that can be ordered. Each product
belongs to a category, represented by the foreign key CategoryID.
● The Order table represents the orders placed by customers. Each order is placed
by a customer, who is represented by the foreign key CustomerID.
● The OrderDetail table represents the many-to-many relationship between orders
and products. Each row in this table represents a product contained in an order
and the quantity of that product in the order.

Description: This diagram models an online shopping system. Customers place orders,
each of which contains one or more products. Products belong to categories for easy
classification and search.
Example 2: University Database
Entities: Student, Course, Professor, Department, Enrollment.
Relationships: Student 'enrolls in' Course, Course 'taught by'
Professor, Professor 'works in' Department.
In this schema:
The Student table represents the students who enroll in courses.
The Department table represents the departments in which
professors work.
The Professor table represents the professors who teach courses.
Each professor works in a department, which is represented by
the foreign key DepartmentID.
The Course table represents the courses in which students enroll.
Each course is taught by a professor, who is represented by the
foreign key ProfessorID.
The Enrollment table represents the many-to-many relationship
between students and courses. Each row in this table represents a
student enrolled in a course and the grade they received in that
course.
Description: This diagram models a university database.
Students enroll in courses, which are taught by professors.
Professors work in departments, indicating their specialties.
Example 3: E-Learning Platform
Entities: Student, Course, Instructor, Assignment, Enrollment.
Relationships: Student 'takes' Course, Course 'taught by' Instructor,
Course 'has' Assignment, Enrollment "has" Course and Student.
In this schema:
The Student table represents the students who take courses.
The Instructor table represents the instructors who teach courses.
The Course table represents the courses that students can take. Each
course is taught by an instructor, who is represented by the foreign
key InstructorID.
The Enrollment table represents the many-to-many relationship
between students and courses. Each row in this table represents a
student taking a course.
The Assignment table represents the assignments for each course.
Each assignment is associated with a course, which is represented by
the foreign key CourseID. The DueDate field represents the due date
for the assignment.
Description: This diagram models an e-learning platform. Students
take courses, which are taught by instructors. Each course may have
one or more assignments.
Problem Statement:
University Database Management System creates, manages and
performs all the activities related to the database of a given
university. The database consists of information about the
university, colleges, students faculties, academic and research
Programs. The main aim of this project is to manage the
database in such a way that information about academic and
research activities can be retrieved easily, efficiently and
accurately