Вы находитесь на странице: 1из 104

Database Systems Implementation

ITIS 411
Chapter 1:
Client/Server Databases
and the Oracle 10 g
Relational Database

Text Book : Guide to Oracle 10 g


 This book focus on oracle 10g to create:
◦ database tables,
◦ retrieve database data (Query the database), and
◦ create database applications.

Guide to Oracle 10g 3


Introduction
 Oracle DB 10g provides a rich environment
that includes:
◦ Client/server DBMS
 Managing concurrent users
 Managing DB resources sharing
◦ Allowing users to develop DB applications

 In this course you will learn about these


utilities and practice using them in the lab and
assignments to build integrated databases.
(Details in next slide).

4 / 90
Textbook
 Addresses DB development activities such as:
◦ Using SQL commands to create tables and insert,
update, delete, and view data values.

 Provides an overview of PL/SQL

 Explores the Developer 10g application


development tools.
◦ How to create an integrated DB application.
◦ How to display application components in a web
browser.
 Overview of DB administration activities using
the browser-based version of Enterpriser
Manager.
5 / 90
6 / 90
Before DBs (Using File System)

 Each software application has its own data files


that were used only for that application.

 Individual data items: fields: describe


characteristics about objects (e.g students).
Fields are also called columns or attributes.
Comma separates each field.
 A record is a collection of related fields that

contain related information. Called also Row or


Tuple
 Each record appears on a separate line in the file.

7 / 90
DB History
 The first DBs were stored on large centralized
mainframe computers that users accessed from
terminals
 Examples: IMS – Information Management

system & IDS-Integrated Data Store


 As distributed computing and microcomputers


became popular during the 1980s, two new
kinds of databases emerged:
◦ personal DBs
◦ client/server DBs

8 / 90
File-based Systems
 Fields (or columns): describe characteristics
about students
◦ Students IDs, last name

 Record is a collection of related fields that


contain related information.
◦ Each student record appears on a separate line in the
file.

9 / 90
File-based Systems
 Problems
◦ With managing data stored
in data files.
◦ Proliferation of data
management programs.

◦ Examples: A student
registration system:

 The system to enable


students to enroll in courses
would have its own data file.
 The system to create class
lists would have its own file.
 The system to create student
transcripts would have its
own file. 10 / 90
File-based Systems
 Because each data file contained different data fields,
programmers had to write and maintain a separate
program to insert, update, delete, and retrieve data
that was sorted in each different data file.
 Redundant Data

Enrollment data file containing redundant data


11 / 90
File-based Systems
 Other problems
◦ Difficult to update (e.g data redundancy, incompatible
files format, isolation and separation of files for different
user)
◦ May contain inconsistent data
◦ Proliferation of data management programs. A program
for each insert, update, delete, and retrieve because
data files has different fields
◦ Redundant data

12 / 90
Databases and DBMS
 A DB stores all organizational data in central
location.

◦ To eliminate redundant data and to reduce


inconsistent data
 DBMS performs all routine data-handling
operations. The DBMS provides a central set
of common functions for managing a DB,
which include inserting, updating, retrieving,
and deleting data values.

13 / 90
DB Approach to data processing
 DBA is the person who is responsible for
installing, administering and maintaining the
DB.

14 / 90
Overview of Relational DBs
 Most modern DBs are RDBs.
 Stores data in a tabular format.

15 / 90
Overview of Relational DBs
 Entity is an object about which you want to
store data (e.g students, faculty, members,
courses, etc)
 Storing data about different entities in

different tables minimizes storing redundant


data.
 To connect information about different

entities you must create relationships, which


are links that show how different records are
related.

16 / 90
Overview of Relational DBs
 Relationships among records in different
tables are established through key fields,
values in DB tables that help to either identify
an individual row or to link data from
different tables.

17 / 90
Types of Key Fields: Primary Key
 Column in a RDB table whose value must be
unique for each row.

 Serves to identify the individual occurrence of


an entity.

 Every row must have a primary key and the


primary key cannot be NULL.
◦ Null is not equivalent to blank space or zero. It
means that the value is absent or unknown.

18 / 90
Types of Key Fields: Primary Key
 Example
◦ Student ID
◦ Address can’t be a primary key because two
students can have the same address. And the
address can change. And text is prone to errors.

 Best primary key is numbers or code.


 Numeric is faster in processing than characters.

19 / 90
Types of Key Fields: Candidate Key
 Any column that could be used as the PK.

 Should be unique for each record and does


