+ All Categories
Home > Documents > Chapt 1 Database Models

Chapt 1 Database Models

Date post: 18-Jul-2016
Category:
Upload: ryanbalkaran
View: 234 times
Download: 2 times
Share this document with a friend
Description:
models of databases
27
Lecture Notes On Database Chapter One DATABASE MODELS Overview 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). Terrence Brunton 1 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 –
Transcript
Page 1: Chapt 1 Database Models

Lecture Notes On Database Chapter One

DATABASE MODELS

Overview

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 1

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 – Codd’s Rules

Page 2: Chapt 1 Database Models

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 customer’s 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 2

Page 3: Chapt 1 Database Models

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 IBM’s Information Management System (IMS) and Btrieve.

Terrence Brunton 3

Page 4: Chapt 1 Database Models

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 4

Page 5: Chapt 1 Database Models

Lecture Notes On Database Chapter One

The most significant limitation of the relational model is it’s 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 5

Page 6: Chapt 1 Database Models

Lecture Notes On Database Chapter One

Overview

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

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 6

Basic Terms and Definitions Popular Relational Database Products Codd’s Rules and Relational Database

Theory

Page 7: Chapt 1 Database Models

Lecture Notes On Database Chapter One

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

Codd’s 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 (Codd’s 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. Codd’s 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 7

Microsoft’s SQL Server 7.0Oracle’s Oracle 8Sybase SQL ServerIBM’s DB2Informix Software’s Informix–SQLComputer Associates’ (formerly ASK Group) IngresCentura Software’s (formerly Gupta) SQLBaseBorland’s Database EngineInterbase’s (formerly Borland) InterbaseT.c.X’s mySQL

Page 8: Chapt 1 Database Models

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 employee’s last name is a column. The name ‘Doe’ is a data value. John Doe’s 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 8

Page 9: Chapt 1 Database Models

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 user’s 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. A database that supports only row-at-a-time (navigational) operations does not

meet this requirement and is not considered 'relational'.

Terrence Brunton 9

Page 10: Chapt 1 Database Models

Lecture Notes On Database Chapter One

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 application’s 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. 

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).

Terrence Brunton 10

Page 11: Chapt 1 Database Models

Lecture Notes On Database Chapter One

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.

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.

Terrence Brunton 11

Page 12: Chapt 1 Database Models

Lecture Notes On Database Chapter One

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 firm’s 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 firm’s customer base.

Periodic shipments and the efficient management of back order, by producing copies of DVDs, are critical to Movie World’s 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. All inventory and transaction information are documented in different log books.

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.

2. Rentals and other transactions are recorded manually in different Log books.Solution: The data will keep track of and calculate each Member’s rentals, their fines due, amount paid, balance due, etc.

Terrence Brunton 12

Page 13: Chapt 1 Database Models

Lecture Notes On Database Chapter One

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.

Business Rules

Terrence Brunton 13

Page 14: Chapt 1 Database Models

Lecture Notes On Database Chapter One

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.

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.

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.

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

Terrence Brunton 14

)) DFDs)

This is more appropriate for Physical DFD with specification of output

Page 15: Chapt 1 Database Models

Lecture Notes On Database Chapter One

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, 2-Romance, 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 World’s market research to acquire information on hot sellers, period of member rentals, frequency of members rentals, favorite actors, member requests, etc.

Terrence Brunton 15

Page 16: Chapt 1 Database Models

Lecture Notes On Database Chapter One

ENTITY RELATIONSHIP DIAGRAM

ENTITY RELATIONSHIP DIAGRAM

Terrence Brunton 16

generates

provides

browses

selects

ships

MEMBER

SUPPLIER

RENTAL

INVENTORY

GENRE

DVD COPY INVENTORY

ORDER

DVD

DAMAGE FINE INVOICE LINE

RENTAL INVOICE

MEMBER

Page 17: Chapt 1 Database Models

Lecture Notes On Database Chapter One

Relational Schema

Terrence Brunton 17

ships

RENTAL

Rental IDMember IDDVD IDDate OutDate InAmount DueCondition upon returnDamage FinesAmount PaidBalance Due

MEMBER

Member-IDUWI IDFirst NameLast NameAddressPhoneStatus

INVENTORY

DVD_IDDVD_TitleCategoryMain ActorQuantity in stockQuantity on orderOrder ID

SUPPLIER

Order IDDVD TitleOrder QuantityCompany NameContactAddressEmailPhone FaxDelivery MethodOrder CostOrder DateExpected Delivery DateDelivery Status

Page 18: Chapt 1 Database Models

Lecture Notes On Database Chapter One

Relational Schema

Terrence Brunton 18

RENTAL INVOICE

Invoice IDMember IDInvoice Line IDAmount DueCondition upon returnDamage FinesAmount PaidBalance DueInvoice Total

MEMBER

Member-IDUWI IDFirst NameLast NameAddressPhoneStatus INVOICE LINE

Invoice Line IDDVD IDPriceDate Out

DAMAGE/FINE

Dam./Fine IDFie AmountAmountPaidBalance

Page 19: Chapt 1 Database Models

Lecture Notes On Database Chapter One

Terrence Brunton 19

ORDER

Order IDDVD TitleDVD IDOrder QuantityCompany NameContactAddressEmailPhone FaxDelivery MethodOrder CostOrder DateExpected Delivery DateDelivery Status

ORDER LINE

Order Line IDDVD IDPrice

INVENTORY OF DVDs

DVD_IDDVD_TitleCategory (Genre)Main ActorQuantity in stockQuantity on orderOrder ID


Recommended