Meeting 1 - Translating ER Diagram - 2

5/27/2018 Meeting 1 - Translating ER Diagram - 2

1/65

Database Technologies

Thursday, 07.00 - 09.00 PM

Aditya Dimas Dewanto, S.T., M.T.

Lecturer

[email protected]

1


2/65

2

Type Percentage

FINAL EXAM (UAS) 30%

MID TERM (UTS) 30%

PROJECTS 40% (+ QUIZ & ACTIVITIES = 15%)

2

Course Assessment


3/653

Topics

10-3

Topic LectureNotes

Translation of ER & EER diagram into Relational Schema 1

Complex SQL Queries 2

The Function and Type of New Data 3

Triggers

Routine

4

Store Procedures

View Table

5

Cases Studies

Using Complex Queries

6

Distributed Database 7

Mid Exam


4/654

References

1.Adi Nugroho, 2004, Konsep Pengembangan Sistem Basis Data, PenerbitInformatika, Bandung.

2.Bambang Hariyanto, 2004, Sistem Manajemen Basis Data, PenerbitInformatika, Bandung.

3.Connoly, Thomas; Begg, Carolyn; Strachan, Anne, 2005; DatabaseSystems : A Practical Approach to Design, Implementation andManagement, 4thedition. Addison Wesley.

4.Courtney, James F; Paradice, David B, 1998; Database Systems forManagement, Times Mirror/Mosby College Publishing, Toronto.

5.Elmasri, Ramez; Navathe, Shamkant B., 2007, Fundamentals of

Database System, 5th

edition, The Benjamin/Cummings PublishingCompany, Inc., California.

6.Jeffrey A. Hoffer, Mary B. Prescott, dan Fred R. McFadden, 2007;Modern Database Management, 8th edition,

7. Raghu Ramakrishnan dan J. Gehrke, 2004, Sistem ManajemenDataBase, (terjemahan) edisi ke-3, McGraw Hill Education, USA.


5/655

Translation of ER/ERR-Diagram

into Relational Schema

Aditya Dimas Dewanto, S.T., M.T

Department of Informatics Engineering


6/656


7/6579.7


8/6589.8


9/6599.9


10/65

Relational Database Design byER- and EER-to-Relational

Mapping


11/65Chapter 7-11

The ERconceptualschemadiagram fortheCOMPANYdatabase.


12/65Chapter 7-12

Result ofmapping theCOMPANYER schemainto arelationalschema.

I Cl E i T f th


13/6513

In-Class Exercise: Transform thefollowing ERD to a relational

structure

EMPLOYEE

DIVISION

DEPARTMENT

SSN

EMP#

FNAME LNAME SALARY

JOBCODE

MARRIED-TO

BLDGDIVNAME

DIVNAME

DEPT#

DEPTNAME

DIRECT

WORK-INMANAGE

BELONG-TO


14/6514

Example Tables

EMP# SOCSEC FNAME LNAME SEX SPOUSE SALARY JOBCODE DIVNAME DEPT#

E1 123-45-6789 JACK SPRATT M E2 12,500 CLERK FINANCE D3

E2 987-65-4321 JANE SPRATT F E1 55,000 SALES MARKETING D1

E3 NULL DICK BUTKUS M NULL 44,000 SALES MARKETING D2

E4 458-22-1513 SAM SPADE M E5 12,800 NULL LEGAL D2

E5 321-47-1698 LAUREN BACALL F E4 19,500 PROG MARKETING D1

EMPLOYEE

DIVNAME DEPT# DEPTNAME MANAGER

FINANCE D3 COMPTROLLER E1

MARKETING D1 NORTHEAST SALES E3

MARKETING D2 SOUTHWEST SALES E9

RESEARCH D3 PRODUCT TEST NULL

LEGAL D2 INVESTIGATION E11

DEPARTMENT

DIVNAME DIRECTOR BUILDING

FINANCE E8 102

MARKETING E13 1000

RESEARCH E9 87

LEGAL E4 495

DIVISION


15/65

The EnhancedEntity-Relationship (EER)

Model


16/65

Outline

Subclasses, Superclasses and Inheritance

Specialization and Generalization

Constrains and Characteristics

Union


17/65

Subclasses, Superclasses andInheritance

In many cases an entity type has numerous subgroupingsof its entities that are meaningful and need to berepresented explicitly because of their significance tothe database application.

For example: EMPLOYEE may be further grouped into: SECRETARY, ENGINEER, TECHNICIAN,

Based on the EMPLOYEEs Job MANAGER

EMPLOYEEs who are managers SALARIED_EMPLOYEE, HOURLY_EMPLOYEE

Based on the EMPLOYEEs method of pay


18/65

Subclasses and Superclasses


19/65


We call each of these subgroupings a subclassof the EMPLOYEEentity type, and the EMPLOYEE entity type is called the superclassfor each of these subclasses.

These are called superclass/subclass(as well as simplyclass/subclass) relationships:

EMPLOYEE/SECRETARY EMPLOYEE/TECHNICIAN EMPLOYEE/MANAGER


20/65

Subclasses and SuperclassesExample

A salaried employee who is also an engineer belongs to

the two subclasses:

ENGINEER, and

SALARIED_EMPLOYEE

A salaried employee who is also an engineering

manager belongs to the three subclasses:

MANAGER,

ENGINEER, and

SALARIED_EMPLOYEE


21/65


An important concept associated with

subclasses is that of type inheritance

An entity that is member of a subclass inherits

All attributes of the entity as a member of the

superclass All relationships of the entity as a member of the

superclass


22/65


Example:

In the previous slide, SECRETARY (as well as

TECHNICIAN and ENGINEER) inherit theattributes Name, SSN, , from EMPLOYEE