not change
 Social security numbers are not good

candidate keys because of the identity theft

 If no alternate data available to uniquely


identify a person, create a surrogate key.

20 / 90
Types of Key Fields: Surrogate Key
 The below table lacking suitable candidate keys
 F_LAST or F-FIRST or even the combination of the two are

not suitable.
 A surrogate key is a column that you create to be the

record’s PK identifier. It has no real relationship to the row


to which it is assigned, other than to identify the row
uniquely. In Oracle 10g Sequences can be used to generate
unique values for each record. They are always numerical.
Oracle 10g can also generate numbers with specific
increment.

21 / 90
Types of Key Fields: Foreign Key
 To create relationships among records.
 One way to represent this relationship is to

combine the FACULTY and STUDENT fields


into a single table, and store the data for
each student’s faculty advisor directly in each
student row.

22 / 90
Types of Key Fields: Foreign Key
 The problem with this approach is that it stores
redundant data.

 RDBs provides a better way to create


relationships by using FKs.

 A FK is a column in a table that is a primary key


in another table.

 The FK creates a relationship between the two


tables.
23 / 90
Types of Key Fields: Foreign Key

24 / 90
Types of Key Fields: Foreign Key
 By using FKs to create relationships, you
repeat only the FK values.

 If the data values for a faculty member


change, you update the values only in the
FACULTY table.

 The PK of the FACULTY table, which is the


F_ID value, does not change, so the STUDENT
table does not need to be updated if the
faculty data changes.
25 / 90
Types of Key Fields: Foreign Key
 A FK value must exist in the table where it is
a PK.
◦ Ex: suppose you have a new record for S_ID JO100
that specifies that the student’s F_ID (advisor ID)
value is 5.
 FK values must match the value in the PK
table exactly.
 So unless the PK is being used for coding

purposes, it is best to use number values for


PKs rather than text values that are prone to
typographical, punctuation, spelling, and
case-variation errors.
26 / 90
Types of Key Fields: Composite
Key
 Sometimes DB designers have to combine
multiple columns to create a unique PK.
◦ (Fig 1.9)
 The S_ID column is not a candidate key, because
one student may enroll in many courses.
 Similarly, the COURSE_NO column is not a
candidate key, because one course may have
many students enrolled.
 The GRADE column is not a candidate key
because many students receive the same grade in
courses.

27 / 90
Types of Key Fields: Composite Key
 As an alternative to adding a surrogate column for
the PK, a combination of the current columns may
create a value that can uniquely identify each row
in the table. A composite key is a unique key that
you create by combining two or more columns.
 Ex: because each student enrolls in each course
only once, the combination of the S_ID column
and the COURSE_NO column represents a unique
identifier of each record.
 The combination of the S_ID and GRADE columns
is not unique unless a student could never receive
two As, Bs and so on while completing
coursework at the university.
28 / 90
Types of Key Fields: Composite
Key
 The combination of the COURSE _NO and
GRADE columns is not unique, because more
than one student can earn the same grade in
the same class.

 A composite key usually comprises fields that


are primary keys in other tables.

 S_ID field in the ENROLLMENT table is part of


the table’s PK, and is also a FK that reference
an S_ID value in the STUDENT table.
29 / 90
Types of Key Fields: Composite
Key

30 / 90
DB Design
 In the previous examples it is simple to
identify which data elements should be stored
in each table and how each table should be
linked.
 In the real world, you may have 1000s of
different data elements for numerous entities,
or you may want to store or track only certain
data.
 DB Design
◦ ER models
◦ Normalization

31 / 90
ER Model
 Entity-Relationship model is designed to help
identify which entities need to be included in
the DB.
◦ Squares: entities
◦ Lines: relationships between the entities

 1-1 Relationships
 1-M Relationships
 N-M Relationships

32 / 90
1-1 Relationships
 Each occurrence of a specific entity (called
instance) is found only once in each set of
data.
◦ Each birth certificate is issued for only one person,
and each person has only one birth certificate.

Birth Certificate Person

33 / 90
One to Many (1:M) Relationships
 Rare in RDB
 An instance can only appear once in one

entity, but one or more times in the other


entity.
◦ A publisher may publish several different books,
but each book is published by only one publisher.
◦ Each publisher would be listed in a PUBLISHER table
only once, but each publisher could have several
books listed in the BOOK table.

