Lecture Notes On Database

Chapter One

DATABASE MODELS

Overview
Flat Files
Hierarchical Database Model
Network Database Models
ISAM
Relational Database Model
Object-Oriented Database Model
Characteristics of a Relational Database Basic Concepts
Characteristics of a Relational Database Commercial Products
Characteristics of a Relational Database Codds Rules

Flat File Database

In it's most simple form, a flat-file database is nothing more than a single, large
table (e.g., a spreadsheet).
A flat file contains only one record structure; there are no links between separate
records.
Access to data is done in a sequential manner; random access is not supported.
Access times are slow because the entire file must be scanned to locate the desired
data.

Terrence Brunton

Lecture Notes On Database

Chapter One

Access times can be improved if the data is sorted but this introduces the potential
for error (e.g., one or more records may be misfiled).
Other problems with a flat-file database include 1) data redundancy; 2) data
maintenance, and 3) data integrity.
EXAMPLE. An orders file might require fields for the order number, date,
customer name, customer address, quantity, part description, price, etc. In this
example, each record must repeat the name and address of the customer (data
redundancy). If the customers address changed, it would have to be changed in
multiple locations (data maintenance). If the customer name were spelled differently
in different orders (e.g., Acme, Acme Inc, Acme Co.) then the data would be
inconsistent (data integrity). (See the Normalization Exercise for a practical example
of these deficiencies.
Flat file data structures are only viable for small data processing requirements

Hierarchical Database Model

The hierarchical and network database models preceded the relational model;
today very few commercial databases use either of these models.
A hierarchical database is a series of flat-files linked in structured 'tree'
relationships
IBM's IMS (Information Management System) database, often referred to by the
name of its proprietary language, DL/I (Data Language I), is the only viable
commercial hierarchical database still in use today, primarily on older mainframe
computers.
The concept for the hierarchical database model was originally based on a bill of
materials (BOM).
Data is represented as a series of parent/child relationships.
This concept is fundamentally different from that used in relational model where
data resides in a collection of tables without any hierarchy and that are physically
independent of each other.
In the hierarchical model, a database 'record' is a tree that consists of one or more
groupings of fields called 'segments'.
Segments make up the individual 'nodes' of the tree (e.g., the 'customers' record
may consist of 'customer' and 'order' segments.)
The model requires that each child segment can be linked to only one parent and
a child can only be reached through its parent.
The requirement for a one-to-many relationship between parent and child can
result in redundant data (e.g., 'orders' might be a child of 'customers' as well as a child
of 'parts').
To get around the data redundancy problem, data is stored in one place and
referenced by links or physical pointers in other places (e.g., the 'customers' record
contains actual data in the 'orders' segment while the 'parts' record contains a pointer
to the 'orders' data in 'customers').

Terrence Brunton

Lecture Notes On Database

Chapter One

EXAMPLE: To create a sales report, you have to access customers to get to

orders.
This is fundamentally different from the way a relational database operates; in
a relational database there is no hierarchy among tables and any table can be
accessed directly or potentially linked with any other table; THERE ARE NO
HARD-CODED, PREDEFINED PATHS AMONG THE DATA (Note that while a
primary key-foreign key combination in a relational database represents a logical
relationship among data, it does not necessarily limit the possible physical access
paths through the data.)
In the hierarchical model, the link established by the pointers is permanent and
cannot be modified; IOW the links are hard-coded into the data structure.
The hard-coding makes the hierarchical model very inflexible; a design originally
optimized to work with the data in one way may be totally inefficient in working with
the data in other ways.
In addition, the physical links make it very difficult to expand or modify the
database; changes typically require substantial rewriting efforts.

Network Database Model

The network database model expands on the hierarchical model by providing

multiple paths among segments (i.e., more than one parent/child relationship).
The network model was standardized as the CODASYL DBTG (Conference on
Data System Languages, Data Base Task Group) model.
Although supporting multiple paths in the data structure eliminates some of the
inflexibility of the hierarchical model, the network model is not very practical.
The network model only supports simple network relationships that are
implemented as 'chains' connecting individual records.
With no restrictions on the number of relations, the database design can become
overwhelmingly complex.
The relational model provides the same flexibility offered by the network model
but is much easier to work with.
The network model is for all practical purposes obsolete.

Indexed Sequential Access Method (ISAM)

The Indexed Sequential Access Method (ISAM), is a disk storage and access
method, not a database model.
There is much confusion surrounding the term ISAM and in practice it is used to
refer to desktop and/or file-based databases like Microsoft's FoxPro and Jet-based
Access, Clipper, dBase, Paradox, and Btrieve.
It also is used to refer to navigational database applications that rely on a
procedural approach to data access and retrieval.
Possibly the only 'true' ISAM-based products are IBMs Information Management
System (IMS) and Btrieve.

Terrence Brunton

Lecture Notes On Database

Chapter One

Under ISAM, records are located using a key value. A smaller index file stores the
keys along with pointers to the records in the larger data file. The index file is first
searched for the key and then the associated pointer is used to locate the desired
record.
ISAM is more concerned with the access and storage of data; it does not represent
a full database management system (DBMS).
Data access and storage methods are discussed below.

Relational Database Model

The theory behind the relational database model is discussed the section entitled
Characteristics of a Relational Database; this section focuses on the distinctions
between the relational model and other database models.
In a relational database, the logical design is independent of the physical design.
Queries against a relational database management system (RDBMS) are based
on logical relationships and processing those queries does not require pre-defined
access paths among the data (i.e., pointers).
The relational database provides flexibility that allows changes to the database
structure to be easily accommodated.
Because the data reside in tables, the structure of the database can be changed
without having to change any applications that were based on that structure.
EXAMPLE: You add a new field for e-mail address in the customers table. If you
are using a non-relational database, you probably have to modify the application that
will access this information by including 'pointers' to the new data. With a relational
database, the information is immediately accessible because it is automatically related
to the other data by virtue of its position in the table. All that is required to access the
new e-mail field is to add it to a SELECT list.
The structural flexibility of a relational database allows combinations of data to be
retrieved that were never anticipated at the time the database was initially designed
In contrast, the database structure in older database models is "hard-coded" into
the application; if you add new fields to a non-relational database, any application
that access the database will have to be updated.
In practice, there is significant confusion as to what constitutes a relational
database management system (RDBMS).
Dr. E.F. Codd provided 12 rules that define the basic characteristics of a relational
database but implementation of these rules varies from vendor to vendo.
No RDBMS product is fully compliant with all 12 rules but some are more so
than others,
When distinguishing DBMS products, there are typically three key area on which
to focus: 1) query formulation and data storage/access; 2) application integration; and
3) processing architecture.

