DatabaseIM ISU1 Fundamentals of Database Systems Chapter 3 Data Modeling Using Entity-Relationship Model

DatabaseIM ISU2 Database Design Process  Two main activities:  Database design  Applications design  Focus in this chapter on database design  To design the conceptual schema for a database application  Applications design focuses on the programs and interfaces that access the database  Generally considered part of software engineering

DatabaseIM ISU3 Database Design Process (cont.)  Requirements collection and analysis  The database designers interview prospective database users  The result is data requirement  Functional analysis  Specify the known functional requirements of the application  Consist of user-defined operations, such as retrievals and updates

DatabaseIM ISU4 Database Design Process (cont.)  Conceptual design  Specify concisely the data requirement of the users, such as entity types, relationships, and constraints  Use high-level conceptual data model, e.g., Entity- Relationship model  Used as a reference to communicate with nontechnical users  Modifications to the conceptual schema can be introduced when some functional requirements cannot be specified

DatabaseIM ISU5 Database Design Process (cont.)  Logical design (data model mapping)  Refer to the actual implementation of the database using a commercial DBMS  Need to transform the conceptual data model into the implementation data model, e.g., relational model  Physical design  Specify the internal storage structures, access paths, and file organizations

DatabaseIM ISU6

DatabaseIM ISU7 Example Database  An COMPANY database  The company is organized into departments  Each department controls several projects  Need to keep track all employee and their working hours  Need to keep track of the dependents of each employee

DatabaseIM ISU8 Example Database (cont.)

DatabaseIM ISU9 ER Model Concepts  Entities and Attributes  Entities are specific objects or things in the mini-world, e.g., EMPLOYEE John Smith  Attributes are properties used to describe an entity, e.g., Name, SSN, Address, Sex, BirthDate for EMPLOYEE  A specific entity will have a value for each of its attributes, e.g, Name = ‘John Smith’

DatabaseIM ISU10 ER Model Concepts (cont.)  Two example entities

DatabaseIM ISU11 ER Model Concepts (cont.)  Types of attributes  Simple vs Composite »Each entity has a single atomic value for the attribute, e.g., SSN »Composite attributes may be composed of several components, e.g., address, and may form a hierarchy  Single-valued vs Multi-valued »Most attributes are single-valued, but some attributes may have multiple values, e.g., Expert

DatabaseIM ISU12 ER Model Concepts (cont.)  An example hierarchy of composite attributes

DatabaseIM ISU13 ER Model Concepts (cont.)  Stored vs Derived »In some case, two (or more) attributes are related »Age (derived attribute) can be derived from the BirthDate attribute (stored attribute)  Complex »In general, composite and multi-valued attributes may be nested arbitrarily »e.g., AddressPhone for a person

DatabaseIM ISU14 ER Model Concepts (cont.)  Entity Types and Key Attributes  Entities with the same basic attributes are grouped or typed into an entity type, e.g, EMPLOYEE type  Key attribute »An attribute for which each entity must have a unique value, e.g, SSN for EMPLOYEE »A key attribute may be composite »An entity type may have more than one key attributes, e.g, VehicleId, Registration

DatabaseIM ISU15 ER Model Concepts (cont.)

DatabaseIM ISU16 ER Model Concepts (cont.)

DatabaseIM ISU17 Displaying an Entity type  In ER diagrams, an entity type is displayed in a rectangular box  Attributes are displayed in ovals  Each attribute is connected to its entity type  Components of a composite attribute are connected to the oval representing the composite attribute  Each key attribute is underlined  Multivalued attributes displayed in double ovals

DatabaseIM ISU18 Displaying an Entity type (cont.)  Example diagram for CAR entity type

DatabaseIM ISU19 Entity Set  Each entity type will have a collection of entities stored in the database  Called the entity set  e.g, entity set for CAR  Same name (CAR) used to refer to both the entity type and the entity set  Entity set is the current state of the entities of that type that are stored in the database

DatabaseIM ISU20 ER Model Concepts – Relationships  Relationships and Relationship Types  A relationship relates two or more distinct entities with a specific meaning »e.g, EMPLOYEE John Smith works on ProductX PROJECT  Relationships of the same type are grouped or typed into a relationship type

DatabaseIM ISU21 ER Model Concepts – Relationships (cont.)

DatabaseIM ISU22 ER Model Concepts – Relationships (cont.)  Degree of a relationship type: the number of participating entity types »e.g., WORKS_FOR is a binary relationship, SUPPLY is a ternary relationship  A relationship type can be represented as attributes »e.g., WORKS_FOR relationship => Department of EMPLOYEE or Employees of DEPARTMENT

DatabaseIM ISU23 ER Model Concepts – Relationships (cont.)

DatabaseIM ISU24 ER Model Concepts – Relationships (cont.)  Recursive relationships: A relationship relate two entities of the same entity type (participates in different roles) »e.g., SUPERVISION: relates relates one EMPLOYEE (in the role of supervisee) to another EMPLOYEE (in the role of supervisor)  A relationship type can have attributes »e.g., HoursPerWeek of WORKS_ON

