Advanced Database Design

IT 4153 Advanced Database

J.G. Zheng Spring 2012

Overview
EER
Database modeling and design issues at the conceptual and logical level

EER
Extended (or enhanced) entity relationship (EER) model

A conceptual data model incorporating extensions to the original ER model, used in the design of databases. It was developed to add more semantic constructs found in relationships. Includes all of the concepts introduced by the ER model. Additionally it includes the concepts of subtypes and supertypes, along with the concepts of specialization and generalization.
3

Super and Sub Types

A Sub-type is a special case, or a category, of a Super-type

Student Graduates, Undergraduates Employee full-time, part-time, contractor Customer : individual, company, non-profit

Sub-Type Completeness
Completeness

Is every super type instance in at least one sub-type entity?

Participant Employee

Organization

Individual

Student Employee
5

Sub-Type Disjointness
Disjointness: does any instance appear in multiple subtype entities?

Yes: No:

Overlap (Inclusive) Disjoint (Exclusive)

When to use sub-type (specification)?

When there are attributes that apply to some (but not all) of the instances of an entity type

When to use sub-type (specification)?

When instances of a subtype participate in a relationship unique to that subtype

When to use super-type (generalization)?

When several entities have same major attributes, see if they are constantly treated together.

Faculty, staff, student assistant Employee, customer, business partner (or, supplier)

Multiple entities participate in a common relationship with the same entity (also see modeling issue #8)
Donation Made by Organization

Made by

Individual
9

Relational Model for EER

Generally each supertype or subtype is transformed into a table, which shares the same primary key
A discriminator is added to the super type table.

Disjoint: one column Overlap: multiple columns

10

Practical Design Issues

Table and column
1.
2. 3.

Columns or tables Fields or values (columns or rows) Primary key selection issues

Relationship and constraints

4. 5. 6.

7.
8.

Minimum cardinality design Fan trap Redundant relationship Ternary relationships Identical relationships

Specific data structure and requirements

9.
10.

Time variant data Hierarchies

11

Issue #1: Column(s) or Table

What data structure level to use for the following data?

Company, Department, ZIP, etc. Composite attribute: an attribute that can be further divided into more attributes Multi-Value Attribute: an attribute that allow multiple values
Example: skills, phone numbers, etc. Example: Name, Address, Date, etc.

Depending on business requirements and contexts

12

Issue #2: Fields or Values?

How to model the following scenario?

Contacts
A sales person can be contacted by Fax Number, Cell

Phone Number, Home Phone Number, Work Phone Number, Work Email, etc.

Advising Hours
Faculty members have specific advising hours on 5

week days: Monday, Tuesday, etc.

Entity-attribute-value model

http://en.wikipedia.org/wiki/Entity-attributevalue_model
13

Issue #3: What's a Good PK?

14

Surrogate Key When (Not)?

Its common to add a surrogate key to replace the composite key in intersection tables

Also use surrogate key when a composite primary key will be used as a foreign key

This is much simpler

When not to use?

If there is a perfect natural key already If the composite key has critical information.
15

Issue #4: Minimum Cardinality

Minimum cardinality describes the minimum number of instances that must participate in a relationship for any one instance

0 (optional): participation in the relationship by the entity is optional. 1 (mandatory): participation in the relationship by the entity is mandatory.

How minimum cardinality affects modeling and design in 1:1 relationship How is minimum cardinality enforced?
16

Minimum Cardinality 1:0

When only one side is optional, foreign key is placed on the optional side, to avoid null values kind of like normalization. Example:

A locker is optional for an employee (an employee may not get one) An employee is mandatory for a locker (a locker has to be assigned to someone)

Lockers LockerNumber Size Location Assigned to / Have

Lockers is the optional side, which gets the foreign key

Employees EmployeeId FirstName LastName Gender

Employees (EmployeeId, FirstName, LastName, Gender) Lockers (LockerNumber, Size, Location, AssginedTo) FK: AssignedTo Employees.EmployeeId

17

Minimum Cardinality 0:0

When both sides are optional, foreign key is placed in the table which causes minimum null values Or, create a new intersection table kind of like normalization. Example:

A locker is optional for an employee (an employee may not get one) An employee is optional for a locker (a locker may not be assigned to someone)

Lockers LockerNumber Size Location Assigned to / Have

Employees EmployeeId FirstName LastName Gender

Employees (EmployeeId, FirstName, LastName, Gender) Lockers (LockerNumber, Size, Location) LockerAssignment (LockerNumber, EmployeeId) FK: LockerNumber Lockers.LockerNumber FK: EmployeeId Employees.EmployeeId

The intersection table with two attributes: one is primary key and the other is unique.

Two foreign keys

18

Issue #5: Fan Trap

Avoid the Fan Trap

Ambiguous (broken) relationship between Department and Staff

19

Issue #6: Redundant Relationship

Entities can be related indirectly by two relationships. A relationship is redundant if it can be completely represented by alternate transitive relationships Is this relationship
redundant?

Department

admits

Student

offer

Program

admit

Can Department and Student be related indirectly through these two relationships?

20

Redundant Relationship?

Database Modeling and Design: Logical Design, 4th Edition by Toby J. Teorey, Sam S. Lightstone, and Tom Nadeau, 2005

21

Chasm Trap
Avoid the Chasm Trap

Ambiguous (broken) relationship between Branch and Property

22

Issue #7: Ternary Relationship

3 binary relationships or a ternary one?

Database Modeling and Design: Logical Design, 4th Edition by Toby J. Teorey, Sam S. Lightstone, and Tom Nadeau, 2005

23

Issue #8: Common relationship trap

Avoid the same (identical) relationship with multiple entities
Donation Made by Organization

Individual

Made by

Individual

DonatorId
Name Department Organization DonatorId Name Department

Donator
DonatorId

Donation
DonationId

Type

Amount
Date DonatedBy
24

Issue #9: Time Variant Data

Normally, existing attribute values are replaced with new value without regard to previous value Time-variant data:

Values change over time Must keep a history of data changes

Keeping history of time-variant data equivalent to having a multi-value attribute

25

Issue #10: Hierarchical Data (1)

If it involves multiple different entities

Use a chain of one-to-many relationship

26

Issue #10: Hierarchical Data (2)

If within the same entity

Adjacency list

Materialized path

27

Analysis and Modeling Tips

Modeling is an iterative refinement process; let entities, attributes, and relationships eventually emerge and refined

Start with entities and attributes first: look for basic and obvious facts or concepts; these are the preliminary entities and attributes. Determine how entities are related Refine relationships and check for common modeling traps. Add, combine, or split entities and attributes as needed. Check relationships and constraints after changes. Repeat some steps and refine the model until satisfactory.
Check for redundant relationships and missing relationships. Consider nery relationships if necessary Quickly identify binary relationships and maximum cardinality first. Identify minimum cardinality

View integration

Start with specific function areas (user views) and integrate them later

Ensure the consistency between requirements, ERD and the data dictionary
28