Object-Oriented Database

The object-oriented database, also referred to as the post-relational database

model, addresses some of the limitations of the relational model.

Terrence Brunton

Lecture Notes On Database

Chapter One

The most significant limitation of the relational model is its limited ability to
deal with BLOBs.
Binary Large OBjects or BLOBs are complex data types such as images,
spreadsheets, documents, CAD, e-mail messages, and directory structures.
At its most basic level, 'data' is a sequence of bits ('1s' and '0s') residing in some
sort of storage structure.
'Traditional' databases are designed to support small bit streams representing
values expressed as numeric or small character strings.
Bit stream data is atomic; it cannot be broken down into small pieces.
BLOBs are large and non-atomic data; they have parts and subparts and are not
easily represented in a relational database.
There is no specific mechanism in the relational model to allow for the retrieval of
parts of a BLOB.
A relational database can store BLOBs but they are stored outside the database
and referenced by pointers.
The pointers allow the relational database to be searched for BLOBs, but the
BLOB itself must be manipulated by conventional file I/O methods.
Object-orient databases provide native support BLOBs.
Unfortunately, there is no clear model or framework for the object-oriented
database like the one Codd provided for the relational database.
Under the general concept of an object-oriented database, everything is treated as
an object that can be manipulated.
Objects inherit characteristics of their class and have a set of behaviors (methods)
and properties that can be manipulated.
The hierarchical notion of classes and subclasses in the object-oriented
database model replaces the relational concept of atomic data types.
The object-oriented approach provides a natural way to represent the hierarchies
that occur in complex data.
EXAMPLE, a Word document object consists of paragraph objects and has
method to draw' itself.
There are a limited number of commercial object-oriented database systems
available; mostly for engineering or CAD applications.
In a way, object-oriented concept represents a Back to the Future approach in
that it is very similar to the old hierarchical database design.
Relational databases are not obsolete and may simply evolve by adding additional
support for BLOBs.

