Entity-Relationship (ER) model.

(Unit 2)
An Entity-Relationship (ER) model is a conceptual framework used in
database design to represent the data and its relationships within a
system. It helps in defining the structure of a database by identifying the
entities, attributes, and the relationships between entities. Here's a
breakdown of the key components and concepts of an ER model:

1. Entities

Entities are objects or things in the real world that have a distinct
existence. They can be physical objects like "Employee" or "Product," or
they can be more abstract like "Project" or "Department." In the ER model,
entities are represented as rectangles.

Example: In a university database, entities might include Student, Course,

and Professor.

2. Attributes

Attributes are properties or characteristics of an entity. They help describe

the entity in more detail. For instance, a Student entity might have
attributes such as StudentID, Name, DateOfBirth, and Major.

Example: The Course entity might have attributes like CourseID, CourseName,
and Credits.

3. Relationships

Relationships represent the associations between entities. They show how

entities interact or are related to each other. Relationships are depicted as
diamonds in the ER diagram.

Example: A Student might be enrolled in a Course, so there would be a

relationship called EnrolledIn between the Student and Course entities.

4. Entities and Relationships Cardinality

Cardinality specifies the number of instances of one entity that can or

must be associated with each instance of another entity. The main types
of cardinality are:

 One-to-One (1:1): An entity in A can be associated with at most

one entity in B and vice versa.
 One-to-Many (1

): An entity in A can be associated with many entities in B, but an

entity in B can be associated with at most one entity in A.
  Many-to-Many (M

): An entity in A can be associated with many entities in B, and an

entity in B can be associated with many entities in A.

Example: A Professor might teach many Courses (1

), and a Course can be taught by many Professors (M

).

5. ER Diagram Components

 Entities: Rectangles.
 Attributes: Ovals connected to their respective entities.
 Relationships: Diamonds connected to the entities involved.
 Cardinality: Lines and symbols (such as 1, N, or M) indicating the
type of relationship.

6. Keys

 Primary Key: A unique identifier for each entity instance. For

example, StudentID for a Student.
 Foreign Key: An attribute that creates a link between two entities.
For example, CourseID in the Enrollment relationship might act as a
foreign key referring to Course.

Example ER Diagram

Here’s a simple example for a university database:

 Entities:
o Student (StudentID, Name, DateOfBirth)
o Course (CourseID, CourseName, Credits)
o Professor (ProfessorID, Name, Department)
 Relationships:
o Enrolls (StudentID, CourseID) showing that a student enrolls in a
course.
o Teaches (ProfessorID, CourseID) showing that a professor teaches a
course.

An ER diagram helps visualize how these entities interact and how data
should be structured. It serves as a blueprint for creating a database
schema in a relational database management system (DBMS).

EER model
An Enhanced Entity-Relationship (EER) model extends the traditional
Entity-Relationship (ER) model by incorporating additional concepts and
features that allow for more complex and detailed database design. The
EER model introduces advanced constructs that address certain
limitations of the basic ER model, making it suitable for modeling more
sophisticated databases. Here’s a look at the key concepts of the EER
model:

Key Concepts of the EER Model

1. Subclasses and Superclasses (Inheritance)

o Subclass: Represents a subset of a superclass with additional
attributes or relationships. Subclasses inherit attributes and
relationships from their superclass.
o Superclass: Represents a general entity type that can be
divided into multiple subclasses.
o Generalization: The process of defining a superclass from
multiple subclasses.
o Specialization: The process of defining subclasses from a
superclass.

Example: Consider a Person superclass with subclasses Student and

Professor. Both subclasses inherit common attributes like Name and
DateOfBirth from Person but may have additional attributes like
StudentID or ProfessorID.

2. Aggregation
o Aggregation is a higher-level abstraction that represents a
relationship between a whole and its parts. It helps to simplify
complex ER diagrams by grouping related entities and their
relationships into a single higher-level entity.

Example: An Order might be an aggregate entity that includes

OrderLine and Customer, representing a complex relationship between
these components.

