bagian 2 pemodelan konseptual part 1

8/14/2019 Bagian 2 Pemodelan Konseptual part 1

1/44

Pemodelan KonseptualPemodelan Konseptual

BasisdataBasisdataKuliah 2 BasisdataIlmu Komputer

IPB

Referensi: Rob and Coronel. Database Systems:

Design, Implementation, andManagement, Sixth Edition,

Jeffrey A. Hoffer. Modern SystemsAnalysis and Design, thisd edition.

dll


2/44

Topik BahasanTopik Bahasan

Gambaran Umum Peracangan BasisdataKonseptual

Fase perancangan Basisdata

Konsep-konsep dalam pemodelan data

ER-Model


3/44

The Design Process

Good decisions require good

information derived from rawfacts known as data.


4/44

Importance of good database

designWell designed database facilitates

data management and becomes agood information generator.

It will grow well.It is easy to use.


5/44

Nails33342003YorkBloggsJW300

Bolts22342002YorkBloggsJW300

Nuts12342001YorkBloggsJW300

DescripPartNoQtyItemNoCompAdd

CompPackerNoteNo

What is wrong with this

organisations database?

Info about Packer, Comp andCompAdd has been repeated

in more than one row

If Bloggs was the only companyto have purchased Nuts andthen decided they did not wantthem so were deleted frompacking note, contents of ParNo

and Descrip fields would be lost

PartNo and Descrip fields cannot beestablished until a packing note has

been raised.

Update anomaly

Delete anomaly

Insert anomaly


6/44

Architect

PlanBuilder

House

Database Designer

Database Design

Database Builder

Database System


7/44

SystemsDevelopment Life

CycleProject Identification

and Selection

Project Initiation

and Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Enterprise modeling

Conceptual data modeling

Logical database design

Physical database designand definition

Database implementation

Database maintenance

DatabaseDatabase

Development ProcessDevelopment Process


8/44

Enterprise ModellingPurpose of modelling: not only IS design

Models not only what but also why

Integrates conceptual and processmodels of the business with objectives,

actors, business rules and informationsystem requirements

Makes information system solutionstraceable to objectives

Makes conceptual modelling aparticipatory activity


9/44

Iterative development ofknowledge and models

Objectives

InformationConceptsProcesses

Actors

IS requirements

Business Rules

ConceptualModels


10/44

Participation inmodelling


11/44

Modelling during four+decades

Pioneeringwork -

concepts

Refinement,

models and

extensions

The search

for a common

framework

Participation

and

understanding

60-ties

70-ties

80-ties

90-ties

2005

- Extended

scope-Standardisation

efforts

Database

models

Information

System models

Modelling of why,

Enterprise models

Temporal

aspects

User education

and participation

Domain Specific

Ontological Models

and languages

Business rule

modelling

Formality

vs informality


12/44

A simplified database

design process

UoDRequirementsCollection and

Analysis

DatabaseRequirements

FunctionalRequirements


13/44


design process

DatabaseRequirements

FunctionalRequirements

ConceptualDesign

FunctionalAnalysis

ConceptualSchema

High-levelTransaction

Specs

DBMS INDEPENDENT


14/44


design process

PhysicalDesign

Application programDesign

ConceptualSchema

High-level

TransactionSpecs

DBMS DEPENDENT

TransactionImplementation

InternalSchema

Applicationsoftware


15/44

Conceptual Schema Outcome of the high-level conceptual

design

Concise description of datarequirements of the users

Includes description of entity types,relationships and constraints

No implementation details Ease of understanding. Used to

communicate with non-technical users


16/44

The Database DesignProcess

1 Define the current process.

2 Define the components of theorganisation.

3 Define rules (how organisation

is run).

4 Model the database.

5 Define the relationships.

6 Review.

7 Create the database.

4, 5, & 6 areconceptual

database design


17/44

What is Conceptual Database

Design?

Representation of organizational dataPurpose is to show rules about the

meaning and interrelationships amongdata

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

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

