information access mgt09/12/971 entity-relationship design information level design

Information Access Mgt 09/12/97 1

Entity-Relationship Design

Information Level Design


The Data Life CycleStage Tool Objective

InitialInvestigation

Report General Scope

Feasibility Function-EntityDecomposition

Business Entities

GeneralAnalysis

E-R Diagram Logical Entities

DetailedDesign

Schema Physical Design

Coding SQL Specify DBMS

Installation Population Plan Initialize Tables


Data Modeling StagesStage Goal Outcome

BusinessScope

Business justificationfor system

Data PlanPPrriioorriittyy lliisstt

BusinessModel

Data requirements inbusiness terms

Project OrganizationCCRRUUDD MMaattrriicceess

IT Model High level technicaldescription

Conceptual DesignEE--RR DDiiaaggrraammss

TechnologyModel

Database specificdesign

Physical DesignNNoorrmmaalliizzeedd TTaabblleess

TechnologyDefinition

Data Definitionspecifications

Table SchemaSSQQLL rreeqquuiirreemmeennttss

DatabaseSystem

Functional Database Populated DatabaseMMaannaaggeemmeenntt ppllaann


Babysitter Service

The AITP Service Club wants to run a babysitting service. Customers call to request a sitter and the Club Coordinator assigns an employee to sit for the customer from a list of employees available for the particular day requested.






Business Entities

GeneralAnalysis


DetailedDesign





Functional Decomposition

Assign Employee• Take Call• Check Availability• Assign to Job• Contact Employee• Confirm Appointment

Determine Availability


Functional-Entity Decomposition

Employee Customer Job

Assign Employee

Take Call U

Check Availability R

Assign to Job R R U

Contact Employee R R

Confirm Appointment R UDetermineAvailability

U






Business Entities

GeneralAnalysis


DetailedDesign





E-R Diagram

Employee

Job

Customer


Data Flow DiagramContext Diagram

Babysitter InformationSystem

Customer

Employee

Request

Confirm-ation

Assignment

Availability


Data Flow DiagramLevel 1

Request

Confirm-ation

1.AssignEmployee

Availability2.Record Avail-ability

Assignment

D1 | Customer

D2 | Employee

New

Current AvailTimes

D3 | Jobs

JobAssign

AvailTimes


Entity Relationship Models

A good E-R model has• One table for every entity in the business

system• Correctly drawn relationships indicating 1-1

or 1-m cardinalities• Optionality indicators to support needed

referential integrity


ATTRIBUTE:

A description or property of a given entity type.

• Must depend on the entity key alone • Must contain information that we

explicitly need• Must have the same data type for all

entity occurrences


Discovering Entities

• Entities are normally described by NOUNS and ADJECTIVES

• Entities do not change anything.• Entity occurrences are records, entity types

are files.• Reports are derived output and not entities.


Keys

Names are normally poor primary keys. They have multiple valid representations. Primary keys:

1. Should not change values over the life of the instance.

2. Should not have null values.

3. Should not be "intelligent keys". These are keys that also describe properties of the entity.

4. Should not be large composite keys.


Not null vs nulls allowed

• Null values represent inapplicable, applicable but not known, and applicable but not present values. Primary keys cannot have null values.

• Null values are different from zeros or blanks


Diagrams: Attributes

Entity

Key . . . . . .Attribute Attribute


Diagrams:Repeating Groups

Course

SectionNum


PREMIERE PRODUCTS EXAMPLE

The Premier Products Company is a wholesale hardware company that provides products to customers. Each customer is served by a salesman who processes orders. The salesmen is paid from commissions earned on each customer order. A customer places an order by calling the company and contacting the salesman. The salesman records the ordering person, products and quantity ordered.


PREMIERE PRODUCTS: REPEATING GROUPS

In the Premier Products Company each salesmen is paid from commissions earned on each customer order. A customer places an order by calling the company and contacting the salesman. The salesman records the ordering person, products and quantity ordered. The order consists of Customer data, Salesman data and a list of products, price, and quantity for the products that the customer wants delivered. The attributes {PRODUCT, PRICE, QUANTITY} constitute a repeating group.


Example: Order

ORDER PRODUCT PRICE QUANTITY

5103 IRON 17.95 11

SKILLET 19.95 6

5110 TOASTER 57.95 4

IRON 17.95 3

Each instance of an order has several order lines. Order lines {Description, Price, Quantity} are examples of repeating

groups.


RELATIONSHIP.

Does not describe processing or change any data. Relationship names should be passive (ordered by).

• CARDINALITY Refers to the number of records that a relationship connects to a given child record in a relationship.

• PARTICIPATION (Optionality) Refers to whether a record must exist in one table before a related one is inserted into another.


Diagrams: 1:m Relationships

Section

Instructor

CourseSection

InstructorID

InstructorID


Diagrams:m:n Relationships

Section

Student

CourseSection

StudentID

Student-Section

CourseSection

StudentID


Optionality(Referential Integrity)

Records in a table that have a relationship with another table may be restricted by optionality requirements.

Relationship Optional Relationship Mandatory (referential

integrity enforced)


Optionality

0

1

Optional (0 allowed)

Mandatory (1 or more required)


Data

information access mgt09/12/971 entity-relationship design information level design

Documents