Chapter ­6: Foundations of Business Intelligence: Databases and Information Management 227

Here are some questions to think about: How did cutting-edge data analy-
sis technology improve decision making by Envision’s drivers in races? How can
Envision maintain its advantages from data analysis in the future?

6-1 Define a database and explain how a relational

database organizes data.
A computer system organizes data in a hierarchy that starts with bits and bytes and
then progresses to fields, records, files, and databases. A bit (or binary digit) repre-
sents the smallest unit of data that a computer can handle: a value of 0 or 1. A group
of bits, called a byte, represents a single character, which can be a letter, a number,
or another symbol. A grouping of characters into a word, a group of words (such as
person’s name), or a complete number (such as a person’s age) is called a field. A group
of related fields comprises a record; a group of records of the same type is called a file.
A group of related files makes up a database.
Examine Figure 6.1, which illustrates the data hierarchy used to create a student
database. Individual bits form the base of the hierarchy and are grouped together to
form a byte. A grouping of bytes forms a field, in this case a field that identifies a spe-
cific course. A group of related fields, here a specific student’s ID, course, date, and
grade fields, creates a record. A grouping of similar student records creates a student
course file. The student course file is then grouped with files on students’ personal
histories and financial backgrounds to create a student database. Databases are at
the heart of all information systems because they keep track of the people, places, and
things that a business must deal with on a continuing, often instant basis.

Student Database Figure 6.1

The Data Hierarchy
A computer system
COURSE FINANCIAL organizes data in a
Database File File hierarchy that starts with
the bit, which represents
either a 0 or a 1. Bits can
PERSONAL be grouped to form a byte
File to represent one character,
number, or symbol. Bytes
can be grouped to form
COURSE
a field, and related fields
can be grouped to form a
File Student_ID Course Date Grade record. Related records can
39044 IS 101 F22 B+
be collected to form a file,
and related files can be
59432 IS 101 F22 A organized into a database.
64029 IS 101 F22 C

Student_ID Course Date Grade

Record
39044 IS 101 F22 B+

Field IS 101 (Course field)

Byte 0100 1001 (Letter I in ASCII)

Bit 0

M01_LAUD0360_15_GE_C06_finalppv3.indd 227 4/11/2023 12:15:29 PM

 228 Part II: Information Technology Infrastructure

ENTITIES AND ATTRIBUTES

To run a business, you most likely will be using data about categories of informa-
tion such as customers, suppliers, employees, orders, products, shippers, and perhaps
parts. Each of these generalized categories representing a person, a place, or a thing
about which we store information is called an entity. Each entity has specific charac-
teristics called attributes. Look again at the File section of Figure 6.1. Here, COURSE
is an entity and Student_ID, Course, Date, and Grade are its attributes.
If you were a business keeping track of parts you used and their suppliers, the en-
tity SUPPLIER would have attributes such as the supplier’s name and address, which
would most likely include the street, city, state, and zip code. The entity PART would
typically have attributes such as part description, price of each part (unit price), and
the supplier who produced the part.

ORGANIZING DATA IN A RELATIONAL DATABASE

If you stored this information in paper files, you would probably have a file on
each entity and its attributes. In an information system, a database organizes the
data much the same way, grouping related pieces of data. The relational database is
the most common type of database today. Relational databases organize data into
­two-dimensional tables (called relations) with columns and rows. Each table contains
data about an entity and its attributes. For the most part, there is one table for each
business entity, so, at the most basic level, you will have one table for customers and a
table each for suppliers, parts in inventory, employees, and sales transactions.
Let’s look at how a relational database would organize data about suppliers and
parts. Examine Figure 6.2, which illustrates a SUPPLIER table. It consists of a grid
of columns and rows of data. Each element of data about a supplier, such as the sup-
plier name, street, city, state, and zip code, is stored as a separate field within the
SUPPLIER table. Each field represents an attribute for the entity SUPPLIER. Fields
in a relational database are also called columns.The actual information about a single
supplier that resides in a table is called a row. Rows are commonly referred to as
records.
Note that there is a field for Supplier_Number in this table. This field uniquely
identifies each record so that the record can be retrieved, updated, or sorted, and it
is called a key field. Each table in a relational database has one field designated as its
primary key. This key field is the unique identifier for all the information in any row of
the table, and this primary key cannot be duplicated.

SUPPLIER Columns (Attributes, Fields)

Supplier_Number Supplier_Name Supplier_Street Supplier_City Supplier_State Supplier_Zip

8259 CBM Inc. 74 5th Avenue Dayton OH 45220

Rows
8261 B. R. Molds 1277 Gandolly Street Cleveland OH 49345 (Records)

8263 Jackson Composites 8233 Micklin Street Lexington KY 56723

8444 Bryant Corporation 4315 Mill Drive Rochester NY 11344

