CS54-Data Modeling Using the Entity-Relationship Data B

8/8/2019 CS54-Data Modeling Using the Entity-Relationship Data B

http://slidepdf.com/reader/full/cs54-data-modeling-using-the-entity-relationship-data-b 1/35

1

Data Modeling Using the

Entity-Relationship (ER) Data Model

Phases of Database Design

yConceptual Design

yE-R model

Requirements

Definition

Develop

ER Model

Normalized

Tables

Design

Application

Steps in DB Design

Data-oriented approach - because data are more stable

than the functions (or processes) in an organization.



2

Database Design and Conceptual Data

Model

Analogous to analysis phase of software development

yRequirement Collection and Analysis

- Designers interview database users to understand and

document data requirements.

yFunctional Requirements- User defined operations to be applied on the database



3

Database Design and Conceptual

Data Model (contd.)

Conceptual Design

-Conceptual schema; a permanent description of database specifications.

- Capture the semantics of the data; description of data,

constraints, relationships

- No storage details needed



4

HISTORY OF DATA MODELS

Description in high-level model

- Close to the user' view of mini-world

- Abstract concepts

- Means of communication between the non-technical

users and the developer

- Allows user to influence design and is independent of

any particular DBMS.Entity Relationship Data Model

- developed by Peter Chen (1983)

- basis for ANSI IRDS (Dolk & Kirsch,1987

; Winkler 1989

)



5

Example COMPANY Database

Requirements for the COMPANY Database:

- The company is organized into DEPARTMENTs. Each

department has a name, number, and an employee whomanages 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. Eachproject has a name, number, and is located at a single

location.



6


(contd.)

- We store each EMPLOYEE'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.



7


(contd.)

- Each employee may have a number of DEPENDENTs.For each dependent, we keep their name, sex, birth date,

and relationship to the employee.



8

ER Model Concepts

(Popular Conceptual model)

Entities

Specific objects or things in the mini-world that arerepresented in the database; for example the EMPLOYEE

John Smith, the Research DEPARTMENT, the ProductX

PROJECT

Attributes

P roperties used to describe an entity (or relationship); for

example an EMPLOYEE entity may have a Name, SSN,

Address, Sex, BirthDate.



9

ER Model Concepts (contd.)

- 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'.

Domain

Possible values for an attribute; for example µM¶ and µF¶ for

the Sex attribute.



10


Types of Attributes:

- Simple: Each entity has a single atomic value for the

attribute; for example SSN or Sex. (i.e., single-valued)

- Composite: The attribute may be composed of several

components; for example Address(Apt#, House#, Street,

City, State, ZipCode, Country) or Name(FirstName,

MiddleName, LastName). Composition may form ahierarchy where some components are themselves

composite.



11


- Multi-valued: An entity may have multiple values for

that attribute; for example Color of a CAR or

PreviousDegrees of a STUDENT. Denoted as {Color} or

{PreviousDegrees}

In general, composite and multi-valued attributes may be

nested arbitrarily to any number of levels although this is

rare. For example, PreviousDegrees of a STUDENT is a

composite multi-valued attribute denoted by{PreviousDegrees(College, Year, Degree, Field)}.



12

Entity Types and Key Attributes

- Entities with the same basic attributes are grouped or

typed into an entity type. For example, the

EMPLOYEE entity type or the PROJECT entity type.

- An attribute of an entity type for which each entity

must have a unique value is called ak

ey attribute of the entity type. For example SSN of EMPLOYEE.



13

Entity Types and Key Attributes

(contd.)

- A key attribute may be composite. For example,

VehicleRegistrationNumber is a key of the CAR entity

type with components (Number, State).

- An entity type may have more than one key.

for example, the CAR entity type may have two keys: VehicleIdentificationNumber and

VehicleRegistrationNumber(Number, State).



14

Relationships and Relationship Types

- A relationship relates two or more distinct entities witha specific meaning; for example, EMPLOYEE John Smithworks on the ProductX PROJECT or EMPLOYEEFranklin Wong manages the Research DEPARTMENT.

- Relationships of the same type are grouped or typed into a relationship type. For example, the WORKS_ONrelationship type in which EMPLOYEEs and PROJECTsparticipate, or the MANAGES relationship type in which

EMPLOYEEs and DEPARTMENTs participate.



15

Relationships and Relationship Types

(contd.)

-The degree of a relationship type is the number of participating entity types. Both MANAGES andWORKS_ON are binary relationships.

- More than one relationship type can exist with thesame participating entity types; for example, MANAGESand WORKS_FOR are distinct relationships betweenEMPLOYEE and DEPARTMENT participate.



16

Structural Constraints and Roles

- A relationship can relate two entities of the same entity type ; for example, a SUPERVISION relationship typerelates one EMPLOYEE (in the role of supervisee ) to

another EMPLOYEE (in the role of supervisor ). This iscalled a recursive relationship type

- A relationship type can have attributes; for example,HoursPerWeek of WORKS_ON; its value for eachrelationship instance describes the number of hoursper week that an EMPLOYEE works on a PROJECT.



17


(contd.)

Structural constraints on relationships:

