9/7/2012ISC329 Isabelle Bichindaritz1 The Relational Database Model.
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
-
Upload
pauline-sharp -
Category
Documents
-
view
214 -
download
0
Transcript of 9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
ISC329 Isabelle Bichindaritz 29/14/2012
Objectives
• Purpose of a design methodology.
• Database design has three main phases: conceptual, logical, and physical design.
9/14/2012 ISC329 Isabelle Bichindaritz 3
Acknowledgments
• Some of these slides have been adapted from Thomas Connolly and Carolyn Begg
ISC329 Isabelle Bichindaritz 49/14/2012
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.
ISC329 Isabelle Bichindaritz 59/14/2012
Preliminary Phase : Database Initial Study
• Purposes– Analyze company situation
• Operating environment• Organizational structure
– Define problems and constraints– Define objectives– Define scope and boundaries
ISC329 Isabelle Bichindaritz 69/14/2012
• 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– multiplicities – 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
ISC329 Isabelle Bichindaritz 79/14/2012
• Examples of business rules are:– An invoice contains one or more invoice lines, but each invoice line is
associated with a single invoice.– A store employs many employees, but each employee is employed by only one
store.– A college has many departments, but each department belongs to a single
college. (This business rule reflects a university that has multiple colleges such as Business, Liberal Arts, Education, Engineering, etc.)
– A driver may be assigned to drive many different vehicles, and each vehicle can be driven by many drivers. (Note: Keep in mind that this business rule reflects the assignment of drivers during some period of time.)
– A client may sign many contracts, but each contract is signed by only one client.
Business Rules
ISC329 Isabelle Bichindaritz 89/14/2012
• 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
ISC329 Isabelle Bichindaritz 99/14/2012
• 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
ISC329 Isabelle Bichindaritz 109/14/2012
• 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
ISC329 Isabelle Bichindaritz 139/14/2012
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
ISC329 Isabelle Bichindaritz 149/14/2012
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.
ISC329 Isabelle Bichindaritz 159/14/2012
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.
ISC329 Isabelle Bichindaritz 169/14/2012
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.
ISC329 Isabelle Bichindaritz 179/14/2012
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.
ISC329 Isabelle Bichindaritz 189/14/2012
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
ISC329 Isabelle Bichindaritz 199/14/2012
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
ISC329 Isabelle Bichindaritz 209/14/2012
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
ISC329 Isabelle Bichindaritz 219/14/2012
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
ISC329 Isabelle Bichindaritz 229/14/2012
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