er modeli(diagrami) ne anglisht

7/28/2019 Er Modeli(Diagrami) Ne Anglisht

1/22


2/22

Phases of database design (simplified):

ENTITIES AND ATTRIBUTES

An entity is an object in the real world.

Each entity has properties, called attributes.

A particular entity has values for the attributes.

Attributes may be:simple (atomic) (ZIP)composite (ADDRESS)single-valued (AGE)


3/22


4/22

ENTITY TYPES

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 instancesobject type object instancesrelation tuples (relation instances)intension extension


5/22

Two entity types and some of the member entities:

KEY ATTRIBUTE OF AN ENTITY TYPE

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


6/22

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 acomposite attribute are shown between ():

INITIAL CONCEPTUAL DESIGN OF THE

COMPANY DATABASE


7/22

First we identify the entity types DEPARTMENTPROJECTEMPLOYEEDEPENDENT

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?

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_FOR

DEGREE: the number of participating entity types eg. WORKS_FOR has degree 2

ROLE_NAME: the role each participating entity plays in a relationship. eg. EMPLOYEE plays the role "employee" in WORKS_FOR relationship

RECURSIVE ROLES: EMPLOYEE can play the role of both "employee" and "supervisor"

CONSTRAINTS: We use CARDINALITY RATIO to express a constraint on a relationshiptype, such as1:11:NM:N

PARTICIPATION CONSTRAINTS: partial or total PARTICIPATION CONSTRAINT

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

Only some employees manage departmentsThe participation is PARTIAL


8/22

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

PARTICIPATION CONSTRAINT

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

Only some employees manage departmentsThe 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.


9/22

Some instances of the WORK_FOR relationship:

The ternary relationship SUPPLY:


10/22

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


11/22

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


12/22


13/22

The M:N relationship WORKS_ON:

ATTRIBUTES OF RELATIONSHIP TYPES

An employee entity WORKS_ON a projectThe relationship is M:NIf 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 entityWe can keep HOURS as an attribute of the WORKS_ON relationship type

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


14/22

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!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 EMPYLOEEentity type owns the DEPENDENT entity type.How can you eliminate weak entity types?

INITIAL DESIGN OF COMPANY

DATABASEDEPARTMENTName, Number, {Locations}, Manager, ManagerStartDate

PROJECTName, Number, Location, ControllingDepartment

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

DEPENDENTEmployee, DependentName, Sex, BirthDate, Relationship

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

ADD RELATIONSHIP TYPES TO

DATABASE SCHEMA

MANAGES (1:1)EMPLOYEE partialDEPARTMENT totalAttribute: StartDate


15/22

WORKS_FOR (1:N)DEPARTMENT totalEMPLOYEE total

CONTROLS (1:N)PROJECT totalDEPARTMENT partial

SUPERVISION (1:N) EMPLOYEE partialEMPLOYEE partial

WORKS_ON (M:N)EMPLOYEE totalPROJECT totalAttribute: Hours

DEPENDENTS_OF (1:N)EMPLOYEE partial

DEPENDENT total(Weak Entity Type)

The ER DiagramER diagram is a graphical design tool

ER schema diagram for the COMPANY database:


16/22

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


17/22

Summary of ER diagram notation:


18/22

An example of ER diagram for the library is shown below, where a key icon indicates therelationship is linked to the key attribute, and a ring icon indicates the relationship is linked to an


19/22

attribute (which could be part of the key).

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)

TAUGHT_DURING: relates a semester to the instructors who taught some course duringthat semester(i,s)


20/22

OFFERED_DURING: relates a semester to the courses offered during that semester by ANYinstructor(s,c)

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.

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


21/22

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

THE UML MODELThe Unified Modeling Language(UML) is an object-oriented analysis and design that evolved asa result of the combined work of James Rumbaugh, Grady Booch, and Ivar Jacobson. In 1997, aUML 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 itcontinues 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
http://www.cs.pitt.edu/~chang/163/UML/class.htmlhttp://www.cs.pitt.edu/~chang/163/UML/class.html


22/22

A library is planning to develop a library information system. This library will serve onlyregistered students. Each book has title, author, publisher, date-of-publication, ISBN number anda set of keywords. Each student has SSN, first name, last name, address, telephone number. Astudent 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 tworenews, the student must return a borrowed book. If a book is overdue, the student must pay afine of $0.5 a day.

ER Model for library information system

Entity type BOOK(ISBN,title,author,publisher,date-of-pub,{keywords}) Notice {keywords} is amulti-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 ofSTUDENT is partial

The UML Class Diagram---------------

| Borrow |

------------------|-------------|-------------------------1 | N | SSN, ISBN | 1 1 |

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

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

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

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

| -------------|Doe,book2: Borrow|----------- |book1: Book|

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

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

|Doe: Student| -------------

-------------- |book2: Book|

--

er modeli(diagrami) ne anglisht

Documents