DatabaseIM ISU25 ER Model Concepts – Relationships (cont.)

DatabaseIM ISU26 ER Model Concepts – Relationships (cont.)  Structural constraints on relationships  Cardinality ratio (of a binary relationship) »Specify the number of relationship instances that an entity can participate in »1:1, 1:N, N:1, or M:N (e.g., WORKS_ON)  Participation constraint (on each participating entity type) »Specifies whether the existence of an entity depends on another entity »Two different types –Total (called existence dependency), e.g., EMPLOYEE in WORKS_FOR –Partial, e.g., EMPLOYEE in MANAGES

DatabaseIM ISU27 ER Model Concepts – Relationships (cont.)

DatabaseIM ISU28 ER Model Concepts – Relationships (cont.)

DatabaseIM ISU29 ER Model Concepts (cont.)  Weak entity types  Entity types that does not have a key attribute  Entity types that have a key attribute are called regular (or strong) entity types  A weak entity type must participate in an identifying relationship type with an owner (identifying entity type)  A weak entity type always has a total participation constraint

DatabaseIM ISU30 ER Model Concepts (cont.)  Example »Suppose that a DEPENDENT entity is identified by –the dependent's first name and birthdate –the specific EMPLOYEE the dependent is related to »DEPENDENT is a weak entity type –EMPLOYEE as its identifying entity type –via the identifying relationship type DEPENDENT_OF

DatabaseIM ISU31 Notation Summary for ER Diagrams

DatabaseIM ISU32 Notation Summary for ER Diagrams (cont.)

DatabaseIM ISU33 Notation Summary for ER Diagrams (cont.)

DatabaseIM ISU34 Alternative Notation for ER Diagrams  Alternative notation for relationship structural constraints  Associate (min, max) with each participation of an entity type E in a relationship type R »Each entity e in E participates in at least (min) and at most (max) relationship instances in R »Default (no constraint): min = 0, max = n »Must have 0 1 »min = 0 implies partial, min > 0 implies total

DatabaseIM ISU35 Alternative Notation for ER Diagrams (cont.) Read the min,max numbers next to the entity type and looking away from the entity type

DatabaseIM ISU36 Notation for ER Diagrams (cont.)

DatabaseIM ISU37 ER Conceptual Design  Design Paradigm  Initial design »Identify all entity types and their attributes  Iterative refinement »Refine the attribute that are reference to another entity into a relationship »An attribute in several entity types may be refined into its own entity type –e.g., Department in STUDENT, INSTRUCTOR, and COURSE »An inverse refinement to the previous case may be applied

DatabaseIM ISU38 ER Conceptual Design (cont.)  Example: An company database  Initial design

DatabaseIM ISU39

DatabaseIM ISU40 ER Conceptual Design (cont.)  Refinement We specify the following relationship types »MANAGES, 1:1 (EMPLOYEE:DEPARTMENT) »WORKS_FOR, 1:N (DEPARTMENT: EMPLOYEE) »CONTROLS, 1:N (DEPARTMENT:PROJECT) »SUPERVISION, 1:N (EMPLOYEE:EMPLOYEE) »WORKS_ON, M:N (EMPLOYEE:PROJECT) »DEPENDENTS_OF, 1:N (EMPLOYEE: DEPENDENT)

DatabaseIM ISU41 ER Conceptual Design (cont.)  In the refined design, some attributes from the initial entity types are refined into relationships:  Manager of DEPARTMENT -> MANAGES  Works_on of EMPLOYEE -> WORKS_ON  Department of EMPLOYEE -> WORKS_FOR  In general, more than one relationship type can exist between the same participating entity types  relationship types MANAGES and WORKS_FOR between EMPLOYEE and DEPARTMENT

DatabaseIM ISU42 Higher Degree Relationship  Binary relationship vs ternary (or n-ary) relationship  A ternary relationship type  three binary relationship types  cp. Fig. 4.13, (s, p), (j, p), (s, j)  (s, j, p)  In general, a ternary relationship type represents more information than do three binary relationship types »e.g., quantity, supply date

DatabaseIM ISU43 Higher Degree Relationship (cont.)

DatabaseIM ISU44 Higher Degree Relationship (cont.)  In case that only binary relationships are permitted, a ternary relationship must be »represented as a weak entity type with no partial key, and »with three identifying relationships  It is often tricky to decide when to use binary or n-degree relationship representation

DatabaseIM ISU45 Higher Degree Relationship (cont.)

DatabaseIM ISU46 Higher Degree Relationship (cont.) »(i, c, s) => (i, c), (i, s), (c, s) »(i, c), (i, s), (c, s)  (i, c, s)

DatabaseIM ISU47 Higher Degree Relationship (cont.)  Constraints on ternary (or n-ary) relationships  Cardinality ratio  Participation constraint »Partial »Total  (min, max) notation

DatabaseIM ISU48 Chapter Summary  ER Model Concepts: Entities, attributes, relationships  Constraints in the ER model  Using ER in step-by-step conceptual schema design for the COMPANY database  ER Diagrams - Notation  Alternative Notations