Pemodelan Konseptual Pemodelan Konseptual BasisdataBasisdataKuliah 2 BasisdataIlmu KomputerIPB

Referensi:◦ Rob and Coronel. Database Systems:

Design, Implementation, and Management, Sixth Edition,

◦ Jeffrey A. Hoffer. Modern Systems Analysis and Design, thisd edition.

◦ dll

Topik BahasanTopik Bahasan

Gambaran Umum Peracangan Basisdata Konseptual

Fase perancangan BasisdataKonsep-konsep dalam pemodelan dataER-Model

The Design Process

Good decisions require good information derived from raw 

facts known as data.

Importance of good database designWell designed database facilitates 

data management and becomes a good information generator.

It will grow well.It is easy to use.

Nails33342003YorkBloggsJW300

Bolts22342002YorkBloggsJW300

Nuts12342001YorkBloggsJW300

DescripPartNoQtyItemNoComp   Add

CompPackerNoteNo

What is wrong with this organisation’s database?

Info about Packer, Comp and CompAdd has been repeated in more than one row

If Bloggs was the only company to have purchased Nuts and then decided they did not want them so were deleted from packing note, contents of  ParNo and Descrip fields would be lost

PartNo and Descrip fields cannot be established until a packing note has been raised.

Update anomaly

Delete anomaly

Insert anomaly

Architect

PlanBuilder

House

Database Designer

Database Design

Database Builder

Database System

Systems Development Life Cycle

Project Identification and Selection

Project Initiation and Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Enterprise modeling

Conceptual data modeling

Logical database design

Physical database design and definition

Database implementation

Database maintenance

Database Database Development Process Development Process 

Enterprise ModellingPurpose of modelling: not only IS designModels not only “what” but also “why”Integrates conceptual and process

models of the business with objectives, actors, business rules and information system requirements

Makes information system solutions traceable to objectives

Makes conceptual modelling a “participatory” activity

Iterative development of knowledge and models

Objectives

InformationConceptsProcesses

Actors

IS requirements

Business Rules

ConceptualModels

Participation in modelling

Modelling during four+ decades

Pioneeringwork ­concepts

Refinement,models andextensions

The searchfor a commonframework

Participationandunderstanding

60­ties

70­ties80­ties

90­ties

2005

­ Extended scope­Standardisationefforts

Databasemodels

InformationSystem models

Modelling of ”why”, Enterprise models

Temporalaspects

User educationand participation

Domain Specific ”Ontological Models”and languages

Business rulemodelling

Formalityvs informality

A simplified database design process

UoDRequirementsCollection and

Analysis

DatabaseRequirements

FunctionalRequirements

A simplified database design process

DatabaseRequirements

FunctionalRequirements

ConceptualDesign

FunctionalAnalysis

ConceptualSchema

High­levelTransaction

Specs

DBMS INDEPENDENT

A simplified database design process

PhysicalDesign

Application programDesign

ConceptualSchema

High­levelTransaction

Specs

DBMS DEPENDENT

TransactionImplementation

InternalSchema

Applicationsoftware

Conceptual Schema Outcome of the high-level conceptual

design Concise description of data

requirements of the users Includes description of entity types,

relationships and constraints No implementation details Ease of understanding. Used to

communicate with non-technical users

The Database Design Process

1 Define the current process.2 Define the components of the organisation.3 Define rules (how organisation is run).4 Model the database.5 Define the relationships.6 Review.7 Create the database.

4, 5, & 6 are  conceptual database design

What is Conceptual Database Design?Representation of organizational dataPurpose is to show rules about the

meaning and interrelationships among data

Process of describing the data, relationships between the data, relationships between the data, and the constraints on the data.

The focus is on the data, rather than on the processes.

The output of the conceptual database design is a Conceptual Data Model usually ER Diagram ( + Data Dictionary)

What is Conceptual Database Design

Main goal of conceptual data modeling is to create accurate E-R diagrams

Consistency must be maintained between process flow, decision logic and data modeling descriptions

10.18

A Common Mistake

Modeling the business processes or functions instead of the data.

What data we want to keep??We are interested in modeling the data, NOT the processes or functions that use or generate those data.

Example:

Member BooksSearchesM N

Is this part of the data requirement?Are we interested to know the books searched by the members?