34 / 90
One to Many (1-M) Relationships
◦ Each of these books would have a FK field that links
back to a specific record in the PUBLISHER table.

Publisher Book

35 / 90
Many to Many (N:M) Relationship
 An instance can occur multiple times in each
entity.
◦ A student can take many different classes in the
same term, and each class can be composed of
many different students.

Student Course

 It is important to DB designer.

36 / 90
Many to Many (N:M) Relationship
 Can’t be represented in the physical DB (i.e.
in the actual DB tables).
 If you tried to convert that data set directly

into two DB tables, one table being the


STUDENT table and the other being the
COURSE table, there would be no way to
correctly link the data in the tables together.
 i.e Nearly impossible to correctly retrieve data

from the DB.

37 / 90
Many to Many (N:M) Relationship
 To solve this problem, during the design of
the actual DB tables, the N:M relationship is
broken down into a series of two or more 1:M
relationship through the use of a linking table
in the process of normalization.

 In many cases, the linking table is a table that


contains the PK of each of the tables being
connected.

38 / 90
Normalization
 A step by step process used by DB designers
to determine which data elements should be
stored in which table.

 The purpose is to eliminate data redundancy.

 Unnormalized data does not have a


primary key identified and/or contains
repeating groups.

39 / 90
Normalization
 JO100 and MA100 are both taking more than
one course.

40 / 90
Normalization
 The multiple entries in the COURSE_NO,
COURSE_NAME, CREDITS, and GRADE fields
for these two students are known as
repeating groups.

41 / 90
Normalization
 The easiest way to remove repeating groups
is to create a separate record for each value
in the repeating group.

 Creation of a separate record simply involves


placing each value in a separate row and then
duplicating the information from the
remaining fields.

42 / 90
43 / 90
Normalization – 1NF
 A primary key field must be identified to convert
the data into first normal form (1NF).

 1NF means that the data has been organized in


such a manner that it has a primary key and no
repeating group.

 Previously, S_ID was used to identify each


student, but in Fig 1-14 there is more than one
entry for each student, so the S_ID field does not
contain unique values.

44 / 90
Normalization – 1NF
 Notice that no single field can be used to
identify a record.

 Therefore a composite key is required


◦ Using S_ID & COURSE_NO because no two records
have identical entries in both fields.

 Now the table is in 1NF

45 / 90
Normalization – 2NF
 Two conditions
◦ It is in 1NF
◦ It has no partial dependencies

 Partial dependency means that the fields


within the table are dependent only on part of
the primary key. This problem can only exist
if there is a composite key
◦ (i,e a table is automatically in 2NF if its primary key
consists of only one field).

46 / 90
Normalization – 2NF
 How to identify the partial dependency?
◦ Look at each field that is not part of the composite
PK and make certain you are required to have both
parts of the composite field to determine the value
of the data element and not just one part of the
composite field.

47 / 90
Normalization – 2NF
◦ Example: is the value in the COURSE_NAME field determined by
the combination of values in both the S_ID and COURSE_ID
fields?

◦ The answer is No. The name of course depends only on the


value in the COURSE_ID field.
48 / 90
Normalization – 2NF
 Therefore, there is at least one partial dependency
currently in the STUDENT table.

 To remove partial dependencies from a table, list


each part of the composite key, as well as the
entire composite key, as separate entries.
S_ID
COURSE_NO
S_ID + COURSE_NO

 Then examine the remaining fields , and determine


which attribute, or characteristic, is determined by
each portion of the composite primary key.
49 / 90
Normalization – 2NF
 The first field to examine is S_LAST, which is
determined by the student not the course.

 Therefore, the S_LAST field should be


assigned to the list of fields determined by
the student’s ID.
S_ID, S_LAST
COURSE_NO
S_ID + COURSE_NO

S_ID, S_LAST, S_ADDRESS, S_STATE, S_ZIP, F_ID, F_LAST


COURSE_NO, COURSE_NAME, CREDITS
S_ID + COURSE_NO, GRADE

50 / 90
Normalization – 2NF
 By figuring out which field is determined by
which portion of the composite PK, we have
in fact divided the data into different tables.
◦ Data regarding the student is placed in one table.
◦ Data regarding the course is placed in one table.
◦ Data regarding the student’s grade is placed in one
table.
◦ Each table is given a name

STUDENT(S_ID, S_LAST, S_ADDRESS, S_STATE, S_ZIP, F_ID, F_LAST)


