APPENDIX C

DESIGNING
DATABASES

© 2014 by McGraw-Hill Education. This is proprietary material solely for authorized instructor
use. Not authorized for sale or distribution in any manner. This document may not be copied,
scanned, duplicated, forwarded, distributed, or posted on a website, in whole or part.
 2

INTRODUCTION
 The core chapters introduced:
• Database - maintains information about various types
of objects (inventory), events (transactions), people
(employees), and places (warehouses)

• Database management system (DBMS) – creates,

reads, updates, and deletes data in a database while
controlling access and security

• Relational database model - a type of database that

stores its information in the form of logically-related
two-dimensional tables
 3

ENTITIES AND DATA

RELATIONSHIPS
 Data model – The logical data structures that detail the
relationships among data elements using graphics or
pictures
 The underlying relationships in a database environment
are:
• Independent of the data model
• Independent of the DBMS that is being used
 Entity-relationship diagram (ERD) - A technique for
documenting the relationships between entities in a
database environment
 4

Entities And Their Attributes

 Entity - Also called a table, stores information
about a person, place, thing, transaction, or
event
• A customer is an entity, as is a merchandise item

 Attribute – Data elements associated with an

entity
A CUSTOMER entity can be described by a Customer
Number, First Name, Last Name, Street, City, State, Zip
Code, Phone Number
 5

Entities And Their Attributes

 6

Attributes
 There are several types of attributes
including:
• Simple versus composite
• Single-valued versus multi-valued
• Stored versus derived
• Null-valued
 7

Simple versus Composite

 Composite attributes can be divided into smaller
subparts, which represent more basic attributes
that have their own meanings
 Example: Address
Address can be broken down into a number of subparts,
such as Street, City, State, Zip Code
Street may be further broken down by Number, Street
Name, and Apartment/Unit Number

 Attributes that are not divisible into subparts are

called simple attributes
 8

Simple versus Composite

 9

Single-Valued versus Multi-Valued

 Single-valued attribute means having
only a single value of each attribute of an
entity at any given time
 Example:
• A CUSTOMER entity allows only one
Telephone Number for each CUSTOMER
• If a CUSTOMER has more than one Phone
Number and wants them all included in the
database the CUSTOMER entity cannot
handle them
 10

Single-Valued versus Multi-

Valued
 Multi-valued attribute means having the
potential to contain more than one value for an
attribute at any given time
 An entity in a relational database cannot have
multi-valued attributes, those attributes must be
handled by creating another entity to hold them
 Relational databases do not allow multi-valued
attributes because they can cause problems:
• Confuses the meaning of data in the database
• Significantly slow down searching
• Place unnecessary restrictions on the amount of data
that can be stored
 11

Single-Valued versus Multi-

Valued
 12

Stored versus Derived

 If an attribute can be calculated using the value of
another attribute, it is called a derived attribute
 The attribute that is used to derive the attribute is called
a stored attribute
 Derived attributes are not stored in the file, but can be
derived when needed from the stored attributes
 Example: A person’s age - if the database has a stored
attribute such as the person’s Date of Birth, you can
create a derived attribute called Age from taking the
Current Date and subtracting the Date of Birth to get the
age
 13

Null-Valued
 Null-valued attribute – Assigned to an
attribute when no other value applies or
when a value is unknown
 Example: A person who does not have a
mobile phone would have null stored at
the value for the Mobile Phone Number
attribute
 14

DOCUMENTING ENTITY-
RELATIONSHIP DIAGRAMS
 The two most commonly used styles of ERD
notation are:
1. Chen
2. Information Engineering
 The Chen model uses rectangles to represent
entities
• Each entity's name appears in the rectangle
and is expressed in the singular, as in
CUSTOMER
• Attributes are expressed in ovals
 15

Basic Data Relationships

 16

Basic Data Relationships

 The relationships that are stored in a database
are between instances of entities
 17

Basic Data Relationships

 Once the basic entities and attributes
have been defined, the next task is to
identify the relationships among entities
 There are three basic types of
relationships:
1. One-to-one
2. One-to-many
3. Many-to-many
 18

One-to-One
 One-to-one (1:1) – A relationship
between two entities in which an instance
of entity A can be related to only one
instance of entity B and entity B can be
related to only one instance of entity A
 19

One-to-Many
 One-to-many (1:M) – A relationship between two