If answer is NO, then DO NOT include that as a relationship.Use other appropriate diagramming techniques to capture the business processes such as Data Flow Diagram. Do not mix up the use of ER Modeling with DFD.

Gathering Information for Conceptual Data ModelingTwo perspectives

◦Top-down` Data model is derived from an intimate

understanding of the business

◦Bottom-up` Data model is derived by reviewing

specifications and business documents

10.21

Conceptual Design Phase

DATA

TOP­DOWN

BOTTOM­UP

Identify Entities

Identify Relationships

Identify Attributes

Identify Relationships

Identify Dependencies

Collect Data

The Entity Relationship (ER) ModelER Modeling is a top-down approach to database

design. Entity Relationship (ER) Diagram

◦ A detailed, logical representation of the entities, associations and data elements for an organization or business

ERD represents the conceptual database as viewed by end user

ERDs depict the ER model’s three main components:

◦ Entities

◦ Attributes

◦ Relationships

Entity­Relationship (ER) Modeling. 

ER Modeling is a top-down approach to database design.

Entity Relationship (ER) Diagram◦ A detailed, logical representation of the

entities, associations and data elements for an organization or business

Notation uses three main constructs◦ Data entities

◦ Relationships

◦ Attributes

Chen Model & Crow’s Foot Model

Person, place, object, event or concept about which data is to be maintained

named property or characteristic of an entity 

Association between the instances of one or more entity types 

Represents a set or collection of objects in the real world that share the same properties

Chen Notation

EntityName Verb Phrase AttributeName

Entities

Refers to the entity set and not to a single entity occurrence

Corresponds to a table and not to a row in the relational environment

In both the Chen and Crow’s Foot models, an entity is represented by a rectangle containing the entity’s name

Entity name, a noun, is usually written in capital letters

Entity  vs. Entity Set (Entities)

Entity Set (Entities) ­­­ Student 

John Smith (999­21­3415, jsmith@, John Smith, 18,  3.5)

Students in ITCS3160

999­21­3415, jsmith@, John Smith, 18,  3.5999­31­2356, jzhang@, Jie Zhang,   20,  3.0999­32­1234, ajain@,     Anil Jain,    21,  3.8

entity

Is it an entity?Rules:2. An entity must be important to the 

organisation.3. An entity must have at least one attribute.4. An entity must occur more than once  

(there must be more than one customer)5. Each entity occurrence (record) must be 

uniquely identifiable (customer id)

Entities

Examples of entities:◦ Person: EMPLOYEE, STUDENT, PATIENT

◦ Place: STORE, WAREHOUSE

◦ Object: MACHINE, PRODUCT, CAR

◦ Event: SALE,REGISTRATION, RENEWAL

◦ Concept: ACCOUNT, COURSE

Guidelines for naming and defining entity types:◦ An entity type name is a singular noun

◦ An entity type should be descriptive and specific

◦ An entity name should be concise

◦ Event entity types should be named for the result of the event, not the activity or process of the event.

Attributes

Characteristics of entities

In Chen model, attributes are represented by ovals and are connected to the entity rectangle with a line

Each oval contains the name of the attribute it represents

In the Crow’s Foot model, the attributes are simply written in the attribute box below the entity rectangle

 

Attributessingle-valued vrs multi-valued:

◦color of car could be multi-valued◦salary of employee is single-valued

atomic vrs composite: ◦age of a person is atomic◦address of a person could be composite

stored vrs derived:◦derived attributes are those that can be

derived from other attributes or entities, e.g., age can be derived from date of birth.

◦All other attributes are stored attributes

Attributes

Example of entity types and associated attributes:STUDENT: Student_ID, Student_Name, Home_Address,

Phone_Number, Major

Guidelines for naming attributes:◦ An attribute name is a noun.

◦ An attribute name should be unique

◦ To make an attribute name unique and clear, each attribute name should follow a standard format

◦ Similar attributes of different entity types should use similar but distinguishing names.

The Attributes of the STUDENT Entity

Domains

Attributes have a domain:

◦The attribute’s set of possible values

Attributes may share a domain

Identifier Attributes

Candidate key◦ Attribute (or combination of attributes) that

uniquely identifies each instance of an entity type

◦ Some entities may have more than one candidate key

