10/3/2012ISC329 Isabelle Bichindaritz1 Logical Design.

ISC329 Isabelle Bichindaritz 110/3/2012

Logical Design

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.

Acknowledgments

• Some of these slides have been adapted from Thomas Connolly and Carolyn Begg

DecisionSupportSystem

ElectronicMedicalRecord

PrimaryCareProvider

extends

View contact

Browse contacts

Place contact KnowledgeBase

Authenticate user

<<uses>>

Review solution

Provide solution

<<uses>>

KnowledgeBase

<<extends>>

Create solution

<<extends>>LTFUSpecialist

extends

Generate statistics

<<uses>>

Use case diagram

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

isSubjectOf

PrimaryCareProvider

lastContactDate : DatelastDateEstimated : Boolean

(from Use Case View)

places

extends

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)

getMedicationInformation

Symptom

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

presents 1

getSymptomInformation

AttributeValue

attribute : Stringvalue : String

Procedure

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

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)

getProcedureInformation

getLaboratoryInformation

0..ngetTreatmentInformation

Diagnosis

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

getDiagnosisInformation

isPartOf0..n

isPartOf1..1

isPartOf0..n1..1

isPartOf

Class diagram

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

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

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

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

E-R Modeling is Iterative

Figure 6.8

Iterative Process of Verification

Figure 6.10

Distributed Database Design

• Design portions in different physical locations

• Development of data distribution and allocation strategies

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

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

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)

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

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

Local Conceptual Data Model for Staff View Showing all Attributes

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.

Remove *:* Binary Relationship Types

Remove *:* Recursive Relationship Types

Remove Complex Relationship Types

Remove Multi-valued Attributes

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.

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

• 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

• 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

Summary of How to Map Entities and Relationships to

Relations

Relations for the Staff View of DreamHome

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).

Referential Integrity Constraints for Relations in Staff View of DreamHome

Step 3 Build and Validate Global Logical

Data Model

• 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

Build and Validate Global Logical Data

Relations for the Branch View of DreamHome

Relations that Represent the Global Logical Data Model for

DreamHome

Global Relation Diagram for DreamHome

10/3/2012ISC329 Isabelle Bichindaritz1 Logical Design.

Documents

Transcript of 10/3/2012ISC329 Isabelle Bichindaritz1 Logical Design.

9/7/2012ISC329 Isabelle Bichindaritz1 The Relational Database Model.

Isabelle - web.cs.wpi.eduweb.cs.wpi.edu/~dd/resources_isabelle/isabelle-slides.ballarin.pdf · Contents I Intro & motivation, getting started with Isabelle I Foundations & Principles

Autohipnoza - Isabelle Thureau · 2019-03-07 · Title: Autohipnoza - Isabelle Thureau Author: Isabelle Thureau Keywords: Autohipnoza - Isabelle Thureau Created Date: 3/7/2019 3:01:35

Isabelle slideshow

10/15/2012ISC239 Isabelle Bichindaritz1 SQL Queries.

Isabelle Choinière - 1isabellechoiniere.com › Teaching_IsabelleChoiniere_Academia.pdf · Isabelle Choinière - 1 Isabelle CHOINIÈRE Curriculum vitae . March 22, 2018 (CV français

Isabelle tostivint

Lecture 4: Embedded methods Isabelle Guyon isabelle@clopinet.com.

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

ISC471/HCI 571 Isabelle Bichindaritz1 Operations Management 9/12/2012.

Isabelle Perrin

Isabelle Huppert

9/28/2012HCI571 Isabelle Bichindaritz1 Working with Data Data Summarization.

ISC471/HCI 571 Isabelle Bichindaritz1 Healthcare Financial Management 9/14/2012.

10/10/2012HCI571 Isabelle Bichindaritz1 Clinical Terminologies.

9/23/2012ISC329 Isabelle Bichindaritz1 Normalization.

11/16/2012ISC329 Isabelle Bichindaritz1 Web Database Application Development.

9/5/2012ISC329 Isabelle Bichindaritz1 Web Database Environment.

10/25/2012ISC239 Isabelle Bichindaritz1 SQL Commands.

Learning Theory Put to Work Isabelle Guyon isabelle@clopinet.com.