3. Categories (Union Types)

o Categories represent a set of entities that can belong to
multiple distinct entities or classes. They are used to model
situations where an entity can be a member of more than one
category, reflecting a union of several entity types.

Example: A Vehicle category might include Car, Truck, and Motorcycle,

where each type of vehicle can be considered a member of the
Vehicle category.

4. Multi-valued Attributes
 o Multi-valued attributes are attributes that can hold multiple
values for a single entity instance. They are represented by
double ovals in an EER diagram.

Example: A Person entity might have a multi-valued attribute

PhoneNumbers, where a person can have multiple phone numbers.

5. Derived Attributes
o Derived attributes are attributes that can be calculated from
other attributes. They are usually represented by a dashed
oval in an EER diagram.

Example: An Age attribute derived from a DateOfBirth attribute in a

Person entity.

6. Relationship Types and Cardinalities

o EER models refine the cardinality and participation constraints
of relationships, providing more detail about how entities
participate in relationships.

Example: A Project might be associated with multiple Employees, and

each Employee might work on multiple Projects, with cardinalities
defined for these relationships.

Example EER Diagram Components

 Entities and Attributes: As in the ER model, but with the added

complexity of subclasses and multi-valued attributes.
 Relationships: More detailed with support for aggregation and
complex constraints.
 Generalization/Specialization: Represented with a triangle or
another notation indicating inheritance and subclass relationships.
 Aggregation: Represented by a higher-level entity that groups
other entities and their relationships.
 Categories: Represented by a circle or oval that encompasses
multiple related entities.

Example

Let's consider a simplified university database using the EER model:

 Superclass: Person with attributes Name, DateOfBirth.

o Subclasses:
 Student with additional attributes StudentID, Major.
 Professor with additional attributes ProfessorID, Department.
  Aggregation: An AcademicRecord might aggregate the Student and
Course entities, representing the relationship between students and
the courses they take.
 Category: Vehicle as a category could include Car, Truck, and
Motorcycle, each having distinct attributes but sharing some common
characteristics.

The EER model helps to create a more comprehensive and detailed

database design by capturing more complex real-world scenarios and
relationships. It enhances the basic ER model by adding these advanced
constructs, making it easier to model and manage complex data
relationships.

CODD Rules

Codd’s Rules are a set of thirteen principles proposed by Edgar F. Codd,

the inventor of the relational database model, to define what is required
for a database management system (DBMS) to be considered truly
relational. These rules aim to establish a standard for relational database
systems and ensure that they adhere to the principles of relational theory.
Here's a summary of Codd's twelve rules (there's a common
misunderstanding that there are thirteen; the original list includes twelve
rules):

1. Information Rule

 All information in a relational database is represented explicitly at

the logical level in tables (relations) and is represented in a
consistent manner.

Example: Data should be stored in tables with rows and columns, where
each column represents an attribute and each row represents a record.

2. Guaranteed Access Rule

 Each datum (atomic value) in a relational database must be logically

accessible by using a combination of table name, primary key, and
column name.

Example: You should be able to access any piece of data in the database
using a straightforward query based on table names and column names.

3. Systematic Treatment of Null Values

  Null values (representing missing or inapplicable information) must
be uniformly handled and distinguished from other values like zero
or an empty string.

Example: A column for PhoneNumber might have a null value if the phone
number is not provided, and this should be treated distinctly from an
empty string.

4. Dynamic On-Line Catalog Based on the Relational Model

 The database must have a catalog (metadata) that is itself stored in

the same relational database and accessible using the same query
language used for other data.

Example: Metadata about tables, columns, and their constraints should

be accessible through queries like any other data in the database.

5. Comprehensive Data Sublanguage Rule

 The system must support a comprehensive data sublanguage that

includes a powerful data definition language (DDL), data
manipulation language (DML), and transaction management
capabilities, all in one language.

Example: SQL is a comprehensive language that provides DDL (for

defining schema), DML (for querying and manipulating data), and
transaction management.

6. View Updating Rule

 Any view that is theoretically updatable must be updatable by the