Ex: A candidate key for EMPLOYEE is Employee_ID, a second is the combination of Employee_Name and Address.

` If there is more than one candidate key, need to make a choice.

Identifier◦ A candidate key that has been selected as the

unique identifying characteristic for an entity type

Referential Attributes

Name            IdNum                 DeptID         Email

Ali           105                  LG         ali@a.com

Mary           106                 IT          mary@a.com

John           107                 ENG          john@a.com

Lim           108                  IT          lim@a.comInstance of Lecturer.

Referential attribute: Ties the lecturer entity to another entity that is department.

Make Reference to another instance in another table

Example

Staff

StaffID

Name Gender

IC

StaffStaffIDNameGenderIC

PK

AttributesMultivalued attributes

Derived Attribute

A Multivalued Attribute in an Entity

Resolving Multivalued Attribute Problems

Although the conceptual model can handle multivalued attributes, you should not implement them in the relational DBMS

◦Within original entity, create several new attributes, one for each of the original multivalued attribute’s components

Can lead to major structural problems in the table

◦Create a new entity composed of original multivalued attribute’s components

Splitting the Multivalued Attribute into New Attributes

A New Entity Set Composed of a Multivalued Attribute’s Components

Derived Attributes

Attribute whose value may be calculated (derived) from other attributes

Need not be physically stored within the database

Can be derived by using an algorithm

Depiction of a Derived Attribute

Relationships

 Associations between instances of one or more entity types that is of interest Given a name that describes its function.

• relationship name is an active or a passive verb.

Author Book

Relationship name: writes

An author writes one or more booksA book can be written by one or more authors.

Constraints on Relationship Types

Constraints limit the set of possible combination of entities that can participate in the relationship type

Two main kinds of constraints: Cardinality constraints Participation constraints

Cardinality Constrain

Relationships can be classified as either

` one – to – one` one – to – many` many – to –many

Cardinality : minimum and maximum number of instances of Entity B that can (or must be) associated with each instance of entity A.

Cardinality Constrain

 

Cardinality Constraints on Relationship Sets

Consider binary relationship set R between entity sets A and B

One to one: an entity in A is associated with at most one entity in B, and an entity in B is associated with atmost one entity in A.◦ an employee has only one spouse in a married-

to relationship.Many to One: An entity in A is associated

with at most one entity in B, an entity in B is associated with many entities in A.◦ an employee works in a single department but

a department consists of many employees.

Cardinality Constraints on Relationship Sets (cont.)Many to Many: An entity in A is

associated with many entities in B, and an entity in B is associated with many entities in A.◦ A customer may have many bank

accounts. Accounts may be joint between multiple customers.

Notation

Chen Model◦1 to represent one. ◦M to represent many

Crow’s Foot

many

One

One or many

1

M

Mandatory one , means (1,1)

Partitipation constraint

Multiplicity of Relationships

Many­to­one One­to­oneMany­to­many

multiplicity of relationship in ER diagram represented by an arrow pointing to “one”

Many to Many Relationship

Multiple customers can share an account

Many accounts may have one owner

customer custacct account

opening date

Customer Account Start DateJohn 1001 Jan 20th 1999Megan 1001 March 16th  1999Megan 2001 Feb 18th 1994

Customer Account Start DateJohn 1001 Jan 20th 1999Megan 1001 March 16th  1999

legal legal 

N N

Many to One Relationship

Multiple customers can share an account but one customer can have only one account.

Customer Account Start DateJohn 1001 Jan 20th 1999Megan 1001 March 16th  1999Megan 2001 Feb 18th 1994

Illegal

Customer Account Start DateJohn 1001 Jan 20th 1999Megan 1001 March 16th  1999

legal

customer custacct account

opening date

N 1

Relationship Attribute in a Many to One Relationship

In a Many-One relationship, relationship attributes can be repositioned to the entity set on the many side.

customer custacct account

opening date

customer custacct account

opening date

N 1

N 1

One to One Relationship

1 customer can have 1 account.

One account can be owned by 1 customer

relationship attributes can be shifted to either of the entity sets

Customer Account Start DateMegan 1001 March 16th  1999Megan 2001 Feb 18th 1994

IllegalCustomer Account Start DateJohn 1001 Jan 20th 1999Megan 1001 March 16th  1999

