93727885-Data-Model

Data Modeling and Database Design

Minder Chen, Ph.D.

[email protected]

is assigned to

contains

staffed by

subcontract

member

is a member of

belongs to

Employee

Employee number

First name

Last name

Employee function

Employee salary

Team

Team number

Specialty

Division

Division number

Division name

Division address

Task

Task name

Task cost

Project

Project number

Project name

Project label

Start date

End date

Customer

Customer number

Customer name

Customer address

Customer activity

Customer telephone

Customer fax

© Minder Chen, 1993~2002 Data Modeling - 2 -

Data Modeling and Database Design Course Outline

• INTRODUCTION – Introduction to Data Modeling – Database Development Life Cycle Overview

• ENTITY AND RELATIONSHIP – Develop the Subject Area Diagram – Develop Preliminary Data Model: Entity & Relationship

Identification • ATTRIBUTES AND SUBTYPES

– Attributes Identification and Definition – Develop Fully Attributed Data Model – Identifiers – Data Modeling Exercise – Partitioning and Entity Subtypes

• NORMALIZATION – Normalization – Normalization Exercise – De-normalization

• DATA MODEL EVALUATION AND MAPPING TO RELATIONAL DBMS – Refine a Data Model: Analysis and Simplification – Transform to Physical Data Base Design

• PowerDesigner: Data Architect • Pysical DB Design and Data Warehouse DB Design


References Data Modeling and Database Design 1. Batini, Ceri, Navathe, Conceptual Database Design, Redwood City, CA: The

Benjamin/Cummings Publishing Company, Inc., 1992. 2. Teorey, T. J., Database Modeling and Design: The Entity-Relationship

Approach, Morgan Kaufmann Publishers, Inc., 1990. 3. Thomas A. Bruce, Designing Quality Databases with IDEF1X Information

Models, Dorset House Publishing, NY: New York, 1991. 4. Texas Instruments, A Guide to IE Using IEF, 2nd edition, Part No. 2739756-0001,

1990. 5. Martin, James, Information Engineering Book II: Planning and Analysis,

Prentice-Hall Inc., 1989. 6. Dave Ensor, Ian Stevenson, Oracle Design, O'Reilly & Associates, 1997 7. Rob Gillette, etc., Physical Database Design for Sybase SQL Server, Prentice

Hall, 1995. 8. Ralph Kimball, The Data Warehouse Toolkit, Wiley, 1996. JAD References 1. August, J. H.. Joint Application Design: The Group Session Approach to

System Design. Englewood Cliffs, NY, Prentice Hall, Inc., 1991. 2. Wood, J. and Silver, D. Joint Application Design: How to Design Quality

Systems in 40% Less Time. New York, NY, John Wiley & Sons, 1989. 3. Andrews, D. C. and Leventhal, N. S., Fusion: Integrating IE, CASE, and JAD: A

Handbook for Reengineering the Systems Organization, Englewood Cliffs, NJ: Yourdon Press, 1993.


Data Modeling and Database Design: INTRODUCTION

• Systems Development Life Cycle (SDLC) in a Client/Server Environment

• Introduction to Data Modeling

• Database Development Life Cycle Overview


Rationales for Data Modeling

• Data is the foundation of modern information systems enabled by data base technologies.

• Data in an organization exist and can be described independently of how these data are used.

• Data should be managed as a corporate-wide resource.

• The types of data used in an organization do not change very much.

• Data have certain inherent properties which lead to correct structuring.

• If we structure data according to their inherent properties, the structure (i.e., data models) will be stable.


History of Data Modeling

• Importance of Entity-Relationship Modeling Technique – Database

– Data modeling and enterprise-wide data

– Data quality

– Data updating and accessing tools and procedure

– Data sharing culture

• ER modeling technique was first developed by Peter Chen in 1976 – A conceptual/logical data modeling tool

– A user-oriented approach

– A graphic-based method

• ER modeling technique is the major data modeling method in Information Engineering and is widely supported by most of CASE tools.

• Data modeling is the foundation of most database-centered transaction processing systems and data warehouse systems


CSC Development Strategies

• RE-CREATE new business process & systems from scratch

• RE-ENGINEER business process & systems

• RE-DESIGN current systems

• RE-HOST current systems

• RE-IMAGE current systems

HIGH

LOW

Risk

Long Term Reward

Short Term Costs

Degree of Change


Distribution of Business Function (Logic)

Data

Space

Presentation

Service

Presentation

Logic

Function

Logic

Data

Logic

Data

Service

Presentation

Space

Client Server

• Presentation logic

• Local input validation

• Output production logic

• Local peripheral drivers

• Performance critical processing

• Functions that access data

on the server

• Functions that need input

from multiple users

• Functions that coordinate

the work of several user

Issues: • Distribution of data

• Platform-specific capabilities and interoperability

• Connectivity capabilities/platform

• Frequency of change to codes

• Configuration management


C/S Development Methodology

User

Interface

Application

Logic

C/S

Architecture

Conceptual

Analysis Logical

Design

Physical

Design

SDLC

Work

Flow

Form

Sequences

Forms,

Screens

Process

Flow

Object

Interaction

Model

Programs,

Procedures

performance => rules=>

Source: David Vaskevitch, Client/Server Strategies, IDG Books, 1993.

Information

& Data Base

Data

Model

Database

Schema

Tables,

Indexes


Client/Server Application Development Methodology

Requirements

Information

& Data Base

Processes

Behavior

Workflow

User Interface Architecture

Application

Design and

Development

Source: David Vaskevitch, Client/Server Strategies, IDG Books, 1993.


Data Modeling (Data Base Design) Process

Information Requirements

Conceptual

DB Design

Logical

DB Design

Physical

DB Design

Conceptual (Enterprise) DB Schema

Logical DB Schema

Physical DB Schema

A conceptual DB schema is a high-

level description of the database,

independent of the particular DBMS.

A logical DB schema is a description of

the structure of the database that can be

processed by a DBMS: relational, network,

or hierarchical.

A physical DB schema is a description of the implementation of the database in external memory; it describes the storage structures and access methods used in order to effectively access and maintain data.

Source: Batini, C., Ceri, S., and Navathe, S. B., Conceptual Database Design: An Entity-

Relationship Approach, The Benjamin/Cummings Publishing Company, Inc., 1992.


Multiple Perspectives

DATA ACTIVITY

EMPLOYEE

HIRE

EMPLOYEE

PAY

EMPLOYEE

PROMOTE

EMPLOYEE

FIRE

EMPLOYEE

......

....

......

....

ONE

BUSINESS

We do these things

We use this data


Member Agreement is enrolled under;

applies to

Club

established by;

established

Member

Order

Product Promotion sponsors;

is sponsored by is featured in;

features

generates; generated by

sells;

is sold on

placed by;

places

Data Model (Entity Relationship Diagram)


Entity Relationship Diagram: Subject Area and Entity Type

• Subject Area and Subject Area Diagram

• Entity Types

• Entity Instances

• Finding Entity Types

• Evaluating Entity Types


Subject Area (Submodel)

• A natural area of interest to the business that is centered on a major resource, inputs, outputs, or activity of the business.

• It contains a set of entity types. • We start the data modeling in the ISP stage by identifying

subject areas with names and descriptions. • In BAA stage, subject areas are used to as high level

grouping of entity types. • Naming: a subject area is a noun in plural form and often

has the name as the central entity type in the subject area. • Examples:

Project Member Task

Project

Projects


Subject Area Diagram

Customers

Purchase

Orders Buyers

Raw-materials Products

Sales-persons

: Subject Area

: Association

Legends

Orders Suppliers


Entity Types

• Definition:

– An entity is an object or event, real or abstract, about which we would like to store data. Entity is the abbreviation of entity type. It represent a set of entity instances which can be described by the same set of attribute types. The value of the same attribute for each entity instance may be different.

• Identifying Entity Types

– What information is required by the business?

– Things that are of interest to the business that need to be remembered in order to manage and track them.

– Things belong to the same entity type have common characteristics.


Naming Entity Types

• The name of each entity is in singular form – a noun

– an adjective + a noun

– a noun + a noun => (noun string)

– an adjective + a noun + a noun

• Examples – Customer, Customer Order, Product, Hourly Employee, Project,

Department, Unfilled Customer Order

• Be clear and concise

• Avoid abbreviation

• Be consist with user’s terminology

• Identify synonyms – Customer Client

– Product Merchandise

– Supplier Vendor

– Teacher Faculty

• Use one name as the official name and document others as aliases


