9/19/2012isc329 isabelle bichindaritz1 conceptual data modeling

9/19/2012 ISC329 Isabelle Bichindaritz 1

Conceptual Data Modeling

ISC329 Isabelle Bichindaritz 29/19/2012

Learning Objectives• How to use ER modeling to build a local

conceptual data model based on information given in a view of the enterprise.

• How to validate resultant conceptual model to ensure it is a true and accurate representation of a view of the enterprise.

• How to document process of conceptual database design.

• End-users play an integral role throughout process of conceptual database design.

9/19/2012 ISC329 Isabelle Bichindaritz 3

Acknowledgments

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


Figure 6.3

Database Lifecycle (DBLC)


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


Methodology Overview - Conceptual Database Design

• Step 1 Build conceptual data model– 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


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


Step 1 Build Conceptual Data Model

To build a local conceptual data model of an enterprise.

• Step 1.1 Identify entity types– To identify the main entity types that are required

by the enterprise.

• Step 1.2 Identify relationship types– To identify the important relationships that exist

between the entity types that have been identified.



• Step 1.3 Identify and associate attributes with entity or relationship types– To identify and associate attributes with the

appropriate entity or relationship types and document the details of each attribute.

• Step 1.4 Determine attribute domains– To determine domains for the attributes in the local

conceptual model and document the details of each domain.



• Step 1.5 Determine candidate and unique identifier attributes– To identify the candidate key(s) for each entity and

if there is more than one candidate key, to choose one to be the unique identifier.

• Step 1.6 Consider use of enhanced modeling concepts (optional step) – To consider the use of enhanced modeling concepts,

such as specialization / generalization, aggregation, and composition.



• Step 1.7 Check model for redundancy – To check for the presence of any redundancy in the model.

• Step 1.8 Validate conceptual model against user transactions – To ensure that the conceptual model supports the transactions

required.

• Step1.9 Review local conceptual data model with user– To review the local conceptual data model with the user to

ensure that the model is a ‘true’ representation of the user’s view of the enterprise.


Extract from Data Dictionary for Staff View of DreamHome

Showing Description of Entities


First-cut ER diagram for Staff View of DreamHome


Extract from Data Dictionary for Staff View of DreamHome Showing

Description of Relationships


Extract from Data Dictionary for Staff View of DreamHome

Showing Description of Attributes


ER Diagram for Staff View of DreamHome

with Unique Identifiers Added


Revised ER Diagram for Staff View of DreamHome with Specialization /

Generalization


Example of a Non-Redundant Relationship FatherOf


User Transactions in the Staff View

( a) List details of staff supervised by a named Supervisor at the branch.

( b) List details of all Assistants alphabetically by name at the branch.

( c) List the details of property ( including the rental deposit) available for rent at the branch, along with the owner’s details.

( d) List the details of properties managed by a named member of staff at the branch.

.



( e) List the clients registering at the branch and the names of the members of staff who registered the clients.

( f ) Identify properties located in Glasgow with rents no higher than £ 450.

( g) Identify the name and telephone number of an owner of a given property.

( h) List the details of comments made by clients viewing a given property.



( i) Display the names and phone numbers of clients who have viewed a given property but not supplied comments.

( j) Display the details of a lease between a named client and a given property.

( k) Identify the leases due to expire next month at the branch.

( l) List the details of properties that have not been rented out for more than three months.

( m) Produce a list of clients whose preferences match a particular property.


Using Pathways to Check that the Conceptual

Model Supports the User Transactions


Data analysis and Requirements• Focus on:

– Information needs– Information users– Information sources– Information constitution

• Data sources– Developing and gathering end-user data views– Direct observation of current system– Interfacing with systems design group

• Business rules


E-R Modeling is Iterative

9/19/2012isc329 isabelle bichindaritz1 conceptual data modeling

Documents

local conceptual model

conceptual data modelstep

resultant conceptual

conceptual data modelto

check model

redundancy step

user transactions step

entity typesstep