COURSE(COURSE_NO, COURSE_NAME, CREDITS)
ENROLLMENT(S_ID + COURSE_NO, GRADE)

51 / 90
Normalization – 2NF
 1NF?
◦ Each table has a PK?
Yes
◦ Each table has no
repeating groups? Yes
 2NF?
◦ No partial
dependencies in the
ENROLLMENT table?
Yes
◦ STUDENT & COURSE
tables are already in
2NF because they
don’t have composite
PKs. And they are in
1NF.
52 / 90
Normalization – 3NF
 A table is considered to be in 3NF if it is in
2NF and does not have any transitive
dependences.

 A transitive dependency means that a field is


dependent on another field within the table
that is not the PK field.

53 / 90
Normalization – 3NF
1. The ENROLMENT table is in 3NF because the
value in the GRADE field is dependent on:
 The primary key
 S_ID
 COURSE_NO

2. The COURSE table is in 3NF because the


course name and the credit hours are
dependent on which course is identified by
the COURSE_NO filed, which is the table’s
primary key.

54 / 90
Normalization – 3NF
3. The STUDENT table
 Notice that the advisor’s last name is
dependent on which advisor ID is included
in the student record, not on the student.
STUDENT(S_ID, S_LAST, S_ADDRESS, S_STATE, S_ZIP, F_ID, F_LAST)
COURSE(COURSE_NO, COURSE_NAME, CREDITS)
ENROLLMENT(S_ID + COURSE_NO, GRADE)

 So, the advisors' last name should be


removed.

55 / 90
Normalization – 3NF
 Because the advisors’ last name is not
relevant to the primary keys of the COURSE
and ENROLLMENT tables, it is placed in a
separate table named FACULTY, along with
the F_ID field to uniquely identify each entry
in the new FACUTY table.
FACULTY(F_ID, F_LAST)
STUDENT(S_ID, S_LAST, S_ADDRESS, S_STATE, S_ZIP, F_ID)
 Now all fields of STUDENT are entirely
dependent on the primary key S_ID, hence
STUDENT is in 3NF.
56 / 90
Normalization
 After converting all tables to 3NF, double
check each table and make sure that all
tables representing entities that have a
relationship are linked through the use of
foreign keys.

 If you are not sure whether there should be a


link between two tables refer to the ER model.

57 / 90
Normalization

Student Course

Course
Student

Enrollment Enrollment is the


linking table
Faculty

58 / 90
 An agency supplies part-time/temporary staff
to hotels within Bahrain. The table shown in
Figure lists the time spent by agency staff
working at various hotels. The CPR INumber
is unique for every member of staff.
 Describe and illustrate the process of

normalizing the table to 3NF.


 State any assumptions you make about the

data shown in this table.

59 / 90
60 / 90
DB Systems
 DB System consists of:
◦ DBMS: Manages the physical storage and data retrieval
◦ DB applications: provides the interface that allows users
to interact with the DB

 When it was first invented, both were running on


centralized mainframe.

 When distributed computing and microcomputers


became popular in 1980s, two kinds of DBMS
emerged:
◦ Personal DBs
◦ Client/Server DBs
61 / 90
Personal Databases
 Personal DB systems, such as Microsoft
Access and FoxPro, are aimed toward
single-user DB applications that usually
are stored on a single user’s desktop
computer, or a client workstation.

 When a personal DBMS is used for multi-


user application, the DB application files
are stored on a file server and transmitted
to the individual users across the network.
62 / 90
63 / 90
Personal Databases
 With a personal DBMS, each client workstation
must load the entire DB application into main
memory along with the client DB application in
order to view, insert, update, or print data.
(DBMS and database applications run on the
same workstation)

 Recent personal DBs use indexed files that


enable the server to send only part of the DB,
but in either case, these DBMSs put a heavy
demand on client workstations and on the
network.
64 / 90
Client/Server Databases
 1. Geneerate less traffic than personal
DB
 In contrast client/server DBs, such as Oracle, split
the DBMS and the applications accessing the
DBMS into a “process” running on the server and
the “applications” running on the client.
 The client application sends data requests across
the network. When the server receives a request:
◦ the server DBMS process retrieves the data from the DB
◦ performs the requested functions on the data (sorting,
filtering, etc), and
◦ sends only the final query result (not the entire DB) back
via the network to the client.
65 / 90
Personal vs. Client/Server
 Multi-user client/server DBs generate less
network traffic than personal DB.

 2- Handle client failures: In a personal DB


