COP 5725 Fall 2012 Database Management Systems

(1)

COP 5725 Fall 2012

Database Management

Systems

(2)

Chap 2. Introduction to

Database Design

(3)

Database Design Steps

• Requirements Analysis

• Conceptual Database Design

– E/R model

• Logical Database Design

– E.g., relational data model

– Output: logical/conceptual schema

(4)

Purpose of E/R Model

• The E/R model allows us to sketch database designs.

– Kinds of data and how they connect.

• Designs are pictures called

entity-relationship diagrams

.

(5)

Entity Sets

•

Entity

= “thing” or object.

– A student

•

Entity set

= collection of similar entities.

– Students in UF

•

Attribute

= property of (the entities of) an entity set.

(6)

E/R Diagrams

• In an entity-relationship diagram:

– Entity set = rectangle.

– Attribute = oval, with a line to the rectangle representing its entity set.

(7)

Example: a Multi-attribute Key

Courses

dept _number hours room

(8)

A more fun Running Example

• Entity set Beers has two attributes, name and

manf (manufacturer).

• Each Beers entity has values for these two attributes, e.g. (Bud, Anheuser-Busch)

Beers

(9)

Relationships

• A relationship connects two or more

entity sets.

• It is represented by a diamond, with

(10)

Example

Drinkers like some beers. Frequents

(11)

Relationship Set

• For the relationship Sells, we might have a relationship set like:

Bar Beer

Joe’s Bar Bud

Joe’s Bar Miller

(12)

Attributes on Relationships

Bars _Sells Beers

(13)

Multiway Relationships

Bars _Beers

name addr _name _manf

license

(14)

A Ternary Relationship Set

Bar Drinker Beer

Joe’s Bar Ann Miller

Sue’s Bar Ann Bud

Sue’s Bar Ann Pete’s Ale

Joe’s Bar Bob Bud

Joe’s Bar Bob Miller

Joe’s Bar Cal Miller

(15)

Roles

• Sometimes an entity set appears more than once in a relationship.

• Label the edges between the

(16)

(17)

(18)

Many-Many Relationships

• Focus: binary relationships, such as

Sells between Bars and Beers.

• In a

many-many

relationship, an entity of either set can be connected to many entities of the other set.

(19)

(20)

Many-One / One-Many

Relationships

manyone

(21)

One-One Relationships

(22)

Representing “Multiplicity”

• In E/R, a many-one relationship is

represented by an arrow entering the

“one” side (i.e., at most one).

• Show a one-one relationship by arrows entering both entity sets.

• Rounded arrow = “exactly one,” i.e., at

(23)

Example (I)

Drinkers _Likes Beers

(24)

Example (II)

Manfs Best- Beers

(25)

Example (III)

Bars _Beers

name addr _name _manf

license

(26)

Weak Entity Sets

• Occasionally, entities of an entity set

need “help” to identify them uniquely.

Players Plays- Teams on

name number name

(27)

Weak Entity-Set Rules

• A weak entity set has one or more many-one relationships to other (supporting) entity sets.

– Not every many-one relationship from a weak entity set need be supporting.

– Many-one with total participation

(28)

Subclasses

Beers

Ales isa

name manf

(29)

Conceptual Design with E/R Model

• Choices in developing E/R diagram

– Avoid Redundancy

– Entity vs. Attribute

– Entity vs. relationship

(30)

Entity vs. Attributes

• Create an entity set representing values of the attribute.

• Make that entity set participate in the relationship.

Bars _Sells Beers

(31)

Entity vs. Attributes (II)

Bars _Sells Beers

Prices

Note convention: arrow from multiway relationship

(32)

Design Techniques

1. Avoid redundancy.

2. Don’t use an entity set when an

attribute will do.

(33)

Avoiding Redundancy

•

Redundancy

occurs when we say the

same thing in two or more different ways.

• Redundancy wastes space and (more importantly) encourages inconsistency.

(34)

