1

CTI2F3
Database Modelling & Implementation

Data Modelling
 2

Learning Outcomes
Students are able to model or develop relational data
from case studies
 3

Topics
Introduction to Data Modelling
Modeling the Rules of the Organization
Entity Relationship Diagram
 4

>> If you don’t get the data right, nothing else matters <<
 5

Introduction to
Data Modelling
 6

Introduction to Data Modeling

• The importance of business rules

• ER-Model as the approach for conceptual data model

 7

ER-Model
• An Entity-Relationship Model (ER-Model) is detailed, logical representation of the
data for an organization or for a business area.
• Entities

• Relationships

• Attributes

• An ER-model is normally expressed as an Entity-Relationship Diagram

 8

Example
 Example 9

• A number of suppliers supply and ship different items to Pine Valley Furniture.
• The items are assembled into products that are sold to customers who order the
products.
• Each customer order may include one or more lines corresponding to the products
appearing on that order.
 Example 10

• CUSTOMER is a person or an organization that has ordered or might

order products.
Example: L. L. Fish Furniture.
 Example 11

• PRODUCT is a type of furniture made by Pine Valley Furniture that

may be ordered by customers.
Example: A 6-foot, 5-shelf, oak bookcase called O600.
• Note that a product is not a specific bookcase, because individual
bookcases do not need to be tracked.
 Example 12

• ORDER is the transaction associated with the sale of one or more

products to a customer and identified by a transaction number from
sales or accounting.
Example: The event of L. L. Fish buying one product O600 and four products
O623 on September 10, 2015.
 Example 13

• ITEM is a type of component that goes into making one or more

products and can be supplied by one or more suppliers.
Example: A 4-inch ball-bearing caster called I-27–4375.
 Example 14

• SUPPLIER is other company that may provide items to Pine Valley

Furniture.
Example: Sure Fasteners, Inc.
 Example 15

• SHIPMENT is the transaction associated with items received in the

same package by Pine Valley Furniture from a supplier.
• All items in a shipment appear on one bill-of-lading document.
Example: The receipt of 300 I-27-4375 and 200 I-27-4380 items from Sure
Fasteners, Inc., on September 9, 2015.
 16

Modeling the Rules

of the Organization
 17

Modeling the Rules of the Organization

• Business Rule

“a statement that defines or constrains some aspect of the business”

• Examples:
• “A student may register for a course only if he or she has successfully completed the
prerequisites for that course.”
• “A preferred customer qualifies for a 10 percent discount, unless he has an overdue account
balance.”
Business Rules Guideliness 18
 19

Guideliness in Naming Data

• Relate to business, not to technical
• Be meaningful
• Be unique
• Be readable
• Be repeatable
• Follow a standard syntax
 20

Entity
Relationship
Diagram
 21

ER-Diagram
• The ER data mode was developed to facilitate database design by allowing specification of an
enterprise schema that represents the overall logical structure of a database.

• The ER data model employs three basic concepts:

• entity sets,

• relationship sets,

• attributes.

• The ER model also has an associated diagrammatic representation, the ER diagram, which can
express the overall logical structure of a database graphically.
 22

Entity
 23

Entity
• An entity is a person, a place, an object, an event, or a concept in the user environment.
• An entity has a noun name.
• Examples:
• Person: EMPLOYEES, STUDENT, PATIENT
• Place: STORE, WAREHOUSE, STATE
• Object: MACHINE, BUILDING, ITEM
• Event: SALE, REGISTRATION, RENEWAL
• Concept: ACCOUNT, COURSE, WORKCENTER

Entity Type: a collection of entities that share common Entity Instance: a single occurence of an
properties or characteristics. It also called Entity Set. entity set
 24

Variation of Entity
Strong Entity
one that exists independently of other entity types
Weak Entity
the existence depends on some other entity type
Associative Entity
associates the instances of one or more entity types and
contains attributes that are specific to the relationship
between those entity instances. *will be discussed later
 25

Strong Entity
• Most of basic entity types are classified as strong entity.

• Instances of strong entity type always have a unique

characteristic (called an identifier)
– that is, an attribute or a combination of attributes that uniquely
distinguish each occurance of that entity.
 26

Weak Entity

• An entity that does not have a specific identifier. A weak entity must participate in an identifying relationship
type with an owner or identifying entity type.

• The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak
entity set is existence dependent, plus the weak entity set’s discriminator.