interrupted updates, insertions or
deletions, records in use at that time of
the failure are locked by failed client,
which means they are unavailable to other
users.

66 / 90
Personal vs. Client/Server
 On the other hand, a client/server DB is not
affected when a client workstation fails. The
failed client’s in-progress transactions are lost,
but the failure of a single client does not affect
other users.

 In the case of a server failure, a central


synchronized transaction log, which contains a
record of all current DB changes, enables in-
progress transactions from all clients to be
either fully completed or rolled back.

67 / 90
Personal vs. Client/Server
 3- Handle competing user transactions:
In a client/server system the transaction
causes the DB to read the table and
simultaneously lock all or part of the table
prior to updating the table.

 A personal DB, uses optimistic locking: it


hopes that two competing transactions will
not access the same record at the same
time. Optimistic locking, therefore, does not
really lock the table. Access will notify the
user that the table has been changed since
he or she last read it, but then Access offers
to proceed and save the update anyway.
68 / 90
Server and Client Processes
 When computers are connected through
networks, some computers act as servers and
others as clients.
◦ Server is a computer that shares its resources with
other computers.
 Data: files
 Hardware: printers
 Shared server-based programs: DBs and email.
◦ Server process is a program that listens for requests
for resources from clients and responds to them.
◦ Client process is a program that requests and uses
server resources.

69 / 90
Server and Client Processes
 Example:
◦ Start an email program
◦ Email program starts a client process
◦ Client process connects to an email server
◦ Email server process
 notifies you if you have new messages
 sends your new messages when you request them
 Forwards your outgoing messages to the recipient’s email
server

 Any computer can be a server and run more


than one server process. It can act as both
server and client, (e.g. sharing your files and
requesting from other computers). 70 / 90
Personal DBMS
 The DBMS and the DB applications run on the same
workstation. They appear to the user as a single
integrated application.

 Used for creating single-user DB applications.


◦ Address book
◦ Track information about your personal finances

 MS Access and Oracle 10g Personal edition are both


personal DB but they differs in data management.
Access has no client/server features. Oracle 10g
Personal Edition got some restriction to prevent
people from using it for large multiuser DB
applications. 71 / 90
Personal DBMS
 Personal DB is rarely used to create simple DB
applications that support access of multiple
users at the same time.
◦ Track lab equipment and employee schedule

 That is done by storing the DB application


files on a file server instead of on a single
user’s workstation and then transmitting the
files or parts of files containing the desired
data to various users across a network.

72 / 90
Personal DBMS
 Access stores all data for a DB in a single
mdb file on a central file server. The client
workstation loads the entire DBMS into main
memory, along with the DB applications to
view, insert, update or print data.

 This imposes a heavy load on client


workstation and on the network. The network
must be fast enough to handle the traffic
generated.

73 / 90
Personal DBMS

74 / 90
Personal DBMS
 Personal DB should only be used for
applications that not mission critical.

 When a client workstation requests a data file,


data within the file is locked and unavailable to
other users.

 If a client workstation fails because of a


software malfunction or power failure during a
DB operation, the data file that is locked
remains unavailable to other users, and
sometimes becomes damaged.
75 / 90
Personal DBMS
 The central DB files might be repairable, but
all users must quit using the DB during the
repair process, which could take several
hours. Updates, deletions, and insertions
taking place at the time of the failure often
can’t be reconstructed.

 If repair is not possible, the DBA can restore


the DB to its state at the time of the last
regular backup, but transactions that
occurred since the backup are lost.
76 / 90
Personal DBMS
 Problem with how the personal DB support
transaction processing.

 Transaction processing: grouping related DB


changes into units of work that must either all
succeed or all fail.

 Example: a customer tries to deposit a check.


The bank must ensure that the money is debited.
If any part of the transaction fails then neither
account balance should change.

77 / 90
Personal DBMS
 When you perform a transaction in Access,
the personal DB records the related changes
in the client workstation’s main memory in a
record called a transaction log.

 If you decide to abort the transaction, or if


some part of the transaction does not
succeed the DBMS can use the transaction log
to reverse, or roll back.

78 / 90
Personal DBMS
 However, since the transaction log is in the
client workstation’s main memory.

 If the client workstation fails in the middle of


the transaction, the transaction log is lost, so
the changes can’t be rolled back.

 Hence, a failed client workstation could result


in a deduction in account1 while no change in
account2, or increase in account2 and no
change in account1.
79 / 90
Client/Server DBMS
 Today’s organizations often need DB to
