0% found this document useful (0 votes)
4 views

Ch2

The document outlines the concepts of the Entity-Relationship (ER) model and the Relational model, detailing entities, attributes, relationships, and their characteristics. It also describes the steps for converting an ER diagram into a relational model, including creating tables, implementing relationships with foreign keys, and handling composite and multi-valued attributes. Additionally, it provides important tips for exams and contrasts the ER model's conceptual design with the relational model's logical design and implementation.

Uploaded by

LL 3708
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

Ch2

The document outlines the concepts of the Entity-Relationship (ER) model and the Relational model, detailing entities, attributes, relationships, and their characteristics. It also describes the steps for converting an ER diagram into a relational model, including creating tables, implementing relationships with foreign keys, and handling composite and multi-valued attributes. Additionally, it provides important tips for exams and contrasts the ER model's conceptual design with the relational model's logical design and implementation.

Uploaded by

LL 3708
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

CS3402 Lecture 2 Notes: ER & Relational Data Models

I. ER Model Concepts
• Entity: A real-world object represented in the database (e.g., an employee).
o Entity Type: A classification of entities sharing the same attributes (e.g., EMPLOYEE).
o Entity Set: A collection of entities of the same entity type (e.g., EMPLOYEE = {John Smith, James Black,...}).
• Attribute: A property describing an entity (e.g., Name, ID, Address, BirthDate for EMPLOYEE).
o Attributes have a domain (data type): Name (Character String), ID (Integer).
o Attribute Types:
§ Simple
§ Composite
§ Single-valued
§ Multi-valued
§ Derived (can be calculated from other attributes)
• Relationship: An association between entities (e.g., EMPLOYEE John Smith works on PROJECT X).
o Relationship Type: Defines the relationship name, participating entity types, and constraints (cardinality, participation) (e.g.,
WORKS_ON between EMPLOYEE and PROJECT).
o Relationship Set: A collection of relationship instances of the same type.
• Cardinality Ratio: Specifies the maximum number of relationship instances an entity can participate in (1:1, 1:N, N:1, M:N).
• Participation Constraint: Specifies the minimum number of relationship instances an entity must participate in.
o Total Participation (existence dependency): Entity must participate (double line).
o Partial Participation: Entity may or may not participate (single line).
• (Min, Max) Notation: Specifies the minimum and maximum number of relationship instances an entity can participate in. Default: min=0,
max=n.
• Degree of Relationship Type: Number of participating entity sets (Binary, Ternary, N-ary). N-ary relationships are generally not
equivalent to n binary relationships.
• Recursive Relationship: A relationship type between the same entity type in different roles (e.g., SUPERVISION where EMPLOYEE is
both supervisor and supervisee).
II. Relational Model Concepts
• Relation Schema: R(A1, A2, ..., An), where R is the relation name and A1, A2, ..., An are attributes. Each attribute Ai has a domain.
o Example: STUDENT(Name: string, Ssn: string, Home_phone: string, Address: string)
• Relation (or Relation State): A set of n-tuples r = {t1, t2, ..., tm}. Each tuple t is an ordered list of n values t = <v1, v2, ..., vn>.
• Characteristics of Relations:
o Tuples are not ordered.
o Each relation has a current state (instance).
o Basic operations: INSERT, DELETE, MODIFY.
• Informal Terms vs. Formal Terms:
o Table = Relation
o Column Header = Attribute
o All possible Column Values = Domain
o Row = Tuple
o Table Definition = Schema of a Relation
o Populated Table = State of the Relation
• Keys:
o Superkey: A set of attributes that uniquely identifies an entity.
o Candidate Key: A minimal superkey (no proper subset is a superkey).
o Primary Key: The candidate key chosen to identify entities.
• Foreign Key: A set of attributes in one relation that references the primary key of another relation. Ensures referential integrity.
III. ER-to-Relational Mapping Algorithm (Key Steps)
Step 1: Understand the ER Diagram
• Identify Entities: Carefully examine the ER diagram and identify all the entities. Each entity will typically become a table in your
relational model. Remember, entities represent real-world objects or concepts (e.g., Customer, Book, Order, Employee).
• Identify Attributes: For each entity, list all its attributes. These attributes will become the columns in your tables. Pay attention to the
data types of the attributes (e.g., text, number, date).
• Identify Relationships: Identify all the relationships between entities. This is where cardinality ratios become important. The
relationships will determine how you connect the tables together using foreign keys.
• Identify Primary Keys: Determine the primary key for each entity. The primary key is the attribute (or combination of attributes) that
uniquely identifies each instance of the entity. It will become the primary key of the corresponding table.
• Identify Composite and Multi-valued Attributes: Note any composite attributes (attributes composed of multiple parts) and multi-valued
attributes (attributes that can have multiple values). You'll need to handle these specially (as we discussed earlier for multi-valued
attributes).
Step 2: Create Tables for Each Entity
• For each entity in the ER diagram, create a corresponding table in your relational model.
• Name the table using a descriptive name, usually the same as the entity name.
• Include all the attributes of the entity as columns in the table.
• Specify the data type for each column based on the attribute's data type.
• Designate the primary key for the table.
Step 3: Implement Relationships Using Foreign Keys
This is the most crucial step, where you translate the relationships from the ER diagram into foreign key constraints in your relational model.
• One-to-Many (1:M) Relationship: In a 1:M relationship between entity A and entity B (where A is "one" and B is "many"), add the
primary key of entity A as a foreign key to the table representing entity B.