Exercise: Entity Type Naming

• Courses

• Department

• Customer Order

• PO


Properties of Entity Types

• Name

• Description

• Identifier

• Properties: Estimated number (Max., Min., Average) of entity instances

• Expected growth rate of entity instances

• Subject Area in which the Entity Type resides

• Attributes that describe the Entity Types

• Examples of entity type instances


Definition of an Entity Type

• A poor definition of Customer: Anyone that buys something from the company. – Can employees be a customer?

– Can a leasor be a customer?

– If the company sold a subsidiary to another company, does the new owner consider a customer?

• Good definition should be: – Compatible

– Precise

– Concise

– Clear

– Complete


Good Definition

• Compatible – Customer: An ORGANIZATION that purchase

PRODUCTs for personal use.

– Distributor: An ORGANIZATION that purchase PRODUCTs for resale.

• Precision: – With appropriate qualifiers

– Example: An ORGANIZATION is considered to have purchase a PRODUCT when we receive a valid PURCHASE ORDER from it.

• Complete – ORGANIZATION, PRODUCT, PURCHASE ORDER

need to be defined.

• Concise and Clear – Use modular definition


Example of Entity Type Descriptions

Entity Type Description

Customer Information about all persons or organizations who purchases

Product All goods manufactured and sold

Raw-material Components used to manufacture Products.

Supplier Vendors of Raw Materials.

Buyer Company personnel responsible for purchasing Raw-Materials from Suppliers


Entity Type and Entity Instance (Occurrence)

Entity Types Entity Instance

Vendor ABC Co.

Employee John Smith

Course Intro. to IE

Department Marketing Department


Exercise: Entity Types or Entity Instances?

• Maryland

• Organization Unit

• Customer

• President

• Bill Clinton

• Department of Commerce

• Address


Finding Entity Types

• Interviews with users

• JAD workshops

• Business forms

• Reports

• Computer files using reverse engineering

• Operation manuals


Where to Look for an Entity Type?

• Tangible or Intangible Things – The nouns that are used to describe the problem domain will often

correspond to the major Entity Types of the system, at least at a high level.

– Examples: Product, Sensor, and Employee, Department, and Sale Office.

• Resources – Any resources that an organization needs to manage should be

represented as an Entity Type. Information assists the efficient and effective use of other resources through improved decision.

– Examples: Inventory, Machine, Bank Account, and Customer.

• Roles Played – Roles can be played by persons or organizational units.

– Examples: Customers, Managers, and Account representatives.

• Events – Events are incidents that occur at points in time. An event often

involved an interaction between two Entity Types or an action that changes the status of an Entity Type.

– Examples: Sale, Delivery, and Registration of a motor vehicle.


BIAIT: Business Information Analysis and Integration Technique

• Analysis of Orders

• Ordered entities can be a thing, a space, or a skill.

• View the order from supplier side.

• If an organization receives no orders, it has no reason for existing.

• An organization unit can receive multiple types of orders.

• 4 questions about the Supplier: – Billing (Cash)?

– Deliver Late (Immediate)?

– Profile customer?

– Negotiate price (Fixed)?

• 3 questions about the Ordered Entity: – Rented (Sold)?

– Tracked?

– Made to order (Stock)?

Source: Carlson, W. M., "BIAIT: Business Information Analysis and Integration Technique - The New Horizon," Data Base, Vol. 10, No. 4, 1979, pp. 3-9.


Criteria for Evaluating an Entity Type

• Need to be remembered by the information system in order to be functional.

• Can be operated on: CREATE, READ, UPDATE, DELETE.

• Has a set of operations/services that always apply to change the status of each occurrence of an Entity Type.

• Carry a set of attributes that always apply to describe each occurrence of an Entity Type.

• Have at least one relationship with other entity type.

• Exist more than one entity occurrence (instance) in an Entity Type.

• Have at least a unique identifier.

• Domain-based requirements: Something that the system must have in order to operate. These may be clearly specified in the problem description or known from subject matter experts.


Entity Relationship Modeling and Diagramming

• Relationships

• Entity Relationship Diagramming Notation

• Attributes

• Identifiers

• Partitioning and Entity Subtypes


Relationship (Type)

• Definition

– A Relationship Type is an association among Entity Types. It indicates that there is a business relationship between these Entity Types.

– Relationship Membership is the participation of an Entity Type in a Relationship.

– In IE, a Relationship Type can involve only two Entity Types (binary relationship). Some other modeling techniques allow n-ary relationships.

• Examples

– CUSTOMER places ORDER

– ORDER is placed by CUSTOMER

– EMPLOYEE works on PROJECT

– PROJECT has project member EMPLOYEE


Paring (Relationship Instance)

Entity Types Entity Instance

Student Student#1

Student#2

Course

Course#A Course#B Course#C Course#D

Relationship Relationship Paring

Student

takes

Course

Student#1 takes Course#A Student#1 takes Course#B Student#1 takes Course#D Student#2 takes Course#A Student#2 takes Course#C Student#2 takes Course#D

• Relationship paring is a pair of Entity Instances of two Entity Types associated by a Relationship Type between these two Entity Types.


Relationship Instances Grouping

• Definition: A collection of pairings of a Relationship Membership in which an Entity Instance is involved.

• Examples: – Student#1 takes Course#A, #B, and #D

– Student#2 takes Course#A, #C, and #D

– Course#A is taken by Student#1 and Student#2


Relationship Cardinality

E1 E2

E1

E1

E2

E2

One-to-Many

Many-to-Many

One-to-One

1:1

1:M

M:N


Relationship Cardinality

• The number of Entity Instances involved in the Relationship Instances Grouping in a Relationship Type.

• Three Forms of Cardinality 1. One-to-one (1:1)

DEPARTMENT has MANAGER

Each DEPARTMENT has one and only one MANAGER

Each MANAGER manages one and only one DEPARTMENT

2. One-to-many (1:m)

CUSTOMER places ORDER

Each CUSTOMER sometimes (95%) place one or more ORDERs

Each ORDER always is placed by exactly one CUSTOMER

3. Many-to-many (m:n)

INSTRUCTOR teaches COURSE

Each INSTRUCTION teaches zero, one, or more COURSEs

Each COURSE is taught by one or more INSTRUCTORs


Entity Relationship Diagram (ERD): Notations

Entity-X Entity-Y relationship-description

reversed-relation-description

Example

Cardinality

indicator

Department Manager is-managed-by

manages

Translate into two structured statements

min max

zero one

many

Each Entity-X relationship-description cardinality-indicator (one-or-many) Entity-Y

Each Entity-Y reversed-relationship-description (zero-or-one) Entity-Y

Graphical Notations


Optionality of Relationship Memberships

• Whether all entity instances of both entity types need to participate in relationship pairing.

• Optionality:

– Mandatory

– Optional

• Example:

– CUSTOMER membership is optional

– ORDER membership is mandatory

CUSTOMER ORDER places

is placed by


Relationship Statements

CUSTOMER ORDER places

is placed by

Cardinality

indicator

one

one or more

Graphical Notations

Optionality

indicator

zero (sometimes)

one (always)

Each CUSTOMER sometimes places one or more ORDER.

Each ORDER always is placed by one CUSTOMER.

Each Entity X optionality relationship cardinality Entity Y


Defining Relationships

• Name

• Description

• Property – Cardinality volumes

– Optionality percentage: % of Entity Type X's instances pairing with Entity Type's Y's instances

– Transferability: A relationship is transferable if an entity instance can change its pairing within the same relationship. » TRANSFERABLE: An EMPLOYEE can change to a

different DEPARTMENT.

» NON-TRANSFERABLE: An ORDER cannot be transferred to another CUSTOMER.


ERD: More Examples

Employee

Project

manages

is-managed-by works-for

has-project-members

Part

is-consists-of

contained-in

Customer Order places

belongs-to

Product is-contained-in

contains

(a)

(b)

(c)

Involuted or Looped

Relationship

Parallel

Relationship


ERD: Alternative Notations

Order places

belongs-to

Alternative Notations:

Order places

belongs-to

Order

Customer

places Customer

belongs-to

Order places Customer 1 M

Customer


Identifying Relationships

• Association between entity types

• Entity types that are used on the same forms or documents.

• A description in a business document that has a verb that relates two entity types

– has

– consists of

– uses


Attributes

• Definition – Characteristics that could be used to describe Entity Types and

Relationship Types. However, in IE, relationship types are not allowed to have attributes.