Characteristics of a Relational Database

Terrence Brunton

Lecture Notes On Database

Chapter One

Overview
This section discusses the following topics with respect to a relational database:

Basic Terms and Definitions

Popular Relational Database Products
Codds Rules and Relational Database
Theory

Basic Terms and Definitions

The term 'database' has many interpretations; one definition is a 'collection of

persistent data'.
A relational database is one in which the data consists of a 'collection of tables
related to each other through common values'.
The two most prominent characteristics of a relational database are 1) data stored
in tables and 2) relationships between tables.
A table (a.k.a. an entity or relation) is a collection of rows and columns.
A row (a.k.a. a record or tuple) represents a collection of information about a
separate item (e.g., a customer).
A column (a.k.a. a field or attribute) represents the characteristics of an item (e.g.,
the customer's name or phone number).
A relationship is a logical link between two tables.
A relational database management system (RDBMS) uses matching values in
multiple tables to relate the information in one table with the information in the other
table.
The presentation of data as tables is a logical construct; it is independent of the
way the data is physically stored on disk.

Popular Relational Database Products

Although IBM did most of the research, Oracle delivered the first commercial
relational database in 1979.
IBM delivered their first product,' SQL/Data System,' in 1982.
Microsoft originally worked in partnership with Sybase to deliver SQL Server 4.2
in 1992.
In 1993 the partnership broke up with Sybase going after the Unix market and
Microsoft pursuing the Windows NT market.
Microsoft SQL Server 6.0 was released in 1995; version 6.5 shipped in 1996.
Microsoft SQL Server 7.0 shipped in November of 1998.

Terrence Brunton

Lecture Notes On Database

Chapter One

The following is a list of vendors and their relational database products:

Microsofts SQL Server 7.0
Oracles Oracle 8
Sybase SQL Server
IBMs DB2
Informix Softwares InformixSQL
Computer Associates (formerly ASK Group) Ingres
Centura Softwares (formerly Gupta) SQLBase
Borlands Database Engine
Interbases (formerly Borland) Interbase
T.c.Xs mySQL

Codds Rules and Relational Database Theory

A relational database is more than just data organized into related tables.
The relational database model is based firmly in the mathematical theory of
relational algebra and calculus.
The original concept for the model was proposed by Dr. E.F. Codd in a 1970
paper entitled A Relational Model of Data for Large Shared Data Banks.
Later Dr. Codd clarified his model by defining twelve rules (Codds Rules) that a
database management system (DBMS) must meet inn order to be considered a
relational database.
In practice, many database products are considered 'relational' even if they do not
strictly adhere to all 12 rules.
A summary of Dr. Codds 12 rules is presented below:

Codd's Rule #1. Data is Presented in Tables

A set of related tables forms a database and all data is represented as tables; the
data can be viewed in no other way.
A table (a.k.a. relation or entity) is a logical grouping of related data in tabular
form (rows and columns).
Each row (a.k.a. record or tuple) describes an item (person, place or thing) and
each row contains information about a single item in the table.
Each column (a.k.a. field or attribute) describes a single characteristic about an
item.
Each value (datum) is defined by the intersection of a row and column.
Data is atomic; there is no more than one value associated with the intersection of
a row and column.
There is no hierarchical ranking of tables.

Terrence Brunton

Lecture Notes On Database

Chapter One

The relationships among tables are logical; there are no physical relationships
among tables.

Codd's Rule #2. Data is Logically Accessible

A relational database does not reference data by physical location; there is no

such thing as the fifth row in the customers table'.
Each piece of data must be logically accessible by referencing 1) a table; 2) a
primary or unique key value; and 3) a column.
EXAMPLE. A specific employee in the' Employee' table (e.g., John Doe) and
related information (last name, first name, ID, phone number, salary, etc) constitute a
row. An employees last name is a column. The name Doe is a data value. John
Does last name can be precisely located by referencing the employee table, the
appropriate column (last_name) and a unique key value (employee_id).