Key Field
(Primary Key)

Figure 6.2
A Relational Database Table
A relational database organizes data in the form of two-dimensional tables. Illustrated here is a table for the entity SUPPLIER, showing how it
represents the entity and its attributes. Supplier_Number is the key field.

M01_LAUD0360_15_GE_C06_finalppv3.indd 228 4/11/2023 12:15:29 PM

 Chapter ­6: Foundations of Business Intelligence: Databases and Information Management 229

We could use the supplier’s name as a key field. However, if two suppliers had the
same name (which does happen from time to time), supplier name would not uniquely
identify each, so it is necessary to assign a special identifier field for this purpose. For
example, if you had two suppliers, both named “CBM,” but one was based in Dayton
and the other in St. Louis, it would be easy to confuse them. However, if each has a
unique supplier number, such confusion is prevented.
We also see that the address information has been separated into four fields:
Supplier_Street, Supplier_City, Supplier_State, and Supplier_Zip. Data are sepa-
rated into the smallest elements that one would want to access separately to make
it easy to select only the rows in the table that match the contents of one field, such
as all the suppliers in Ohio (OH). The rows of data can also be sorted by the con-
tents of the Supplier_State field to get a list of suppliers by state regardless of their
cities.
So far, the SUPPLIER table does not have any information about the parts that a par-
ticular supplier provides for your company. PART is an entity separate from SUPPLIER,
and fields with information about parts should be stored in a separate PART table.
Why not keep information on parts in the same table as information on suppli-
ers? If we did that, each row of the table would contain the attributes of both PART
and SUPPLIER. Because one supplier could supply more than one part, the table
would need many extra rows for a single supplier to show all the parts that the sup-
plier provided. We would be maintaining a great deal of redundant data about sup-
pliers, and it would be difficult to search for the information on any individual part
because we would not know whether this part is the first or the 50th part in this
supplier’s record. Examine Figure 6.3, which illustrates a separate table, PART,
that should be created to store data about parts (in this case, part number, part
name, and unit price) and solve this problem.
The PART table would also have to contain another field, Supplier_Number, so
that you would know the supplier for each part. It would not be necessary to keep
repeating all the information about a supplier in each PART record because having a
Supplier_ Number field in the PART table allows you to look up the data in the fields
of the SUPPLIER table.
Notice that Supplier_Number appears in both the SUPPLIER and the PART ta-
bles. In the SUPPLIER table, Supplier_Number is the primary key. When the field
Supplier_Number appears in the PART table, however, it is called a foreign key and is
essentially a look-up field to find data about the supplier of a specific part. Note that
the PART table would itself have its own primary key field, Part_Number, to identify
each part uniquely. This key is not used to link PART with SUPPLIER but could be
used to link PART with a different entity.

PART Figure 6.3

The PART Table
Data for the entity PART
Part_Number Part_Name Unit_Price Supplier_Number have their own separate
137 Door latch 22.00 8259
table. Part_Number is the
primary key, and Supplier_
145 Side mirror 12.00 8444 Number is the foreign
key, enabling users to find
150 Door molding 6.00 8263
related information in the
152 Door lock 31.00 8259 SUPPLIER table about the
supplier for each part.
155 Compressor 54.00 8261

178 Door handle 10.00 8259

Primary Key Foreign Key

M01_LAUD0360_15_GE_C06_finalppv3.indd 229 4/11/2023 12:15:29 PM

 230 Part II: Information Technology Infrastructure

As we organize data into tables, it is important to make sure that all the attributes
for a particular entity apply only to that entity. If you were to keep the supplier’s ad-
dress with the PART record, that information would not really relate only to PART: It
would relate to both PART and SUPPLIER. If the supplier’s address were to change, it
would be necessary to alter the data in every PART record rather than only once, in the
SUPPLIER record.