1
o Example: If a Customer can place many Orders, add the CustomerID (primary key of Customer) as a foreign key to the
Orders table.
• One-to-One (1:1) Relationship: In a 1:1 relationship between entity A and entity B, you can add the primary key of either entity as a
foreign key to the other table. The choice often depends on which entity is more likely to exist independently.
o Example: If each Employee has one ParkingSpace assigned to them, you could add the EmployeeID (primary key of
Employee) as a foreign key to the ParkingSpace table, or vice versa.
• Many-to-Many (M:N) Relationship: In an M:N relationship between entity A and entity B, you need to create a new table called a
"junction table" or "associative entity." This table will have two foreign keys: the primary key of entity A and the primary key of entity B.
The combination of these two foreign keys often forms the primary key of the junction table.
o Example: If a Student can enroll in many Courses, and a Course can have many Students, you would create a
StudentCourse table with StudentID (foreign key referencing Student) and CourseID (foreign key referencing Course).
• Zero-to-Many (0:M) Relationship: This is handled the same way as a 1:M relationship. The "zero" simply means that the foreign key
column in the "many" side table can be NULL (i.e., an instance of entity B might not be related to any instance of entity A).
Step 4: Handle Composite and Multi-valued Attributes
• Composite Attributes: Break down composite attributes into their individual components and include each component as a separate
column in the table.
o Example: If Address is a composite attribute consisting of Street, City, State, and ZipCode, create separate columns for
each of these components in the table.
• Multi-valued Attributes: As we discussed earlier, create a separate table for each multi-valued attribute. The table will have a foreign
key referencing the primary key of the original table and a column to store the value of the multi-valued attribute.
Step 5: Define Primary Keys and Foreign Key Constraints
• Clearly specify the primary key for each table.
• Define foreign key constraints to enforce the relationships between tables. This ensures data integrity and prevents orphaned records.
Step 6: Document Your Relational Model
• Create a data dictionary or schema diagram to document your relational model. This will help others understand the structure of your
database.
Important Tips for the Exam:
• Show Your Work: Clearly show each step of the conversion process. This will help you get partial credit even if you make a mistake.
• Use Clear and Consistent Naming Conventions: Choose descriptive names for your tables and columns.
• Pay Attention to Cardinality Ratios: Understanding the cardinality ratios is crucial for correctly implementing the relationships.
• Consider Data Types: Choose appropriate data types for each column.
• Double-Check Your Work: Before submitting your answer, carefully review your relational model to ensure that it accurately reflects
the ER diagram and that all relationships are correctly implemented.
IV. ER Model vs. Relational Model
• ER model is for conceptual design.
• Relational model is for logical design and implementation.

You might also like