The output of the conceptual databasedesign is a Conceptual Data Modelusually ER Diagram ( + Data


18/44

What is Conceptual Database

Design

Main goal of conceptual datamodeling is to create accurate E-R

diagramsConsistency must be maintained

between process flow, decision

logic and data modelingdescriptions

10.18


19/44

A Common Mistake

Modeling the business processes or functionsinstead 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.


20/44

Example:

Member BooksSearches

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.


21/44

Gathering Information forConceptual Data ModelingTwo perspectives

Top-down Data model is derived from an intimate

understanding of the businessBottom-up Data model is derived by reviewing

specifications and business documents

10.21


22/44

Conceptual Design Phase

DATA

TOP-DOWN

BOTTOM-UP

Identify Entities

Identify Relationships

Identify Attributes

Identify Relationships

Identify Dependencies

Collect Data


23/44

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

design.

Entity Relationship (ER) Diagram

A detailed, logical representation of the entities,associations and data elements for anorganization or business

ERD represents the conceptual database as viewedby end user

ERDs depict the ER models three maincomponents:

Entities

Attributes


24/44

Entity-Relationship (ER) Modeling.

ER Modeling is a top-downapproachto database design.

Entity Relationship (ER) Diagram

A detailed, logical representation of theentities, associations and data elementsfor an organization or business

Notation uses three main constructs

Data entities Relationships

Attributes

Chen Model &Crows FootModel


25/44

Person, place, object, eventor concept about which data

is to be maintained

named property orcharacteristic of an

entity

Associationbetween the

instances of one ormore entity types

Represents a set or collection ofobjects in the real world thatshare the same properties

Chen Notation

EntityName Verb Phrase AttributeName


26/44

Entities

Refers to the entity setand not toa single entity occurrence

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

In both the Chen and Crows Foot

models, an entity is represented bya rectangle containing the entitysname

Entity name, a noun, is usually


27/44

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

999-31-2356, jzhang@, Jie Zhang, 20, 3.0

999-32-1234, ajain@, Anil Jain, 21, 3.8

entity


28/44

Is it an entity?

Rules:

2. An entity must be important to theorganisation.

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 beuniquely identifiable (customer id)


29/44

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 entitytypes:

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 theevent, not the activity or process of the event.


30/44

Attributes

Characteristics of entities

In Chen model, attributes are

represented by ovals and areconnected to the entity rectanglewith a line

Each oval contains the name ofthe attribute it represents

In the Crows Foot model, the

attributes are simply written in the


31/44

Attributes

single-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 ofbirth.


32/44

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.


33/44

The Attributes of theSTUDENT Entity


34/44


35/44

Identifier Attributes

Candidate key

Attribute (or combination of attributes) thatuniquely identifies each instance of an entity type

Some entities may have more than one candidatekey

Ex: A candidate key for EMPLOYEE is Employee_ID, asecond is the combination of Employee_Name andAddress.

If there is more than one candidate key, need to make achoice.

Identifier

A candidate key that has been selected as theunique identifying characteristic for an entity type


36/44

Referential Attributes

Name IdNum DeptID Email

Ali 105 LG [email protected]

Mary 106 IT [email protected]

John 107 ENG [email protected]

Lim 108 IT [email protected] of Lecturer.

Referential attribute:Ties the lecturer entity toanother entity that is department.

Make Reference to another instance in another table


37/44


38/44

Attributes

Multivalued attributes

Derived Attribute


39/44

A Multivalued Attribute inan Entity


40/44

Resolving MultivaluedAttribute Problems

Although the conceptual model canhandle multivalued attributes, youshould not implement them in therelational DBMS

Within original entity, create severalnew attributes, one for each of the

original multivalued attributescomponents

Can lead to major structural problems in thetable

Splitting the Multivalued


41/44

Splitting the MultivaluedAttribute into New

Attributes

C d f


42/44

Composed of aMultivalued Attributes

Components


43/44

Derived Attributes

Attribute whose value may becalculated (derived) from other

attributes

Need not be physically storedwithin the database

Can be derived by using analgorithm

i i f i d


44/44

Depiction of a DerivedAttribute

bagian 2 pemodelan konseptual part 1

Documents