Codd's Rule #3. Nulls are Treated Uniformly As Unknown

Null must always be interpreted as an unknown value.

Null means no value has been entered; the value is not known.
'Unknown' is not the same thing as an empty string ("") or zero.
EXAMPLE. If you pick up an item in a store and the price is not marked, the
price is unknown (NULL); it is not free.
If not handled properly, nulls can cause confusion in your database.
EXAMPLE. If you search for all of the authors whose home state is not
California, the results will not include any authors with NULL in the 'state' column.
SQL is very literal. You asked for authors where the state was NOT California and
NULL means 'unknown.' A NULL value for 'state' may mean that the state is
California and it may mean that it is not California; you just don't know. Because the
database engine can't tell for sure whether the state is not California, a record with
NULL will not be returned.
Nulls propagate through arithmetic expressions (e.g., 2 + NULL = NULL).
Comparing a null to any value, including itself, returns NULL.

Codd's Rule #4. Database is Self-Describing

In addition to user data, a relational database contains data about itself.

There are two types of tables in a RDBMS: user tables that contain the 'working'
data and system tables contain data about the database structure.
Metadata is data that describes the structure of the database itself and includes
object definitions (tables, indexes, stored procedures, etc.) and how they relate to each
other
The collection of system tables is also referred to as the system catalog or data
dictionary.

Terrence Brunton

Lecture Notes On Database

Chapter One

System tables can be accessed in the same manner as user tables.

Codd's Rule #5. A Single Language is Used to Communicate with the

Database Management System

There must be a single language that handles all communication with the database
management system.
The language must support relational operations with respect to: data
modification (i.e., SELECT, INSERT, UPDATE, DELETE), data definition (i.e.,
CREATE, ALTER, DROP) and administration (i.e., GRANT, REVOKE, DENY,
BACKUP, RESTORE).
Structured Query Language (SQL) is the de facto standard for a relational
database language.
SQL is a nonprocedural or declarative language; it allows users to express
what they want from the RDBMS without specifying the details about where it's
located or how to get it.
The SQL language is discussed in more detail here.

Codd's Rule #6. Provides Alternatives for Viewing Data

A relational database must not be limited to source tables when presenting data to
the user.
Views are virtual tables or abstractions of the source tables.
A view is an alternative way of looking at data from one or more tables.
A view definition does not duplicate data; a view is not a copy of the data in the
source tables.
Once created, a view can be manipulated in the same way as a source table.
If you change data in a view, you are changing the underlying data in the source
table (although there are limits on how data can be modified from a view).
Views allow the creation of custom tables that are tailored to special needs.
EXAMPLE: By not including the columns with sensitive information in a view
definition, a view can be used to restrict a users access to the data.
Views can be used to simplify data access by predefining complex joins; the
concept is similar to that of a 'saved query'.

Codd's Rule #7. Supports Set-Based or Relational Operations

Rows are treated as sets for data manipulation operations (SELECT, INSERT,
UPDATE, DELETE).
A relational database must support basic relational algebra operations (selection,
projection; & join) and set operations (union, intersection, division, and difference).
Set operations and relational algebra are used to operate on 'relations' (tables) to
produce other relations.

Terrence Brunton

Lecture Notes On Database

Chapter One

A database that supports only row-at-a-time (navigational) operations does not

meet this requirement and is not considered 'relational'.
The set-based nature of SQL is discussed in more detail here.

Codd's Rule #8. Physical Data Independence

Applications that access data in a relational database must be unaffected by

changes in the way the data is physically stored (i.e., the physical structure).
EXAMPLE: The code in an application that accesses data in a file-based
database typically depends on the file format (e.g., the code references a 'phone
number' field that is 10 characters wide, is preceded by the 'zip code' field, followed
by the 'fax number' field...). If the layout of the data in the file is changed, the
application must also be changed. In contrast, the storage and access methods
(physical) used in a relational database can change without affecting the user or
applications ability to work with the data. The user still only sees tables (logical
structure).
An application that accesses data in a relational database contains only a basic
definition of the data (data type and length); it does not need to know how the data is
physically stored or accessed.

