Sei sulla pagina 1di 20

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

DATA MODELING USING THE ENTITY- RELATIONSHIP MODEL

Click here for audio-text lecture and feed it to the speech agent

Click here for part A of an audio lecture that can be played using RealPlayer

Click here for part B of an audio lecture that can be played using RealPlayer

Click here for part C of an audio lecture that can be played using RealPlayer

E-R model is a high-level conceptual model for database designC of an audio lecture that can be played using RealPlayer Example 1. COMPANY has departments

Examplemodel is a high-level conceptual model for database design 1. COMPANY has departments 2. Department has

1. COMPANY has departments

2. Department has name, number, manager

Manager is an employee Manager has starting date

Department has several locations

3. Department controls projects

Project has name, number, location

4. Employee has name, social security, number, address, salary, sex, birthdate.

5. Employee is in one department but may work on several projects

6. Hours each employee works on each project

7. Employee has supervisor

8. Employee has dependents with name, sex, birthdate, and relationship to employee.

Phases of database design (simplified):

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html ENTITIES AND ATTRIBUTES An entity is an object in the real

ENTITIES AND ATTRIBUTES

An entity is an object in the real world.ENTITIES AND ATTRIBUTES Each entity has properties, called attributes. A particular

Each entity has properties, called attributes.AND ATTRIBUTES An entity is an object in the real world. A particular entity has values

A particular entity has values for the attributes.real world. Each entity has properties, called attributes. Attributes may be: simple (atomic) (ZIP) composite (ADDRESS)

Attributes may be:A particular entity has values for the attributes. simple (atomic) (ZIP) composite (ADDRESS) single-valued

simple (atomic) (ZIP) composite (ADDRESS) single-valued (AGE) multivalued (DEGREES)

Derived attribute:(ADDRESS) single-valued (AGE) multivalued (DEGREES) AGE from BIRTHDATE Attributes may have NULL values unknown

AGE from BIRTHDATE

Attributes may have NULL values unknown not applicable(ADDRESS) single-valued (AGE) multivalued (DEGREES) Derived attribute: AGE from BIRTHDATE 2 of 20 09/21/2015 09:45 PM

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Entity-Relationship Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html 3 of 20 09/21/2015 09:45 PM

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html ENTITY TYPES An entity type is the set of entities having

ENTITY TYPES

ENTITY TYPES An entity type is the set of entities having the same

An entity type is the set of entities having the same attributes

We can describe an entity type by an entity type schema The real entities in the entity type are entity instances entity type <-> entity instances object type <-> object instances relation <-> tuples (relation instances) intension <-> extension

tuples (relation instances) intension <-> extension Two entity types and some of the member entities: 4
tuples (relation instances) intension <-> extension Two entity types and some of the member entities: 4

Two entity types and some of the member entities:

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html KEY ATTRIBUTE OF AN ENTITY TYPE A key attribute uniquely

KEY ATTRIBUTE OF AN ENTITY TYPE

KEY ATTRIBUTE OF AN ENTITY TYPE A key attribute uniquely identifies an entity The entity

A key attribute uniquely identifies an entity The entity type is (v1, v2) Suppose the entities are:

(1, A) (4, A) (5, B) The key attribute is the first attribute v1.

DOMAIN OF AN ATTRIBUTE The domain of v1 is {1,4,5} The domain of v2 is {A,B} CARTESIAN PRODUCT {1,4,5} X {A,B}

{1,A},{1,B},{4,A},{4,B},{5,A},{5,B}

The CAR entity type. Multivalued attributes are shown between braces {}. Components of a composite attribute are shown between ():

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE First we

INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE

INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE First we identify the entity types DEPARTMENT PROJECT

First we identify the entity types DEPARTMENT PROJECT EMPLOYEE DEPENDENT

Then we identify the attributes for each entity type Multivalued attributes, composite attributes, derived attributes, attributes with possible nulls Key attributes are identified or assumed. For example, we assume each project has a unique project_number Question: Why do we need key attributes?

we assume each project has a unique project_number Question: Why do we need key attributes? 6
we assume each project has a unique project_number Question: Why do we need key attributes? 6
we assume each project has a unique project_number Question: Why do we need key attributes? 6
we assume each project has a unique project_number Question: Why do we need key attributes? 6

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html Are there real life objects without key attributes?

Are there real life objects without key attributes?

RELATIONS, ROLES AND STRUCTURAL CONSTRAINTS

An entity type PARTICIPATES in a relationship type eg. EMPLOYEE and DEPARTMENT participate in the relationship WORKS_FORkey attributes? RELATIONS, ROLES AND STRUCTURAL CONSTRAINTS DEGREE: the number of participating entity types eg.

