1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

29
1/26/2004 545 TCSS A Isabelle Bichinda ritz 1 Database Management Systems Design Methodology

Transcript of 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

Page 1: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 1

Database Management Systems Design Methodology

Page 2: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 2

Objectives• Purpose of a design methodology.

• Database design has three main phases: conceptual, logical, and physical design.

• How to use ER modeling to build a local conceptual data model based on information given in a view of the enterprise.

• How to document process of conceptual database design.

Page 3: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 3

Design Methodology• Structured approach that uses procedures,

techniques, tools, and documentation aids to support and facilitate the process of design.

• Database design methodology has 3 main phases:– Conceptual database design;

– Logical database design;

– Physical database design.

Page 4: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 4

Preliminary Phase : Database Initial Study

• Purposes– Analyze company situation

• Operating environment• Organizational structure

– Define problems and constraints– Define objectives– Define scope and boundaries

Page 5: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 5

• What are business rules, what is their source, and why are they crucial?

• Business rules are precise statements, derived from a detailed description of the organization's operations, that define one or more of the following modeling components:– entities - in the E-R model corresponds to a table– relationships – are associations between entities– attributes – are characteristics of entities– connectivities – are used to describe the relationship classification– cardinalities – express the specific number of entity occurrences

associated with one occurrence of the related entity– constraints – limitations on the type of data accepted

Business Rules

Page 6: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 6

• Data – Raw facts stored in databases– Need additional processing to become useful

• Information– Required by decision maker – Data processed and presented in a meaningful

form– Transformation

Changing Data into Information

Page 7: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 7

• Database – Carefully designed and constructed repository of facts

– Part of an information system

• Information System– Provides data collection, storage, and retrieval

– Facilitates data transformation

– Components include:• People

• Hardware

• Software–Database(s)–Application programs–Procedures

The Information System

Page 8: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 8

• System Analysis– Establishes need and extent of an information system

• System development

– Process of creating information system

• Database development– Process of database design and implementation– Creation of database models– Implementation

• Creating storage structure• Loading data into database• Providing for data management

The Information System

Page 9: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 9

Figure 6.3

Database Lifecycle (DBLC)

Page 10: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 10

Initial Study Activities

Page 11: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 11

DecisionSupportSystem

ElectronicMedicalRecord

User

User

PrimaryCareProvider

extends

View contact

Browse contacts

Place contact KnowledgeBase

Authenticate user

<<uses>>

<<uses>>

<<uses>>

Review solution

Provide solution

<<uses>>

KnowledgeBase

<<extends>>

Create solution

<<extends>>LTFUSpecialist

extends

Generate statistics

<<uses>>

Use case diagram

Page 12: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 12

Conceptual/Logical Database Design

• Conceptual database design– Process of constructing a model of information used

in an enterprise, independent of all physical considerations.

• Logical database design– Process of constructing a model of information used

in an enterprise based on a specific data model (e.g. relational), but independent of a particular DBMS and other physical considerations.

Page 13: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 13

Physical Database Design

• Process of producing a description of the implementation of the database on secondary storage; it describes the base relations, file organizations, and indexes design used to achieve efficient access to the data, and any associated integrity constraints and security measures.

Page 14: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 14

Critical Success Factors in Database Design

• Work interactively with users as much as possible.• Follow a structured methodology throughout the

data modeling process.• Employ a data-driven approach.• Incorporate structural and integrity considerations

into the data models.• Combine conceptualization, normalization, and

transaction validation techniques into the data modeling methodology.

Page 15: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 15

Critical Success Factors in Database Design

• Use diagrams to represent as much of the data models as possible.

• Use a Database Design Language (DBDL) to represent additional data semantics.

• Build a data dictionary to supplement the data model diagrams.

• Be willing to repeat steps.

Page 16: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 16

Methodology Overview - Conceptual Database Design

• Step 1 Build local conceptual data model for each user view– Step 1.1 Identify entity types– Step 1.2 Identify relationship types– Step 1.3 Identify and associate attributes with entity or relationship

types– Step 1.4 Determine attribute domains– Step 1.5 Determine unique identifier (will become a key) attributes– Step 1.6 Consider use of enhanced modeling concepts (optional step)– Step 1.7 Check model for redundancy – Step 1.8 Validate local conceptual model against user transactions – Step 1.9 Review local conceptual data model with user

Page 17: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 17

User

userName : Stringpassword : StringfirstName : StringlastName : StringmiddleInitial : Stringinstitution : Stringemail : StringphoneNumber : StringstreetNumber : StringstreetName : StringaddressComplement : StringzipCode : Stringstate : Stringposition : String

(from Use Case View)LTFUSpecialist

(from Use Case View)

extends

Contact