Every SECRETARY entity will have values for

the inherited attributes Every SECRETARY entity will also keep all

relationships


23/65

Specialization

Specializationis the process of defining a setof subclassesof an entity type

The set of subclasses is based upon somedistinguishing characteristics of the entities inthe superclass

Example: {SECRETARY, ENGINEER, TECHNICIAN}is a specialization of EMPLOYEE based uponjob type.


24/65

Specialization

It may have several specializations of the samesuperclass

Example: Another specialization of EMPLOYEE based on

method of payis {SALARIED_EMPLOYEE,HOURLY_EMPLOYEE}.

The subset symbol on each line connecting asubclass to indicates the direction of thesuperclass/subclass relationship


25/65

Specialization

In summary, the specialization process

allows us to do the following:

Define a set of subclass of an entity type Establish additional specific attributes with

each subclass

Establish additional specific relationship

types between each subclass and other entity

types or other subclasses


26/65

Generalization

Generalization is the reverse of the

specialization process

Several classes with common features are

generalized into a superclass;

original classes become its subclasses


27/65

Generalization

Example: CAR, TRUCK generalized into

VEHICLE;

both CAR, TRUCK become subclasses of thesuperclass VEHICLE.

We can view {CAR, TRUCK} as a specialization

of VEHICLE

Alternatively, we can view VEHICLE as a

generalization of CAR and TRUCK


28/65

Generalization (2)

Displaying an attribute


29/65

Displaying an attribute-defined specialization in

EER diagrams


30/65

Example of overlapping total Specialization


31/65

Shared Subclass Engineering_Manager

Specialization /


32/65

Specialization /Generalization LatticeExample (UNIVERSITY)


33/65

Union

All of the superclass/subclass relationships wehave seen so far origin from a single superclass

Sometimes we may need more than one

superclass In this case, the subclass will represent acollection of objects that is a subset of theUNION of distinct entity types

We call such a subclassa UNION TYPE


34/65

Union

Example: In a database for vehicle

registration, a vehicle owner can be a

PERSON, a BANK (holding a lien on avehicle) or a COMPANY.

A UNION type called OWNER is created to

represent a subset of the unionof the threesuperclasses COMPANY, BANK, and PERSON

Two categories (UNION


35/65

Two categories (UNIONtypes): OWNER,

REGISTERED_VEHICLE


36/65

Shared Subclass Engineering_Manager


37/65

Chapter 7-37

EER diagramnotation foran attribute-definedspecializationon JobType.


38/65

Chapter 7-38

Options for mapping specialization or generalization.

(a) Mapping the EER schema in Figure 4.4 using option 8A.


39/65

Chapter 7-39

Generalization. (b) Generalizing CAR and TRUCK intothe superclass VEHICLE.


40/65

Chapter 7-40

Options for mapping specialization or generalization.

(b) Mapping the EER schema using option 8B.


41/65

Chapter 7-41

EER diagramnotation foran attribute-definedspecializationon JobType.


42/65

Chapter 7-42

A specializationlattice withmultipleinheritance for aUNIVERSITYdatabase.


43/65

Chapter 7-43

Mapping the EER specialization lattice usingmultiple options.

(


44/65

Chapter 7-44

Two categories (uniontypes): OWNER andREGISTERED_VEHICLE.

Mapping the EER


45/65

Chapter 7-45

Mapping the EERcategories (uniontypes) to relations.


46/65

Chapter 7-46

Mapping Exercise

FIGURE 7.7

An ER schema for a SHIP_TRACKING database.

Mapping a regular entity


47/65

47

(a) CUSTOMER

entity type withsimple

attributes

pp g g y

(b) CUSTOMER relation

Mapping a composite attribute


48/65

48

(a) CUSTOMER

entity type withcomposite

attribute

pp g p

(b) CUSTOMER relation with address detail

Mapping a multivalued attribute


49/65

49

Mapping a multivalued attribute

1tomany relationship between original entity and new relation

(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

Example of mapping a weak entity


50/65

50

(a) Weak entity DEPENDENT


51/65

51

Relations resulting from weak entity

NOTE: the domain constraint

for the foreign key should

NOT allow nullvalue if

DEPENDENT is a weak

entity

Foreign key

Composite primary key


52/65

52

Example of mapping a 1:M relationship

(a) Relationship between customers and orders

Note the mandatory one

M i h l i hi


53/65

53

Mapping the relationship

Foreign key


54/65

54

Mapping a binary 1:1 relationship

(a) Binary 1:1 relationship


55/65

55

Resulting relations

Example of mapping an M:N relationship


56/65

56

Example of mapping an M:N relationship

(a) ER diagram (M:N)

The Suppliesrelationship will need to become a separate relation


57/65

57

Three resulting relations

Newintersection

relationForeign key

Foreign key

Composite primary key

M i i ti tit


58/65

58 Prentice Hall, 2002

Mapping an associative entity

(a) Associative entity


59/65

59

Three resulting relations

Mapping a unary 1:N relationship


60/65

60

Mapping a unary 1:N relationship

(a) EMPLOYEE entity with

Manages relationship

(b) EMPLOYEErelation with

recursive foreign

key

Mapping a unary M:N relationship


61/65

61

pp g y p

(a) Bill-of-materials

relationships (M:N)

(b) ITEM andCOMPONENT

relations

Mapping a ternary relationship


62/65

62

(a) Ternary relationship with associative entity

Mapping the ternary relationship


63/65

63

Mapping the ternary relationship

Remember that the

primary key MUST be

unique

Supertype/subtype relationships


64/65

64

Supertype/subtype relationships

Mapping Supertype/subtype relationships to relations


65/65

Mapping Supertype/subtype relationships to relations

Documents

Meeting 1 - Translating ER Diagram - 2