Optativa 4to (IIN400)

Modelado de Datos Conceptual:

Conceptos Básicos

Carlos A. Suárez-Núñez
csuarez@usfq.edu.ec

Slides adaptados de: ISE 3024 – Virginia Tech - Prof. John P. Shewchuk
8. CONCEPTUAL DATA MODELING:
FUNDAMENTAL CONCEPTS

 First step in database design: determining what is of

interest to us.
• what kinds of data are of concern.
• how the different kinds of data are related.

 This is called the conceptual schema.

 Conceptual schema = ‘blueprint’ for the database design.

8 –1
 Let’s first describe the fundamental concepts behind
conceptual data modeling.

 We will do this in the context of an ‘old-fashioned’ bookstore.

 We’ll then see how we can use the discovery process

to develop conceptual schema.

8 –2
8.1 Entities, Entity Classes, Attributes and Attribute
Values

 Entity = some particular object of interest to us.

• e.g., a book having ISBN 0-13-056517-2

John Smith (a customer)

Thomson International (a book supplier)

shelf s4 (a shelf in the bookstore)

8 –3
 Entity Class = collection of similar entities

e.g., Book entity class

Customer entity class

Supplier entity class

Shelf entity class

 Can also think of entities as instances of a given class.

8 –4
 Attributes = characteristics used to define similar entities.

e.g., Book entities defined by ISBN, title, author,

publisher, year, price, bookId

Customer: lastname, firstname, address

Supplier: name, state, phone, rating

Shelf: shelfId

8 –5
  Attribute Values = values for attributes for a particular entity.

e.g., Book entities:

book
Id title author publisher ISBN year price
12 Star Wars: Jedi Trial Dan Cragg Random House 0-3454-6115-0 2005 $6.99
27 Band of Brothers Stephen Ambrose Simon & Schuster 0-7432-2454-X 2001 $17.82
9 Circle of Friends Maeve Binchy Dell Publishing 0-4402-1126-3 1995 $7.99
37 Message In ABottle Nicholas Sparks Time Warner 1-5948-3636-1 1999 $7.50
23 The Long Road Home Danielle Steel Dell Publishing 0-4402-4344-0 2006 $14.99
4 Star Wars: Jedi Trial Dan Cragg Random House 0-3454-6115-0 2005 $6.99
18 Beyond Valor Patrick O’Donnell Simon & Schuster 0-6848-7385-0 2001 $8.99
32 Curious George Margret and H.A. Rey Houghton Mifflin 0-3951-5023-X 1973 $14.00
17 Beyond Valor Patrick O’Donnell Simon & Schuster 0-6848-7385-0 2001 $8.99

8 –6
 Customer entities:

address
lastName firstName street city state zip
Smith John 214 Church St. Blacksburg VA 24073
Davis Diane 185 Clay St. Blacksburg VA 24073
O’Keefe Patrick 35 Cambria St. Christiansburg VA 24061
Smith John 24 Range Road Radford VA 24141
Morgan Leslie 240 Kent St., Apt. 27 Christiansburg VA 24061
Carter Brian 14 2nd Street Lafayette IN 47096

8 –7
Supplier entities: Shelf entities:

name state phone rating shelfId

Thomson International CA (216) 175-5065 A
s1
ABC Books IN (216) 831-9175, A s2
(704) 668-2203 s3
BookWorld VA (331) 791-4982, C s4
(501) 773-7381 s5
s6
:
s40

8 –8
8.2 Attributes

Attribute Type
• single-valued - e.g., title (attribute of Book)
• multivalued - e.g., phone (attribute of Supplier)
• composite - e.g., address

8 –9
Attribute Definition

i) name

ii)data type - e.g., integer, string, currency, date

iii) length - e.g., 4-digit integer, 20-character string

iv) format - e.g., “#.##” for decimal

v) domain, or set of possible values

vi)description

8 –10
  e.g.,
Data
Name Type Length Format Domain Description Example

title string unbounded none none Title of a book Beyond Valor