Codd's Rule #9. Logical Data Independence

Logical independence means the relationships among tables can change without
impairing the function of applications and ad hoc queries.
The database schema or structure of tables and relationships (logical) can change
without having to re-create the database or the applications that use it.

Codd's Rule #10. Data Integrity Is a Function of the DBMS

In order to be considered relational, data integrity must be an internal function of

the DBMS; not the application program.
Data integrity means the consistency and accuracy of the data in the database
(i.e., keeping the garbage out of the database).
There are three types of data integrity: entity, domain, and referential.
Within the database, data integrity can be enforced procedurally or declaratively.
Declarative data integrity involves placing or declaring constraints on columns.
Procedural data integrity is maintained through code (i.e., through stored
procedures or triggers).
Data integrity is discussed in more detail here.

Terrence Brunton

10

Lecture Notes On Database

Chapter One

Codd's Rule #11. Supports Distributed Operations

Data in a relational database can be stored centrally or distributed.

Users can join data from tables on different servers (distributed queries) and from
other relational databases (heterogeneous queries).
Data integrity must be maintained regardless of the number of copies of data and
where it resides.

Codd's Rule #12. Data Integrity Cannot be Subverted

There cannot be other paths into the database that subvert data integrity; in other
words, you can't get in the 'back door' and change the data in such a manner as data
integrity is violated.
The DBMS must prevent data from being modified by machine language
intervention.

EXAMPLE ONE
MOVIE WORLD DVD CLUB
This first example is particularly useful for helping students to identify entities, attributes
and relationships. The importance of naming will also be highlighted particularly in the
context of the business rules.
Identification and naming of entities and attributes is a crucial challenge to the system
analysts since it establishes the structure of the database.
Entity Relationship Diagramming in particular is helpful in the formation of data base
structure. The key device used to draw out the entities and attributes is a type of
narrative that we call the business rules.

BACKGROUND
Movie World DVD Club is a small business establishment that is engaged in the rental of
DVDs. This enterprise is located on the UWI St. Augustine Campus, upstairs the Student
Activity Centre. Though the firm mainly handles the rental of DVDs they also sell DVDs
and movie posters.

Terrence Brunton

11

Lecture Notes On Database

Chapter One

They have a wide range of DVDs available to their customers. There is a broad selection
of movies (over 2,000), copies of which are readily available. Some of the different
genres of movies are science-fiction, comedy, drama, indian, action, horror/thriller, etc.
DVD rentals are characterized by high volume, low-cost transactions. Because each
rental transaction affects inventory, inventory updates need to be frequent. Inventory
management is an integral part of the firms operations. At all times it is important to
know which movies are available, need to be ordered, or are out on loan. In this
particular business, inventory management also involves managing loans of the movies
amongst the firms customer base.
Periodic shipments and the efficient management of back order, by producing copies of
DVDs, are critical to Movie Worlds business operations. Movie World requires detailed
reporting capability in order to achieve this and to manage their inventory effectively.
Presently, the operations at Movie World are performed manually, there has been no
computerization of their registration, borrowing or returning processes and they do not
have a database for their business/operations. Records are kept via manual bookkeeping.
Hence, to initiate the process of building a database at Movie World the records of both
members and all the different movies they have in stock for rental would have to be
entered into MS Access to start the database building process.
New movies are sourced periodically and are stored in an updated DVD list.
inventory and transaction information are documented in different log books.

All

The customers consist entirely of students and staff of the UWI. The customer base now
stands at just over 600 and is relatively stable. The owner sees the need to increase this
customer base. Problems with some customers, such as bad attitudes and dishonesty,
make business harder from time to time. The club has grown substantially since
inception, which is evident by its present customer base and product mix, which they try
to increase frequently. The owner anticipates a further 33% growth in the coming year.

Current Problems and Possible Solutions

1. The organization is a small firm, thus there are heavy demands on the Manager and
front desk employee to run the DVD club successfully. In particular, the front desk
employee has to manually update the Listing when new DVDs are acquired by the
firm. This is time-consuming as it must be done frequently thus is costly in terms of
loss of time.
Solution: The database will contain a table called INVENTORY which will list all
the originals and DVD copies that Movie World has in stock. New DVDs will be
entered into the INVENTORY table as they become available. This table will be able
to be sorted in ascending or descending order (if required) by the program MS
Access.