DEGREE: the number of participating entity types eg. WORKS_FOR has degree 2and DEPARTMENT participate in the relationship WORKS_FOR ROLE_NAME: the role each participating entity plays in a

ROLE_NAME: the role each participating entity plays in a relationship. eg. EMPLOYEE plays the role "employee" in WORKS_FOR relationshipof participating entity types eg. WORKS_FOR has degree 2 RECURSIVE ROLES: EMPLOYEE can play the role

RECURSIVE ROLES: EMPLOYEE can play the role of both "employee" and "supervisor"plays the role "employee" in WORKS_FOR relationship CONSTRAINTS: We use CARDINALITY RATIO to express a

CONSTRAINTS: We use CARDINALITY RATIO to express a constraint on a relationship type, such asthe role of both "employee" and "supervisor" 1:1 1:N M:N PARTICIPATION CONSTRAINTS: partial or total

1:1

1:N

M:N

PARTICIPATION CONSTRAINTS: partial or total PARTICIPATION CONSTRAINT An employee MUST work for a department An employee entity can exist only if it participates in a WORKS_FOR relationship instance Thus its participation is TOTALa constraint on a relationship type, such as 1:1 1:N M:N Only some employees manage departments

Only some employees manage departments The participation is PARTIAL

A formal constraint: (m, n) where m, n are number of times

PARTICIPATION CONSTRAINT

An employee MUST work for a department An employee entity can exist only if it participates in a WORKS_FOR relationship instance Thus its participation is TOTAL

Only some employees manage departments The participation is PARTIAL

A formal constraint: (min,max) where m, n are min and max number of times an entity participates in a relationship instance. For example, (0,10) means partial participation, and (1,max) means total participation.

Entity-Relationship Model

Some instances of the WORK_FOR relationship:

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

http://people.cs.pitt.edu/~chang/156/03ERmodel.html The ternary relationship SUPPLY: 8 of 20 09/21/2015 09:45

The ternary relationship SUPPLY:

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html The recursive relationship SUPERVISION - EMPLOYEE plays two

The recursive relationship SUPERVISION - EMPLOYEE plays two roles of "supervisor" and "supervisee":

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html The 1:1 relationship MANAGES, with partical participation of

The 1:1 relationship MANAGES, with partical participation of EMPLOYEE and total participation of DEPARTMENT:

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html The M:N relationship WORKS_ON: 11 of 20 09/21/2015 09:45 PM

The M:N relationship WORKS_ON:

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html ATTRIBUTES OF RELATIONSHIP TYPES An employee entity WORKS_ON

ATTRIBUTES OF RELATIONSHIP TYPES

An employee entity WORKS_ON a project The relationship is M:N If we want to keep track of the number of hours an employee works for a project, it is difficult to keep it as an attribute of the employee entity We can keep HOURS as an attribute of the WORKS_ON relationship type

An employee WORKS_FOR a department The relationship is N:1 If we want to keep track of the starting date of an employee working for a department, where do we keep it? IN SCHEMA DESIGN, THE DESIGNER MUST DECIDE WHERE TO KEEP ATTRIBUTES.

WEAK ENTITY TYPES

John Doe is an employee. He has a dependent Cindy Doe. Mary Doe is an employee. She has a dependent Cindy Doe. The two DEPENDENT entities are IDENTICAL!

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Such entity types are called WEAK ENTITY TYPES, where entities may not be distinct. (They still correspond to same real-life object) Weak entity type must be OWNED by some owner entity type. For example, the EMPYLOEE entity type owns the DEPENDENT entity type. How can you eliminate weak entity types?

INITIAL DESIGN OF COMPANY DATABASE

DEPARTMENT Name, Number, {Locations}, Manager, ManagerStartDate

PROJECT Name, Number, Location, ControllingDepartment

EMPLOYEE Name, SSN, Sex, Address, Salary, BirthData, Department, Supervisor, {WorksOn(Project, Hours)}

DEPENDENT Employee, DependentName, Sex, BirthDate, Relationship

Note: {} indicates multivalued attributes, and () indicates component attributes of a composite attribute

ADD RELATIONSHIP TYPES TO DATABASE SCHEMA

MANAGES (1:1) EMPLOYEE partial DEPARTMENT total Attribute: StartDate

WORKS_FOR (1:N) DEPARTMENT total EMPLOYEE total

CONTROLS (1:N) PROJECT total DEPARTMENT partial

SUPERVISION (1:N) EMPLOYEE partial EMPLOYEE partial

WORKS_ON (M:N)

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

EMPLOYEE total PROJECT total Attribute: Hours

DEPENDENTS_OF (1:N) EMPLOYEE partial DEPENDENT total (Weak Entity Type)

The ER Diagram

ER diagram is a graphical design tool

ER schema diagram for the COMPANY database:

