Top Banner
Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011
28

Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Jan 17, 2016

Download

Documents

Arnold Austin
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Database Systems

Conceptual to Relational Modeling II

Lecture # 11Feb 25th 2011

Page 2: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

ER Model => Relational Model Step 1: Regular Entities (and Single-valued attributes). Step 2: Many-to-Many Relationships Step 3: Many-to-One Relationships Step 4: One-to-One Relationships Step 5: n-ary (m-way) relationships Step 6: Weak Entities Step 7: Multi-valued Attributes Step 8: Entity Subtypes and Super-types Step 9: Additional Constraints These steps may not be followed in the above sequence.

You may have to do step 6 before step 2, and so on.

Page 3: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

An Example

Contain

Prj_Manage

Proj_Work

SPJ_S

SPJ_P

SPJ_J

spj

QTY

emp_dep

emp_phone

QTYsupply

work_in

manage

Phone

phone

Sys_P

OS

App_P

Web

Programmer

language

Dependent

dnamegender

Project

J#JnameCity

Part

P#PnameColorWeightCity

Supplier

S#SnameStatusCity

Employee

E#FNMNLNSalarymanager

Department

D#DnameCity

Page 4: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 1: Regular Entities

Each regular entity type maps into a base table. Each simple attribute of the entity type maps to an

attribute of the table. Each composite attribute will be broken into many

simple attributes. We’ll treat Multi-valued attributes later. Derived attributes, by definition, can be derived, and

therefore are not necessary to be represented. The primary key of the entity type maps to the

primary key of the table.

Page 5: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 1: Example

