Module 6: Deriving a Physical Data Design

Module 6: Deriving a Physical Data
Design


THIS PAGE LEFT INTENTIONALLY BLANK




Module 1: Course
Overview
Module 4: Deriving a
Logical Data Design
Module 5: Normalizing the
Logical Data Design
Module 6: Deriving a
Physical Data Design
Module 7:
Implementing Data
Integrity
Module 2: Solution
Design Processes
Module 3: Using a
Conceptual Design for Data
Requirements
Module 8: Designing
Data Services
Module 9: Data Storage
Considerations
Designing Data

Services and
Data Models
Physical Data
Design
Activity 6.1: Translating the
Logical Data Design
Implementing
Relationships
Data Optimization
Techniques
Activity 6.2: Optimizing a
Physical Data Design
Module 6: Deriving a
Physical Data Design

Module 6: Deriving a Physical Data Design 119



!
!!
! Overview
"
Physical Data Design
"
Implementing Relationships
"
Data Optimization Techniques
"
Review

In this module...
In this module...


At the end of this module, you will be able to:
"
Derive a physical data design for tables and fields from a logical data
design.
"
Analyze data-usage characteristics to optimize a physical data design.
"
Determine methods for implementing relationships in a physical data
design.
"
Identify different optimization techniques.
"
Determine the proper criteria for optimizing a physical data design.

Slide Objective
To provide an overview of
this module’s topics and
objectives.
Lead-in
In this module, you will learn
about how data is stored,
how to implement a
relational model, and how to
optimize a database system.
120 Module 6: Deriving a Physical Data Design

!
!!
! Physical Data Design
"
Describing a Physical Data Model
"
Identifying Database Tables and Fields
"
Common Data Types
In this section...
In this section...


In this section, you will learn about the physical design of a database.
Slide Objective
To introduce general
relational database
concepts.
Lead-in
This section discusses a few
general relational database
concepts and the ways in
which data is stored.
Module 6: Deriving a Physical Data Design 121



Describing a Physical Data Model

"
Flat-file
$
ISAM
"
Hierarchical
$
Microsoft Exchange
"
Relational
$
SQL


Of the many different types of database management systems (DBMS)
available today, most use one of three models for storing data. These models
define the internal structure that the DBMS uses to keep track of data. The
structure affects the types of database tables that you can create, as well as the
speed of access and versatility of the database.
Flat-File
Flat-file databases were one of the first methods used to store data in an
organized format. A flat-file database uses a set of rows and columns to store all
information within a single file. There is no relationship between flat-file
databases because each database exists without knowledge of any other
database. Performance on this type of database is usually very good because of
its inherent simplicity. Fast updates and retrievals of flat-file data are achieved
by using an indexing method called the indexed sequential access method
(ISAM). Legacy mainframe databases, as well as smaller PC-based databases,
employ ISAM storage technology.
Hierarchical

Hierarchical databases are extensible and flexible. They have the advantage of
being able to store a wide range of information in a variety of formats. This
type of database is often used when information storage needs vary greatly. An
example of a hierarchical database is Microsoft
®
Exchange, which is capable of
storing varying types of information in a format that facilitates messaging and
collaboration applications. (With collaborative applications, many types of
information tend be encapsulated in messages.)
Relational
Relational databases combine the advantages of both flat-file and hierarchical
databases by providing good performance and flexibility of storage. The
relational model tends to be the most popular for new database development
because tables can be linked together with unique values. It is important to
understand, however, that the other models are still in use and that developers
Slide Objective
To introduce the different
data storage models
available for use with a
database management
system (DBMS).
Lead-in
A DBMS can store data in
several ways.
122 Module 6: Deriving a Physical Data Design



working in enterprise environments will likely need to interface with one of
these other types of databases at some point.

"
The relational model focuses on storing data, retrieving data, and
maintaining data integrity. Data is stored in one or more tables, consisting of
columns and rows, within a single file. Related items of data can be
retrieved efficiently by using Structured Query Language (SQL), regardless
of whether the items are all stored in one table or in many tables. Data
integrity is maintained by applying rules and constraints.
Module 6: Deriving a Physical Data Design 123



Identifying Database Tables and Fields
"
Each entity becomes a table in the physical model
$
Tables are organized in rows and columns
Each row is an instance of an entity
Each column is an attribute
$
Tables can be linked
"
Fields are the attributes of the entity
$
Each field contains only one piece of data
$
Each field must have a distinct data type


Tables are the physical representation of entities. If logical data design is done
correctly, entities identified in the logical design stage should map directly to

tables within a relational database. Good logical design is extremely important
for good database design.
Tables can store a wide variety of data. A table can contain a name, address,
picture, voiceprint, movie, Microsoft Word document, and so on. Because of
this flexibility, a database can be used not only to store simple text data, but
also to store the knowledge base of a business, no matter what form that
knowledge takes.
"
The data in a table is stored in rows, or records. Each record must be unique.
Records are manipulated by using the American National Standards Institute
(ANSI) standard relational database language, which is referred to as SQL.
SQL is an English-like language that abstracts the operations performed on
a database into easily readable statements, such as Insert, Update, and
Delete. Most referential databases adhere to the ANSI SQL standard,
although the version and enhancements used vary from product to product.

Tables can be linked to other tables within the same database file. This
capability allows one type of data to be joined to another type and allows data
normalization.
The data in each record is stored in columns, or fields, that are specified from
the attributes of the table’s defining entity. Each field contains one distinct item
of data, such as a customer name, and each field must have a singular data type,
such as text. This data type is defined based on the kind of data stored in the
field. The data types that are allowed for a given field depend on the data types
supported by the hosting DBMS. When defining your tables, you should choose
data types that will optimize performance, conserve disk space, and allow for
growth.
Slide Objective
To introduce the role of a
table and fields in the