-Cardinality ratio (of a binary relationship):

1:1, 1:N, N:1, or M:N.

-Participation constraint(on each participating entity type): total (called existencedependency ) or partial.



18


(contd.)

Alternative (min, max) notation for relationshipstructural constraints:

- Specified on each participation of an entity type Ein a relationship type R.

- Specifies that 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 min<max, min>0, max>1.- Derived from the mini-world constraints.



19


(contd.)

Examples:

(a) A department has exactly one manager and an

employee can manage at most one department.

- Specify (1,1) for participation of EMPLOYEE inMANAGES

- Specify (0,1) for participation of EMPLOYEE inMANAGES



20


(contd.)

(b) An employee can work for exactly one department

but a department can have any number of employees.

- Specify (1,1) for participation of EMPLOYEE inWORKS_FOR- Specify (0,n) for participation of DEPARTMENT inWORKS_FOR



21

Weak Entity Types

An entity type that does not have a key attribute

A weak entity type must participate in an identifyingrelationship 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



22

Weak Entity Types (contd.)

Example:

Suppose that a DEPENDENT entity is identified by the

dependent's first name and birthdate, and the specificEMPLOYEE that the dependent is related to.DEPENDENT is a weak entity type with EMPLOYEE asits identifying entity type via the identifying relationshiptype DEPENDENT_OF



23

Relationships of Higher Degree

- Relationship types of degree 2 are called binary

- Relationship types of degree 3 are called ternary and of

degree n are called n-ary

- In general, an n-ary relationship is not equivalent to nbinary relationships



24

Enhanced Entity-Relationship Model

(Concepts/Features)

Subclass/subtype, superclass/supertype

Specialization -- define subclasses

Generalization -- define superclass

Constraints on Specialization

Disjointness (Disjoint or Overlap)

Completeness (Total or Partial Specialization)

Inheritance.

Hierarchies and Lattices

Union Types (Categories)



25

Enhanced ER Model (EER)

EER Model = ER Model + Extensions

Extensions:

- Subclass (Specialization)

- Superclass (Generalization)

- Category

- Attribute and Relation Inheritance



26

Subclass/Superclass

Subclass: Entities of an Entity type sharing a set of

attribute which are grouped together

Superclass: The µparent¶ entity type from whichsubclasses are formed

Class/Subclass relationship: Relationship between a

superclass and oneof the subclasses

Specialization: The process of forming subclasses

from a superclass



27

Subclass/Superclass (contd.)

Type Inheritance: Member of subclass possessing all

attributes and relationships of a member of superclass

Local Attributes: Attributes that apply only to

members of a subclass (a.k.a. specific attribute)

Local Relationships: Relationships applicable only to

members of a subclass(a.k.a. specific relationships)

Generalization: Process of forming a supercalss from

subclasses. (Functionally, inverse of specialization)



28

Specialization/GerneralizationCharacteristics

Several Specializations could be defined on the same

entity type (Superclass)

Specialization with single subclass is also permitted

Predicate-defined subclass: Specialization specified

by a condition on the valuesome attribute of

superclass. (a.k.a. condition-defined)

Defining predicate: Condition satisfied by allmembers of a predicate-defined subclass



29

Specialization/Gerneralization

Characteristics (contd.)

Attribute-defined specialization: All subclasses

having membership condition on the same attribute of

the superclass

Defining Attributes: No condition exists for determing

membership in the subclass



30

Specialization/GeneralizationConstriaints

Disjointness constraint: Subclasses of the

specialization must be disjoint (an entity is a member

of at most one subclass)

- Overlapping: Subclasses not constrained to be

disjoint

Completeness Constraint:

- Total: Every entity in superclass must be a member of some subclass (e.g.\{HOURLY\_EMPLOYEE,

SALARIED\_EMPLOYEE\}



31

Specialization/Generalization

Constriaints (contd.)

- Partial: An entity in superclass may not be a member

of any subclass

Disjointness and Completeness are independent.(leads to 4 possible constraints on specialization)

- Disjoint, Total

- Disjoint, Partial

- Overlapping, Total

- Overlapping, Partial



32

Specialization Hierarchies and Lattices

Subclass may have further subclasses, and so on.

Specialization Hierarchy: Every subclass participates

in only one class/subclass relationship Specialization Lattice: A subclass can participate in

more than one class/subclass relationship

Leaf Node: A class that has no subclass



33

Specialization Hierarchies and Lattices

(contd.)

Shared Subclass: A subclass with more than one

superclass

Multiple Inheritance: A shared subclass inheritingattributes and relationships from multiple (super )

classes



34

Union Type/Categories

Uniontype (Category): Subclass with class/subclass

relationship with more than one superclass of

different entity types

Category is a subset of the union of its superclass

An entity in Category is a member of only one of its

superclass

Category types: Total or Partial



35

Coincidences between the ER Model and the

Surface Structure of English

(P. Chen, 1983)Symbol ER Meaning English Equivalent

Entity

Attribute of:

Entity

Relationship

Relationship

Noun

Verb

Adjective

Adverb

Documents

CS54-Data Modeling Using the Entity-Relationship Data B