Transcript 2 Relational Database Concepts

Relational Database Concepts
Let’s start with a simple example
of a database application

Assume that you want to keep track of
your clients’ names, addresses, and
phone numbers.
Client information to store and
retrieve



Name
Address
Phone Number
A typical design and sample
table entries might be:
Name
Address
Phone
Janice Chen
236 Boylston Ave. Boston,
MA 02117
617-331-6235
Al Brown
Bradford St., Provincetown
28, MA 02960
508-478-2654
Janice Chen
36 Commonwealth Ave.,
Brookline, MA 02113
617-229-7640


But if we wanted to sort the records in
alphabetical order by name in the usual
way, there would be a problem because
the last name is buried in the Name
field.
Solution: Split the Name field into 2
atomic fields, Last Name and First
Name.



Similarly, we may want to query the
database for all clients from MA, or all
clients from Brookline, or group clients
by ZIP code for mass mailings.
To do this, we need to break the
address into several smaller atomic
fields as well.
Our table then looks as follows:
Last Name
First Name
Street
City
State
Zip
Phone
Chen
Janice
236 Boylston Ave.
Boston
MA
02117
617-331-6235
Brown
Al
28 Bradford St.
Provincetown
MA
02960
508-478-2654
Chen
Janice
36 Commonwealth
Ave.
Brookline
MA
02113
617-229-7640
Primary key


How can we identify a record in this
table uniquely? Notice that the last
name is not sufficient; nor is the
combination of last name and first
name.
Perhaps the combination of all the
name and address fields is sufficient.


A primary key in a table is a field or
combination of fields that uniquely
distinguishes any record from all other
records.
Every table in a relational database
must have a primary key.

So in this example, perhaps we could
specify the combination of all the name
and address fields as the primary key
(or perhaps the combination of the 2
name fields along with the phone
number).


A single field is generally preferable as a
primary key, so one choice we have
available for our database is to add an
additional field – Social Security
Number. These are guaranteed to
identify individuals uniquely.
An alternative is to generate our own
numbering system for clients, say C001,
C002, etc.
Now let’s consider a slightly more
involved example


Assume that you have a small company
selling books and you want to keep
track of your customers’ orders.
To keep things simple, let’s assume that
among the data we intend to keep track
of for each order is the following:
Data to store and retrieve about
customer orders







Customer Name
Customer Address
Book Title
Quantity Ordered
Date Shipped
Purchase Price
etc.

As before, we’ll probably want to break
the name and address fields down
further, but here we’ll take those details
for granted and emphasize some
additional considerations.


First, let’s imagine placing all the data in
a single table.
Since a customer can order books at
different times (or even multiple books
in a single order), we can end up with
multiple records containing the identical
name and address information for a
customer.

This one table will thus contain
redundant information, which can lead
to more date entry errors or updating
errors if some of the customer data
changes. And of course it wastes
space.



The solution is to have multiple tables.
In particular, we should have a separate
Customers table that holds only things
like the name and address of
customers.
We’ll also have an Orders table.
Foreign keys


One of the fields in the Orders table will
identify which customer the order is for.
Instead of using the entire name and
address of the customer in the Orders
table, we’ll use a simple customer id
number to identify the customer.


This customer id number will be used
as a primary key in the Customers
table, and it will also be used as a
foreign key in the Orders table, to
identify which customer placed the
order.
A foreign key is just a kind of pointer to
information in a related table.
Many-to-one relationships


Since each order is placed by exactly
one customer, but each customer may
place many orders, there is a many-toone relationship between orders and
customers.
Many-to-one relationships always
require the use of a foreign key in the
“many” table (Orders in this case).


We can expand on this example by
considering how we might keep track of
our book inventory.
In particular, let’s also have a Books
table that stores all the information
about the books we sell, including title,
author, publisher, etc.
Many-to-many relationships


One order can be for more than one
book, and any book can appear in
multiple orders.
Thus there is a many-to-many
relationship between books and orders.


The way to handle the many-to-many
relationship between books and orders
is to have an additional table besides
the Books and Orders tables.
We’ll call this table Order Details.


The Order Details table may contain
multiple entries for any particular order
and multiple entries for any particular
book.
It contains foreign keys pointing to the
Orders table and to the Books table.

Here is how the Relationships Window in
Access displays this information, by listing
the names of all the fields in all 4 tables
and showing which fields (foreign keys)
correspond to which other fields(primary
keys) in other tables. Primary keys are
indicated in bold. (ISBN number is a
standard unique identifier for books.)
Referential Integrity


The point of this example has been to
show how a useful database may
contain multiple tables.
But when there are related tables, care
must be taken to insure that the
relationships between the tables are
respected.


Consider what might happen if a
customer is deleted from the Customers
table.
If there is an entry in the Orders table
for this customer, it would now contain
a meaningless customer id.

There are 2 possible solutions to this
problem:


Do not allow a customer to be deleted from the
Customers table if there are corresponding
orders in the Orders table
When deleting an entry from the Customers
table, delete all corresponding orders for that
customer (called cascaded deletion).
Queries and Joins


Retrieving information from the database is
done using queries.
Consider a query of the form: Find the
names and addresses of all customers who
have ordered books by a particular author.

This involves:




looking in the Books table to find all books by
that author,
then looking in the Order Details table to see
which orders were for those books,
then looking in the Orders table to see which
customers placed those orders,
and finally, looking in the Customers table to get
the names and addresses of these customers.


On the other hand, if we had kept all
the information in just 1 big table, we
could have just pulled the information
out of that table.
The join of 2 or more related tables is
conceptually just the same as one large
table combining the information from
the smaller tables.



A query involving multiple tables is
sometimes said to be a query on the join of
those tables.
The actual join itself need not be
determined; it is just a conceptual entity.
Just think of the process in the way we
described it earlier: looking up information in
one table, then in another table, etc.