Department {D#, Dname, City};Employee {E#, First, MI, Last, Salary, Manager};Supplier {S#, Sname, City, Status};Part {P#, Pname, Color, Weight, City};Project {J#, Jname, City};

Primary keys are underlined.

How about Employee Name and Phone?

Page 6: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 2: M-N Relationships Each Many-to-Many relationship type maps into a

table.

The primary key of this table is the combination of the primary keys of the participating entity types.

These are also foreign keys.

Attributes of the relationship type maps to attributes of the table, similar to those of regular entity types.

Page 7: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 2: Example

Proj_Work{E#, J#}Foreign key {E#} References Employee,

Foreign key {J#} References Project;SP {S#, P#, QTY}

Foreign key {S#} References Supplier,Foreign key {P#} References Part;

Contain {Cont_P#, Comp_P#, QTY}Foreign key {Cont_P#} References Part,Foreign key {Comp_P#} References Part;

Page 8: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 3: M-1Relationships

For each regular Many-to-One relationship type, introduce a foreign key in the table on the

“many” side that references the table on the “one” side. Do not need to introduce a separate table.

We’ll treat the identifying relationship of each weak entity type later.

Page 9: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 3: Example

Employee {Emp#, First, MI, Last, Salary, Manager, D#}

Foreign key {D#} references Department;

Project {J#, Jname, City, PrjMgr_E#}

Foreign key {PrjMgr_E#} references Employee;

Do we need tables for: Employee Prj_Manage Project Employee Work_In Department

Page 10: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 4: 1-1 Relationships

We treat One-to-One relationship similarly as we treat Many-to-One relationship.

We prefer to extend the entity type that has a “mandatory” participation in the relationship.

Page 11: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 4: Example

For Manage Relationship:

Department {Dept#, Dname, City, Manager_E#}Foreign key {Manager_E#} references

Employee;

However, both M-1 and 1-1 relationships can be treated as special cases of M-M relationships, so a separate table could be created for each relationship, no matter whether it’s M-M, M-1, or 1-1.

Page 12: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 5: M-Way relationships

The primary key of this table is the combination of the primary keys of the participating entity types.

These are also foreign keys.

Attributes of the relationship type maps to attributes of the table, similar to those of regular entity types.

Page 13: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 5: Example

SPJ {S#, P#, J#, QTY}

Page 14: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 6: Weak Entities

The identifying relationship of a weak entity is of course a Many-to-One relationship,

The weak entity type must have a “mandatory” participation in its identifying relationship.

Each weak entity type maps into a base table. Attributes are treated as usual. Introduce a foreign key that references the primary key of

its identifying entity type. The primary key is the primary key of its identifying entity

type plus its own partial key.

Page 15: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 6: Example

Dependent {E#, Dname, Gender}

Foreign key {E#} References Employee;

Page 16: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 7: Multi-valued Attributes Each multi-valued attribute maps into a separate table. The table has an attribute for each simple attribute of

the multi-valued attribute. Include also an attribute for the primary key of the entity

or relationship type that the attribute belongs to. This is also a foreign key. The primary key of this table is the combination of all the

attributes if the multi-valued attribute is simple. If the multi-valued attribute is composite, the primary

key of this table may be a combination of some of the attributes.

Page 17: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 7: Example

Emp_Phone{Emp#, Phone}Foreign key {Emp#} References Employee;

E.g. Customer has Cust#, name, multiple Credit Cards that have Card # and ExpirationCustomer {Cust#, name};Credit_Cards {Cust#, Card#, Expiration}

Foreign key {Cust#} References Customer;

Page 18: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 8: Entity Subtypes/Supertypes

The supertype maps into a base table.

Each subtype maps into another base table. The primary key is the same as the primary key of its

supertype. This is also a foreign key. Treat attributes that belongs to the subtype only as usual.

The primary key of the root entity propagates down a hierarchy of entity types.

Page 19: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 8: Example

Employee {E#, First, MI, Last, Salary, Manager, D#}

Foreign key {D#} references Department;Programmer {E#, Language}

Foreign key {E#} references Employee;SYS_Prog {E#, OS}

Foreign key {E#} references Programmer;APP_Prog {E#, Web_Based}

Foreign key {E#} references Programmer;

Page 20: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

The Relational Schema (So far)

Department {D#, Dname, City, Manager_E#}Foreign key {Manager_E#} references Employee;

Employee {E#, First, MI, Last, Salary, Manager, Dept#}Foreign key {D#} references Department;

Supplier {S#, Sname, City, Status};Part {P#, Pname, Color, Weight, City};Project {J#, Jname, City, Prj_Mgr_E#}

Foreign key {Prj_Mgr_E#} references Employee; Proj_Work {E#, J#}

Foreign key {E#} References Employee,Foreign key {J#} References Project;

Page 21: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

The Relational Schema (Cont.)SP {S#, P#, QTY}

Foreign key {S#} References Supplier,Foreign key {P#} References Part;

Contain {Cont_P#, Comp_P#, QTY}Foreign key {Cont_P#} References Part,Foreign key {Comp_P#} References Part;

SPJ {S#, P#, J#, QTY}Foreign key {S#} References Supplier,Foreign key {P#} References Part,Foreign key {J#} References Project;

Dependent {E#, Dname#, Gender}Foreign key {E#} References Employee;

Page 22: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

The Relational Schema (Cont.)

Emp_Phone {E#, Phone}Foreign key {E#} References Employee;

Programmer {E#, Language}Foreign key {E#} references Employee;

SYS_Prog {E#, OS}Foreign key {E#} references Programmer;

APP_Prog {E#, Web_Based}Foreign key {E#} references Programmer;

Totally 14 tables.

Page 23: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

SUPPLIER – PART DB

Supplier

S#

SNAME

STATUS

CITY

Part

P#

PNAME

COLOR

WEIGHT

CITY

SUPPLY

QTY

Page 24: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Additional Constraints

However, we haven’t treated the additional constraints.

Weight is a real number in [0, 10000]. QTY is a real number in [0, 60000]. QTY must be entered for SP. Color must be one of ('Red', 'Green', 'Blue', 'Yellow',

'White', 'Black', 'Other'). Sname does not have duplicates and must be entered. Suppliers in London must have status 20. No suppliers with status less than 20 can supply any part

in a quantity greater than 500.

Page 25: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Step 9: Additional Constraints

Supplier {S#, Sname, City, Status} Constraint NOT(

CITY='London' AND STATUS <> 20), Constraint Sname UNIQUE NOT NULL;

Part {P#, Pname, Color, Weight, City}Constraint Color IN ('Red', 'Green', 'Blue',

'Yellow', 'White', 'Black', 'Other'),Constraint Weight >= 0 AND Weight <= 10000;

Page 26: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Data Modeling Tools

A number of popular tools that cover conceptual modeling and mapping into relational schema design. Examples: ERWin, S- Designer (Enterprise Application Suite), ER- Studio, etc.

POSITIVES: serves as documentation of application requirements, easy user interface - mostly graphics editor support

Page 27: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Problems with Current Modeling Tools DIAGRAMMING

Poor conceptual meaningful notation. To avoid the problem of layout algorithms and aesthetics of

diagrams, they prefer boxes and lines and do nothing more than represent (primary-foreign key) relationships among resulting tables.(a few exceptions)

METHODOLGY lack of built-in methodology support. poor tradeoff analysis or user-driven design preferences. poor design verification and suggestions for improvement.

Page 28: Database Systems Conceptual to Relational Modeling II Lecture # 11 Feb 25 th 2011.

Some of the Currently Available Automated Database Design Tools

COMPANY TOOL FUNCTIONALITY

Embarcadero Technologies

ER Studio Database Modeling in ER and IDEF1X

DB Artisan Database administration and space and security management

Oracle Developer 2000 and Designer 2000

Database modeling, application development

Popkin Software System Architect 2001 Data modeling, object modeling, process modeling, structured analysis/design

Platinum Technology

Platinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus

Data, process, and business component modeling

Persistence Inc. Pwertier Mapping from O-O to relational model

Rational Rational Rose Modeling in UML and application generation in C++ and JAVA

Rogue Ware RW Metro Mapping from O-O to relational model

Resolution Ltd. Xcase Conceptual modeling up to code maintenance

Sybase Enterprise Application Suite Data modeling, business logic modeling

Visio Visio Enterprise Data modeling, design and reengineering Visual Basic and Visual C++