+ All Categories
Home > Documents > Lecture 9: Conceptual Database Design January 27 th, 2003.

Lecture 9: Conceptual Database Design January 27 th, 2003.

Date post: 23-Dec-2015
Category:
Upload: nickolas-hunter
View: 218 times
Download: 0 times
Share this document with a friend
Popular Tags:
39
Lecture 9: Conceptual Database Design January 27 th , 2003
Transcript
Page 1: Lecture 9: Conceptual Database Design January 27 th, 2003.

Lecture 9:Conceptual Database Design

January 27th, 2003

Page 2: Lecture 9: Conceptual Database Design January 27 th, 2003.

Building an Application with a DBMS

• Requirements modeling (conceptual, pictures)– Decide what entities should be part of the application and

how they should be linked.

• Schema design and implementation– Decide on a set of tables, attributes.

– Define the tables in the database system.

– Populate database (insert tuples).

• Write application programs using the DBMS– way easier now that the data management is taken care of.

Page 3: Lecture 9: Conceptual Database Design January 27 th, 2003.

Database Design

• Why do we need it?– Agree on structure of the database before

deciding on a particular implementation.

• Consider issues such as:– What entities to model– How entities are related– What constraints exist in the domain– How to achieve good designs

Page 4: Lecture 9: Conceptual Database Design January 27 th, 2003.

Database Design Formalisms1. Object Definition Language (ODL):

– Closer in spirit to object-oriented models

– I don’t teach it anymore.

2. Entity/Relationship model (E/R):– More relational in nature.

• Both can be translated (semi-automatically) to relational schemas

• ODL to OO-schema: direct transformation (C++ or Smalltalk based system).

Page 5: Lecture 9: Conceptual Database Design January 27 th, 2003.

2. Entity / Relationship Diagrams

Entities

Attributes

Relationships between entities

Product

address

buys

Page 6: Lecture 9: Conceptual Database Design January 27 th, 2003.

Keys in E/R Diagrams

• Every entity set must have a key

Product

name category

price

Page 7: Lecture 9: Conceptual Database Design January 27 th, 2003.

address name ssn

Person

buys

makes

employs

CompanyProduct

name category

stockprice

name

price

Page 8: Lecture 9: Conceptual Database Design January 27 th, 2003.

What is a Relation ?

• A mathematical definition:– if A, B are sets, then a relation R is a subset of

A x B

• A={1,2,3}, B={a,b,c,d}, R = {(1,a), (1,c), (3,b)}

- makes is a subset of Product x Company:

1

2

3

a

b

c

d

A=

B=

makes CompanyProduct

Page 9: Lecture 9: Conceptual Database Design January 27 th, 2003.

Multiplicity of E/R Relations

• one-one:

• many-one

• many-many

123

abcd

123

abcd

123

abcd

Page 10: Lecture 9: Conceptual Database Design January 27 th, 2003.

address name ssn

Person

buys

makes

employs

CompanyProduct

name category

stockprice

name

price

What doesthis say ?

Page 11: Lecture 9: Conceptual Database Design January 27 th, 2003.

Multi-way RelationshipsHow do we model a purchase relationship between buyers,products and stores?

Purchase

Product

Person

Store

Can still model as a mathematical set (how ?)

Page 12: Lecture 9: Conceptual Database Design January 27 th, 2003.

Q: what does the arrow mean ?

A: if I know the store, person, invoice, I know the movie too

Rental

VideoStore

Person

Movie

Invoice

Arrows in Multiway Relationships

Page 13: Lecture 9: Conceptual Database Design January 27 th, 2003.

Q: what do these arrow mean ?

A: store, person, invoice determines movie and store, invoice, movie determines person

Rental

VideoStore

Person

Movie

Invoice

Arrows in Multiway Relationships

Page 14: Lecture 9: Conceptual Database Design January 27 th, 2003.

Q: how do I say: “invoice determines store” ?

A: no good way; best approximation:

Q: Why is this incomplete ?

Rental

VideoStore

Person

Movie

Invoice

Arrows in Multiway Relationships

Page 15: Lecture 9: Conceptual Database Design January 27 th, 2003.

Roles in Relationships

Purchase

What if we need an entity set twice in one relationship?

Product

Person

Store

salesperson buyer

Page 16: Lecture 9: Conceptual Database Design January 27 th, 2003.

Attributes on Relationships

Purchase

Product

Person

Store

date

Page 17: Lecture 9: Conceptual Database Design January 27 th, 2003.

Converting Multi-way Relationships to Binary

Purchase

Person

Store

Product

StoreOf

ProductOf

BuyerOf

date

Page 18: Lecture 9: Conceptual Database Design January 27 th, 2003.

From E/R Diagramsto Relational Schema

• Entity set relation

• Relationship relation

Page 19: Lecture 9: Conceptual Database Design January 27 th, 2003.

Entity Set to Relation

Product

name category

price