physical data design.
Lead-in
Tables and fields are the
basic building blocks of
physical data design.
124 Module 6: Deriving a Physical Data Design



Common Data Types
Date and time dataDate
Fixed-length character dataString
Fixed-length binary dataBinary
Currency values with fixed scaleMoney
Integer (whole number) dataInteger
Floating point with fixed-precision data rangeFloat
Float value with double-precision data range over
regular float data type
(Double)
Float
(Long)
Integer
Integer value with double-precision data range
over regular integer data type


Every field within a database must have a data type. The data type allows you,
and the database engine itself, to verify that a value entered in a field is valid for
the information that the field represents.
Most DBMSs support two major classifications of data types:

"
System-supplied data types
Every DBMS contains its own data types. Examples of system-supplied
types are Integer, Character, and Binary. Some DBMSs contain variations of
these types as well as additional types.
"
User-defined data types
Some DBMSs allow you to define your own data types based on the system-
supplied types. For example, with SQL Server
™
you might define a State
data type based on the Character type with a length of 2. Defining this data
type would help maintain conformity across all tables that include a State
field. In every table, any field of State data type would be consistent and
identical.

The slide shows a set of common data types, each of which is a variation on a
generic character, number, or binary data type. For example, Float, Money, and
Integer all store numeric data, but they store it in different formats and can
display it in different formats. Because their data is stored in different formats,
different data types consume different amounts of storage space . For example,
the double variants of a data type can store a number that is twice as large or
store a fraction to more decimal places, but they typically use twice as much
storage space. During physical design, you need to consider the nuances of each
data type to ensure that the most efficient storage solution is obtained.
Details about data types are generally specific to the DBMS engine being used.
Refer to the DBMS documentation for specific information.
Slide Objective
To provide a generic listing
of common data types.

Lead-in
Most system-supplied data
types fall within a generic
set of types.
Module 6: Deriving a Physical Data Design 125



!
!!
!

Implementing Relationships
"
Implementing One-to-One Relationships
"
Implementing One-to-Many Relationships
"
Implementing Many-to-Many Relationships
"
Activity 6.1: Translating the Logical Data Design
In this section...
In this section...


Just as the entities and attributes identified in logical design are represented as
tables and columns in physical design, the relationships identified in logical
design also have to be represented physically.
In this section, you will learn about the relationships in a physical model and
how they are implemented in a host DBMS.

Slide Objective
To introduce the discussion
of how to implement
relationships.
Lead-in
This section takes a look at
the various relationships
that can exist between
database tables and how to
implement those
relationships.
126 Module 6: Deriving a Physical Data Design



Implementing One-to-One Relationships
"
If relationship is mandatory
$
Put both entities in a single
table
OR
$
Maintain separate tables
"
If relationship is optional
$
Use foreign keys to maintain
relationship between two
tables

Attr1
Attr2
Attr3
E1_Key (PK)
E2_Key (FK)
Enti ty1
Attr1
Attr2
Attr3
E2_Key (PK)
E1_K ey (F K)
Entity2
E1_Attr1
E1_Attr2
E1_Attr3
E1_Key ( PK)
Enti ty1
E2_Attr1
E2_Attr2
E2_Attr3
E2_Key (PK)
Entity2
+
E1_Attr1
E1_Attr2
E1_Attr3
E2_Attr1
E2_Attr2
E2_Attr3
E1_Key (PK)

E2_Key (PK)
Entity3


If the relationship specified between two entities is one-to-one, you have
several options when designing the physical model. In a one-to-one
relationship, an instance of one entity is directly related to the corresponding
instance of the other entity. If both entities are required for the relationship, the
entities and their relationship can be represented in one of two ways:
"
As one table
You can combine the two entities into one table and use the primary keys as
a composite key of the combined tables. The advantage of combining the
entities into one table is that you avoid the need to maintain separate tables,
thereby reducing overhead and providing for more efficient utilization of
storage space. The disadvantage is that if the relationship changes at some
point in the future, reversing this design decision can sometimes be costly.
"
As two tables
You can keep each entity in its own table and add the primary key of one
entity as a foreign key of the other entity. Often there is an implied parent-
child relationship between the entities. In this case, you should add the
primary key of the child entity as a foreign key in the parent entity because
the parent entity owns the child entity. This arrangement forces the database
to allow only unique entries in each key field and helps to ensure that each
instance of one entity can relate to only one instance of the other entity.

"
If the relationship between the entities is optional, meaning that the parent
entity can exist without a related instance of the child entity, then you

should create a separate table for each entity and then use foreign keys to
implement the relationship.
Slide Objective
To introduce the issues
involved in specifying one-
to-one relationships in the
physical design.
Lead-in
One-to-one relationships
can be mandatory or
optional.
Module 6: Deriving a Physical Data Design 127



Implementing One-To-Many Relationships
Attr1
Attr2
Attr3
E2_Key (PK)
E1_Key (FK)
Entity2
Attr1
Attr2
Attr3
E1_Key (PK)
Entity1
"
Use foreign keys to identify relationship between entities
"

Enforce relationship with foreign key constraints
"
Use unique primary key to differentiate instances of
child entity
"
Use same foreign key to allow multiple instances of child
entity


The physical design of a one-to-many relationship is really an extension of that
of a one-to-one relationship. It requires the use of foreign keys in the child
entity. This foreign key determines the existence of the relationship. Enforcing
the relationship usually involves making sure that the foreign key is a valid
parent entity.
A one-to-many relationship is used frequently in data design because it tends to
work well under most circumstances.
Slide Objective
To introduce the issues
involved in specifying one-
to-many relationships in the
physical design.
Lead-in
Implementing a one-to-
many relationship is much
like implementing a one-to-
one relationship.