Unit 2: Relational Model and Entity Relationship Model
1. The Relational Model
The Relational Model is the most widely used data model for commercial data processing. It organizes
data into two-dimensional tables called relations.
1.1 Structure of a Relational Database
• Relation (Table): A fundamental construct in the relational model. It is a two-dimensional table
with rows and columns, representing a collection of related data. Each table typically represents
an entity type (e.g., Student, Course) or a relationship between entity types.
o Example: A Student table.
• Tuple (Row/Record): A single row in a relation. Each tuple represents a single record or an
instance of the entity described by the relation.
o Example: A specific student's data: (101, 'Alice', 'Computer Science', '2004-05-15').
• Attribute (Column/Field): A named column in a relation. Each attribute describes a specific
characteristic or property of the entity that the relation represents. All values in a given attribute
(column) must be of the same data type.
o Examples: StudentID, Name, Major, DateOfBirth in the Student table.
• Domain: The set of all possible values for a given attribute. It defines the permissible data type
and range of values for an attribute.
o Example: The domain for Age might be integers between 18 and 100. The domain for
Gender might be {'Male', 'Female', 'Other'}.
• Degree of a Relation: The number of attributes (columns) in a relation.
o Example: If a Student table has StudentID, Name, Major, DateOfBirth, its degree is 4.
• Cardinality of a Relation: The number of tuples (rows) in a relation. This changes dynamically as
data is inserted, deleted, or updated.
o Example: If a Student table currently has 100 student records, its cardinality is 100.
1.2 Database Schema
• Relation Schema (or Table Schema): The description of a single relation. It defines the name of
the relation, the names of its attributes, and their corresponding domains (data types).
o Notation: R(A1, A2, ..., An) where R is the relation name and A1...An are its attributes.
o Example: Student (StudentID: INT, Name: VARCHAR(50), Major: VARCHAR(30), DOB:
DATE)
• Database Schema: The overall logical design of the entire database. It is the collection of
schemas for all the relations in the database. It defines the structure of all tables, their
attributes, and the relationships/constraints between them.
o Example: Database Schema = {Student_Schema, Course_Schema, Enrollment_Schema}
1.3 Keys
Keys are crucial for uniquely identifying tuples within a relation and for establishing relationships
between relations.
• Super Key: An attribute or a set of attributes that can uniquely identify a tuple in a relation. A
super key can contain extra attributes that are not strictly necessary for unique identification.
o Example: In Student (ID, Name, Age, Phone), (ID), (ID, Name), (ID, Age, Phone) are all
super keys if ID is unique. (Phone) could also be a super key if phone numbers are
guaranteed unique.
• Candidate Key: A minimal super key. It is a super key from which no attribute can be removed
without losing the uniqueness property. A relation can have multiple candidate keys.
o Example: In Student (ID, Name, Age, Phone), if both ID and Phone are unique, then (ID)
and (Phone) are candidate keys. (ID, Name) is a super key but not a candidate key
because Name can be removed and ID alone is still unique.
• Primary Key (PK): A candidate key chosen by the database designer to uniquely identify each
tuple in a relation. There can be only one primary key per relation.
o Characteristics:
▪ Uniquely identifies each row.
▪ Cannot contain NULL values (Entity Integrity Constraint).
▪ Should be minimal.
▪ Should ideally be stable (values don't change frequently).
o Example: In Student (ID, Name, Age, Phone), ID is typically chosen as the Primary Key.
• Composite Key: A primary key that consists of two or more attributes combined to uniquely
identify a record. This is used when a single attribute is not sufficient for unique identification.
o Example: In an Enrollment (StudentID, CourseID, Semester, Grade) table, (StudentID,
CourseID, Semester) might form a composite primary key if a student can enroll in the
same course multiple times in different semesters.
• Foreign Key (FK): An attribute or a set of attributes in one relation (the "referencing" or "child"
table) that refers to the primary key or a unique key of another relation (the "referenced" or
"parent" table). It is used to establish and enforce a link between the data in two tables.
o Referential Integrity Constraint: The values in the foreign key column(s) must either
match a value in the referenced primary/unique key column(s) or be NULL (if allowed).
o Example: In an Enrollment (StudentID, CourseID, Semester, Grade) table, StudentID
would be a foreign key referencing the ID (Primary Key) in the Student table. CourseID
would be a foreign key referencing the CourseID (Primary Key) in the Course table.
• Unique Key: An attribute or a set of attributes that uniquely identifies each tuple in a relation,
similar to a primary key. However, unlike a primary key, a unique key can allow one NULL value. A
table can have multiple unique keys.
o Example: In a Student table, Phone could be a unique key (assuming phone numbers are
unique), and it might allow a NULL value if a student doesn't have a phone number.
• Alternate Key: A candidate key that is not chosen as the primary key. If a relation has multiple
candidate keys, one is chosen as the primary key, and the others are called alternate keys.
o Example: If (ID) and (Phone) are both candidate keys for Student, and ID is chosen as the
Primary Key, then Phone is an Alternate Key.
1.4 Schema Diagrams
A schema diagram is a visual representation of the database schema. It shows the relations (tables) as
rectangles, with attributes listed inside. Primary keys are usually underlined, and foreign keys are
indicated by arrows pointing from the foreign key to the primary key it references.
• (Self-note: In a lecture, you'd draw this on a board or show a slide. Describe the visual elements).
o Rectangles: Represent relations/tables.
o Text inside Rectangles: Attribute names.
o Underlined Attributes: Primary Key(s).
o Dashed Underlined Attributes: Unique Key(s).
o Arrows (from FK to PK): Represent foreign key relationships.
Example Sketch Description:
Student table:
| StudentID (PK, underlined) | Name | Major |
Course table:
| CourseID (PK, underlined) | Title | Credits |
Enrollment table:
| StudentID (FK, underlined) | CourseID (FK, underlined) | Semester (underlined) | Grade |
Arrow from Enrollment.StudentID to Student.StudentID.
Arrow from Enrollment.CourseID to Course.CourseID.
1.5 Relational Query Language
Relational query languages are used to retrieve, insert, delete, and update data in relational databases.
• Structured Query Language (SQL): The most widely used declarative (non-procedural) relational
query language. Users specify what data they want, and the DBMS determines how to retrieve
it. (Covered extensively in future units).
• Relational Algebra: A procedural query language that consists of a set of operations that take
one or two relations as input and produce a new relation as output. It forms the theoretical
foundation for relational query languages like SQL.
1.6 Relational Operations (Relational Algebra)
Relational Algebra operations are categorized into fundamental operations and derived operations.
Fundamental Operations:
1. Select (σ):
o Purpose: Filters rows (tuples) from a relation based on a specified condition (predicate).
o Notation: σpredicate(R)
o Example: Get all students majoring in 'CS'.
▪ σMajor=′CS′(Student)
2. Project (π):
o Purpose: Selects specified columns (attributes) from a relation and eliminates duplicate
rows in the result.
o Notation: πA1,A2,...,An(R)
o Example: Get the names and majors of all students.
▪ πName,Major(Student)
3. Union (∪):
o Purpose: Combines all tuples from two relations, eliminating duplicates. Both relations
must be union-compatible (have the same number of attributes and corresponding
attributes must have compatible domains).
o Notation: R∪S
o Example: Get all students who are either in the Undergrad table or Grad table.
▪ Undergrad ∪ Grad
4. Set Difference (Minus) (−):
o Purpose: Returns tuples that are in the first relation but not in the second. Both relations
must be union-compatible.
o Notation: R−S
o Example: Get students who are in AllStudents but not in Graduates.
▪ AllStudents − Graduates
5. Cartesian Product (×):
o Purpose: Combines every tuple from the first relation with every tuple from the second
relation. If R has 'm' tuples and S has 'n' tuples, R×S will have 'm * n' tuples.
o Notation: R×S
o Example: Combine Student and Course tables (results in every student combined with
every course).
▪ Student × Course
6. Rename (ρ):
o Purpose: Used to rename a relation or an attribute. Essential for operations involving
self-joins or when attributes have the same name.
o Notation: ρS(R) (rename relation R to S) or ρB/A(R) (rename attribute A to B in relation
R).
o Example: ρStudent_Names(πName(Student))
Derived Operations:
1. Intersection (∩):
o Purpose: Returns tuples that are common to both relations. Both relations must be
union-compatible.
o Notation: R∩S
o Equivalence: R∩S≡R−(R−S)
o Example: Get students who are in both Undergrad and Grad tables.
▪ Undergrad ∩ Grad
2. Join (⋈):
o Purpose: Combines tuples from two relations based on a common attribute or a
specified join condition. It is a fundamental operation for combining related data.
o Types of Joins:
▪ Theta Join (⋈θ): Combines relations based on an arbitrary comparison operator
(θ, e.g., =, <, >) between attributes.
▪ Notation: R⋈θS
▪ Equivalence: R⋈θS≡σθ(R×S)
▪ Example: Find students whose age is less than the course's minimum
age.
▪ Student ⋈Student.Age<Course.MinAge Course
▪ Equi-Join (⋈=): A specific type of Theta Join where the comparison operator is
equals (=).
▪ Notation: R⋈R.A=S.BS
▪ Example: Join Student and Enrollment tables on StudentID.
▪ Student ⋈Student.StudentID=Enrollment.StudentID Enrollment
▪ Natural Join (⋈): A special type of Equi-Join where the join is performed
automatically on all common attributes between two relations, and duplicate
common attributes are eliminated from the result.
▪ Notation: R⋈S
▪ Example: Natural Join Student and Enrollment (they share StudentID).
▪ Student ⋈ Enrollment
▪ Outer Joins: (Left, Right, Full) - Include tuples that do not have matching values
in the other relation, padding with NULLs. (Mention briefly as advanced topic).
3. Division (÷):
o Purpose: Used for queries that involve universal quantification ("for all"). It finds tuples
in one relation that are related to all tuples in another specific relation.
o Notation: R÷S (R must contain all attributes of S, plus at least one more. S is a unary or
binary relation).
o Example: Find students who have taken all courses offered by the 'CS' department. This
is a complex operation typically broken down using other operations in practice.
2. Entity-Relationship (E-R) Model
The Entity-Relationship (E-R) model is a high-level conceptual data model used to design the database at
the conceptual level. It provides a graphical representation of the database's logical structure, focusing
on entities, their attributes, and the relationships between them.
2.1 Purpose of E-R Model
• Conceptual Design: Helps in designing the database from a high-level perspective,
understandable by non-technical users and domain experts.
• Communication Tool: Serves as a clear communication tool between database designers,
developers, and business stakeholders.
• Blueprint for Relational Model: Provides a blueprint that can be easily mapped to the relational
model (tables, columns, keys).
• Requirements Analysis: Aids in gathering and documenting data requirements for a system.
2.2 Entities and Attributes
• Entity: A real-world object or concept that has an independent existence and can be uniquely
identified.
o Strong Entity: An entity that can exist independently and has its own primary key.
Represented by a single rectangle.
▪ Example: STUDENT, COURSE, DEPARTMENT
o Weak Entity: An entity that cannot be uniquely identified by its own attributes alone. Its
existence depends on a strong entity (its "owner" or "identifying" entity). Represented
by a double rectangle.
▪ Example: DEPENDENT (depends on EMPLOYEE), COURSE_SECTION (depends on
COURSE). A weak entity's primary key is typically a combination of its partial key
and the primary key of its identifying entity.
• Attribute: A property or characteristic that describes an entity. Represented by an oval.
o Simple Attribute: An attribute that cannot be further divided into smaller components.
▪ Example: Age, Gender.
o Composite Attribute: An attribute that can be divided into smaller sub-attributes.
▪ Example: Address can be composed of Street, City, State, ZipCode. (Represented
by an oval connected to the main oval with lines).
o Derived Attribute: An attribute whose value can be calculated or derived from other
attributes in the database. It is not stored explicitly. Represented by a dashed oval.
▪ Example: Age (derived from DateOfBirth), YearsOfService (derived from
HireDate).
o Multi-valued Attribute: An attribute that can have multiple values for a single entity
instance. Represented by a double oval.
▪ Example: Phone_Numbers for a person (a person can have multiple phone
numbers), Degrees for an employee.
• Key Attribute: An attribute or a set of attributes that uniquely identifies an entity instance.
Represented by an underlined oval. This will become the primary key in the relational model.
o Example: StudentID for STUDENT entity.
2.3 Relationships
• Relationship: An association or link between two or more entities. Represents how entities
interact or are connected. Represented by a diamond.
o Example: STUDENT enrolls in COURSE. EMPLOYEE works for DEPARTMENT.
• Degree of a Relationship: The number of entity types participating in a relationship.
o Unary (Recursive): A relationship between occurrences of a single entity type.
▪ Example: EMPLOYEE manages EMPLOYEE.
o Binary: A relationship between two distinct entity types. Most common type.
▪ Example: STUDENT enrolls in COURSE.
o Ternary: A relationship among three distinct entity types.
▪ Example: SUPPLIER supplies PART to PROJECT.
o N-ary: A relationship among N entity types.
• Cardinality Ratios (Mapping Cardinalities): Specify the number of instances of one entity that
can be associated with the number of instances of another entity via a relationship. Represented
by numbers (1 or N/M) on the lines connecting entities to the relationship diamond.
o One-to-One (1:1): An instance of entity A can be associated with at most one instance of
entity B, and vice-versa.
▪ Example: EMPLOYEE manages DEPARTMENT (where one employee manages
one department, and one department is managed by one employee).
o One-to-Many (1:N or 1:M): An instance of entity A can be associated with multiple
instances of entity B, but an instance of entity B can be associated with at most one
instance of entity A.
▪ Example: DEPARTMENT has EMPLOYEE (one department has many employees,
but an employee belongs to only one department).
o Many-to-One (N:1 or M:1): The reverse of one-to-many. An instance of entity A can be
associated with at most one instance of entity B, but an instance of entity B can be
associated with multiple instances of entity A.
▪ Example: EMPLOYEE works for DEPARTMENT.
o Many-to-Many (M:N): An instance of entity A can be associated with multiple instances
of entity B, and vice-versa.
▪ Example: STUDENT enrolls in COURSE (a student can enroll in many courses, and
a course can have many students).
• Participation Constraints (Existence Dependency): Specify whether an entity instance must
participate in a relationship. Represented by line thickness.
o Total Participation (Mandatory): Every instance of an entity type must participate in the
relationship. Represented by a double line connecting the entity to the relationship
diamond.
▪ Example: Every COURSE_SECTION must be for a COURSE.
o Partial Participation (Optional): An instance of an entity type may or may not participate
in the relationship. Represented by a single line connecting the entity to the relationship
diamond.
▪ Example: An EMPLOYEE may manage a DEPARTMENT (not all employees are
managers).
2.4 Constraints in E-R Model
Constraints are rules that govern the values in the database to maintain data integrity and consistency. In
the E-R model, they are represented visually:
• Key Constraints: Represented by underlining key attributes. (Already covered under Attributes)
• Cardinality Ratio Constraints: Represented by numbers (1, N, M) or crow's foot notation on the
relationship lines. (Already covered under Relationships)
• Participation Constraints: Represented by single (partial) or double (total) lines connecting
entities to relationships. (Already covered under Relationships)
• Structural Constraints: This is a broader term encompassing cardinality and participation
constraints, describing the structure of connections.
• General Constraints (Semantic Constraints/Business Rules): These are additional rules that
cannot always be directly represented in the E-R diagram symbols but are crucial for the
business logic. They are typically noted separately or enforced at the implementation level (e.g.,
using triggers or application code).
o Example: "A student can enroll in a maximum of 5 courses per semester." (Cannot be
directly shown with standard ER symbols).
2.5 E-R Diagrams
E-R Diagrams are graphical representations of the E-R model, using a set of standard symbols.
• Symbols:
o Rectangle: Entity Set (Strong Entity)
o Double Rectangle: Weak Entity Set
o Diamond: Relationship Set
o Double Diamond: Identifying Relationship Set (connecting a weak entity to its strong
entity)
o Oval: Attribute
o Underlined Oval: Key Attribute
o Dashed Oval: Derived Attribute
o Double Oval: Multi-valued Attribute
o Lines: Link attributes to entity sets, and entity sets to relationship sets.
o Double Line: Total Participation
o Cardinality Notations (1, N, M or Crow's Foot): Placed near entity ends of relationship
lines to indicate cardinality ratio.
• Steps to Draw an E-R Diagram (General Guidelines):
1. Identify Entities: Determine the main objects or concepts relevant to the system.
2. Identify Attributes for each Entity: List the properties for each entity and classify them
(simple, composite, derived, multi-valued, key).
3. Identify Relationships: Determine how entities are associated with each other.
4. Determine Degree of Relationships: (Binary, Ternary, etc.).
5. Determine Cardinality Ratios: (1:1, 1:N, M:N) for each relationship.
6. Determine Participation Constraints: (Total/Mandatory or Partial/Optional) for each
entity in a relationship.
7. Draw the Diagram: Use standard E-R symbols to represent entities, attributes, and
relationships, including all constraints.
8. Refine and Review: Ensure the diagram accurately reflects the business requirements
and is easy to understand.