address composite Two strings of none none An address con- 214 Church St.,
string 36 characters, sisting of street, Blacksburg,
one2-char city, state, and VA,24073
string, one zip code
5-char string
phone multivalued 10 char xxx-xxx-xxxx none Phone numbers 216-175-5065
string
price currency 5 digits $xxx.xx none Price ($,cents) 17.42
shelfId string 2 char none “s1”–“s40” Shelf identifier s3
year integer 4 digits none Values Year (Julian 1994
1900-2010 calendar)

8 –11
Key Attributes
 Key Attribute = attribute which, either on its own or along
with others, uniquely identifies entities
within a class.

e.g., for our bookstore:

Book:

Customer:

Supplier:

Shelf:

8 –12
 Each such attribute (or set of attributes) = key.
• Primary key: preferred (only) key. Every entity class must
have a primary key.
• Secondary key: alternative key.Entity classes may have
one or more secondary keys.

 For any key,

• value must be provided
(cannot have nulls).
• set of values defining the key
must be unique (no duplicates).

 Primary key objectives: - single attribute

- value unlikely to change
8 –13
Non-Key Attributes
 Non-key attribute = attribute which is not part of any key.

e.g., for our bookstore:

Book: title, author, publisher, ISBN,

year, price,

Customer:

Supplier:
Shelf:

8 –14
 For any non-key attribute:

• values do not have to be provided (up to user).

• values do not have to be unique (up to user).

 Nulls (i.e., no values provided) should be avoided if

possible. A null could mean

• the attribute is not applicable for that entity

• the value is known but missing (i.e., not recorded).

• the value is unknown.

8 –15
 e.g.,
address
lastName firstName street city state zip
Smith John 214 Church St. Blacksburg VA 24073
Davis Diane
O’Keefe Patrick 35 Cambria St. VA 24061
Smith John 24 Range Road Radford VA 24141

8 –16
Derived Attributes
 Derived attribute = attribute for which values are not
entered directly, but is calculated from
other data instead.

e.g., for our bookstore:

Book:

Customer:

Supplier:

Shelf

8 –17
8.3 Relationships and Relationship Types

 Many situations: entities related to one another.

e.g., whenever a customer buys a book, a relationship is

created between that customer and that book.

 Important part of conceptual data modeling: establishing

what kinds of relationships can occur and incorporating this
information into the conceptual schema.

8 –18
 Relationship Type = specification of the nature of an
association that one entity may have
with another (entities of different
classes usually)

e.g., Customer Purchases Book

 Relationship = specific association between two actual

entities, per given relationship type.

e.g., “John Smith buys ‘Band of Brothers’ ”

8 –19
 Can also think of relationships as instances of a given
relationship type.

 Relationship types identified via verb phrases incorporating

entity classes, e.g.,
Phrase Relationship Type Between
A customer buys a book Purchases Customer, Book
Books are found on shelves FoundOn Book, Shelf

 Reverse order can also be used.

e.g., Shelf Holds Book

8 –20
 Relationship types may have attributes (just like entity
classes).

g. ., Customer Purchases Book

• whenever a customer buys a book, we may want

to record the date of the sale.
• the corresponding attribute, saleDate, only exists
for a given sale, i.e., customer and book.

e.g., Book AvailableFrom Supplier

price = cost of that book from that supplier
= attribute of relationship type AvailableFrom

8 –21
8.4 Constraints on Relationship Types

Cardinality Ratio Constraint

 One-to-One (1:1) – an entity from either class may be

related to at most one entity from
the other class.

e.g., relationship type isMarriedTo between Man and

Woman
Each man may be married to at most one woman
Each woman may be married to at most one man

 Man to Woman is 1:1

8 –22
 One-to-Many (1:M) – an entity from the first class may be
related to multiple entries from the
second: an entity from the second
may be related to at most one entity
from the first.

e.g., Customer Purchases Book

Each customer may purchase many books

 Customer to Book is 1:M

8 –23
 Many-to-Many (M:N) – an entity from either class may
be related to multiple entries
from the other class.

e.g., Book AvailableFrom Supplier

Each book may be available from multiple suppliers

 Book to Supplier is M:N

8 –24
Min/Max Constraints

 How many relationships of a given type an entity may have.

e.g., Shelf Holds Book. Each shelf can hold no more

than 60 books.
- max cardinality of Book = 60
- min cardinality of Book = 0

 every Shelf entity can be associated with between