design tool ER schema diagram for the COMPANY database: ER diaram for the COMPANY schema with

ER diaram for the COMPANY schema with all role names included and with structural constraints on relationships specified using the (min,max) notation:

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html Summary of ER diagram notation: 15 of 20 09/21/2015 09:45

Summary of ER diagram notation:

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html An example of ER diagram for the library is shown below,

An example of ER diagram for the library is shown below, where a key icon indicates the relationship is linked to the key attribute, and a ring icon indicates the relationship is linked to an attribute (which could be part of the key).

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html A TERNARY RELATIONSHIP TYPE IS NOT EQUIVALENT TO THREE

A TERNARY RELATIONSHIP TYPE IS NOT EQUIVALENT TO THREE BINARY RELATIONS

CAN_TEACH: relates a course to the instructors who can teach that course (i,c)TYPE IS NOT EQUIVALENT TO THREE BINARY RELATIONS TAUGHT_DURING: relates a semester to the instructors who

TAUGHT_DURING: relates a semester to the instructors who taught some course during that semester (i,s)a course to the instructors who can teach that course (i,c) OFFERED_DURING: relates a semester to

OFFERED_DURING: relates a semester to the courses offered during that semester by ANY instructor (s,c)who taught some course during that semester (i,s) OFFERS: relates an instrcutor who offers a course

OFFERS: relates an instrcutor who offers a course during a semester (i,c,s) Constraint: (i,c,s) cannot exist unless (i,c),(i,s),(s,c) exist, but converse is not true.courses offered during that semester by ANY instructor (s,c) The following figures illustrate (a) ternary relationship

The following figures illustrate (a) ternary relationship type SUPPLY; (b) three binary relationship types are not equivalent to one ternary relationship type SUPPLY; (c) another example of ternary versus binary relationship type:

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html A weak entitye type INTERVIEW with a ternary identifying

A weak entitye type INTERVIEW with a ternary identifying relationship type:

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Model http://people.cs.pitt.edu/~chang/156/03ERmodel.html THE UML MODEL The Unified Modeling Language(UML) is an

THE UML MODEL

The Unified Modeling Language(UML) is an object-oriented analysis and design that evolved as a result of the combined work of James Rumbaugh, Grady Booch, and Ivar Jacobson. In 1997, a UML consortium(which include Microsoft, Hewlett-Packard, Oracle, MCI Systemhouse, IBM, IntelliCorp and more) submitted the 1.1 version of the UML to the Object Management Group(OMG). Since then, UML has become a de facto standard in the software industry, and it continues to evolve.

For database modeling, the most useful part of UML is the Class Diagram and Object Diagram. We can use these diagrams for object-oriented database design.

An example of the conceptual design of a library information system

A library is planning to develop a library information system. This library will serve only registered students.

Each book has title, author, publisher, date-of-publication, ISBN number and a set of keywords. Each student has SSN, first name, last name, address, telephone number. A student can borrow a book for up to two weeks,

so it is necessary to keep track of the date-of-borrow. He can then renew the book for another two weeks.

Two renewals are allowed. After two renews, the student must return a borrowed book. If a book is overdue, the student must pay a fine of $0.5 a day.

ER Model for library information system

Entity-Relationship Model

http://people.cs.pitt.edu/~chang/156/03ERmodel.html

Entity type BOOK(ISBN,title,author,publisher,date-of-pub,{keywords}) Notice {keywords} is a multi-valued attribute. The key is ISBN.

Entity type STUDENT(SSN,fname,lname,address,telephone) The key is SSN.

Relation type BORROW(SSN,ISBN,date-of-borrow,no-of-renewal,fine)

The BORROW relation type is one-to-many. Participation of BOOK is partial Participation of STUDENT is partial

The UML Class Diagram

---------------

|

Borrow

|

------------------|-------------|-------------------------

|

-------------- | data-borrow |

1

|

N

|

SSN, ISBN

1

1

|

---------------

|

Student

|

| no-renewal

|

|

Book

|

|------------|

| telephone

|

|-------------|

| SSN

|

|

fine

|

|

ISBN

|

| fanme

|

|-------------|

|

author

|

| lname

|

| borrow()

|

|

title

|

| address

|

| renewal()

|

| publisher

|

| telephone

|

| cal-fine9)

|

| date-pub

|

|------------|

---------------

 

| keywords

|

| add()

|

|-------------|

| delete()

|

|

add()

|

--------------

| delete()

|

The UML Object Diagram

-------------------

---------------

--------------|Doe,book1: Borrow|-------------------------------

|

-------------------

|

|

-------------------

-------------

|

|book1: Book|

-------------|Doe,book2: Borrow|----------- | |

|

-------------------

|

--------------

-------------

|Doe: Student|

-------------

--------------

|book2: Book|

-------------