10/3/2012ISC329 Isabelle Bichindaritz1 Logical Design.
-
Upload
jonas-armstrong -
Category
Documents
-
view
217 -
download
2
Transcript of 10/3/2012ISC329 Isabelle Bichindaritz1 Logical Design.
ISC329 Isabelle Bichindaritz 110/3/2012
Logical Design
ISC329 Isabelle Bichindaritz 210/3/2012
Learning Objectives• How to remove features from a local conceptual model that are
not compatible with the relational model.
• How to derive a set of relations from a local logical data model.
• How to validate these relations using the technique of normalization.
• How to validate a logical data model to ensure it supports required user transactions.
• How to merge local logical data models based on specific views into a global logical data model of the enterprise.
• How to ensure that resultant global model is a true and accurate representation of enterprise.
ISC329 Isabelle Bichindaritz 310/3/2012
Acknowledgments
• Some of these slides have been adapted from Thomas Connolly and Carolyn Begg
ISC329 Isabelle Bichindaritz 410/3/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 510/3/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 610/3/2012
Logical Design• Translates conceptual design into internal model • Maps objects in model to specific DBMS
constructs• Design components
– Tables– Indexes – Views– Transactions– Access authorities– Others
ISC329 Isabelle Bichindaritz 710/3/2012
Purpose of Database Design
• Structure the data in stable structures, called normalized tables– Not likely to change over time– Minimal redundancy
• Develop a logical database design that reflects actual data requirements
• Develop a logical database design from which a physical database design can be developed
ISC329 Isabelle Bichindaritz 810/3/2012
Purpose of Database Design
• Translate a relational database model into a technical file and database design that balances several performance factors
• Choose data storage technologies that will efficiently, accurately and securely process database activities
ISC329 Isabelle Bichindaritz 910/3/2012
Process of Database Design • Logical Design
– Based upon the conceptual data model– Four key stages
1. Develop a logical data model for each known user interface / report / view for the application using normalization principles
2. Combine normalized data requirements from all user interfaces into one consolidated logical database model
3. Translate the conceptual E-R data model for the application into normalized data requirements
4. Compare the consolidated logical database design with the translated E-R model and produce one final logical database model for the application
ISC329 Isabelle Bichindaritz 1010/3/2012
E-R Modeling is Iterative
Figure 6.8
ISC329 Isabelle Bichindaritz 1110/3/2012
Iterative Process of Verification
Figure 6.10
ISC329 Isabelle Bichindaritz 1210/3/2012
Distributed Database Design
• Design portions in different physical locations
• Development of data distribution and allocation strategies
ISC329 Isabelle Bichindaritz 1310/3/2012
Deliverables and Outcomes• Logical database design must account for
every data element on a system input or output
• Normalized relations are the primary deliverable
• Physical database design results in converting relations into files
ISC329 Isabelle Bichindaritz 1410/3/2012
Relational Database Model
• Well-Structured Relation– A relation that contains a minimum amount of
redundancy and allows users to insert, modify and delete the rows without errors or inconsistencies
ISC329 Isabelle Bichindaritz 1510/3/2012
Normalization
• The process of converting complex data structures into simple, stable data structures
• Second Normal Form (2NF)– Each nonprimary key attribute is identified by
the whole key (called full functional dependency)
ISC329 Isabelle Bichindaritz 1610/3/2012
Normalization
• Third Normal Form (3NF)– Nonprimary key attributes do not depend on
each other (called transitive dependencies)
• The result of normalization is that every nonprimary key attribute depends upon the whole primary key
ISC329 Isabelle Bichindaritz 1710/3/2012
Functional Dependencies and Primary Keys
• Foreign Key– An attribute that appears as a nonprimary key attribute
in one relation and as a primary key attribute (or part of a primary key) in another relation
• Referential Integrity– An integrity constraint specifying that the value (or
existence) of an attribute in one relation depends on the value (or existence) of the same attribute in another relation
ISC329 Isabelle Bichindaritz 1810/3/2012
Local Conceptual Data Model for Staff View Showing all Attributes
ISC329 Isabelle Bichindaritz 1910/3/2012
Step 1 Remove Features not Compatible with the Relational
Model• First step Remove features not compatible
with the relational model (optional step)
• To refine the local conceptual data model to remove features that are not compatible with the relational model. This involves:– remove *:* binary relationship types; – remove *:* recursive relationship types; – remove complex relationship types; – remove multi-valued attributes.
ISC329 Isabelle Bichindaritz 2010/3/2012
Remove *:* Binary Relationship Types
ISC329 Isabelle Bichindaritz 2110/3/2012
Remove *:* Recursive Relationship Types
ISC329 Isabelle Bichindaritz 2210/3/2012
Remove Complex Relationship Types
ISC329 Isabelle Bichindaritz 2310/3/2012
Remove Multi-valued Attributes
ISC329 Isabelle Bichindaritz 2410/3/2012
Step 2 Build and Validate Local Logical
Data Model• Step 2 Derive relations for local logical
data model – To create relations for the local logical data model
to represent the entities, relationships, and attributes that have been identified.
ISC329 Isabelle Bichindaritz 2510/3/2012
Transforming E-R Diagrams into Relations
• Represent Entities– Each regular entity is transformed into a relation– The identifier of the entity type becomes the primary
key of the corresponding relation– The primary key must satisfy the following two
conditionsa. The value of the key must uniquely identify every row in the
relation
b. The key should be nonredundant
ISC329 Isabelle Bichindaritz 2610/3/2012
Transforming E-R Diagrams into Relations
• Represent Relationships– Binary 1:N Relationships
• Add the primary key attribute (or attributes) of the entity on the one side of the relationship as a foreign key in the relation on the right side
• The one side migrates to the many side
– Binary or Unary 1:1• Three possible options
a. Add the primary key of A as a foreign key of B
b. Add the primary key of B as a foreign key of A
c. Both of the above
ISC329 Isabelle Bichindaritz 2710/3/2012
Transforming E-R Diagrams into Relations
• Represent Relationships (continued)– Binary and Higher M:N relationships
• Create another relation and include primary keys of all relations as primary key of new relation
– Unary 1:N Relationships• Relationship between instances of a single entity type• Utilize a recursive foreign key
– A foreign key in a relation that references the primary key values of that same relation
– Unary M:N Relationships• Create a separate relation• Primary key of new relation is a composite of two attributes
that both take their values from the same primary key
ISC329 Isabelle Bichindaritz 2810/3/2012
ISC329 Isabelle Bichindaritz 2910/3/2012
Summary of How to Map Entities and Relationships to
Relations
ISC329 Isabelle Bichindaritz 3010/3/2012
Relations for the Staff View of DreamHome
ISC329 Isabelle Bichindaritz 3110/3/2012
Step 2 Build and Validate Local Logical Data Model• Validate relations using normalization
– To validate the relations in the local logical data model using the technique of normalization.
• Validate relations against user transactions– To ensure that the relations in the local logical data
model support the transactions required by the view.
• Define integrity constraints– To define the integrity constraints given in the view
(i.e. required data, entity and referential integrity, domains, and enterprise constraints).
ISC329 Isabelle Bichindaritz 3210/3/2012
Referential Integrity Constraints for Relations in Staff View of DreamHome
ISC329 Isabelle Bichindaritz 3310/3/2012
Referential Integrity Constraints for Relations in Staff View of DreamHome
ISC329 Isabelle Bichindaritz 3410/3/2012
Step 3 Build and Validate Global Logical
Data Model
ISC329 Isabelle Bichindaritz 3510/3/2012
Transforming E-R Diagrams into Relations
• Merging Relations (View Integration)– Purpose is to remove redundant relations– View Integration Problems
• Synonyms– Two different names used for the same attribute– When merging, get agreement from users on a single, standard
name• Homonyms
– A single attribute name that is used for two or more different attributes
– Resolved by creating a new name• Dependencies between nonkeys
– Dependencies may be created as a result of view integration– In order to resolve, the new relation must be normalized
ISC329 Isabelle Bichindaritz 3610/3/2012
Build and Validate Global Logical Data
Model
ISC329 Isabelle Bichindaritz 3710/3/2012
Relations for the Branch View of DreamHome
ISC329 Isabelle Bichindaritz 3810/3/2012
Relations that Represent the Global Logical Data Model for
DreamHome
ISC329 Isabelle Bichindaritz 3910/3/2012
Global Relation Diagram for DreamHome