Bagian 2 Pemodelan Konseptual
Transcript of Bagian 2 Pemodelan Konseptual
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
60ties
70ties80ties
90ties
2005
Extended scopeStandardisationefforts
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
HighlevelTransaction
Specs
DBMS INDEPENDENT
A simplified database design process
PhysicalDesign
Application programDesign
ConceptualSchema
HighlevelTransaction
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
TOPDOWN
BOTTOMUP
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
EntityRelationship (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 (999213415, jsmith@, John Smith, 18, 3.5)
Students in ITCS3160
999213415, jsmith@, John Smith, 18, 3.5999312356, jzhang@, Jie Zhang, 20, 3.0999321234, 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 [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 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
Manytoone OnetooneManytomany
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 (ACCT211)
Intro to Microcomputing (CIS220)
Intro to Statistics (QM261)
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