Terrence Brunton

12

Lecture Notes On Database

Chapter One

2. Rentals and other transactions are recorded manually in different Log books.
Solution: The data will keep track of and calculate each Members rentals, their fines
due, amount paid, balance due, etc.
3. All members of the Movie Club are manually recorded in a Member Log book.
Solution: The database will contain a MEMBER table that will contain all the
members of the DVD Club with their respective MEMBER IDs.
4. Movie World faces a major growth problem that is evident by their relatively stagnant
customer base. The owner cited the need for more members. More members would
mean more revenue pouring into the firm, which could fuel further development.
Solution: The database marketing system can help the organization to achieve this
growth. It will allow the firm to precisely analyze rental trends. With this database,
marketers will be able to project rentals based on rental trends and repeat rentals by
customers (Aaker; Kumar & Day, 2001).
5. So much effort is put into performing day-to-day activities that the owner finds it
difficult to formulate and execute strategic plans for development, while continuing to
run the business single-handedly.
Solution: Divestiture and delegation of responsibility may assist in this instance. The
owner and manager could lessen the amount of control they exercise in day-to-day
tasks that they may be involved in at present. Instead, once they have sufficient trust
in the front-desk employee, they can leave the more routine duties to this worker and
thus be able to focus their attention and energies on more strategic areas of
management, e.g. properly utilizing and operationalising the marketing function of
the databse we are proposing, so that the business can experience the growth it desires
and needs.
6. Resources, in terms of computer hardware and software, finances for training in
database maintenance, etc. are not available at present at Movie World.
Solution: In order to put this database model into effect, Movie World needs to
acquire the necessary computer hardware, software, peripherals and network(s). They
already have sufficient physical space for the installation of this computer equipment,
with some minor structural adjustments and renovations. However, in addition to the
acquisition of this equipment, staff needs to be trained and certified in Microsoft
applications, in particular MS Access. This is necessary for them to be able to
properly manage the database system in terms of basic operation, database backups,
access management and security.
7. The fine for damages and lost DVDs is somewhat high.
Solution: Movie World should consider lowering these prices, especially if the DVD
is not an original. Thus, fines for damaged/lost original should be higher than for the
copies.

Terrence Brunton

13

Lecture Notes On Database

Chapter One

Business Rules
1. When a new member joins the Movie World DVD Club, personal data is entered in
the Members Table.
This prompts the naming of an entity MEMBER.
2. Each member is issued a membership ID card bearing the Member ID
number. This establishes the entity MEMBER. MEMBER ID is
the Primary Key (PK) for the Member Registration.
Note: The hardcopy of the Member ID is a printed form from
the database. A hardcopy of a Members Contract will also be
printed from a form in the database.

This is more
appropriate for
Physical DFD
with
specification of
output

A primary key Member ID has been established.

3. In order to borrow, members may peruse manually or the front desk
employee will access the inventory listing. However, a member cannot
borrow until he pays off any outstanding fines that he/she may have at
Movie World. N.B. Late fees will be $5.00 per day or part therefore.

)
) DFDs
)

This rule establishes the entity called INVENTORY.

4. Each original DVD or copy made must be entered in the INVENTORY table. This
table will have different category numbers that each pertains to a different genre of
Movie.
Maybe these should be DVD, COPY - Entities.

5. Each DVD has a unique identification number that is mandatory.

This establishes the DVD ID NO. which is the PK Field for the entity INVENTORY
DVD.
6. Each movie that is rented is entered as a RENTAL record in the RENTAL table. The
DVD_ID_No is recorded. The date borrowed is entered in the DATE-Out field.
We have not established a RENTAL Table.
7. Only a member can rent a movie. This rule makes MEMBER mandatory to the
RENTAL table.

Terrence Brunton

14

Lecture Notes On Database

Chapter One

How about if we try Rental as a Transaction which is recorded by an Invoice.