contactDate : DatecontactType : StringcontactMean : StringcontactDirection : BooleancontactTakenBy : Stringsource : Stringtitle : Stringphone : Stringfax : StringreasonForContact : StringKPS : Integerweight : IntegerweightUnit : Booleanheight : IntegerheightUnit : Boolean

Patient

patientUpn : StringfirstName : StringlastName : StringmiddleName : String

0..n

1

0..n

1

isSubjectOf

PrimaryCareProvider

lastContactDate : DatelastDateEstimated : Boolean

(from Use Case View)

0..n

1

0..n

1

places

extends

0..n1

0..n1

caresFor

Problem

problemCode : Stringrank : IntegerdateObserved : Datecomment : Stringtext : String

isPartOf0..n 1..1

AttributeValue

attribute : Stringvalue : String

Medication

medicationCode : Stringrank : Integerdose : Doubleunit : Stringexponent : IntegercalculatedValue : DoubledateStart : DatedateEnd : Doublefrequency : Stringroute : Stringcomment : Stringtext : String

KnowledgeBase(from Use Case View)

10..n

10..n

getMedicationInformation

Symptom

symptomCode : Stringrank : IntegersiteCode : StringorganismCode : StringdateObserved : Dateimportance : Stringlevel : Stringcomment : Stringtext : String

0..n

1

0..n

1

presents 1

0..n

1

0..n

getSymptomInformation

AttributeValue

attribute : Stringvalue : String

Procedure

procedureCode : Stringrank : IntegerdateResult : DatesiteCode : StringorganismCode : Stringcomment : Stringtext : String

0..n

1

0..n

1

presents

Laboratory

labCode : Stringrank : IntegerdateResult : Datevalue : Stringunit : Stringmethod : Stringinterval : Stringdose : Stringdelay : Integersource : StringrangeInferior : DoublerangeSuperior : Doubleinterpretation : Stringevolution : Stringcomment : Stringtext : String

Treatment

treatmentCode : Stringrank : Integercomment : Stringtext : String

KnowledgeBase(from Use Case View)

1

0...

1

0...

getProcedureInformation

1

0..n

1

0..n

getLaboratoryInformation

1

0..n

1

0..ngetTreatmentInformation

Diagnosis

diagnosisCode : Stringrank : IntegerdateObserved : DatedateStarted : DatedateEnded : Dateabstraction : StringsiteCode : StringorganismCode : Stringoutcome : Stringcomment : Stringtext : String

1

0..n

1

0..n

getDiagnosisInformation

isPartOf0..n

1..1

isPartOf1..1

0..n

isPartOf0..n1..1

isPartOf

0..n

1..1

isPartOf

0..n

1..1

isPartOf

0..n

1..1

Class diagram

Page 18: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 18

Methodology Overview - Logical Database Design for Relational Model

• Step 2 Build and validate local logical data model for each view – Step 2.1 Remove features not compatible with the

relational model (optional step)

– Step 2.2 Derive relations for local logical data model

– Step 2.3 Validate relations using normalization

– Step 2.4 Validate relations against user transactions

– Step 2.5 Define integrity constraints

– Step 2.6 Review local logical data model with user

Page 19: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 19

Methodology Overview - Logical Database Design for Relational

Model

• Step 3 Build and validate global logical data model– Step 3.1 Merge local logical data models into global

model

– Step 3.2 Validate global logical data model against the conceptual data model

– Step 3.3 Check for future growth

– Step 3.4 Review global logical data model with users

Page 20: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 20

Methodology Overview - Physical Database Design for Relational

Databases

• Step 4 Translate global logical data model for target DBMS– Step 4.1 Design base relations– Step 4.2 Design representation of derived data – Step 4.3 Design enterprise constraints

• Step 5 Design physical representation– Step 5.1 Analyze transactions– Step 5.2 Choose file organization– Step 5.3 Choose indexes– Step 5.4 Estimate disk space requirements

Page 21: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 21

Methodology Overview - Physical Database Design for Relational

Databases • Step 6 Design user views

• Step 7 Design security mechanisms

• Step 8 Consider the introduction of controlled redundancy

• Step 9 Monitor and tune the operational system

Page 22: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 22

Extract from Data Dictionary for Staff View of DreamHome

Showing Description of Entities

Page 23: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 23

First-cut ER diagram for Staff View of DreamHome

Page 24: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 24

Extract from Data Dictionary for Staff View of DreamHome Showing

Description of Relationships

Page 25: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 25

Extract from Data Dictionary for Staff View of DreamHome

Showing Description of Attributes

Page 26: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 26

ER Diagram for Staff View of DreamHome

with Unique Identifiers Added

Page 27: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 27

Revised ER Diagram for Staff View of DreamHome with Specialization / Generalization

Page 28: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 28

Example of a Non-Redundant Relationship FatherOf

Page 29: 1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.

1/26/2004 TCSS545A Isabelle Bichindaritz 29

Using Pathways to Check that the Conceptual

Model Supports the User Transactions