• The discriminator (or partial key) of a weak entity type is the set of attributes that distinguishes among all the
entities of a weak entity type.
 27

Attribute
 28

Attributes
• An entity is represented by a set of attributes; i.e., descriptive properties possessed
by all members of an entity set.
• Example:
employee = (employee_number, name, address, city, state, zip_code, date_hired, birth_date)

• A subset of the attributes form a primary key of the entity set; i.e., uniquely
identifying each member of the set.
 29

Attributes Type
• Simple and composite attributes.
• Simple Attributes : attributes that can’t be divided into different parts ;
• Composite Attribute : attributes that can be divided into parts ; example : Name, that can be divided into First Name and
Last Name
• Single-valued and multivalued attributes
• Single-valued Attributes : attributes that only have 1 value
• Multi-valued Attributes : Attributes that can have many values in the same domain ;
• Example: multivalued attribute: phone_numbers, address
• Derived attributes
• Can be computed from other attributes
• Example: age, given date_of_birth
Domain – the set of permitted values for each attribute
Attributes Type Example 30

Simple/
Single/Stored
Attribute

Derived and Multivalued can’t be identifier.

WHY??!!
 31

Relationship
 32

Relationship Sets
A relationship is an association among several entities

A relationship name is a verb

phrase (such as Assigned To,
Supplies, or Teaches).

Relationships represent actions

being taken, usually in the
present tense. The name states
the action taken, not the result
of the action (e.g., use
Assigned To, not Assignment)

Relationship and their characteristics (degree and cardinality) represent business rules.
 Attributes on Relationship 33

• Attributes may be associated with a many-to-many (or one-to-one) relationship. The attribute or
property of the relationship called as descriptive attribute.
• For example:
Date Completed has not been associated
with either the EMPLOYEE or
COURSE entity. That is because Date
Completed is a property of the
relationship Completes, rather than a
property of either entity.
Other attributes might be added to this relationship if appropriate,
such as Course Grade, Instructor, and Room Location. Please
In other words, for each instance of the complete the diagram with those attribute.
relationship Completes, there is a value
for Date Completed. One such instance
Descriptive attribute can’t be assosiated with a one-to-many
(for example) shows that the employee relationship. WHY??!!
named Melton completed the course
titled C++ in 06/2014.
 34

Assosiative Entities
A relationship cannot have key attributes.
What if it turns out that the conditions require it? then you may have an associative entity or
gerund.
An associative entity is an entity type that associates the instances of more or more entity types
and contains attributes that are specific to the relationship between those entity instances.
An EMPLOYEE completes a COURSE
of study and is awarded a certificate. The
CERTIFICATE is the associative entity.

Note that the relationship is converted

to a sort of entity - there is a clear
identifier attribute, Certificate
Number.
 35

Assosiative Entities
How do you know whether to convert a relationship to an associative entity type?
Following are four conditions that should exist:
1. All the relationships for the participating entity types are “many” relationships.
2. The resulting associative entity type has independent meaning to end users and, preferably,
can be identified with a single-attribute identifier.
3. The associative entity has one or more attributes in addition to the identifier.
4. The associative entity participates in one or more relationships independent of the entities
related in the associated relationship.

No relationship names on the

lines between an associative
entity and a strong entity.
WHY??!!
 36

Identifying
Relationship
 37

Identifying Relationship
• Identifying relationship
The relationship between a weak entity type and its owner.

• Identifying Owner
The entity type on which the weak entity type depends.
 38

Degree of
Relationship
 39

Degree of Relationship
• It refers to number of entity sets that participate in a relationship set.
• Relationship sets that involve two entity sets are binary (or degree two). Generally, most
relationship sets in a database system are binary.
• Relationship sets may involve more than two entity sets. The three most common relationship
degrees in E-R models are Unary (degree 1), Binary (degree 2), and Ternary (degree 3)
• Unary relationship is a relationship between the instances of a single entity type. (Unary
relationships are also called recursive relationships)
• Binary relationship is a relationship between the instances of two entity types and is the most
common type of relationship encountered in data modeling.
• Ternary relationship is a simultaneous relationship among the instances of three entity types.
 40

Examples
 41

Examples
 42

Examples
 43

Cardinality
Constraint
 44

Cardinality Constraint

• Cardinality constraint
specifies the number of instances of one entity that can (or must) be associated with each instance of another entity.
• Minimum cardinality
minimum number of instances of one entity that may be associated with each instance of another entity.
• Maximum cardinality
maximum number of instances of one entity that may be associated with each instance of another entity.
 45