• Naming Conventions: – Names that have business meaning – Don't use abbreviation or possessive case, e.g., PN and

Customer's name – Don't include entity type name because IEF will prefix the attribute

name with entity type name automatically – Use standard format: Entity Type Name (Qualifiers) Domain Name Customer Name Employee Starting Date

• Examples – Customer has customer name, address, and telephone number – Product has quantity-on-hand, weight, volume, color, and name. – Employee has SSN, salary, and birthday. – Employee-works-for-project has percentage-of-time, starting-date.


Attributes: Notations

Student

Student ID

Student Name

Birth date

Student ID

Course no.

Birth date

enrollment

Student(Student ID, Student Name, Birth Date)

Finding Attributes:

Attributes are identified progressively during BAA phase.

• Data Analysis

• Activity Analysis

• Interaction Analysis

• Current Systems Analysis

Employee

Employee number

First name

Last name

Employee function

Employee salary

studentID

name

phone

Student


Attribute Value

• Definition

– Attribute Values are instances of Attributes used to describe specific Entity Instances

• Examples

– Customer Number: 011334

– Customer Name: Minder Chen

– State: VA

– Order Total: $23,000

– Sale tax: $250

• An attribute of an entity type should have only one value at any given time. (No repeating group)

• Avoid using complex coding scheme for an attribute.

For example: PART Number: X-XXX-XXX

Part Type Material Sequence Number


Type & Instance

OBJECT TYPE OCCURRENCE

Entity Type Entity Instance

Entity Entity Instance

Entity Type Entity

Relationship (Type) Pairing (Relationship Instance)

Attribute (Type) (Attribute) Value


Attribute Source Categories

• Basic – Definition: An Attribute Value that cannot be deduced

or calculated.

– Examples: Student name and Birthday

• Derived – Definition: The Attribute Value can be calculated or

deduced from relationship Groupings or from the values of other Attributes. The value of a Derived Attribute changes constantly.

– Examples: Student Age, Account Balance, Number of courses taken.

• Designed – Definition: The Attribute is created to overcome the

system constraints. The value of a Designed Attribute does not change.

– Examples: Student ID, Course number.


Data Types


Properties of Attributes

• Name

• Description

• Attribute Source Category: Basic, Derived, Designed

• Domain or data type: Text, Number, Date, Time, Timestamp

• Optionality: Mandatory or optional

• Length and/or precision

• Permitted Values (Legal Values) – Ranges

– A set of values (Code Table)

• Default value or algorithm

Tools such as PowerBuilder has additional properties for table’s columns called extended attributes – Validation Rule

– Editing Format

– Reporting Format

– Column Heading

– Form Label

– Code Table


Composite Attribute

• Definition:

• Example:

– Telephone Number =

Area code + Exchange + Extension

• There is no support of composite attribute type most of CASE tools. In such case, an composite attribute must be stored as an entity type.


Domain

• A collection of values which can be taken by one or more attributes.

• Date is the domain for Ordered Date, Student's Birthday, Employee Starting Date.

• A used defined domain can have customized validation rules and formats.

• CASE tools such as IEF only supports the following basic domains:

– Text

– Number

– Date

– Time

– Timestamp


Identifiers

• The identifier of an entity type is a set of attributes and/or relationships whose values can uniquely identify an entity.

• Entity types should have one identifier.

• Identifiers may consist of – A single attribute: Student ID

– A set of attributes: Students ID + Course ID

– An attribute and a relationship membership (implemented as a foreign Key): Order Item No + Order Has Order Item


Identifying Relationship

order order

item is part of

contains

customer product

places

is placed by

is ordered by

has

ORDERS

Symbol for

Identifying Relationship


Data Modeling Case Study The following is description by a pharmacy owner:

"Jack Smith catches a cold and what he suspects is a flu virus. He makes an appointment with his family doctor who confirm his diagnosis. The doctor prescribes an antibiotic and nasal decongestant tablets. Jack leaves the doctor's office and drives to his local drug store. The pharmacist packages the medication and types the labels for pill bottles. The label includes information about customer, the doctor who prescribe the drug, the drug (e.g., Penicillin), when to take it, and how often, the content of the pill (250 mg), the number of refills, expiration date, and the date of purchase."

Please develop a data model for the entities and relationships

within the context of pharmacy. Also develop a definition for "prescription". List all your underlying assumptions used in your data models.


Data Modeling Case Study

Given the following narrative description of entities and their relationships, prepare a draft entity relationship diagram (ERD). Be sure any reasonable assumptions that you are making.

Burger World Distribution Center serves as a supplier to 45 Burger World franchises. You are involved with a project to build a database system for distribution. Each franchise submits a day-by-day projection of sales for each of Burger World's menu products - the products listed on the menu at each restaurant - for the coming month. All menu product require ingredients and/or packaging items. Based on projected sales for the store, the system must generate a day-by-day and ingredients need and then collapse those needs into one-per-week purchase requisitions and shipments.


Data Modeling Process

• List entity types

• Create relationships

– Pick a central entity type

– Work around the neighborhood

» Add entity types to the diagram

» Build relationships among them

– Determine cardinalities of relationships

• Find/Create identifiers for each entity type

• Add attributes to the entity type in the data model

• Analyze and revise the data model


Classifying Attribute and Partitioning

• An Entity Subtype A collection of Entities of the same

type to which a narrower definition and additional

Attributes and Relationships apply. An Entity Subtype

inherits (retains) all the Attributes and Relationships of

its parent Entity Type.

• Classifying Attribute: An attribute of the Base Entity Type

whose values partition the Entity Instances into

Subtypes.

• Partitioning: A basis for subdividing one entity type into

subtypes. The process of dividing an Entity Type into

several Subtypes based on a Classifying Attribute is

called Partitioning.

• The Classifying Attribute is recorded as a property of the

Partitioning and it appears on the diagram.


Characteristics of Partitioning

• Optionality: – Mandatory: Every Entity instances of the Entity Type

must fall into one of the Subtype categories.

– Optional: Not every Entity instances of the Entity Type must fall into one of the Subtype categories.

• Entity Life Cycle: The states through which an Entity Type can pass are used for Partitioning.

• Enumeration: – Fully enumerated

– Not fully enumerated

• Classifying Attributes and Values – Classifying Attribute: Type

– D: Domestic Subtype

– F: Foreign Subtype


Partitioning and Entity Subtype: Notation

Employee

Seminar Lecturer

ATTRIBUTE:

Employee ID

Name

Birthday ATTRIBUTE:

Teaching Quality Indicator

Teaches

Staff

Type

Wage

Hourly

Status


Alternative Notations for Subtypes

employeeID

name

phone

full-time-emp

employeeID (FK)

salary

part-time-emp

employeeID (FK)

hourly-rate

employee type

Complete Category

All categories shown

Savings

Rate

Checking

Fees

Account

Account Number

Name

IDEF1X PowerDesigner


Entity Subtype Partitioning

Order

Taken

Scheduled

Order Status

Shipped

Billed

Paid

Life Cycle Partitioning


Normalization

• A data base is a model or an image of the reality.

• Logical Data Base Design is a process of modeling and capturing the end-user views of an application domain and synthesis them into a data base structure.

• Normalization is a logical data base design method.

• The basis for normalization is the functional dependencies among attributes in a table.


SQL Terminology

p_no product_name quantity price

101 Color TV 24 500

201 B&W TV 10 250

202 PC 5 2000

CREATE TABLES

(p_no CHAR(5) NOT NULL,

product_name CHAR(20),

quantity SMALLINT,

price DECIMAL(10, 2));

Create a table in SQL

Product Table

Row

Column


SQL Terminology

Set Theory Relational DB File Example

Relation Table File Product_table

Attribute Column Data item Product_name

Tuple Row Record Product_101's info.

Domain Pool of legal values Data type DATE


SQL Principles

• The result of a SQL query is always a table (View or Dynamic Table)

• Rows in a table are considered to be unordered

• Dominate the markets since late 1980s

• Can be used in interactive programming environments

• Provide both data definition language (DDL) and data manipulation language (DML)

• A non-procedural language

• Can be embedded in 3GL: – Embedded SQL

– Dynamic SQL


SQL: Data Definition Language (DDL)

CREATE

DROP

TABLE

VIEW

INDEX

DATABASE

ALTER TABLE


SQL: Introduction

• A relational data base is perceived by its users

as a collection of tables

• E. F. Codd 1969

• Dominate the markets since late 1980s

• Strengths:

– Simplicity

– End-user orientation

– Standardization