Example (I)

Beers _ManfBy Manfs

(35)

Example (II)

Beers _ManfBy Manfs

name name

manf

(36)

Example (III)

Beers name

This design repeats the manufacturer’s address once for each beer and loses the address if there

(37)

Entity Sets Versus Attributes

• An entity set should satisfy at least one of the following conditions:

– It is more than the name of something; it has at least one nonkey attribute.

or

(38)

Example (I)

Beers _ManfBy Manfs

name

•Manfs deserves to be an entity set because of the nonkey attribute addr.

•

(39)

Example (II)

Beers name

There is no need to make the manufacturer an

(40)

Example (III)

Beers _ManfBy Manfs

name

Since the manufacturer is nothing but a name, and is not at the “many” end of any relationship,

(41)

Don’t Overuse Weak Entity Sets

• Beginning database designers often doubt that anything could be a key by itself.

– They make all entity sets weak, supported by all other entity sets to which they are linked.

• In reality, we usually create unique ID’s for

(42)

When Do We Need Weak Entity

Sets?

• The usual reason is that there is no global authority capable of creating

unique ID’s.

• Example: it is unlikely that there could be an agreement to assign unique

(43)

Key Constraints

• Key constraints on relations

– Superkeys

– Keys (minimal)/Candidate keys

– Primary keys

• Key constraints on relationships

– Many-One/One-Many

(44)

More IC: Participation Constraints

• Does every Manf have a Best-seller?

– _{If so, this is a}_{participation constraint}_{: the}

participation of Manf in Best-seller is said to be

total (vs. partial).

• Every Manf entity must appear in an instance of the Best Seller relationship.

(45)

IC in ER Model

• Constraints in the ER Model:

– _{A lot of data semantics can (and should)} be captured.

– _{But some constraints cannot be captured in} ER diagrams (e.g., functional

(46)

More example

Manages Departments Employees

(47)

At most, at least and exactly one!

Manfs Best- Beers

(48)

(49)

(50)

Aggregation

name Projects Sponsors

Employees

Monitors

lot ssn

(51)

Other Choices in E/R Design

• Attribute vs. Entity (more examples)

• Entity vs. Relationship

(52)

Entity vs. Attribute

• Should

price address

be an attribute / entity

1. If we have several prices per beer (e.g., seasonal) or several addresses per bar

2. If the structure (street, city, etc.) is important, e.g., we want to retrieve bars in a given city

3. otherwise, simpler representation (i.e., attribute) would better to avoid overhead

(53)

Entity vs. Relationship

• What if a manager gets a discretionary

budget that covers

all managed depts?

– Redundancy: dbudget

stored for each dept managed by manager. – Misleading: Suggests

dbudget associated with department-mgr

Employees Departments

(54)

Binary vs. Ternary Relationships

• If each policy is owned by just 1 employee, and each dependent is tied to the

covering policy • What are the

additional

constraints in the

age

policyid _cost

Beneficiary

(55)

Binary vs. Ternary Relationships

(Contd.)

• Previous example illustrated a case when two binary relationships were better than one ternary relationship.

• An example in the other direction: a ternary relation Favorite relates entities Drinkers,

(56)

Summary of Conceptual Design

• Conceptual design follows requirements analysis,

– Yields a high-level description of data to be stored • ER model popular for conceptual design

– Constructs are expressive, close to the way people think about their applications.

• Basic constructs: entities, relationships, and attributes (of entities and relationships).

(57)

Summary of ER (Contd.)

• Several kinds of integrity constraints can be expressed in the ER model: e.g.

key

constraints

,

participation

constraints

,

foreign

key constraints

.

– _{Some constraints (notably,} _{candidate keys}_,

(58)

Summary of ER (Contd.)

• ER design is

subjective

. There are often many ways to model a given scenario! Analyzing alternatives can be tricky,

especially for a large enterprise. Common choices include:

– Entity vs. attribute, entity vs. relationship,