Upload
brendan-watts
View
223
Download
0
Embed Size (px)
Citation preview
IM ISU 1Database
Fundamentals of Database Systems
Chapter 3
Data Modeling Using Entity-Relationship Model
IM ISU 2Database
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
IM ISU 3Database
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
IM ISU 4Database
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-R
elationship model Used as a reference to communicate with nontechni
cal users Modifications to the conceptual schema can be intro
duced when some functional requirements cannot be specified
IM ISU 5Database
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
IM ISU 6Database
IM ISU 7Database
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
IM ISU 8Database
Example Database (cont.)
IM ISU 9Database
ER Model Concepts
Entities and Attributes Entities are specific objects or things in the m
ini-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’
IM ISU 10Database
ER Model Concepts (cont.)
Two example entities
IM ISU 11Database
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 attrib
utes may have multiple values, e.g., Expert
IM ISU 12Database
ER Model Concepts (cont.) An example hierarchy of composite attributes
IM ISU 13Database
ER Model Concepts (cont.)
Stored vs Derived» In some case, two (or more) attributes are related» Age (derived attribute) can be derived from the B
irthDate attribute (stored attribute)
Complex » In general, composite and multi-valued attributes
may be nested arbitrarily » e.g., AddressPhone for a person
IM ISU 14Database
ER Model Concepts (cont.)
Entity Types and Key Attributes Entities with the same basic attributes are gro
uped or typed into an entity type, e.g, EMPLOYEE type
Key attribute» An attribute for which each entity must have a un
ique value, e.g, SSN for EMPLOYEE» A key attribute may be composite» An entity type may have more than one key attrib
utes, e.g, VehicleId, Registration
IM ISU 15Database
ER Model Concepts (cont.)
IM ISU 16Database
ER Model Concepts (cont.)
IM ISU 17Database
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
IM ISU 18Database
Displaying an Entity type (cont.)
Example diagram for CAR entity type
IM ISU 19Database
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
IM ISU 20Database
ER Model Concepts – Relationships
Relationships and Relationship Types A relationship relates two or more distinct ent
ities 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
IM ISU 21Database
ER Model Concepts – Relationships
(cont.)
IM ISU 22Database
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
IM ISU 23Database
ER Model Concepts – Relationships
(cont.)
IM ISU 24Database
ER Model Concepts – Relationships
(cont.) Recursive relationships: A relationship relate t
wo entities of the same entity type (participates in different roles)» e.g., SUPERVISION: relates relates one EMPLO
YEE (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
IM ISU 25Database
ER Model Concepts – Relationships
(cont.)
IM ISU 26Database
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
IM ISU 27Database
ER Model Concepts – Relationships
(cont.)
IM ISU 28Database
ER Model Concepts – Relationships
(cont.)
IM ISU 29Database
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
IM ISU 30Database
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
IM ISU 31Database
Notation Summary for ER Diagrams
IM ISU 32Database
Notation Summary for ER Diagrams (cont.)
IM ISU 33Database
Notation Summary for ER Diagrams (cont.)
IM ISU 34Database
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 < min < max, max > 1» min = 0 implies partial, min > 0 implies total
IM ISU 35Database
Alternative Notation for ER Diagrams (cont.)
Read the min,max numbers next to the entity type and looking away from the entity type
IM ISU 36Database
Notation for ER Diagrams (cont.)
IM ISU 37Database
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
IM ISU 38Database
ER Conceptual Design (cont.)
Example: An company database Initial design
IM ISU 39Database
IM ISU 40Database
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)
IM ISU 41Database
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
IM ISU 42Database
Higher Degree Relationship
Binary relationship vs ternary (or n-ary) relationship A ternary relationship type three binary relat
ionship types cp. Fig. 4.13, (s, p), (j, p), (s, j) (s, j, p) In general, a ternary relationship type represent
s more information than do three binary relationship types» e.g., quantity, supply date
IM ISU 43Database
Higher Degree Relationship (cont.)
IM ISU 44Database
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
IM ISU 45Database
Higher Degree Relationship (cont.)
IM ISU 46Database
Higher Degree Relationship (cont.)
» (i, c, s) => (i, c), (i, s), (c, s)» (i, c), (i, s), (c, s) (i, c, s)
IM ISU 47Database
Higher Degree Relationship (cont.)
Constraints on ternary (or n-ary) relationships Cardinality ratio Participation constraint
» Partial» Total
(min, max) notation
IM ISU 48Database
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