system. This means that changes made through a view should be
reflected in the underlying base tables.

Example: If you have a view showing StudentName and Course, you should
be able to update the student's name in the view, and the change should
be reflected in the underlying Student table.

7. High-Level Insert, Update, and Delete

 The system must support set-based operations for inserting,

updating, and deleting data, rather than requiring row-by-row
operations.

Example: You should be able to insert multiple rows into a table with a
single command, such as INSERT INTO Students (Name, Age) VALUES ('Alice', 20),
('Bob', 22);.

8. Physical Data Independence

  Changes to the physical storage of data should not require changes
to the logical structure of the database. The application should not
be affected by changes in the physical storage of data.

Example: Changing the way data is stored on disk (e.g., moving from one
type of storage device to another) should not require changes to the
database schema or application queries.

9. Logical Data Independence

 Changes to the logical structure of the database (like adding a new

column) should not affect the applications that use the database.

Example: Adding a new column to a table should not require

modifications to existing applications that interact with the table if they do
not use the new column.

10. Integrity Independence

 Integrity constraints must be stored in the catalog and must not be

specified only in application programs. This ensures that constraints
are enforced consistently.

Example: Constraints such as foreign keys and unique constraints should

be defined in the database schema rather than in application code.

11. Distribution Independence

 The system should support distribution of data across multiple

locations without requiring changes to the application or database
schema.

Example: The database should handle data distribution across different

servers transparently to the user and application.

12. Non-Subversion Rule

 If the system provides a low-level (e.g., file-based) interface, it

should not be able to bypass the integrity rules or the relational
model.

Example: Access through a low-level interface should not compromise

the database's integrity constraints or allow access that would violate the
relational model.

Application of Codd's Rules

While not all database systems strictly adhere to every rule (especially
older systems or those not designed around pure relational principles),
these rules provide a benchmark for evaluating the relational capabilities
of a database system. Modern relational database systems like MySQL,
PostgreSQL, and Oracle strive to meet these principles, though
implementations can vary.

Relational data model

The relational data model is a framework for managing and structuring

data in a database system using a table-based format. It was introduced
by Edgar F. Codd in 1970 and has since become the foundation for most
modern database systems. Here’s a detailed look at the key concepts of
the relational data model:

Key Concepts of the Relational Data Model

1. Tables (Relations)
o Definition: A table, or relation, is a collection of rows and
columns where each row represents a unique record, and
each column represents an attribute of the record.
o Structure: Each table is defined by its schema, which
includes the table name, column names, and data types.
o Example: A table named Employee might have columns
EmployeeID, Name, Department, and Salary.

Employe Nam Departm Salar

eID e ent y
6000
1 Alice HR
0
7000
2 Bob IT
0
Charli 7200
3 IT
e 0

2. Rows (Tuples)
o Definition: A row, or tuple, represents a single record or
instance of an entity in a table.
o Characteristics: Each row contains values for each attribute
defined by the columns of the table.
o Example: The row (1, Alice, HR, 60000) represents an employee
with EmployeeID 1, named Alice, working in the HR department
with a salary of 60,000.
3. Columns (Attributes)
o Definition: Columns, or attributes, represent the properties
or characteristics of the entity modeled by the table.
o Characteristics: Each column has a specific data type (e.g.,
integer, varchar) and defines the kind of data that can be
stored.
 o Example: The Salary column in the Employee table might have
a data type of INTEGER.
4. Keys
o Primary Key: A unique identifier for each row in a table. It
ensures that each record is unique and can be identified
without ambiguity.
 Example: EmployeeID in the Employee table is a primary
key.
o Foreign Key: An attribute in one table that links to the
primary key of another table, establishing relationships
between tables.
 Example: A DepartmentID column in an Employee table