ESTABLISHING RELATIONSHIPS
Now that we’ve broken down our data into a SUPPLIER table and a PART table,
we must make sure we understand the relationship between them. A schematic
called an entity-relationship diagram clarifies table relationships in a relational data
base. The most important piece of information that an entity-relationship dia-
gram provides is the manner in which two tables are related to each other. Tables
in a relational database may have one-to-one, one-to-many, and many-to-many
relationships.
An example of a one-to-one relationship is a human resources system that stores
confidential data about employees. The system stores data, such as the employee
name, date of birth, address, and job position, in one table and confidential data
about that employee, such as salary or pension benefits, in another table. These two
tables pertaining to a single employee would have a one-to-one relationship because
each record in the EMPLOYEE table with basic employee data has only one related
record in the table storing confidential data.
The relationship between the SUPPLIER and the PART entities in our database
is a one-to-many relationship. Each supplier can supply more than one part, but each
part has only one supplier. For every record in the SUPPLIER table, many related
records might be in the PART table.
Examine Figure 6.4, which illustrates how an entity-relationship diagram would
depict this one-to-many relationship. The boxes represent entities. The lines connect-
ing the boxes represent relationships. A line connecting two entities that ends in two
short marks designates a one-to-one relationship. A line connecting two entities that
ends with a crow’s foot symbol preceded by a short mark indicates a one-to-many rela-
tionship. The text above the line is read left to right (i.e., SUPPLIER provides PART),
while the text below the line is read right to left (i.e., PART is supplied by SUPPLIER).
Figure 6.4 shows that each part has only one supplier, but the same supplier can pro-
vide many parts.
We would also see a one-to-many relationship if we wanted to add to our database
a table about orders because one supplier services many orders. The ORDER table
would contain only the Order_Number and Order_Date fields. Examine Figure 6.5,
which illustrates a sample order report showing an order of parts from a supplier. If
you look at the report, you can see that the information on the top-right portion of
the report (the Order number and the Order date) comes from the ORDER table. The
actual line items ordered are listed in the lower portion of the report.
Because one order can be for many parts from a supplier and because a single part
can be ordered many times on different orders, this creates a many-to-many relationship
between the PART and ORDER tables. Whenever a many-to-many relationship exists

provides

SUPPLIER PART

is supplied by

Figure 6.4
A Simple Entity-Relationship Diagram
This diagram shows the relationship between the entities SUPPLIER and PART.

M01_LAUD0360_15_GE_C06_finalppv3.indd 230 4/11/2023 12:15:29 PM

 Chapter ­6: Foundations of Business Intelligence: Databases and Information Management 231

Order Number: 3502 Figure 6.5

Order Date: 1/15/2023 Sample Order Report
The shaded areas show
which data came from the
ORDER, SUPPLIER, and
Supplier Number: 8259 LINE_ITEM tables. The
Supplier Name: CBM Inc. database does not maintain
Supplier Address: 74 5th Avenue, Dayton, OH 45220 data on extended price or
order total because these
data can be derived from
Order_Number Part_Number Part_Quantity Part_Name Unit_Price Extended Price other data in the tables.
3502 137 10 Door latch 22.00 $220.00
3502 152 20 Door lock 31.00 620.00
3502 178 5 Door handle 10.00 50.00

Order Total: $890.00

between two tables, it is necessary to link these two tables in a table that joins this infor-
mation. Creating a separate table for a line item in the order would serve this purpose.
This table is often called a join table or an intersection relation. This join table contains
only three fields: Order_Number and Part_Number, which are used only to link the
ORDER and PART tables, and Part_Quantity. If you look at the bottom-left part of the
report, this is the information coming from the LINE_ITEM table.
We would thus wind up with a total of four tables in our database. Examine
Figure 6.6, which illustrates the final set of tables. Note that the ORDER table
does not contain data on extended price because that value can be calculated by

PART LINE_ITEM

Part_Number Part_Name Unit_Price Supplier_Number Order_Number Part_Number Part_Quantity

137 Door latch 22.00 8259 3502 137 10

145 Side mirror 12.00 8444 3502 152 20

150 Door molding 6.00 8263
3502 178 5
152 Door lock 31.00 8259
ORDER
155 Compressor 54.00 8261
Order_Number Order_Date
178 Door handle 10.00 8259
3502 1/15/2023

3503 1/16/2023

3504 1/17/2023
SUPPLIER

Supplier_Number Supplier_Name Supplier_Street Supplier_City Supplier_State Supplier_Zip

8259 CBM Inc. 74 5th Avenue Dayton OH 45220

8261 B. R. Molds 1277 Gandolly Street Cleveland OH 49345

8263 Jackson Components 8233 Micklin Street Lexington KY 56723

8444 Bryant Corporation 4315 Mill Drive Rochester NY 11344

Figure 6.6
The Final Database Design with Sample Records
The final design of the database for suppliers, parts, and orders has four tables. The LINE_ITEM table is a “ join table” that eliminates the
many-to-many relationship between ORDER and PART.

M01_LAUD0360_15_GE_C06_finalppv3.indd 231 4/11/2023 12:15:30 PM

 232 Part II: Information Technology Infrastructure

provides is ordered belongs to

SUPPLIER PART LINE_

ORDER
ITEM
is supplied by contains includes

Figure 6.7
Entity-Relationship Diagram for the Database with Four Tables
This diagram shows the relationships among the SUPPLIER, PART, LINE_ITEM, and ORDER entities.

multiplying Unit_Price by Part_Quantity. This data element can be derived when