support 1000s of simultaneous users and
support mission-critical tasks.

 Client/Server DBMS takes advantages of


distributed processing and networked
computers by distributing processing across
multiple computers.

80 / 90
Client/Server DBMS
 The DBMS server process runs on one
workstation, while the DB applications run on
separate client workstation.

81 / 90
Client/Server DBMS
Advantages
 Generates less network traffic than personal DB.

 Less likely to be bogged down by an overloaded


network.

 In case of hardware and software malfunctions,


the DBMS server processes have extra features
to minimize the chance of failure.
◦ They have powerful recovery mechanisms that often
operate automatically.

82 / 90
Client/Server DBMS
 In case of transaction processing, they maintain
a file-based transaction log on the DB server.

 If a workstation fails before finishing a


transaction, the DB server automatically rolls
back all the transaction changes.

 If the server crashes, the file-based transaction


log allows transactions to be rolled back when
the server is restarted.

83 / 90
Client/Server DBMS
 They are preferred for DB applications that
retrieve and manipulate small amounts of
data from DB containing large number of
records because
◦ they minimize network traffic
◦ improve response times.

 They are essential for mission-critical


applications because of the
◦ failure handling
◦ recovery mechanisms
◦ transaction-management control
84 / 90
Client/Server DBMS
 They have a rich set of DB management and
administration tools for handling large numbers
of users.

 They are ideal for web-based DB applications


that require increased security and fault
tolerance.

 Organizations use them if the DB generally has


more than 10 simultaneous users and if the DB is
mission-critical.

85 / 90
Oracle 10g Client/Server DB
 On the server side, the DBA installs and
configures the Oracle 10g DBMS server process.

 All Oracle server- and client-side programs use


Oracle Net, which is a utility that enables
network communication between the client and
the server.

 Oracle Net process starts automatically on the


client workstation when you start an Oracle
client-side process.

86 / 90
Oracle 10g Client/Server DB
 Client Oracle Net process communicates with
an Oracle Net process running on the DB
server.

 The process running on the server forwards


user request to the Oracle DBMS.

87 / 90
Oracle 10g Client/Server DB
 Oracle Application Server: used to create
World Wide Web pages that allow users to
access Oracle databases and create dynamic
web pages that interact with an Oracle DB.

 The DBA installs and configures those


products

88 / 90
Oracle 10g Client/Server DB
 Oracle Client products:
◦ SQL*Plus: creating and testing command-line SQL
queries and executing PL/SQL procedural
programs.
 PL/SQL is Oracle’s sequential programming language
that is used to create programs that process DB data.
◦ Oracle 10g Developer Suite: develop DB
applications:
 Forms Builder: Creating custom user applications
 Reports Builder: Creating reports
◦ Enterprise Manager: Performing DB administration
tasks such as creating new user accounts and
configuring how the DBMS stores and manages
data. 89 / 90
Summary:
DB Cases
 When creating DB tables:
◦ Convert all tables to 3NF
◦ When linking tables, include the primary key as the
foreign key in the table on the many side of the
relationship
◦ Specify the data type for each column
 Use a number data type for columns that store
numerical values that are involved in calculations. i.e.
store phone numbers and postal codes as text strings.

93 / 90
The Clearwater Traders Sales
Order Database
 Clothing and sporting goods through mail-
order catalogs
 Wants to begin accepting orders using Web

site
 Required data consists of information for:

◦ Customers
◦ Orders
◦ Items
◦ Shipments

96 / 90
The Clearwater Traders Sales
Order Database
 Tables:
◦ CUSTOMER
◦ ORDER_SOURCE
◦ ORDERS
◦ CATEGORY
◦ ITEM
◦ ORDER_LINE
◦ SHIPMENT
◦ INVENTORY
◦ SHIPMENT_LINE
◦ COLOR

97 / 90
Visual Representation of the
Clearwater Traders Database

98 / 90
The Northwoods University Student
Registration Database
 Student registration system
 Data items consist of information about:

◦ Students
◦ Courses
◦ Instructors
◦ Student Enrollment

99 / 90
 -
The Northwoods University Student
Registration Databas
 Tables:
◦ LOCATION
◦ FACULTY
◦ STUDENT
◦ TERM
◦ COURSE
◦ COURSE_SECTION
◦ ENROLLMENT

10 / 90
3
Visual Representation of the
Northwoods University Database

10 / 90
4

Вам также может понравиться