that references the DepartmentID in a Department table.
5. Integrity Constraints
o Entity Integrity: Ensures that each table has a primary key
and that the primary key columns contain unique values and
are not null.
o Referential Integrity: Ensures that foreign keys match
primary keys in the referenced table or are null, maintaining
consistency across relationships.
o Domain Integrity: Ensures that all column values conform to
a specified domain (data type, length, format).
6. Relationships
o One-to-One (1:1): Each row in Table A is related to at most
one row in Table B, and vice versa.
 Example: A Person table and a Passport table where each
person has at most one passport and each passport is
assigned to one person.
o One-to-Many (1

): Each row in Table A can be related to many rows in Table B,

but each row in Table B is related to at most one row in Table
A.

 Example: A Department table and an Employee table

where each department can have many employees, but
each employee belongs to only one department.
o Many-to-Many (M

): Rows in Table A can be related to many rows in Table B and

vice versa, often managed through a junction table.

Example: A Student table and a Course table where

students can enroll in multiple courses and each course
can have multiple students. This is managed by an
Enrollment table.
7. Normalization
 o Definition: A process of organizing the data to reduce
redundancy and improve data integrity by decomposing
tables into smaller tables and defining relationships.
o Normal Forms: Various levels of normalization (e.g., 1NF,
2NF, 3NF) ensure that tables are structured to avoid
anomalies during data operations.

Normal forms in DBMS:

Normalization is a process used in database design to organize tables and

their relationships to reduce redundancy and improve data integrity. The
goal is to ensure that the database is free of anomalies and efficiently
supports operations like insertion, deletion, and update. Normal forms are
specific levels of normalization, each addressing different types of
redundancy and potential anomalies. Here’s a detailed explanation of the
main normal forms:

1. First Normal Form (1NF)

Definition: A table is in First Normal Form if all its attributes contain only
atomic (indivisible) values, and each column contains only one value per
row.

Requirements:

 Atomicity: Each cell in a table should contain a single value, not a

set or list of values.
 Uniqueness: Each column must be unique in its name, and the
order in which data is stored does not matter.

Example: Consider a table where each row contains a list of phone

numbers for a person:

Person Nam PhoneNumber

ID e s
123-4567, 234-
1 Alice
5678
2 Bob 345-6789

To convert this to 1NF, we need to ensure each cell contains only one
value:

Person Nam PhoneNum

ID e ber
1 Alice 123-4567
Person Nam PhoneNum
ID e ber
1 Alice 234-5678
2 Bob 345-6789

2. Second Normal Form (2NF)

Definition: A table is in Second Normal Form if it is in 1NF and all non-key

attributes are fully functionally dependent on the entire primary key, not
just part of it.

Requirements:

 Full Functional Dependency: In tables with composite primary

keys, each non-key attribute must be fully dependent on the entire
primary key.

Example: Consider a table with a composite key (StudentID, CourseID) and

attributes StudentName, CourseName:

Student Course StudentNa CourseNa

ID ID me me
1 101 Alice Math
1 102 Alice Science
2 101 Bob Math

Here, StudentName depends only on StudentID, and CourseName depends only

on CourseID. To achieve 2NF, we need to split the table:

Student Table:

Student StudentNa
ID me
1 Alice
2 Bob

Course Table:

Course CourseNa
ID me
101 Math
102 Science

Enrollment Table:

Student Course
ID ID
1 101
Student Course
ID ID
1 102
2 101

3. Third Normal Form (3NF)

Definition: A table is in Third Normal Form if it is in 2NF and all the

attributes are functionally dependent only on the primary key and not on
any other non-key attributes (i.e., no transitive dependency).

Requirements:

 No Transitive Dependency: Non-key attributes should not depend

on other non-key attributes.

Example: Consider a table with attributes EmployeeID, EmployeeName,

DepartmentID, and DepartmentName:

Employe EmployeeN Departme DepartmentN

eID ame ntID ame
1 Alice 10 HR
2 Bob 20 IT

Here, DepartmentName depends on DepartmentID, which is not the primary

key. To achieve 3NF, split the table:

Employee Table:

Employe EmployeeN Departmen

eID ame tID
1 Alice 10
2 Bob 20

Department Table:

Departmen DepartmentN
tID ame
10 HR
20 IT