– Value-based instead of pointer-based

– Endorsed by major computer companies

• Most CASE products support the development

of relational data base centered applications


SQL: Data Manipulation Language (DML)

SELECT

UPDATE

INSERT

DELETE

p_no product_name quantity price

101 Color TV 24 500

201 B&W TV 10 250

202 PC 5 2000

SELECT [DISTINCT] column(s)

FROM table(s)

[WHERE conditions]

[GROUP BY column(s) [HAVING condition]]

[ORDER BY column(s)]

The Generic Form of the SELECT Statement


Database Table

• The following code retrieves only the Last Name and the Employee ID where the Employee ID is greater than 5. The records are retrieved in descending order.

SELECT LastName, EmployeeID

FROM Employees

WHERE EmployeeID > 5

ORDER BY EmployeeID DESC


WHERE Clause

• WHERE: Use the Where clause to limit the selection. The # symbol indicates literal date values.

SELECT * FROM Employees

WHERE LastName = "Smith"

SELECT Employees.LastName FROM Employees

WHERE Employees.State in ('NY','WA')

SELECT OrderID FROM Orders

WHERE OrderDate BETWEEN #01/01/93# AND

#01/31/93#


Keys

• A key, also called identifier, is an Attribute or a Composite Attribute that can be used to uniquely identify an instance of an entity type.

• Examples:

Entity Type Key

Warehouse Warehouse Number

Product Product Number

Student Student ID or SSN

Ship Name and Port of Registration

Stock of Product Product Number and Warehouse No.


Types of Key

• Primary Key: A unique key is an attribute or a set of attributes that has been used by the DBMS as the identifier of a table.

• Candidate (Alternative) Key: An attribute or a set of attributes that could have been used as the primary key of a table.

• Secondary (Index) Key: An attribute or a set of attributes that has been used to construct the data retrieval index.

• Concatenated (Combined or Composite) Key: A set of attributes that has been used as the key.

• Foreign Key: An attribute or a set of attributes that is used as the primary key in another table.


Purposes of Normalization

• Avoid maintenance problems such as Update .

• Insert: There may be no place to insert new information.

• Delete: Some important information will be lost by deletion.

• Update: Inconsistency may occur because of the existence of data redundancy.

• Provide maximum flexibility to meet future information needs by keeping tables corresponding to object types in their simplified forms.


A Common Sense Approach to Normalization

• Don't rush to put all the information in one table.

• Create a table to correspond to a class of a simple object type that should exist by itself, i.e., "one fact in one place."

• Include common fields (links) as ways of joining information from several related tables.

• Avoid redundancy by using links to retrieve data from related tables.


Normalization Theory

• Normalization is a process of systematically breaking a complex table into simpler ones.

• It is built around the concept of normal forms. • A relation is in a particular normal form if it

satisfies a specific set of constraints such as dependencies among attributes in the relation.

• For x is an integer and x > 1, if a relation is in x-NF than it is in (x-1)-NF.

• Higher order normal forms are usually more desirable than lower order normal forms.

• Normalization process usually starts from complex relations which are usually drawn from some existing documents such as business forms.


A Business Form


An Informal Example of Normalization

• A CUSTOMER ORDER contains the following information: – OrderNo

– OrderDate

– CustNo

– CustAddress

– CustType

– Tax

– Total

– one or more than one Order-Item which has » ProductNo

» Description

» Quantity

» UnitPrice

» Subtotal.


Solution

Unnormalized table

Remove repeating group

1st NF

2nd NF

3rd NF

Remove partial FD

Remove transitive FD

(OrderNo, OrderDate, CustNo, CustAddress, CustType, Tax, Total)

(OrderNo, ProductNo, Description, Quantity, UnitPrice, Subtotal)

(ProductNo, Description, UnitPrice)

(OrderNo, ProductNo, Quantity, UnitPrice, Subtotal)

(OrderNo, OrderDate, CustNo, Tax, Total) (CustNo, CustAddress, CustType)

(OrderNo, OrderDate, CustNo, CustAddress, CustType, Tax, Total,

1{ProductNo, Description, Quantity, UnitPrice,Subtotal}n)


Unnormalized Form

• A relation that has multi-valued attributes (repeating groups).

• Normalization Process: Remove Multi-value Attributes • If an unnormalized relation R has a primary key K and a

multi-value attribute M, the normalization process is: – The multi-value attribute M should be removed from R. – A new relation will be created with (K,M) as the primary key of

the relation. – There may be some other attributes associated with this new

relation. – R will then be at least in 1NF.

• Example: An Employee relation has an attribute language-spoken. For some employees there may be more than one language that they can speak.

EMP (employeeID, empName, empAddress, (language1, language2, ...))

EMP (employeeID, empName, empAddress)

EMP-LANGUAGE (employeeID, language, skillLevel)


How Do You Remove the Repeating Groups?

CREATE TABLE MEM_CONDITION (

MEMBER# VARCHAR2(12) NOT NULL,

CASE# VARCHAR2(16) NOT NULL,

DIAG_ARRAY_1 VARCHAR2(6) NOT NULL,





DIAG_EX_ARRAY_1 VARCHAR2(2) NOT NULL,





DRUG_ARRAY_1 VARCHAR2(12) NOT NULL,





LC_ARRAY_1 VARCHAR2(4) NOT NULL,





MEM_REVIEW VARCHAR2(4) NOT NULL,

OP# VARCHAR2(4) NOT NULL,

PROC_ARRAY_1 VARCHAR2(6) NOT NULL,





PROV_ARRAY_1 VARCHAR2(12) NOT NULL,





REC_TYPE VARCHAR2(2) NOT NULL,

SP_ARRAY_1 VARCHAR2(4) NOT NULL,





TRANSCODE VARCHAR2(2) NOT NULL,

TT_ARRAY_1 VARCHAR2(4) NOT NULL,





VOID VARCHAR2(2) NOT NULL,

YMDEFF VARCHAR2(8) NOT NULL,

YMDEND VARCHAR2(8) NOT NULL,

YMDTRANS VARCHAR2(8) NOT NULL,

PRIORITY VARCHAR2(2) NOT NULL

);


Functional Dependency

• Notation: R.X => R.Y

• Definition: Attribute Y of Relation R is functionally dependent on the Attribute X of Relation R when there is each value of R.Y associated with no more than one value of R.X. R.X and R.Y may be composite attributes.

• Description:

– R .Y is functionally dependent on R.X

– R.X functionally determines R.Y


Full & Partial Dependency

• R.A => R.B

• If B is not functionally dependent on any subset of A (other than A itself), B is fully dependent on A in R.

• If B is functionally dependent on a subset of A (other than A itself), B is partially dependent on A in R.


First Normal Form (1NF)

• A relation R is in the first normal form (1NF) if and only if all attributes of any tuple in R contain only atomic values.

• Normalization Process: – Remove Partial Functional Dependencies

– If R is in 1NF and has a composite primary key (K1,K2), an attribute P is functionally dependent on K1 (K1 => P) (i.e., P is partially dependent on (K1, K2)), the normalization process is:

– The attribute P should be removed from R and a new relation will be created with K1 as the primary key and P as a non-key attribute.

– A relation that is in 1NF and not in 2NF must have a composite primary key.

• Example – Supplier-Part relation has attributes supplier#, part#, qty, city,