Product(name, category, price)

name category price

gizmo gadgets $19.99

Page 20: Lecture 9: Conceptual Database Design January 27 th, 2003.

Relationships to Relations

makes CompanyProduct

name category

Stock price

name

Makes(product-name, product-category, company-name, year) Product-name Product-Category Company-name Starting-year

gizmo gadgets gizmoWorks 1963

Start Year

price

(watch out for attribute name conflicts)

Page 21: Lecture 9: Conceptual Database Design January 27 th, 2003.

Relationships to Relations

makes CompanyProduct

name category

Stock price

name

No need for Makes. Modify Product:

name category price StartYear companyName

gizmo gadgets 19.99 1963 gizmoWorks

Start Year

price

Page 22: Lecture 9: Conceptual Database Design January 27 th, 2003.

Multi-way Relationships to Relations

Purchase

Product

Person

Storename price

ssn name

name address

Purchase( , , )

Page 23: Lecture 9: Conceptual Database Design January 27 th, 2003.

3. Design Principles

PurchaseProduct Person

What’s wrong?

President PersonCountry

Moral: be faithful!

Page 24: Lecture 9: Conceptual Database Design January 27 th, 2003.

Design Principles:What’s Wrong?

Purchase

Product

Store

date

personNamepersonAddr

Moral: pick the right kind of entities.

Page 25: Lecture 9: Conceptual Database Design January 27 th, 2003.

Design Principles:What’s Wrong?

Purchase

Product

Person

Store

dateDates

Moral: don’t complicate life more than it already is.

Page 26: Lecture 9: Conceptual Database Design January 27 th, 2003.

Modeling Subclasses

The world is inherently hierarchical. Some entities are special cases of others

• We need a notion of subclass.• This is supported naturally in object-oriented formalisms.

Products

Software products

Educational products

Page 27: Lecture 9: Conceptual Database Design January 27 th, 2003.

Product

name category

price

isa isa

Educational ProductSoftware Product

Age Groupplatforms

Subclasses in E/R Diagrams

Page 28: Lecture 9: Conceptual Database Design January 27 th, 2003.

Understanding Subclasses

• Think in terms of records:– Product

– SoftwareProduct

– EducationalProduct

field1

field2

field1

field2

field1

field2

field3

field4field5

Page 29: Lecture 9: Conceptual Database Design January 27 th, 2003.

Subclasses to Relations

Product

name category

price

isa isa

Educational ProductSoftware Product

Age Groupplatforms

Name Price Category

Gizmo 99 gadget

Camera 49 photo

Toy 39 gadget

Name platforms

Gizmo unix

Name Age Group

Gizmo todler

Toy retired

Product

Sw.Product

Ed.Product

Page 30: Lecture 9: Conceptual Database Design January 27 th, 2003.

Modeling UnionTypes With Subclasses

FurniturePiece

Person Company

Say: each piece of furniture is owned either by a person, or by a company

Page 31: Lecture 9: Conceptual Database Design January 27 th, 2003.

Modeling Union Types with Subclasses

Say: each piece of furniture is owned either by a person, or by a company

Solution 1. Acceptable, imperfect (What’s wrong ?)

FurniturePiecePerson Company

ownedByPerson ownedByPerson

Page 32: Lecture 9: Conceptual Database Design January 27 th, 2003.

Modeling Union Types with Subclasses

Solution 2: better, more laborious

isa

FurniturePiece

Person CompanyownedBy

Owner

isa

Page 33: Lecture 9: Conceptual Database Design January 27 th, 2003.

Constraints in E/R Diagrams

Finding constraints is part of the modeling process. Commonly used constraints:

Keys: social security number uniquely identifies a person.

Single-value constraints: a person can have only one father.

Referential integrity constraints: if you work for a company, it must exist in the database.

Other constraints: peoples’ ages are between 0 and 150.

Page 34: Lecture 9: Conceptual Database Design January 27 th, 2003.

Keys in E/R Diagrams

address name ssn

Person

Product

name category

price

No formal way to specify multiple keys in E/R diagrams

Underline:

Page 35: Lecture 9: Conceptual Database Design January 27 th, 2003.

Single Value Constraints

makes

makes

v. s.

Page 36: Lecture 9: Conceptual Database Design January 27 th, 2003.

Referential Integrity Constraints

CompanyProduct makes

CompanyProduct makes

Page 37: Lecture 9: Conceptual Database Design January 27 th, 2003.

Other Constraints

CompanyProduct makes<100

What does this mean ?

Page 38: Lecture 9: Conceptual Database Design January 27 th, 2003.

Weak Entity SetsEntity sets are weak when their key comes from otherclasses to which they are related.

UniversityTeam affiliation

numbersport name

Page 39: Lecture 9: Conceptual Database Design January 27 th, 2003.

Handling Weak Entity Sets

UniversityTeam affiliation

numbersport name

Convert to a relational schema (in class)


Recommended