Cardinality Constraint
• In general, participation in a relationship may be optional or mandatory for the entities involved. If
the minimum cardinality is zero, participation is optional; if the minimum cardinality is one,
participation is mandatory.
• It is possible for the maximum cardinality to be a fixed number, not an arbitrary “many” value.
• For example, suppose corporate policy states that an employee may work on at most five projects at
the same time. We could show this business rule by placing a 5 above or below the crow’s foot next
to the PROJECT entity

5
 46

Multiple
Relationship
Between Entity
 47

Multiple Relationship Between Entity

• There may be more than one relationship between the same entity types in a given
organization.
• Example #1:
 48

Multiple Relationship Between Entity

Example #2:
The example #2 shows two
relationships between the entity types
PROFESSOR and COURSE.
The first relationship, IsQualified is
associates professors with the
courses they are qualified to teach.

A given course must have at a minimum two qualified instructors (an example of how to use a
fixed value for a minimum or maximum cardinality).
This might happen, for example, so that a course is never the “property” of one instructor.
Conversely, each instructor must be qualified to teach at least one course
 49

Multiple Relationship Between Entity

The second relationship associates professors with the courses they are actually scheduled to
teach during a given semester. Because Semester is a characteristic of the relationship, we place
an associative entity, SCHEDULE, between PROFESSOR and COURSE

Notice that Semester is a partial

identifier; thus, the full identifier will be
the identifier of PROFESSOR along
with the identifier of COURSE as well
as Semester.

Because such full identifiers for associative entities can become long and complex, it is often
recommended that surrogate identifiers be created for each associative entity; so, Schedule ID
would be created as the identifier of SCHEDULE, and Semester would be an attribute.
 50

When to create a Surrogate Key?

A surrogate key is usually created to simplify the key structures. According to Hoberman (2006), a
surrogate key should be created when any of the following conditions hold:
• There is a composite primary key, as in the case of the DEPENDENT relation shown previously
with the four-component primary key.
• The natural primary key (i.e., the key used in the organization and recognized in conceptual data
modeling as the identifier) is inefficient. For example, it may be very long and hence costly for
database software to handle if it is used as a foreign key that references other tables.
• The natural primary key is recycled (i.e., the key is reused or repeated periodically, so it may not
actually be unique over time); a more general statement of this condition is when the natural primary
key cannot, in fact, be guaranteed to be unique over time (e.g., there could be duplicates, such as
with names or titles).
 51
Case Study
Buatlah ERD pada soal dibawah ini: (tambahkan asusmsi atribut jika tidak
didefinisikan di soal)
1. Construct an E-R diagram for a car insurance company whose customers own one
or more cars each. Each car has associated with it zero to any number of recorded
accidents. Each insurance policy covers one or more cars.
2. Construct an E-R diagram for a hospital with a set of patients and a set of medical
doctors. Associate with each patient examinations conducted. A patient can be
examined by some doctors and a doctor can examine some patient in one day
3. Each car is identified by a car identification number (CIN). Each individual car is a
particular model of a particular brand offered by the company (e.g., the XF is a
model of the car brand Jaguar of Tata Motors). Every model must be had one or
more car (no less). Every car must have exactly one model.
 52
Case Study
4. E-commerce Tel-U Mart memiliki produk untuk dijual. Terdapat beberapa jenis
produk antara lain makanan, minuman, obat-obatan, perabotan, dll. Setiap jenis
produk memiliki bermacam-macam item produk. Contoh: jenis produk makanan
memiliki item produk: bang-bang 200 gram, Mawar roti sandwich keju, dll.
Pembeli harus terdaftar menjadi anggota pada Tel-U Mart. Anggota dapat membeli
satu atau banyak produk dalam satu kali transaksi. Setiap transaksi akan diberikan
struk pembelian. Anggota dapat melakukan nol atau satu atau banyak transaksi
dalam satu hari
 53

Reference
Hoffer, Jeffrey A., et.al., "Modern Database Management", Twelfth Edition, Pearson,
2016. Chapter 2

Recommended Link:
https://www.codeproject.com/Articles/878359/Data-Modelling-using-ERD-with-Crow-
Foot-Notation
https://www.youtube.com/watch?v=xzQQW0NiAMM
 54

THANK
YOU