distance, where (supplier#, part#) is the key.

– City is partially dependent on supplier#.

SUPPLIER-PART (supplier#, part#, qty, city, distance)

SUPPLIER-PART (supplier#, Part#, qty)

SUPPLIER (supplier#, city, distance)


Non-loss Decomposition

• Normalization is a reduction (decomposition) process that replaces a relation by suitable projections. Each of the projection is a new relation that is in a further normalized form than the original relation. The collection of projections is equivalent to the original relation.

• The original relation can always be recovered by taking the natural join of these projections.

• Any information that can be derived from the original relation can also be derived from the further normalized relations. The converse is not true.

• The process is reversible because no information is loss in the reduction process.


Transitive Dependency

In a relation R,

if R.A =>R.B and R.B => R.C

then attribute C is said to be transitively dependent on attribute A.


Second Normal Form (2NF)

• A relation R is in the second normal form (2NF) if and only if it is in 1NF and every non-key attribute is fully dependent on the primary key.

• Normalization Process: Remove Transitive Dependencies

• If R is in 2NF and has two non-key attributes A1 and A2 where A2 is functionally dependent on A1 (A1 => A2). The A2 should be removed from R and a new relation will be created with A1 as the primary key and A2 as a non-key attribute.

• Example – Supplier relation has attributes supplier#, city, distance, where

supplier# is the key and distance to a supplier can be determined by the city of the supplier.

SUPPLIER (supplier#, city, distance, quality_level)

SUPPLIER (Supplier#, city, quality_level)

CITY-DISTANCE (city, distance)


Third Normal Form (3NF)

• A relation R is in the third normal form (3NF) if and only if the non-key attributes (if there is any) are fully dependent on the primary key of R (i.e., R is in its 2NF) and are mutually independent.

• Heuristic to Check Whether a Relation Is in 3NF

– All the non-key attributes (which are not multi-value attributes) are dependent on the (primary) key, the whole key, and nothing but the key.

• All the non-key attributes have atomic value and dependent on the key (1NF - No multi-value attribute),

• the whole key, (2NF - No Partially Functional Dependency)

• and nothing but the key (3NF - No Transitive Functional Dependency)

Explanation


Normalization Process

F G

Unnormalized Form

A F G H

1NF

H A B C D E

2NF

A F G

3NF

F H

3NF

A B C D E

A B

D E 3NF

3NF

remove transitive dependencies remove partial dependencies

remove repeating groups

D C


Normalization: Pros and Cons

• Pros

– Reduce data redundancy & space required

– Enhance data consistency

– Enforce data integrity

– Reduce update cost

– Provide maximum flexibility in responding ad hoc queries

• Cons

– Many complex queries will be slower because joins have to be

performed to retrieve relevant data from several normalized

tables

– Programmers/users have to understand the underlying data

model of an database application in order to perform proper

joins among several tables

– The formulation of multiple-level queries is a nontrivial task.


Join Two Tables

SELECT Categories.CategoryName, Products.ProductName

FROM Categories, Products

WHERE Products.CategoryID = Categories.Category ID


Tables in Relational DB

ID

ID ID

• Identify Primary Keys and Foreign Keys in the following Tables!!!


Join Tables

SELECT Orders.OrderID, Orders.CustID, LastName, Firstname, Orders.ItemID, Description

FROM Customer, Orders, Inventory

WHERE Customer.CustID = Orders.CustID AND

Orders.ItemID = Inventory.ItemID

ORDER BY CustID, Orders.ItemID

ID ID


Foreign Keys & Primary Keys in a Sample Access Database


An Example of a Complex Query

SELECT customer_name, customer_phone FROM customer WHERE customer_number IN SELECT customer_number FROM order WHERE order_no IN SELECT order_no FROM orderItem WHERE product_number = 007

Please list name and phone number of customers who have ordered product number 007.


Denormalization

• The process of intentionally backing away from normalization to improve performance. Denormalization should not be the first choice for improving performance and should only be used for fine tuning a database for a particular application.

• Requirements – Prior normalization

– Knowledge of data usage

• Benefits – Minimize the need for joins

– Reduce number of tables

– Reduce number of foreign keys

– Reduce number of indices

• Knowledge of Data Usage – How often are two data items needed together

– How many rows are involved

– How volatile is denormalized data

– How important is visibility of data to users

– What is the minimum response time and frequency of an query


De-normalization: An Example

• Where:

– R1 (ProductNo, SupplierNo, Price)

– R2 (SupplierNo, Name, Address, Phone)

– R1*R2 (ProductNo, SupplierNo, Name, Address, Phone, Price)

• R2 should be kept to prevent data loss.

• Data redundancy in R1*R2 and R2 could cause potential data inconsistency problems if the redundant data in these two tables are not maintained properly.

R1 R2 JOIN

R1 * R 2 R2

Denormalization


Data Model Refinement and Transformation

• Data Model Refinement

• Associative Entity Type

• Removing Many-to-Many Relationships

• Keys

• Transformation to Relational Databases


Refinement of a Data Model: Analysis and Simplification

• Isolated Entity Type

• Solitary Entity Type

• One-to-One Relationship

• Redundant Relationship

• Multi-Valued Attributes

• Attribute with Attributes

• Many-to-Many Relationship


Isolated Entity Type

• An Entity Type that does not participate in a Relationship.

• Since every Entity Type should participate in at least one Relationship, there exist two alternatives:

– Identify a relevant Relationship

– Remove the Entity Type from the model


Solitary Entity Type

• An Entity Type that has only one Entity Instance. Examples: Computer Center, Sales Tax, and Current Order Number. Solitary Entity Types may be too restrictive.

• Alternatives:

– Introduce another Entity Type with a wider scope.

– Computer Center ==> Organization Unit

– Define it as an Attribute of an Entity Type.

– Sales Tax ==> Sales Tax of Order

– Define it as a data element in an parameter table. A parameter table has only one row.

– Current Order Number ==> Current Order Number of Parameter Table


Evaluate One-to-One Relationship

Purchase

Request Purchase

Order

becomes

has request

Maybe Incorrect

Purchase

Order

Correct

• It may be an unnecessary relationship between two Entity Types if they have the same attribute and relationships (i.e., they are identical).

• It should be then combined into one Entity Type.


Redundant Relationship

order is part of

contains

customer

places

is placed by

is ordered by

has

ORDERS

Is this relationship redundant?

has ordered product

order

item

Differences in timing of an entity type in its life cycle: • Implemented as separate entity types or use subtypes

• Use value of attributes or additional attributes to differentiate them


Redundant Relationship

Product stocks

Redundant

Non-redundant

Warehouse

is contained in

contains Order Order Line is contained in

contains

Order History is contained in

contains Customer

is contained in

contains

is placed by

places

is held as holds

is held in contains Stock

Product


Multi-Valued Attribute

• Definition

– An Attribute that may have more than one value at a time is called a multi-valued attribute.

• Solution:

– Create an Entity Type for the multi-valued attribute

• Example:

– Languages spoken by an Employee

– Employee(ID, Name, Phone, Languages)

– Employee(111, “John Smith”, 201-999-8888, (English, Chinese))

– Employee(ID, Name, Phone)

– Employee(111, “John Smith”, 210-999-8888)

– Employee_language(ID, Language)

– Employee_language(111, English)

– Employee_language(111, Chinese)


Attribute with Attributes

• An Attribute that can be described by other Attributes is called an attribute with attributes.

• Example:

– College Degree by an Employee

– (John Smith has a College Degree in Computer Sciences from George Mason University)

• Solution:

– Create an Entity Type to avoid an Attribute with Attributes.

– Add new attributes to the existing Entity Type.


Associative Entity Type

• An Associative Entity Type is an Entity Type whose existence is meaningful only if it participates in several (>=2) Relationship Types at the same time.

• Associative Entity Types are often introduced to represent additional information in many-to-many Relationships or to decompose a many-to-many Relationship into two one-to-many Relationships.

• Associative Entity Types are also used to

represent n-ary Relationships in a binary data model.


Remove Many-to-Many Relationship

Order contains

belongs-to

Order Product contains

is contained in

Why?

has

belongs to

How? A many-to-many relationship can be decomposed into two

one-to-many Relationships by creating an Associative Entity

Type between the existing two Entity Types.

• There is no place to attach Attributes that are required to describe a many-to-many Relationship.

• It is difficult to translate many-to-many Relationships into relational tables automatically.

Given

Product

Order Line


Remove Many-to-Many Relationships: Exercises

Supplier has-sources

offers

Remove the many-to-many relationship from the

following ER diagrams

Course takes

is-taken-by

Part

Student

consists-of

is-contained-in

(a)

(b)

(c)

Product


Bills of Material

Part

consists-of is-a-component-in

Product Structure

Product-Structure(Parent Part No, Child Part No, Quantity)

A

B C

D E D F

2 1

1 3 2 2

A B 2

A C 1

B D 1

B E 3

C D 2

C F 2


Using an Associative Entity Type to Represent an N-ary Relationship

Product Project

Supplier

is used in

Product Usage

supplies

uses

Product Project

Supplier

involved in

product usage

involved in

product usage

involved in

product usage

Product Usage is an Associative Entity Type for a 3-ary Relationship.


Translate Data Models to Relational Tables

Order Product contains

is contained in Order Line

has

belongs to

Given

Key: Order#

Attribute:

Order date

Customer ID

Sale Person ID

Key: Order#+Product#

Attribute:

Quantity

Unit Price

Key: Product#

Attribute:

Description

Qty-on-hand

Unit Price

CREATE TABLE ORDER

(OrderNo CHAR(10) NOT NULL,

OrderDate DATE,

CustomerID CHAR(10),

SalePersonID CHAR(10));

Relational Tables Created


Transformation of Data Models to Relational Database Tables

• The entire, or part of, a data (entity-relationship) model can be translated into a normalized database design.

• Objects Created

– At most one relational database

– One or more relations (tables)

– Data structures (DDL) representing the elements (attributes) and the primary key of each relation

– Data type of each data elements


Heuristics of Transformation • A table is created for each Entity Type in the ER diagram.

• A table is created for each multi-valued attribute.

• Relationship Types are implemented as tables or as foreign keys in other tables.

• Many-to-many relationship types are translated into tables.

• Foreign keys are used for implementing one-to-one and one-to-many Relationship Types.

• For one-to-many Relationship Types, the foreign key is placed in the table that represents the Entity Type on the "many" end of the Relationship Type.

• For identifying one-to-many Relationship Types, the PK of the "one" table migrate to the "many" table as a FK and the FK is also part of the PK of the "many" table.

• For non-identifying one-to-many Relationship Types, the PK of the "one" table migrate to the "many" table as a FK and the FK is a non-key attribute of the "many" table.


PowerDesign: Data Architect

Generation/Reverse Engineering:

CDM, PDM

Target DBMS

Generation & Reverse Engineering:

Triggers & Stored Procedures

Database Structure

Target 4GL Tool

Extended Attributes Database Structure

Generation & Reverse Engineering:

http://www.powersoft.com/


PowerDesigner


A Sample Conceptual Data Model

Is member of supervises

Is manager of

Uses Subcontract

composes composed of

Division

Division number

Division name

Division address

Employee

Employee number

First name

Last name

Employee function

Employee salary

Customer

Customer number

Customer name

Customer address

Customer activity

Customer telephone

Customer fax

Project

Project number

Project name

Project label

Team

Team number

Speciality

Task

Task name

Task cost

Material

Material number

Material name

Material type

Participate

Start date

End date

Conceptual Data Model

Project : Management

Model : Project Management

Author : User Version 6.x 7/21/98

Activity

Start date

End date


Notations

Division

Division number

Division name

Division address

Employee

Employee number

First name

Last name

Employee function

Employee salary

Employee

Employee number

First name

Last name

Employee function

Employee salary

Entity

Rela

tion

sh

ip

One-to-many


More on Relationships

member

is a member of Employee

Employee number

First name

Last name

Employee function

Employee salary

Team

Team number

Specialty

A project 'contains’ one or more tasks, and a task's

existence is dependent on the project.

Many-to-many cardinality

Project

Project number

Project name

Project label

Task

Task name

Task cost


Advanced Concepts

Savings

Rate

Checking

Fees

Account

Account Number Name

Employee

Employee number

First name

Last name

Employee function

Employee salary

Reflexive relationship

Subtype

composes composed of

Material

Material number Material name Material type


Define Entities


Define Attributes


Check Parameters


Relationship Definition


Dependent (Identifying Relationship)

• Check the box to indicate a dependent relationship. "One to many" and "mandatory" are automatically chosen as the cardinality and optionality.

• At the physical data model level, the parent entity type's primary key (PK) will become part of the

dependent child entity type's PK. It is also a foreign key.


Inheritance (Super-Type and Sub-Type)


Generate Physical Data Model


Physical Data Model

DIVNUM = DIVNUM

EMPLOYEE

EMPNUM <pk> DIVNUM <fk> EMPFNAM EMPLNAM EMPFUNC EMPSAL

DIVISION

DIVNUM <pk> DIVNAME DIVADDR

DIVNUM automatically migrates as a foreign key.

belongs to

Employee

Employee number First name Last name Employee function Employee salary

Division

Division number Division name Division address

Conceptual

Data Model

Physical

Data Model

Tra

ns

form

atio

n

Do not define FK as an attribute.


Dependent Relationship

PRONUM = PRONUM

PROJECT

PRONUM <pk>

CUSNUM <fk>

EMPNUM <fk>

ACTBEG

ACTEND

PRONAME

PROLABL

TASK

PRONUM <pk,fk>

TSKNAME <pk>

ACTBEG

ACTEND

TSKCOST

Project

Project number

Project name

Project label

Task

Task name

Task cost

Conceptual

Data Model

Physical

Data Model

Tra

ns

form

atio

n


Physical Data Model

PRONUM = PRONUM TSKNAME = TSKNAME

EMPNUM = EMPNUM

MATNUM = CPN_MATNUM

MATNUM = CPD_MATNUM

DIVNUM = DIVNUM

EMPNUM = EMPNUM

MATNUM = MATNUM

PRONUM = PRONUM

EMPNUM = EMPNUM

EMPNUM = EMP_EMPNUM

EMPNUM = EMPNUM

TEANUM = TEANUM

CUSNUM = CUSNUM

DIVISION

DIVNUM <pk> DIVNAME DIVADDR

EMPLOYEE

EMPNUM <pk> EMP_EMPNUM <fk> DIVNUM <fk> EMPFNAM <ak> EMPLNAM <ak> EMPFUNC <ak> EMPSAL

CUSTOMER

CUSNUM <pk> CUSNAME CUSADDR CUSACT CUSTEL CUSFAX

PROJECT

PRONUM <pk> CUSNUM <fk> EMPNUM <fk> ACTBEG ACTEND PRONAME PROLABL

TEAM

TEANUM <pk> TEASPE

TASK

PRONUM <pk,fk> TSKNAME <pk> ACTBEG ACTEND TSKCOST

MATERIAL

MATNUM <pk> MATNAME MATTYPE

PARTICIPATE

PRONUM <pk,fk> TSKNAME <pk,fk> EMPNUM <pk,fk> PARBEG PAREND

MEMBER

TEANUM <pk,fk> EMPNUM <pk,fk>

USED

MATNUM <pk,fk> EMPNUM <pk,fk>

COMPOSE

CPD_MATNUM <pk,fk> CPN_MATNUM <pk,fk>

Physical Data Model

Project : Management

Model : Project Management

Author : User Version 6.x 7/21/98

EMPLOYE_MATERIAL

MATERIAL.MATNAME char(30) PROJ.EMPLOYEE.EMPNUM numeric(5) PROJ.EMPLOYEE.EMPFNAM char(30) PROJ.EMPLOYEE.EMPLNAM char(30) PROJ.EMPLOYEE.EMPFUNC char(30)

MATERIAL PROJ.EMPLOYEE USED


References (Relationships at the Physical Data Model)


Referential Integrity

• The arrow is pointing from the table containing the foreign key to the table where the foreign key is used as a primary key.


Deletion Rules

•Update Constraints

•Delete Constraints

–None

–Restrict

–Cascade

–Set null

–Set Default


Generation of Oracle SQL DLL

-- ============================================================

-- Database name: PROJECT

-- DBMS name: ORACLE Version 8

-- Created on: 7/21/98 8:59 PM

-- ============================================================

-- ============================================================

-- Table: DIVISION

-- ============================================================

create table ADMIN.DIVISION

(

DIVNUM numeric(5) not null

constraint CKC_DIVNUM_DIVISION check (DIVNUM >= '1'),

DIVNAME char(30) not null,

DIVADDR char(80) null ,

constraint PK_DIVISION primary key (DIVNUM)

)

/

-- ============================================================

-- Table: CUSTOMER

-- ============================================================

create table PROJ.CUSTOMER

(

CUSNUM numeric(5) not null

constraint CKC_CUSNUM_CUSTOMER check (

CUSNUM >= '1'),

CUSNAME char(30) not null,

CUSADDR char(80) not null,

CUSACT char(80) null ,

CUSTEL char(12) null ,

CUSFAX char(12) null ,

constraint PK_CUSTOMER primary key (CUSNUM)

)

/

-- ============================================================

-- Table: TEAM

-- ============================================================

create table PROJ.TEAM

(

TEANUM numeric(5) not null

constraint CKC_TEANUM_TEAM check (TEANUM >= '1'),

TEASPE char(80) null ,

constraint PK_TEAM primary key (TEANUM)

)

/

-- ============================================================

-- Table: MATERIAL

-- ============================================================

create table PROJ.MATERIAL

(

MATNUM numeric(5) not null

constraint CKC_MATNUM_MATERIAL check (MATNUM >= '1'),

MATNAME char(30) not null,

MATTYPE char(30) not null,

constraint PK_MATERIAL primary key (MATNUM)

)

/

-- ============================================================

-- Table: EMPLOYEE

-- ============================================================

create table PROJ.EMPLOYEE

(

EMPNUM numeric(5) not null

constraint CKC_EMPNUM_EMPLOYEE check (

EMPNUM >= '1'),

EMP_EMPNUM numeric(5) null ,

DIVNUM numeric(5) not null,

EMPFNAM char(30) null ,

EMPLNAM char(30) not null,

EMPFUNC char(30) null ,

EMPSAL numeric(8,2) null ,

constraint PK_EMPLOYEE primary key (EMPNUM),

constraint AK_EMP_AK1_EMPLOYEE unique (EMPLNAM, EMPFNAM, EMPFUNC)

)

/

-- ============================================================

-- Index: CHIEF_FK

-- ============================================================

create index PROJ.CHIEF_FK on PROJ.EMPLOYEE (EMP_EMPNUM asc)

/

-- ============================================================

-- Index: BELONGS_TO_FK2

-- ============================================================

create index PROJ.BELONGS_TO_FK2 on PROJ.EMPLOYEE (DIVNUM asc)

/

-- ============================================================

-- Table: PROJECT

-- ============================================================

create table PROJ.PROJECT

(

PRONUM numeric(5) not null

constraint CKC_PRONUM_PROJECT check (

PRONUM >= '1'),

CUSNUM numeric(5) not null,

EMPNUM numeric(5) null ,

ACTBEG timestamp null

constraint CKC_ACTBEG_PROJECT check (

ACTBEG is null or ((activity.begindate < activity.enddate))),

ACTEND timestamp null

constraint CKC_ACTEND_PROJECT check (

ACTEND is null or ((activity.begindate < activity.enddate))),

PRONAME char(30) not null,

PROLABL char(80) null ,

constraint PK_PROJECT primary key (PRONUM)

)

/

-- ============================================================

-- Index: SUBCONTRACT_FK

-- ============================================================

create index PROJ.SUBCONTRACT_FK on PROJ.PROJECT (CUSNUM asc)

/

-- ============================================================

-- Index: IS_RESPONSIBLE_FOR_FK

-- ============================================================

create index PROJ.IS_RESPONSIBLE_FOR_FK on PROJ.PROJECT (EMPNUM asc)

/

-- ============================================================

-- Table: TASK

-- ============================================================

create table PROJ.TASK

(

PRONUM numeric(5) not null,

TSKNAME char(30) not null,

ACTBEG timestamp null

constraint CKC_ACTBEG_TASK check (ACTBEG is null or ((activity.begindate < activity.enddate))),

ACTEND timestamp null

constraint CKC_ACTEND_TASK check (ACTEND is null or ((activity.begindate < activity.enddate))),

TSKCOST numeric(8,2) not null,

constraint PK_TASK primary key (PRONUM, TSKNAME),

constraint CKT_TASK check (

(task.begindate < min(participate.begindate)

and

task.enddate < max(participate.enddate)))

)

/

-- ============================================================

-- Index: BELONGS_TO_FK

-- ============================================================

create index PROJ.BELONGS_TO_FK on PROJ. TASK (PRONUM asc)

/

-- ============================================================

-- Table: PARTICIPATE

-- ============================================================

create table PROJ.PARTICIPATE

(

PRONUM numeric(5) not null,

TSKNAME char(30) not null,

EMPNUM numeric(5) not null,

PARBEG timestamp null

constraint CKC_PARBEG_PARTICIP check (PARBEG is null or (((task.begindate < min(participate.begindate)

and

task.enddate < max(participate.enddate)) and

(participate.begindate < participate.enddate)))),

PAREND timestamp null

constraint CKC_PAREND_PARTICIP check (PAREND is null or (((task.begindate < min(participate.begindate)

and


(participate.begindate < participate.enddate)))),

constraint PK_PARTICIPATE primary key (PRONUM, TSKNAME, EMPNUM),

constraint CKT_PARTICIPATE check (

((task.begindate < min(participate.begindate)

and


(participate.begindate < participate.enddate)))

)

/

-- ============================================================

-- Index: WORKS_ON_FK

-- ============================================================

create index PROJ.WORKS_ON_FK on PROJ. PARTICIPATE (EMPNUM asc)

/

-- ============================================================

-- Index: IS_DONE_BY_FK

-- ============================================================

create index PROJ.IS_DONE_BY_FK on PROJ. PARTICIPATE (PRONUM asc, TSKNAME asc)

/

-- ============================================================

-- Table: MEMBER

-- ============================================================

create table PROJ.MEMBER

(

TEANUM numeric(5) not null,


constraint PK_MEMBER primary key (TEANUM, EMPNUM)

)

/

-- ============================================================

-- Index: MEMBER_FK

-- ============================================================

create index PROJ.MEMBER_FK on PROJ.MEMBER (TEANUM asc)

/

-- ============================================================

-- Index: IS_MEMBER_OF_FK

-- ============================================================

create index PROJ.IS_MEMBER_OF_FK on PROJ.MEMBER (EMPNUM asc)

/

-- ============================================================

-- Table: USED

-- ============================================================

create table PROJ.USED

(

MATNUM numeric(5) not null,


constraint PK_USED primary key (MATNUM, EMPNUM)

)

/

-- ============================================================

-- Index: USED_FK

-- ============================================================

create index PROJ.USED_FK on PROJ.USED (MATNUM asc)

/

-- ============================================================

-- Index: USES_FK

-- ============================================================

create index PROJ.USES_FK on PROJ.USED (EMPNUM asc)

/

-- ============================================================

-- Table: COMPOSE

-- ============================================================

create table PROJ.COMPOSE

(

CPD_MATNUM numeric(5) not null,

CPN_MATNUM numeric(5) not null,

constraint PK_COMPOSE primary key (CPD_MATNUM, CPN_MATNUM)

)

/

-- ============================================================

-- Index: COMPOSES_FK

-- ============================================================

create index PROJ.COMPOSES_FK on PROJ.COMPOSE (CPD_MATNUM asc)

/

-- ============================================================

-- Index: COMPOSED_OF_FK

-- ============================================================

create index PROJ.COMPOSED_OF_FK on PROJ.COMPOSE (CPN_MATNUM asc)

/

alter table PROJ.EMPLOYEE

add constraint FK_EMPLOYEE_CHIEF_EMPLOYEE foreign key (EMP_EMPNUM)

references PROJ.EMPLOYEE (EMPNUM)

/


add constraint FK_EMPLOYEE_BELONGS_T_DIVISION foreign key (DIVNUM)

references ADMIN.DIVISION (DIVNUM)

/

alter table PROJ.PROJECT

add constraint FK_PROJECT_SUBCONTRA_CUSTOMER foreign key (CUSNUM)

references PROJ.CUSTOMER (CUSNUM)

/


add constraint FK_PROJECT_IS_RESPON_EMPLOYEE foreign key (EMPNUM)


/

alter table PROJ.TASK

add constraint FK_TASK_BELONGS_T_PROJECT foreign key (PRONUM)

references PROJ.PROJECT (PRONUM)

/

alter table PROJ.PARTICIPATE

add constraint FK_PARTICIP_WORKS_ON_EMPLOYEE foreign key (EMPNUM)


/

alter table PROJ.PARTICIPATE

add constraint FK_PARTICIP_IS_DONE_B_TASK foreign key (PRONUM, TSKNAME)

references PROJ.TASK (PRONUM, TSKNAME)

/

alter table PROJ.MEMBER

add constraint FK_MEMBER_MEMBER_TEAM foreign key (TEANUM)

references PROJ.TEAM (TEANUM)

/

alter table PROJ.MEMBER

add constraint FK_MEMBER_IS_MEMBER_EMPLOYEE foreign key (EMPNUM)


/

alter table PROJ.USED

add constraint FK_USED_USED_MATERIAL foreign key (MATNUM)

references PROJ.MATERIAL (MATNUM)

/

alter table PROJ.USED

add constraint FK_USED_USES_EMPLOYEE foreign key (EMPNUM)


/

alter table PROJ.COMPOSE

add constraint FK_COMPOSE_COMPOSES_MATERIAL foreign key (CPD_MATNUM)


/

alter table PROJ.COMPOSE

add constraint FK_COMPOSE_COMPOSED__MATERIAL foreign key (CPN_MATNUM)


/


Referential Integrity


add constraint FK_EMPLOYEE_CHIEF_EMPLOYEE foreign key (EMP_EMPNUM)


/


add constraint FK_EMPLOYEE_BELONGS_T_DIVISION foreign key (DIVNUM)

references ADMIN.DIVISION (DIVNUM)

/


add constraint FK_PROJECT_SUBCONTRA_CUSTOMER foreign key (CUSNUM)

references PROJ.CUSTOMER (CUSNUM)

/


add constraint FK_PROJECT_IS_RESPON_EMPLOYEE foreign key (EMPNUM)


/

alter table PROJ.TASK

add constraint FK_TASK_BELONGS_T_PROJECT foreign key (PRONUM)

references PROJ.PROJECT (PRONUM)

/


Physical Database Design Activities

Define Tables & Columns

Define Keys

Identify Critical Transactions

Add Columns: • Redundant columns

• Derived data columns

Manipulate Tables: • Collapse tables

• Supertypes & subtypes

Add Tables: • Derived data

tables

Handle Integrity Issues: • Row uniqueness & Domain restrictions

• Referential integrity & Generate sequence numbers

• Derived and redundant data

Controlling Access

Manage Objects: • Sizes • Placement

Source: Gillete, Rob, etc., Physical

Database Design for Sybase SQL

Server, Prentice Hall, 1995.


Architecture of Data Warehouse

Corporate

Operational

Database

Data Warehouse End User

Access and

OLAP front-

end Tools

• EIS

• DSS

• Report Writers

• Spreadsheets

Summarized

Detailed

Past Current

Data

Replication

& Cleansing

Informational

Database

• Data extraction

• Data filtering

• Table joining

• Translation

• Re-Formatting

Projecte

d

Derived

Data Bridging/

Transformation

Metadata

Info. Directory


Operational vs. Informational Databases

Data

Content

Data

organizations

Data

Volatility

Data

normalization

Access

frequency

Data

Update

Usage

Response

Time

Current value

Application by application

Dynamic

Fully normalized for

transaction processing

High

Updated on a record and field

basis

Highly structured

transaction processing

Sub-second to 2-3 seconds

Archival data, summarized

data, calculated data

Subject areas across

enterprise

Static until refreshed

Joined views suitable for

business analysis

Low - Medium

Access only;

no direct update

Highly unstructured, heuristic

or analytical processing

Several seconds to minutes

Operational Database Informational Database Characteristics


Relational View

Multidimensional View

Excel Pivot

Table Wizard


Dimensional Model

Product • Key

• Name

• Description

• Size

• Price

Promotion • Key

• Description

• Discount

• Media

Market Region • Key

• Description

• District

• Region

• Demographics

Time • Key

• Weekday

• Holiday

• Fiscal

Sale

Product Key

Market Key

Promotion Key

Time Key • Dollars

• Units

• Price

• Cost

Time

Region

Product


Modeling a Data Warehouse

• MDM: Multidimensional Modeling

– A logical model of business information

– Easy to understand

– Applicable to relational and multidimensional databases

– Extremely useful for analysis

– A tried-and-tested techniques

• Why?

– An OLTP (On-Line Transaction Process) design of an order processing system may have dozens or hundreds of tables. It becomes difficult for business managers to understand the design in order to analyze the data.


Approach

• Designed around numeric data:

– values

– counts

– weights

– occurrence

• An example of a MDM problem statement:

– "What is my profitability by customer over time, by organization?"


The Classic Star Schema

Market ID

description

region

state

district

city

Product ID

description

supplier ID

brand

color

size

Period ID

description

year

quarter

month

current flag

resolution

sequence

Market ID

Product ID

Period ID

dollars

units

price

Market Dimension

Product Dimension

Fact Table Period Dimension

Each dimension is described by its own table

and the facts are arranged in a single large

table with a concatenated primary key

comprises the individual keys of each

dimension.


Snow Flake Structure

Product identifier = Product identifier

Brand identifier = Brand identifier

Year identifier = Year identifier

Quarter identifier = Quarter identifier

Month identifier = Month identifier

Week identifier = Week identifier

Country identifier = Country identifier

Region identifier = Region identifier

Time identifier = Time identifier

Customer identifier = Customer identifier

Store identifier = Store identifier

Customer

Customer identifier <pk> int

Customer name char(30)

Customer address char(80)

Customer activity char(80)

Customer phone number char(12)

Customer fax number char(12)

Sale

Time identifier <fk> int

Customer identifier <fk> int

Store identifier <fk> int

Product identifier <fk> int

Sale total real

Sale revenu real

Store

Store identifier <pk> int

Region identifier <fk> int

Store name char(50)

Store address char(80)

Store manager char(30)

Store phone number char(20)

Store FAX number char(20)

Store financial services type char(10)

Store photo services type char(10)

Day

Week identifier <fk> int

Time identifier <pk> int

Date datetime

Day of week char(30)

Day number in month int

Product

Product identifier <pk> int

Brand identifier <fk> int

Product description char(80)

Product category char(30)

Product unit price int

Region

Region identifier <pk> int

Country identifier <fk> int

Region name char(30)

Country

Country identifier <pk> int

Country name char(80)

Year

Year identifier <pk> int

Year name char(30)

Month

Month identifier <pk> int

Quarter identifier <fk> int

Month name char(10)

Quarter

Quarter identifier <pk> int

Year identifier <fk> int

Quarter name char(10)

Week

Week identifier <pk> int

Month identifier <fk> int

Week name char(30)

Week number in year int

Brand

Brand identifier <pk> int

Brand name char(30)


Steps to Build MDM

• Pick a business subject area

– Weekly sales reports, monthly financial statements, insurance claim costs.

• Asking six fundamental questions:

– What business process is being modeled?

– At what level of detail (granularity) is "active" analysis conducted?

– What do the measures have in common (the "dimensions")?

– What are the dimensions' attributes?

– Are the attributes stable or variable over time and is their "cardinality" bounded or unbounded?


Issues

• Active analysis – Mechanical manipulation: Pivoting, Drilling

down, Graphing

– Agent-based manipulation: Alert reporting, exception reporting

– Workflow manipulation: Publishing, distributing documents.

• Cardinality means "how many" – A relational database usually has "unbounded"

cardinality

– A multidimensional database usually has "bounded" cardinality. Complete reorganization is needed to change cardinality.


A Data Model for an Electronic Commerce Application dept_id = parent_id

sku = sku

pfid = pfid

shopper_id = shopper_id

pfid = pfid

shopper_id = shopper_id

pfid = pfid

order_id = order_id

pfid = pfid

pfid = pfid

dept_id = dept_id

basket shopper_id char(32) date_changed datetime marshalled_order image

dept dept_id int parent_id int name varchar(255) description text date_changed datetime

product_attribute pfid varchar(30) attribute_id tinyint attribute_index tinyint attribute_value varchar(20)

product_family pfid varchar(30) dept_id int manufacturer_id int name varchar(255) short_description varchar(255) long_description text image_filename varchar(255) intro_date datetime date_changed datetime list_price int monogramable tinyint

product_variant sku int pfid varchar(30) attribute0 tinyint attribute1 tinyint attribute2 tinyint attribute3 tinyint attribute4 tinyint

promo_cross pfid varchar(30) related_pfid varchar(30) description varchar(255)

promo_price promo_name varchar(255) promo_type int promo_description text promo_rank int active int date_start datetime date_end datetime shopper_all int shopper_column varchar(64) shopper_op varchar(2) shopper_value varchar(64) cond_all int cond_column varchar(64) cond_op varchar(2) cond_value varchar(64) cond_basis char(1) cond_min int award_all int award_column varchar(64) award_op varchar(2) award_value varchar(64) award_max int disjoint_cond_award int disc_type char(1) disc_value real

promo_upsell pfid varchar(30) related_pfid varchar(30) description varchar(255)

receipt order_id char(26) shopper_id char(32) total int status tinyint date_entered datetime date_changed datetime marshalled_receipt image

receipt_item pfid varchar(30) sku int order_id char(26) row_id int quantity int adjusted_price int

shopper shopper_id char(32) created datetime name varchar(235) password varchar(20) street varchar(50) city varchar(50) state varchar(30) zip varchar(15) country varchar(20) phone varchar(16) email varchar(50)


Attribute 0 of pfid 14 is size and the attribute value 1 is Grande

and 2 is Tall and 3 is Short


Web-based Build-To-Order Application


Data Model for Build-To-Order Application


http://www.oracle.com/tools/jdeveloper/documents/jsptwp/index.html?content.html

Auction Web Site's Data Model

93727885-Data-Model

Documents

references data modeling

types of data

database modeling

preliminary data model

data warehouse toolkit

data base technologies

physical database design

database design minder