Illegal

Customer Account Start DateMegan 1001 March 16th  1999John 2001 Feb 18th 1994

Legal

customer custacct account

opening date

1 1

car driver

car driver

car driver

car driver1:1 A car can only have one driver; a driver can have only one car.

1:M A car can have more than one driver; a driver can only one car.

1:M A car can have only one driver; a driver can have more than one car.

M:N A car can have more than one driver; a driver can have more than one car.

A typical company

Managing DirectorCompany

Sales Staff Customer

employs

manages

take orders

Relationship name

 

Participation Constraints

total participation is also called existential dependency mandatory

If an entity does not have a total participation in a relationship, it is said to have a partial participation optional

Mandatory vs. Optional Cardinalities

Specifies whether an instance must exist or can be absent in the relationship

Lecturer Classhandles

A Lecturer may handle zero or many classes. 

A class is handled by one and only one Lecturer.

OptionalMandatory

(0,N)(1,1)

Lecturer Class(0,N) (1,1)

handles1 M

Degree of Relationships

Degree: number of entity types that participate in a relationship

Three cases◦ Unary: between two instances of one entity type

◦ Binary: between the instances of two entity types

◦ Ternary: among the instances of three entity types

Three Types of Relationships

Unary

The 1:1 Recursive Relationship “EMPLOYEE is Married to EMPLOYEE”

Implementation of the M:N Recursive “PART Contains PART” Relationship

Implementation of the 1:M “EMPLOYEE Manages EMPLOYEE” Recursive Relationship

Binary Relationships

1:M relationship

◦ Relational modeling ideal

◦ Should be the norm in any relational database design

The 1: M relationship between PAINTER and PAINTING 

The Implemented 1:M relationship between PAINTER and PAINTING 

Binary Relationships

1:1 relationship

◦ Should be rare in any relational database design

◦ A single entity instance in one entity class is related to a single entity instance in another entity class

◦ Could indicate that two entities actually belong in the same table

The 1:1 Relationship Between PROFESSOR and DEPARTMENT

The Implemented 1:1 Relationship Between PROFESSOR and DEPARTMENT 

Binary Relationships

M:N relationships

◦ Must be avoided because they lead to data

redundancies.

◦ Can be implemented by breaking it up to

produce a set of 1:M relationships

◦ Can avoid problems inherent to M:N relationship

by creating a composite entity or bridge

entity

` This will be used to link the tables that were

originally related in a M:N relationship

` The composite entity structure includes-as

foreign keys-at least the primary keys of

the tables that are to be linked.

The M:N Relationship Between STUDENT and CLASS 

This CANNOT be implemented as shown next…..

Bowser

Smithson

Accounting 1 (ACCT­211)

Intro to Microcomputing (CIS­220)

Intro to Statistics (QM­261)

The tables have many redundancies!!

+ CLASS_CODECLASS_CODE

+ STU_NUM

Changing the M:N relationship to TWO 1:M relationships

Converting the M:N relationship into TWO 1:M relationships 

Foreign keys reference the primary keys in the other tables of which it has a relationship with

The database designer has 2 main options to define a composite table’s primary key: either 

use the combination of those foreign keys or create a new primary key.

How to Evaluate a Data Model?

A good data model has the following:◦ Accuracy and completeness

◦ Non redundancy

◦ Enforcement of business rules

◦ Data Reusability

◦ Stability and Flexibility

◦ Communication Effectiveness

◦ Simplicity

Next ….Enhanced/Extended ER model…

PR : A hospital in-patient system

A hospital is organised into a number of wards.

Each ward has a ward number and a name recorded, along with a number of beds in that ward.

Each ward is staffed by nurses.Nurses have their staff number and name

recorded, and are assigned to a single ward.

Each patient in the hospital has a patient identification number, and their name, address and date of birth are recorded.

Each patient is under the care of a single consultant and is assigned to a single ward.

Each consultant is responsible for a number of patients.

Consultants have their staff number, name and specialism recorded.

Exercise on In-patient system

1. State 4 entities for the system giving a suitable identifier for each entity.

2. Draw an entity-relationship diagram to show the relationships between the entities.

Semoga Bermanfaat,Sekian dan Terimakasih