entities, in which an instance of entity A, can be
related to zero, one, or more instances of entity B
and entity B can be related to only one instance of
entity A
 20

Many-to-Many
 Many-to-many (M:N) – A relationship
between two entities in which an instance
of entity A can be related to zero, one, or
more instances of entity B and entity B
can be related to zero, one, or more
instances of entity A
 21

Documenting Relationships –
The Chen Method
 The Chen method uses diamonds for
relationships and lines with arrows to
show the type of relationship between
entities
 22

Documenting Relationships –
The Chen Method
 There is no obvious way to indicate weak
entities and mandatory relationships
• An ORDER should not exist in the database without
a CUSTOMER
• ORDER is a weak entity and its relationship with a
CUSTOMER is mandatory
• Some database designers have added a new symbol
to the Chen method for a weak entity, a double-
bordered rectangle
 23

DEALING WITH MANY-TO-

MANY RELATIONSHIPS
 There are problems with many-to-many
relationships
1. The relational data model cannot handle
many-to-many relationships directly
– It is limited to one-to-one and one-to-many
relationships
– Many-to-many relationships need to be replaced
with a collection of one-to-many relationships
2. Relationships cannot have attributes
– An entity must represent the relationship
 24

Composite Entities
 Composite entities - Entities that exist to
represent the relationship between two
other entities
 Example:
• There is a many-to-many relationship
between an ITEM and an ORDER
An ORDER can contain many ITEM(s) and over
time, the same ITEM can appear on many
ORDER(s)
 25

Composite Entities
 26

Composite Entities
 27

RELATIONSHIP CONNECTIVITY
AND CARDINALITY
 Cardinality - expresses the specific number of entity
occurrences associated with one occurrence of the
related entity
 In the Chen model, the cardinality is indicated by placing
numbers beside the entities in the format of (x, y)
• The first number is the minimum value and the
second number is the maximum value
 28

Relational Data Model and the

Database
 Once the ERD is completed, it can be
translated from a conceptual logical
schema into the formal data model
required by the DBMS
 Most database installations are based on
the relational data model
 The relational data model is the result of
the work of one person, Edgar (E. F.)
Codd
 29

FROM ENTITIES TO TABLES

 The word “table” is used synonymously
with “entity”
 The definition specifies what will be
contained in each column of the table, but
does not include data
 30

FROM ENTITIES TO TABLES

 When rows of data are included, an
instance of a relation is created
 31

FROM ENTITIES TO TABLES

 When the same column name appears in more
than one table and tables that contain that
column are used in the same data manipulation
operation
• The name of the column must be qualified by
preceding it with the name of the table and a period

 Example:
• CUSTOMER.Customer Number, First Name, Last
Name, Phone Number
 32

FROM ENTITIES TO TABLES

 A row in a relation has the following
properties:
• Only one value at the intersection of a column
and row - a relation does not allow multi-
valued attributes
• Uniqueness - there are no duplicate rows in a
relation
• Primary key - A field (or group of fields) that
uniquely identifies a given entity in a table
 33

FROM ENTITIES TO TABLES

 A unique primary key makes it possible to
uniquely identify every row in a table
 The primary key is important to define to be able
to retrieve every single piece of data put into a
database
 There are only three pieces of information to
retrieve for any specific bit of data:
1. The name of the table
2. The name of the column
3. The primary key of the row
 34

FROM ENTITIES TO TABLES

 The proper notation to use when
documenting the name of the table, the
column name, and primary key:
• CUSTOMER(Customer Number, First
Name, Last Name, Phone Number)
 Two qualities of all primary keys:
1. A primary key should contain some value
that is highly unlikely ever to be null
2. A primary key should never change
 35

LOGICALLY RELATING
TABLES
 The use of
identifiers
represent
relationships
between
entities
 36

LOGICALLY RELATING
TABLES
 When a table contains a column that is the
same as the primary key of a table, the column
is called a foreign key
 Foreign key - A primary key of one table that
appears as an attribute in another file and acts
to provide a logical relationship between the two
files
 Example:
• CUSTOMER(Customer Number, First Name, Last Name,
Phone Number)
• ORDER(Order Number, Customer Number, Order Date)
 37

LOGICALLY RELATING
TABLES
 Foreign keys do not necessarily need to
reference a primary key in a different table
• They need only reference a primary key

 Example:
• EMPLOYEE(Employee Number, First Name,
Last Name, Department, Manager Number)