Chapter 4 Entity Relationship (E-R) Modeling Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel

Basic Modeling Concepts Database design is both art and science. A data model is the relatively simple representation, usually graphic, of complex real-world data structures. It represents data structures and their characteristics, relations, constraints, and transformations. The database designer usually employs data models as communications tools to facilitate the interaction among the designer, the applications programmer, and the end user. A good database is the foundation for good applications.

Figure 4.1 Four Modified (ANSI/SPARC) Data Abstraction Models

Data Models: Degrees of Data Abstraction The Conceptual Model The conceptual model represents a global view of the data. It is an enterprise-wide representation of data as viewed by high-level managers. Entity-Relationship (E-R) model is the most widely used conceptual model. The conceptual model forms the basis for the conceptual schema. The conceptual schema is the visual representation of the conceptual model. The conceptual model is independent of both software (software independence) and hardware (hardware independence).

Tiny College Entities Figure 4.2

A Conceptual Schema for Tiny College Figure 4.3

Data Models: Degrees of Data Abstraction The Internal Model The internal model adapts the conceptual model to a specific DBMS. The internal model is software-dependent. Development of the internal model is especially important to hierarchical and network database models.

Figure 4.4

Data Models: Degrees of Data Abstraction The External Model The external model is the end user’s view of the data environment. Each external model is then represented by its own external schema. CREATE VIEW CLASS_VIEW AS SELECT (CLASS_ID, CLASS_NAME, PROF_NAME, CLASS_TIME, ROOM_ID) FROM CLASS, PROFESSOR, ROOM WHERE CLASS.PROF_ID = PROFESSOR.PROF_ID AND CLASS.ROOM_ID = ROOM.ROOM_ID;

Figure 4.5 The External Models for Tiny College

Data Models: Degrees of Data Abstraction The External Model Advantages of Using External Schemas It makes application program development much simpler. It facilitates the designer’s task by making it easier to identify specific data required to support each business unit’s operations. It makes the designer’s job easier by providing feedback about the conceptual model’s adequacy. It helps to ensure security constraints in the database design.

Data Models: Degrees of Data Abstraction The Physical Model The physical model operates at the lowest level of abstraction, describing the way data is saved on storage media such as disks or tapes. It requires the definition of both the physical storage devices and the access methods required to reach the data within those storage devices. The physical model is both software and hardware-dependent. It requires detailed knowledge of hardware and software used to implement the database design.

The Entity Relationship (E-R) Model E-R model is commonly used to: Translate different views of data among managers, users, and programmers to fit into a common framework. Define data processing and constraint requirements to help us meet the different views. Help implement the database.

The Entity Relationship (E-R) Model E-R Model Components Entities In E-R models an entity refers to the entity set. An entity is represented by a rectangle containing the entity’s name. Attributes Attributes are represented by ovals and are connected to the entity with a line. Each oval contains the name of the attribute it represents. Attributes have a domain -- the attribute’s set of possible values. Attributes may share a domain. Primary keys are underlined. Relationships

The Attributes of the STUDENT Entity Figure 4.6

Basic E-R Model Entity Presentation Figure 4.7

The CLASS Table (Entity) Components and Contents Figure 4.8

The Entity Relationship (E-R) Model Classes of Attributes A simple attribute cannot be subdivided. Examples: Age, Sex, and Marital status A composite attribute can be further subdivided to yield additional attributes. Examples: ADDRESS Street, City, State, Zip PHONE NUMBER  Area code, Exchange number

The Entity Relationship (E-R) Model Classes of Attributes A single-valued attribute can have only a single value. Examples: A person can have only one social security number. A manufactured part can have only one serial number. Multivalued attributes can have many values. A person may have several college degrees. A household may have several phones with different numbers Multivalued attributes are shown by a double line connecting to the entity.

The Entity Relationship (E-R) Model Multivalued Attribute in Relational DBMS The relational DBMS cannot implement multivalued attributes. Possible courses of action for the designer Within the original entity, create several new attributes, one for each of the original multivalued attribute’s components (Figure 4.9). Create a new entity composed of the original multivalued attribute’s components (Figure 4.10). Table 4.1

Splitting the Multivalued Attributes into New Attributes Figure 4.9

Figure 4.10 A New Entity Set Composed of Multivalued Attribute’s Components Figure 4.10