8. Each member can rent more than one DVD movie. Each rental transaction is given a
unique RENTAL_ID number. RENTAL_ID is the PK field of the RENTAL table.
This establishes a 1:M relationship between MEMBER and RENTAL.
9. To complete the rental process, members must pay in full the respective cost of
renting the DVD, i.e.. the original rental price or copy rental price.
10. When a movie is returned, the date is entered in the Date_in field in the RENTAL
table.
11. Amount_due is calculated by finding the difference between Date_Out and Date_in.
12. The condition of the DVD is examined and the Status is indicated. If the status is
lost a fine of $175 is recorded in the Damage_Fine field. If the status is damaged a
fine of $150 is recorded in the Damage_fine field.
13. The total sum paid is recorded in the Amount_paid field.
14. The balance due is calculated by finding the sum of Amount_due plus Damage_Fine
less Amount_paid.
15. Original DVD movies are ordered from abroad and shipped to the Movie World DVD
Club in UWI-St. Augustine, Trinidad. This business rule establishes a new entity
named: SUPPLIER (1:M).
16. Upon receipt of the DVDs from the SUPPLIER the front desk employee will
scrutinize the order for damages or any other discrepancies to the DVDs.
18. A front desk employee enters the new DVD arrivals with a unique DVD_ID_NO into
the INVENTORY Table. This rule establishes the entity INVENTORY. Each DVD
will be categorized from 1 through 8 based on its genre: 1-Horror/Thriller, 2Romance, 3-Indian, 4-Comedy, 5-Drama, 6-Action, 7-SciFi, 8-Children.
19. Movie World will generate at least one copy of an original movie upon receipt of
DVDs from suppliers. Each copy will have the letters CC at the front of its ID
number.
20. If a DVD is out of stock and is in high demand, Movie World will generate copies of
the DVD in order that Movie World has a sufficient number of copies - especially for
the very popular movies.
21. Only active and inactive members who are in fair, reasonable or good standing will be
the target for Movie Worlds market research to acquire information on hot sellers,

Terrence Brunton

15

Lecture Notes On Database

Chapter One

period of member rentals, frequency of members rentals, favorite actors, member

requests, etc.

ENTITY RELATIONSHIP DIAGRAM

MEMBER

INVENTORY

browses

RENTAL
selects

MEMBER

provides

RENTAL
INVOICE

DAMAGE
FINE

ships

INVOICE LINE

SUPPLIER

GENRE

ENTITY RELATIONSHIP DIAGRAM

DVDgenerates
COPY

Terrence Brunton

DVD

INVENTORY

ORDER

16

Lecture Notes On Database

Chapter One

ships

MEMBER
Member-ID
UWI ID
First Name
Last Name
Address
Phone
Status

RENTAL
Rental ID
Member ID
DVD ID
Date Out
Date In
Amount Due
Condition upon return
Damage Fines
Amount Paid
Balance Due

Relational Schema
SUPPLIER
Order ID
DVD Title
Order Quantity
Company Name
Contact
Address
Email
Phone
Fax
Delivery Method
Order Cost
Terrence
Brunton
Order Date
Expected Delivery Date
Delivery Status

INVENTORY
DVD_ID
DVD_Title
Category
Main Actor
Quantity in stock
Quantity on order
Order ID

17

Lecture Notes On Database

Chapter One

Relational Schema

DAMAGE/FINE

MEMBER
Member-ID
UWI ID
First Name
Last Name
Address
Phone
Status

Terrence Brunton

RENTAL INVOICE
Invoice ID
Member ID
Invoice Line ID
Amount Due
Condition upon return
Damage Fines
Amount Paid
Balance Due
Invoice Total

Dam./Fine ID
Fie Amount
Amount
Paid
Balance

INVOICE LINE
Invoice Line ID
DVD ID
Price
Date Out

18

Lecture Notes On Database

Chapter One

ORDER
Order ID
DVD Title
DVD ID
Order Quantity
Company Name
Contact
Address
Email
Phone
Fax
Delivery Method
Order Cost
Order Date
Expected Delivery Date
Delivery Status

Terrence Brunton

INVENTORY OF DVDs

ORDER LINE
Order Line ID
DVD ID
Price

DVD_ID
DVD_Title
Category (Genre)
Main Actor
Quantity in stock
Quantity on order
Order ID

19