0 and 60 Book entities.

 some Shelf entities may not be associated with any

Book entities.

8 –25
Each book, however, is found in exactly one shelf.
- max cardinality of Shelf = 1
- min cardinality of Shelf = 1

 every Book entity can be associated with between

1 and 1 Shelf entity.

 every Book entity associated with exactly one

Shelf entity.

8 –26
Participation Constraints

 Whether or not entities must participate in associated

relationship types.
g. ., Customer Purchases Book
- participation of Customer: optional
(Customer can exist without any books)
- participation of Book: optional

Shelf Holds Book

- participation of Shelf: optional
(Some shelves may not have any books)
- participation of Book: mandatory
(Every book must be located on some shelf)
8 –27
 Note that
• optional participation when min cardinality of related
entity class = 0.

e.g., cardinality of Book = (0..60)  participation of

Shelf optional
• mandatory participation when min cardinality of
related entity class > 0.

e.g., cardinality of Shelf = (1..1) 

 Thus, we can use min cardinality to determine and/or

specify whether participation is mandatory or optional.

8 –28
 8.5 The Discovery Process

 To obtain the information needed to construct a

database, the discovery process is used.

 Consists of interviewing the people involved with the data

management application, analyzing current documents and
information systems, etc., to determine
• user requirements. What kind of operations are the users
interested in performing on the data? What types of queries
will they be interested in?

• objects of interest (entities), their characteristics

(attributes), and how they interact (relationships).

8 –29
 Result = narrative descriptions of how process/system
works or what information must be extracted from it.

 Such descriptions usually incomplete, conflicting,

ambiguous, and/or contain irrelevant information.
• database designer must sort through the mess and
come up with a single, agreed-upon description.
• iterative process.

 Discovery process can also results in descriptions of

how the data management application must behave.

 Such information is often referred to as the behavioral

model of the system.
8 –30
8.6 Example: Conceptual Data Modeling for Anna’s
Books

 Anna’s Books is a small, locally-operated bookstore

which sells books the ‘old-fashioned’ way (i.e., person-to-
person, no online sales).

 The store owner has hired you as a consultant to design

and implement an information system to aid in selling
books.

 The discovery process has resulted in the following

description of user requirements and system operation:

8 –31
Anna’s Books is a small bookstore which sells books to walk-in
customers. The owner wants computer support in:

• locating where (i.e., on what shelf) a given book can be

found.

• determining how many copies of a given title are on

hand.

• tracking customer sales, and

• keeping track of what books are available from which

suppliers, and at what price.

8 –32
Customers purchase one or more books at a time: for each
purchase, the date must be recorded. The first and last name of
each customer is known: it is desirable to also know each
customer’s address (for advertising purposes). The title, author,
publisher, year, price, and ISBN # are recorded for each book.

Books are located on one of forty shelves. Each shelf can hold up
to sixty books. All books of the same type (i.e., title) are to be kept
together on the same shelf (one shelf is sufficient for any title).

Books are obtained from different suppliers, each of whom has a

rating (A, B, or C), is located in a particular state, and can be
contacted via one or more phone numbers. Every book is available
from at least two different suppliers: a single supplier may supply
many different books. Suppliers not able to provide any books
should still be kept on record. For each book and possible supplier,
we need to know the book price.
8 –33
(a) Entity classes, attributes, and additional attribute information:
Attribute Type and/or
Entity Class Attribute Constraints
Customer firstName Partial key
lastName Partial key
address Partial key; composite
attribute consisting of
street, city,
state, zip
Book bookId Key
title
author
publisher
year
price Currency; not null
ISBN

8 –34
 Attribute Type and/or
Entity Class Attribute Constraints
Supplier name Key
state
phone Multivalued attribute
rating Value from {A, B, C}
Shelf shelfId Key

8 –35
(b) Relationship types, cardinality ratio constraints, and attributes:
Relationship Type and Cardinality
Entity Classes Ratio Attributes
Customer Purchases Book 1:M saleDate
Book AvailableFrom Supplier M:N price
Shelf Holds Book 1:M

Note that as (i) Shelf has no other attributes besides key,

and (ii) has only a simple relation with Book, we could
simply make shelfId an attribute of Book.

Best to leave as a separate entity, however:

• meaning clearer.
• may want to provide additional shelf information later.

8 –36
(c) Participation constraints and min/max cardinality constraints:

Relationship Type Entity Class Participation Min/Max

Constraint Cardinality
Purchases Customer optional (0..1)
Book optional (0..M)

AvailableFrom Book mandatory (0..M)

Supplier optional (2..N)

Holds Shelf optional (1..1)

Book mandatory (0..60)

8 –37
8.7 Example: Conceptual Data Modeling for JA
Industries

 You are an IE at JA Industries, a company employing

cellular manufacturing.

 Theplant manager has charged you with improving

productivity on the shop floor.

 Thediscovery process has resulted in the following

description of user requirements and system operation.

8 –38
JA Industries produces various machined components via
the use of manufacturing cells. The company aims to
improve productivity on the shop floor.

Typical questions arising in support of this effort:

• Where (i.e., what machine and/or cell) are parts located?

• What is the status (e.g., busy) of each machine?

• What processes are required for a given part?

• Which machines are capable of a given process?

8 –39
Each cell at JA Industries has a unique cell number, is of a
specific type, and consists of 2-4 machines. Some cells also
contain a robot for loading/unloading machines, in which case
the single robot handles all machines in the cell. Every robot
has a particular number, and is of a specific type and model.
Shop workers perform load/unload if there is no robot in a cell.

Each machine has a unique name, and is of a specific type. A

separate number identifies the machine amongst all machines
of that type (e.g., 3rd machine of type T4).

Every machine can perform up to 5 different processes, where

each process is defined by a unique identifier and a process
description. Every process can be performed by at least one
machine: some can be done by multiple machines. Not all
machines perform a given process equally: the efficiency may
vary from one machine to another.
8 –40
Each part produced in the facility has a unique serial number
(SN) and is of a given type. For each part type, a unique process
plan exists. The process plan specifies the sequence of
operations (between 1 and 4) for that part type, where each
operation is defined by machine, process, setup time, and run
time.

Also associated with each process plan is a list of the planners

responsible for the plan. Some processes and machines may not
be required for any operations.

At any given time during production, every part in the system is

located at a machine (i.e., in process or waiting to be processed).
A given machine may not have any parts, however. Additionally,
at any time, each machine is either busy, idle, or down.

8 –41
(a) Entity classes, attributes, and additional attribute information:

Attribute Type and/or

Entity Attribute Constraints
Cllass
Cel cellNo Key
cellType

Robot robotNo Key

robotType
robotModel

Machine machName Key

machNo Partial secondary key
machType Partial secondary key
status Value from {busy, idle down}

8 –42
 Constraints or Further
Entity Class Attribute Description
Part partSN Key
Op
Process processId Key
process
Description
ProcessPlan planNo Key
partType
planners Multivalued attribute
date
Operation opno Key
setup
run

8 –43
(b) Relationship types, cardinality ratio constraints, and attributes:

Relationship Type and Cardinality

Entity Classes Ratio Attributes
Cell Has Machine
1:M
Cell Contains Robot 1:1
Robot Serves Machine 1:M
Machine Has Part 1:M
Process DoneAt Machine M:N efficiency
Process DoneVia Operation 1:M
Machine Performs Operation 1:M
ProcessPlan Has Operation 1:M
ProcessPlan For Part 1:M

8 –44
(c) Participation constraints and min/max cardinality constraints:

Relationship Entity Participation Min/Max

Type Class Constraint Cardinality
Has Cell mandatory (1..1)
Machine mandatory (2..4)
Contains Cell optional (1..1)
Robot mandatory (0..1)
Serves Robot mandatory (0..1)
Machine optional (2..4)
Has Machine optional (1..1)
Part mandatory (0..M)

8 –45
 Relationship Entity Participation Min/Max
Type Class Constraint Cardinality
DoneAt Process mandatory (1..5)
Machine mandatory (1..M)
DoneVia Process optional (1..1)
Operation mandatory (0..M)
Performs Machine optional (1..1)
Operation mandatory (0..M)
Has ProcessPlan mandatory (1..1)
Operation mandatory (1..4)
For ProcessPlan optional (1..1)
Part mandatory (0..M)

8 –46