The Entity Relationship (E-R) Model A derived attribute is not physically stored within the database; instead, it is derived by using an algorithm. Example: AGE can be derived from the data of birth and the current date. Figure 4.11 A Derived Attribute

The Entity Relationship (E-R) Model Relationships A relationship is an association between entities. Relationships are represented by diamond-shaped symbols. Figure 4.12 An Entity Relationship

The Entity Relationship (E-R) Model A relationship’s degree indicates the number of associated entities or participants. A unary relationship exists when an association is maintained within a single entity. A binary relationship exists when two entities are associated. A ternary relationship exists when three entities are associated.

The Implementation of a Ternary Relationship Figure 4.14

The Entity Relationship (E-R) Model Connectivity The term connectivity is used to describe the relationship classification (e.g., one-to-one, one-to-many, and many-to-many). Figure 4.15 Connectivity in an ERD

The Entity Relationship (E-R) Model Cardinality Cardinality expresses the specific number of entity occurrences associated with one occurrence of the related entity. Figure 4.16 Cardinality in an ERD

Figure 4.17

Existence Dependency Figure 4.18 If an entity’s existence depends on the existence of one or more other entities, it is said to be existence-dependent. Figure 4.18

The Entity Relationship (E-R) Model Relationship Participation The participation is optional if one entity occurrence does not require a corresponding entity occurrence in a particular relationship. An optional entity is shown by a small circle on the side of the optional entity. Figure 4.19 An ERD With An Optional Entity

Figure 4.20 CLASS is Optional to COURSE Figure 4.21 COURSE and CLASS in a Mandatory Relationship

The Entity Relationship (E-R) Model Weak Entities A weak entity is an entity that Is existence-dependent and Has a primary key that is partially or totally derived from the parent entity in the relationship. The existence of a weak entity is indicated by a double rectangle. (Figure 4.22) The weak entity inherits all or part of its primary key from its strong counterpart.

A Weak Entity in an ERD Figure 4.22

Figure 4.23 An Illustration of the Weak Relationship Between DEPENDENT and EMPLOYEE Figure 4.23

The Entity Relationship (E-R) Model Recursive Entities A recursive entity is one in which a relationship can exist between occurrences of the same entity set. A recursive entity is found within a unary relationship. Figure 4.24 An E-R Representation of Recursive Relationships

Figure 4.25 Figure 4.26

The Implementation of the M:N Recursive “PART Contains PART” Relationship Figure 4.27

Figure 4.28 Implementation of the M:N “COURSE Requires COURSE” Recursive Relationship Figure 4.28

Figure 4.29 Implementation of the 1:M “EMPLOYEE Manages EMPLOYEE” Recursive Relationship Figure 4.29

The Entity Relationship (E-R) Model Composite Entities A composite entity is composed of the primary keys of each of the entities to be connected. The composite entity serves as a bridge between the related entities. The composite entity may contain additional attributes.

Converting the M:N Relationship Into Two 1:M Relationships Figure 4.30

The M:N Relationship Between STUDENT and CLASS Figure 4.31

A Composite Entity in the ERD Figure 4.32

The Entity Relationship (E-R) Model Entity Supertypes and Subtypes Figure 4.33 Nulls Created by Unique Attributes

The Entity Relationship (E-R) Model Entity Supertypes and Subtypes The generalization hierarchy depicts the parent- child relationship. The supertype contains the shared attributes, while the subtype contains the unique attributes. A subtype entity inherits its attributes and its relationships from the supertype entity.

A Generalization Hierarchy Figure 4.34

The Entity Relationship (E-R) Model Entity Supertypes and Subtypes The supertype entity set is usually related to several unique and disjointed (nonoverlapping) subtype entity sets. The supertype and its subtype(s) maintain a 1:1 relationship.

The EMPLOYEE/PILOT Supertype/Subtype Relationship Figure 4.35

The Entity Relationship (E-R) Model Entity Supertypes and Subtypes The generalization hierarchy depicts the parent- child relationship. (Figure 4.34) The supertype contains the shared attributes, while the subtype contains the unique attributes. The supertype entity set is usually related to several unique and disjointed (nonoverlapping) subtype entity sets. The supertype and its subtype(s) maintain a 1:1 relationship.

A Generalization Hierarchy With Overlapping Subtypes Figure 4.36

Figure 4.37