Outlines Data Modeling Using the Entity- Relationship Model Instructor: Chapter 6 Churee Techawut 1) Database design process 2) ER Model concepts 3) ER diagrams notation 4) Relationships and relationship types 5) Degree of relationship types 6) Cardinality of relationships 7) Cardinality constraints and cardinality ratio 8) Weak entity types 9) Transforming ER diagrams into relations CS (204)321 Database System I 1 2 Database Design Process ER Model Concepts Miniworld ER model describes data as entities, relationships, and attributes. Three important concepts are: DBMS-independent Functional requirements Functional analysis Requirements collection & analysis Database requirements Conceptual design Entities and attributes Entity types and key attributes Relationships and relationships types High-level transaction specification Conceptual schema Logical design (Data model mapping) DBMS-specific Application program design Transaction implementation Application programs Logical schema Physical design Internal schema 3 4 Entities and attributes Entities and attributes Entities Entities are specific objects or things in the mini-world that are represented in the database. An entity may be an object with a physical existence (for example, PERSON, CAR, HOUSE, or ) or with a conceptual existence (for example, DEPARTMENT, PROJECT, JOB, or UNIVERSITY COURSE.) Value A specific entity will have a value for each of its attributes, for example a specific employee entity may have Name= John Smith, SSN= 123456789, Address= 731 Fondren, Houston, TX, Sex= M, BirthDate= 09-JAN-55. Each attribute has a value set (or data type) associated with it e.g., integer, string, subrange, enumerated type,... Attributes Attributes are properties used to describe an entity, for example an entity may have a Name, SSN, Address, Sex, and BirthDate. 5 6
Entities and attributes Entities and attributes Types of attributes Simple VS. Composite Simple (or atomic) attributes: Attributes that are not divisible such as SSN and sex. Composite attributes: Attributes that can be divided into smaller subparts. For example, Address(Apt#, House#, Street, City, State, Zipcode, Country) or Name(FirstName, MiddleName, LastName). Types of attributes (Continued) Single-valued VS. Multi-valued Single-valued attributes: An attribute that has a single value, such as Age of person. Multivalued attributes: Attributes that have numbers of values. For example, Color of a car or PreviousDegrees of a STUDENT. Denoted as {Color} and {PreviousDegrees}. Stored VS. Derived Stored attributes: e.g., BirthDate Derived attributes: It is derivable from stored attribute.; such as Age Null-valued attribute: An attribute that it s attribute value exists but is missing, or is unknown whether the attribute value exists. 7 8 Entity types and key attributes Entity types and key attributes Entity types A set of entities that have the same attributes. Each entity type in the database is described by a name and a list of attributes. Example of entity type Entity type name: Attributes: Ssn, Name, Age, Salary Entity set: e 1 (152056009, John Smith, 55, 80k) (Extension) e 2 (123098987, Fred Brown, 40, 30k) e 3 (143024992, Judy Clark, 25, 20k) Entity types (Continued) ER diagrammatic notation Use a rectangular box enclosing the entity type name. Attribute names are enclosed in ovals and are attached to their entity type by straight lines. Composite attributes are attached to their component attributes by straight lines. Multivalued attributes are displayed in double ovals. 9 10 Entity types and key attributes Entity types and key attributes Entity types (Continued) Example of ER diagram Key attributes Attributes of whose values are distinct for each individual entity and its values can be used to identify each entity uniquely. A key attributes may be composite. Example key attributes Entity type Key attribute PERSON Social Security Number Ssn Name Age Salary CAR Registration (Number + State) 11 ER diagrammatic notation Each key attribute has its name underlined inside the oval. 12
Entity types and key attributes Key attributes (Continued) Example of ER diagram Exercise Requirements for CAR are as followings: 1) CAR is an entity type. 2) Registration is a key attribute consisting of RegistrationNumber and State. 3) Other important attributes for a car are VehicleID, Make, Model, Year. 4) A car can have more than one Color. Possible attribute values for CAR entity type: Ssn Name Age Salary car 1 car 2 car 3 ABC 123 ABC 123 VSY 720 TEXAS NEW YORK TEXAS TK629 WP9872 TD729 Ford Mustang Nissan Sentra Chrysler LeBaron Convertible 2-door 4-door 1989 1992 1993 red, black blue white, blue 13 14 Exercise Exercise Answer the following questions: 1) What is the name of your entity type? 2) What are the attributes for the entity type? 3) What are the types of each attributes? 4) Write ER diagram from the requirements above. Entity type name: Attributes: Entity set: (Extension) CAR Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, {Color} car 1 ((ABC123, TEXAS), TK629, Ford Mustang, Convertible, 1989, {red, black}) car 2 ((ABC123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, {blue}) car 3 CAR ((VSY720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, {white, blue}) 15 16 Exercise ER diagram notation ER diagram ENTITY TYPE CAR WEAK ENTITY TYPE Registration Number State Year Color RELATIONSHIP TYPE IDENTIFYING RELATIONSHIP TYPE ATTRIBUTE KEY ATTRIBUTE VehicleID Make Model MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE 17 18
Example of COMPANY Database Relationships and relationship types Requirements for the COMPANY database The company is organized into DEPARTMENTs. Each department has a name, number, and a employee who manages the department. We keep track of the start date of the department manager. A department may have several locations. Each department controls a number of PROJECTs. Each project has a name, number, and is located at a single location. We store each s social security number, address, salary, sex and birth date. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. Each employee may have a number of DEPENDENTs. For each dependent, we keep their name, sex, birth date, and relationship to the employee. Relationships A relationship relates two or more distinct entities with a specific meaning. e.g. John Smith works on the Product X PROJECT. Franklin Wong manages the Research DEPARMENT. Relationship types A relationship type defines a set of associations among entities. e.g. WORKS_ON relationship type in which s and PROJECTs participate. MANAGEs relationship type in which s and DEPARMENTs participate. ER diagram of COMPANY database 19 20 Relationships and relationship types Relationships and relationship types Relationship instances Each relationship type R consists of relationship instances r i. Example of relationship type WORKS_FOR between two entity types WORKS_FOR DEPARTMENT ER diagrammatic notation Use a diamond-shaped box to display a relationship type enclosing the relationship name. e 1 e 2 e 3 r 1 r 2 r 3 d 1 d 2 d 3 It must be connected by straight lines to the rectangular boxes representing the participating entity types. e 4 r 4 e 5 r 5 21 22 Relationships and relationship types Degree of relationship types Example of ER diagram It is the number of participating entity types. Three kinds of degree of a relationship type: WORKS_FOR PROJECT Unary relationship Binary relationship Ternary relationship Ssn Name Age Name Number Location More than one relationship type can exist with the same participating entity types. e.g. MANAGES and WORKS_FOR are distinct relationships between and DEPARTMENT participate. Salary 23 24
Degree of relationship types Cardinality of relationships one - to - one Each entity in the relationship will have exactly one related entity. one - to - many Unary Binary Ternary One entity related to another of the same entity type. Entities of two different types related to each other. Entities of three different types related to each other. An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity. many - to - many Entities on both sides of the relationship can have many related entities on the other side. 25 26 Cardinality constraints and cardinality ratio Cardinality constraints and cardinality ratio Cardinality constraints The number of instances of one entity that can or must be associated with each instance of another entity. Cardinality ratio Minimum cardinality - If zero, then optional. - If one or more, then mandatory. Maximum cardinality - The maximum number Cardinality ratio (Continued) Mandatory one Mandatory many Optional one Optional many 27 28 Examples of unary relationships Examples of binary relationships is_assigned PARKING PLACE one-to-one PERSON is_married_to manages PRODUCT LINE contains PRODUCT one-to-one one-to-many one-to-many STUDENT registers_for COURSE 29 many-to-many 30
Weak entity types An entity that does not have a key attribute. A weak entity must participate in an identifying relationship type with an owner or identifying entity type. Entities are identified by the combination of: A partial key of the weak entity type The particular entity they are related to in the identifying entity type Step 1: Mapping Regular Entities to Relations Step 2: Mapping Weak Entities Step 3: Mapping Unary/Binary Relationships Step 4: Mapping Multivalued attributes Step 5: Mapping N-ary Relationship Types. Suppose that a DEPENDENT entity is identified by the dependent s first name and birhtdate, and the specific that the dependent is related to. DEPENDENT is a weak entity type with as its identifying entity type via the identifying relationship type DEPENDENT_OF. 31 32 1. Mapping Regular Entities to Relations Simple attributes: ER attributes map directly onto the relation Composite attributes: Use only their simple, component attributes Multi-valued attributes: Becomes a separate relation with a foreign key taken from the superior entity Figure 3.2: The ER conceptual schema diagram for the COMPANY database. We create the relations, DEPARTMENT, and PROJECT in the relational schema corresponding to the regular entities in the ER diagram. SSN is a primary key for the relation DNUMBER is a primary key for the relation DEPARTMENT and PNUMBER is a primary key for the relation PROJECT. 33 34 2. Mapping Weak Entities Becomes a separate relation with a foreign key taken from the parent entity. Primary key composed of: Partial identifier of weak entity type Primary key of identifying entity type (strong entity type) Create the relation DEPENDENT in this step to correspond to the weak entity type DEPENDENT. Include the primary key SSN of the relation as a foreign key attribute of DEPENDENT (renamed to ESSN). The primary key of the DEPENDENT relation is the combination {ESSN, DEPENDENT_NAME} because DEPENDENT_NAME is the partial key of DEPENDENT. 35 3. Mapping Unary/Binary Relationships One-to-One: Primary key on the optional side becomes a foreign key on the mandatory side. The 1:1 relation MANAGES is mapped by choosing the entity type E as the optional side and DEPARTMENT as the mandatory side. We include the primary key of the relation as foreign key in the DEPARTMENT relation and rename it MGRSSN. We also include the simple attribute StartDate of the MANAGES relationship type in the DEPARMENT relation and rename it MGRSTARTDATE. 36
3. Mapping Unary/Binary Relationships One-to-Many: Primary key on the one side becomes a foreign key on the many side. 3. Mapping Unary/Binary Relationships Many-to-Many: Create a new relation with the primary keys of the two entities as its primary key The 1:N relationship types WORKS_FOR, CONTROLS, and SUPERVISION in the figure. For WORKS_FOR we include the primary key DNUMBER of the DEPARTMENT relation as foreign key in the relation and call it DNO. The M:N relationship type WORKS_ON from the ER diagram is mapped by creating a relation WORKS_ON in the relational database schema. The primary keys of the PROJECT and relations are included as foreign keys in WORKS_ON and renamed PNO and ESSN, respectively. 37 Attribute HOURS in WORKS_ON represents the HOURS attribute of the relation type. The primary key of the WORKS_ON relation is the combination of the foreign key attributes {ESSN, PNO}. 38 4. Mapping Multivalued attributes Create a new relation that includes a multivalued attribute plus the primary key attribute of the entity type - as a foreign key in R If the multivalued attribute is composite, we include its simple components. The relation DEPT_LOCATIONS is created. The attribute DLOCATION represents the multivalued attribute LOCATIONS of DEPARTMENT. DNUMBER-as foreign key-represents the primary key of the DEPARTMENT relation. The primary key is the combination of {DNUMBER, DLOCATION}. 5. Mapping N-ary Relationship Types. For each n-ary relationship type R, where n>2, create a new relationship S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. Also include any simple attributes of the n-ary relationship type (or simple components of composite attributes) as attributes of S. The relationship type SUPPLY in the ER below. This can be mapped to the relation SUPPLY shown in the relational schema, whose primary key is the combination of the three foreign keys {SNAME, PARTNO, PROJNAME} 39 40 Example of ternary relationship types: The SUPPLY relationship. Mapping the n-ary relationship type SUPPLY 41 42
Summary of Mapping Constructs and Constraints Correspondence between ER and Relational Models ER Model Relational Model Entity type Entity relation 1:1 or 1:N relationship type Foreign key (or relationship relation) M:N relationship type Relationship relation and two foreign keys n-ary relationship type Relationship relation and n foreign keys Simple attribute Attribute Composite attribute Set of simple component attributes Multivalued attribute Relation and foreign key Value set Domain Key attribute Primary (or secondary) key 43