Data Modeling Using Entity-Relational Model and Relational Model (10 LHs)

1. Using High-Level Conceptual Data Models for Database Design

• High-Level Conceptual Data Models:
o Used to represent the real-world entities and relationships in a database design.
o Provides a clear and user-friendly overview of the structure and constraints of the
database.
o Commonly used models include the Entity-Relationship (ER) model.
• Purpose:
o Simplifies communication between stakeholders (e.g., users, developers, and
designers).
o Acts as the blueprint for detailed database design.

2. Entity Types, Entity Sets, Attributes, and Keys

• Entity Types:
o Represents a group of objects with the same attributes.
o Example: "Student," "Employee."
• Entity Sets:
o A collection of entities of the same type.
o Example: All students in a university form a "Student" entity set.
• Attributes:
o Describes the properties of an entity.
o Types:
▪ Simple Attributes: Atomic values (e.g., Name, Age).
▪ Composite Attributes: Can be divided into smaller parts (e.g., Full Name
-> First Name, Last Name).
▪ Derived Attributes: Can be derived from other attributes (e.g., Age from
Date of Birth).
▪ Multivalued Attributes: Can have multiple values (e.g., Phone Numbers).
• Keys:
 o Primary Key: Uniquely identifies an entity in an entity set.
o Candidate Key: A set of attributes that could serve as a primary key.
o Composite Key: A primary key composed of multiple attributes.

3. Relationship Types, Relationship Sets, Roles, and Structural Constraints

• Relationship Types:
o Defines the association between two or more entities.
o Example: "Enrolls" between "Student" and "Course."
• Relationship Sets:
o A collection of relationships of the same type.
o Example: All enrollments of students in courses.
• Roles:
o Specifies the part played by an entity in a relationship.
o Example: In a "Teaches" relationship, "Professor" plays the role of teacher.
• Structural Constraints:
o Defines the rules of participation:
▪ Cardinality: Specifies the number of entities involved (e.g., 1:1, 1:N,
M:N).
▪ Participation: Can be total (mandatory) or partial (optional).

4. Weak Entity Types

• Definition:
o Entities that cannot be uniquely identified by their attributes alone.
o Requires a "strong entity" and a "foreign key" for identification.
• Key Features:
o Always associated with a "strong entity".
o Has a "discriminator" (partial key) to distinguish between weak entities.
o Depicted with a double rectangle in ER diagrams.
• Example:
 o "Dependent" weak entity associated with the "Employee" strong entity.

5. ER Diagrams, Naming Conventions, and Design Issues

• ER Diagrams:
o Graphical representation of entities, attributes, and relationships.
o Symbols:
▪ Rectangle: Entity type.
▪ Ellipse: Attribute.
▪ Diamond: Relationship type.
▪ Double Ellipse: Multivalued attribute.
▪ Double Rectangle: Weak entity.
• Naming Conventions:
o Use singular nouns for entities.
o Use meaningful names for relationships.
o Avoid abbreviations unless necessary.
• Design Issues:
o Redundancy: Avoid duplicating information.
o Complexity: Simplify the design for clarity.
o Consistency: Ensure the schema aligns with real-world requirements.

6. Relationship Types of Degree Higher Than Two

• Higher-Degree Relationships:
o Involves more than two entities.
o Example: "ProjectAssignment" relationship between "Employee," "Project," and
"Role."
• Challenges:
o More complex to model and understand.
o Often can be decomposed into simpler binary relationships.
7. Concepts of Specialization and Generalization
• Specialization:
o Process of creating sub-classes from a super-class.
o Example: "Employee" specialized into "Manager" and "Technician."
o Represents "is-a" relationships.
• Generalization:
o Process of combining multiple classes into a super-class.
o Example: "Car" and "Truck" generalized into "Vehicle."
• Characteristics:
o Disjoint Specialization: An entity belongs to only one subclass.
o Overlapping Specialization: An entity can belong to multiple subclasses.

8. Constraints and Characteristics of Specialization and Generalization

• Constraints:
o Disjointness Constraint: Specifies whether subclasses are disjoint.
o Completeness Constraint: Specifies whether all entities in the superclass must
belong to a subclass (total or partial).
• Characteristics:
o Reflects real-world hierarchies.
o Simplifies data modeling by grouping similar entities.

9. Converting ER Schema to Relational Schema

• Steps:
1. Convert each entity type to a table with attributes.
2. Convert relationships:
▪ 1:1 relationships: Add a foreign key to one of the tables.
▪ 1:N relationships: Add a foreign key to the "N" side.
▪ M:N relationships: Create a separate table with foreign keys from both
entities.
 3. Handle multivalued attributes by creating separate tables.
4. Represent weak entities with foreign keys referencing strong entities.
• Example:
o ER Diagram with "Student" and "Course" entities and an "Enrolls" relationship
converts into:
▪ Student(StudentID, Name, Age)
▪ Course(CourseID, Title)
▪ Enrolls(StudentID, CourseID, EnrollDate)

10. Structure of the Relational Database

• Definition:
o A database structured to recognize relations among stored items.
• Components:
o Tables (Relations): Represent entities and relationships.
o Rows (Tuples): Represent individual records.
o Columns (Attributes): Represent properties of the entity.
• Characteristics:
o Data is stored in a tabular format.
o Primary and foreign keys enforce relationships and constraints.
o Supports SQL for querying and manipulating data.