needed, using information that already exists in the PART and LINE_ITEM tables.
Order_Total is another derived field, calculated by totaling the extended prices
for the items ordered. Finally, examine Figure 6.7, which shows what the entity-
relationship diagram for this set of tables would look like. This diagram illustrates
the relationships among the entities SUPPLIER, PART, LINE_ITEM, and ORDER.
Figure 6.7 shows that one ORDER can contain many LINE_ITEMs. (A PART can
be ordered many times and appear many times as a line item in a single order.) Each
PART can have only one SUPPLIER, but many PARTs can be provided by the same
SUPPLIER.
The process of streamlining complex groups of data to minimize redundant data
elements and awkward many-to-many relationships and to increase stability and flex-
ibility is called normalization. A properly designed and normalized database is easy to
maintain and minimizes duplicate data.
Relational database systems enforce referential integrity rules to ensure that rela-
tionships between coupled tables remain consistent. When one table has a foreign key
that points to another table, you may not add a record to the table with the foreign key
unless there is a corresponding record in the linked table. In the database we have just
created, the foreign key Supplier_Number links the PART table to the SUPPLIER
table. We may not add a new record to the PART table for a part with supplier num-
ber 8266 unless there is a corresponding record in the SUPPLIER table for supplier
number 8266. We must also delete the corresponding record in the PART table if we
delete the record in the SUPPLIER table for supplier number 8266. In other words, we
shouldn’t have parts from nonexistent suppliers!
The example provided here for parts, orders, and suppliers is a simple one. Even in
a small business, you will have tables for other important entities such as customers,
shippers, and employees. A large corporation typically has databases with thousands
of entities (tables) to maintain. What is important for any business, large or small, is
to have a good data model that includes all its entities and the relationships among
them, one that is organized to minimize redundancy, maximize accuracy, and make
data easily accessible for reporting and analysis.
It cannot be emphasized enough: If the business does not get its data model right,
the system will not be able to serve the business properly. The company’s systems will
not be as effective as they could be because they will have to work with data that may
be inaccurate, incomplete, or difficult to retrieve. Understanding the organization’s
data and how they should be represented in a database is a very important lesson you
can learn from this course.
For example, The Globe and Mail, Canada’s largest newspaper, was unable until
recently to execute ambitious marketing programs because it had trouble housing
and managing the data on sales prospects. Much of the required data were stored
in a mainframe system where the data were not easy to access and analyze. If users
needed any information, they had to extract the data from the mainframe and bring

M01_LAUD0360_15_GE_C06_finalppv3.indd 232 4/11/2023 12:15:30 PM

 Chapter ­6: Foundations of Business Intelligence: Databases and Information Management 233

it to one of a number of local databases�including those maintained in Microsoft

Access and Excel�for analysis. This practice created numerous pockets of data main-
tained in isolated databases for specific purposes but no central repository where
the most up-to-date data could be accessed from a single place. With data scattered
in so many different systems throughout the company, it was very difficult to cross-
reference subscribers with prospects when developing the mailing list for a marketing
campaign.

6-2 Describe the principles of a database

management system.
Now that you have started creating the files and identifying the data your business re-
quires, you will need a database management system to help you manage and use the
data. A database management system (DBMS) is a specific type of software for cre-
ating, storing, organizing, and accessing data from a database. Microsoft Access is a
DBMS for desktop systems, whereas IBM Db2, Oracle Database, and Microsoft SQL
Server are DBMS for large mainframes and midrange computers. MySQL is a popular
open-source DBMS. All these products are relational DBMS that support a relational
database.
By separating the logical view and the physical view of the data, the DBMS
relieves the end user or programmer of the task of understanding where and how
the data are actually stored. The logical view presents data as end users or busi-
ness specialists would perceive them, whereas the physical view shows how data
are actually organized and structured on physical storage media, such as a hard
disk.
A DBMS makes the physical database available for different logical views required
by users. Examine Figure 6.8, which illustrates a DBMS that enables different views
of the data contained within a human resources database. Different members of the
human resources team need access to different types of data. For instance, a benefits
specialist typically will require a view consisting of an employee’s name, social secu-
rity number, and health insurance coverage. A payroll department member will need
data such as an employee’s name, social security number, gross pay, and net pay. The
data for all of these views are stored in a single database, where the organization can
manage it more easily.

Figure 6.8
Name Human Resources
SSN Benefits
Health_Care View Database with Multiple
Views
A single human resources
database provides many
Employee_ID
views of data, depending
Name
SSN on the information
Database
Position requirements of the user.
Management
Date_Hired System Illustrated here are two
Gross_Pay possible views, one of
Net_Pay interest to a benefits
Life_Insurance specialist and one of
Pension_Benefit
Health_Care
interest to a member of
Name
the company’s payroll
SSN Payroll
Gross_Pay department.
View
Human Resources Net_Pay
Database

M01_LAUD0360_15_GE_C06_finalppv3.indd 233 4/11/2023 12:15:30 PM