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

ICFAI

BUSINESS SCHOOL

Database Management System

Copyright - ICFAI Business


02/11/10 School 1
ICFAI Chapter Objectives
BUSINESS SCHOOL

 Understand Concept of Database


 Data Analysis using ER modeling
 Normalization
 Structured Query Language

Copyright - ICFAI Business


02/11/10 School 2
ICFAI File Systems
BUSINESS SCHOOL

START

EM Read EM

ET Read ET

ET>EM Read EM

ADD SAL

Copyright - ICFAI Business


02/11/10 School 3
ICFAI Databases
BUSINESS SCHOOL

• Hierarchical Databases
• Network Database
• Relational Databases

Orgn Dept Orgn Proj Orgn

Dept Dept Dept Emp Dept

Emp Emp Emp Allow Dedu Depen Emp


Hierarchical Network Relational
IBM’s Total DBMS-11 ORACLE

Copyright - ICFAI Business


02/11/10 School 4
ICFAI
BUSINESS SCHOOL

Copyright - ICFAI Business


02/11/10 School 5
ICFAI Database Management System
BUSINESS SCHOOL

Performan Utilitie
Monitorin ce s
g • Indexes • Explain Plan
• Alerts • Threads
• OEM • DBMS Pkgs
• PQs

Data
Data
Management
Entry
• IMP, EXP
• Forms
Database • Backup
• SQL
• Recovery
• Reports

Securit Transactio
Integrit
y n
y
• Keys • Users • Locks
• Constraints • Privileges • Commit
• Views

Copyright - ICFAI Business


02/11/10 School 6
ICFAI RDBMS Packages
BUSINESS SCHOOL

Product Scope Provider


Oracle Enterprise Oracle
Corporation
DB2 Enterprise IBM
Informix Department Informix
MySQL Department Linux, GNU
Sybase Enterprise Sybase
SQL Server Department Microsoft
MS Access Personal Microsoft

Copyright - ICFAI Business


02/11/10 School 7
ICFAI Characteristics of RDBMS
BUSINESS SCHOOL

Information Rule
Guaranteed Access Rule
Null Value support
Data Description
Sublanguage
View Updating
Insert update rule
Physical Data independence
Logical Data independence
Integrity independence
Distribution rule
Non-subversion

Copyright - ICFAI Business


02/11/10 School 8
ICFAI Data Modeling
BUSINESS SCHOOL

The design process follows five steps:

• Planning and Analysis


• Conceptual Design
• Logical Design
• Physical Design
• Implementation

Planning
Data ER
and
Modeling Diagram
Analysis

Copyright - ICFAI Business


02/11/10 School 9
ICFAI Data Modeling
BUSINESS SCHOOL

• The data model is one part of the conceptual design process.


• The other, typically is the functional model.
• The data model focuses on what data should be stored in the
database.
• The functional model deals with how the data is processed.

To put this in the context of the relational database,

• The data model is used to design the relational tables.


• The functional model is used to design the queries which will
access and perform operations on those tables.

Copyright - ICFAI Business


02/11/10 School 10
ICFAI E-R Model
BUSINESS SCHOOL

The Entity-Relationship Model

• The Entity-Relationship (ER) model was originally proposed by Chen in


1976.
• An ER model is a conceptual model that views the real world as entities
and relationships.
• A basic component of the model is the Entity-Relationship diagram which
is used to visually represent data objects.
• Since introduction the model has been considerably extended and is most
commonly used method for relational database design today.

Copyright - ICFAI Business


02/11/10 School 11
ICFAI Utility of E-R Model
BUSINESS SCHOOL

For the database designer, the utility of the ER model is:

• It maps well to the relational model. The constructs used in the ER model
can easily be transformed into relational tables.
• It is simple and easy to understand with a minimum of training. Therefore,
the model can be used by the database designer to communicate the
design to the end user.
• In addition, the model can be used by the database developer to physically
construct the data structures.

Copyright - ICFAI Business


02/11/10 School 12
ICFAI Basic Constructs of E-R Modeling
BUSINESS SCHOOL

The ER model views the real world as a network of entities and association
between entities.

Entities

Entities are the principal data object about which information is to be


collected. Entities are usually recognizable concepts, physical or abstract,
such as people, places, things, or events which have relevance to the
application system. Some specific examples of entities are

• EMPLOYEES
• DEPARTMENTS
• PROJECTS
• ORDERS
• INVOICES etc.

An entity maps to a table in the database.

Copyright - ICFAI Business


02/11/10 School 13
ICFAI Basic Constructs of E-R Modeling
BUSINESS SCHOOL

Relationships

A Relationship represents an association between two or more


entities. An example of a relationship is:

• EMPLOYEES are assigned to PROJECTS


• PROJECTS have SUBTASKS
• DEPARTMENTS manage one or more PROJECTS

A relationship maps to primary and foreign key associations in tables.

Copyright - ICFAI Business


02/11/10 School 14
ICFAI Basic Constructs of E-R Modeling
BUSINESS SCHOOL

Attributes

• Attributes describe the entity of which they are associated. A


particular instance of an attribute is a value. For example, "John F
Kennedy" is one value of the attribute Name.

• The domain of an attribute is the collection of all possible values an


attribute can assume. The domain of Name is a string of alphabets.

• Attributes can be classified as identifiers or descriptors. Identifiers,


more commonly referred to as keys, uniquely identify an instance
of an entity. A descriptor describes a non-unique characteristic of
an entity instance.

Copyright - ICFAI Business


02/11/10 School 15
ICFAI Classifying Relationships
BUSINESS SCHOOL

Relationships are classified by their degree, connectivity, cardinality,


direction, type, and existence.
Degree of a Relationship
The degree of a relationship is the number of entities associated with
the relationship. The n-ary relationship is the general form for degree
n. In real world binary with degree 2 and ternary with degree 3 are
most frequently encountered relationships.
Connectivity and Cardinality
The connectivity of a relationship describes the mapping of
associated entity instances in the relationship. The values of
connectivity are "one" or "many". The cardinality of a relationship is
the actual number of related occurrences for each of the two entities.
The basic types of connectivity for relations are: one-to-one, one-to-
many, and many-to-many.

Copyright - ICFAI Business


02/11/10 School 16
ICFAI Connectivity
BUSINESS SCHOOL

One-to-One (1:1) relationship


At most one instance of entity A Is associated with only one instance of
entity B.

For example, each passenger in a flight is assigned only one seat. Here
both the passenger and seat number are unique in the relationship.

One-to-Many (1:M) relationship


For one instance of entity A, there are zero, one, or many instances of
entity B, but for one instance of entity B, there is only one instance of
entity A.

An example of a 1:M relationship is


a department has many employees
each employee is assigned to one department

Copyright - ICFAI Business


02/11/10 School 17
ICFAI Connectivity
BUSINESS SCHOOL

A many-to-many (M:M) relationship

Sometimes called non-specific,


For one instance of entity A, there are zero, one, or many Instances of
entity B
And for one instance of entity B there are zero, one, or many instances
of entity A.
An example is:
Employees can be assigned to more than one project and at the same
time projects must have one or more employees assigned to it.

Copyright - ICFAI Business


02/11/10 School 18
ICFAI Existence
BUSINESS SCHOOL

Existence denotes whether the existence of an entity


instance is dependent upon the existence of another,
related, entity instance. The existence of an entity in a
relationship is defined as either mandatory or optional. If
an instance of an entity must always occur for an entity to
be included in a relationship, then it is mandatory.

An example of mandatory existence is the statement


"every project must be managed by a single department".
If the instance of the entity is not required, it is optional. An
example of optional existence is the statement,
"employees may be assigned to work on projects".

Copyright - ICFAI Business


02/11/10 School 19
ICFAI E-R Notation
BUSINESS SCHOOL

In this course we will follow the following notation.


Entities are represented by
Rectangular boxes with rounded corners
Named in singular UPPER CASE SALES
Attributes are listed inside the box # Order Number
о Order Date
Attributes should be ● Dely Date

Named in Title Case


Prefixed with
● if mandatory ORDERLINE
о if optional #@ Order Number
# Line Number
# if whole or part of unique identifier о Quantity
● Unit Price
@ is used to indicate foreign key

Copyright - ICFAI Business


02/11/10 School 20
ICFAI E-R Notation
BUSINESS SCHOOL

• Relationship lines must have phrases describing at both ends.


• Indicate optionality at both ends

Is represented by
• solid line for mandatory relationship
• dotted line for optional relationship
• crow’s foot for m degree Relationship Notation
• single line for “1” degree
mandatory
optional
one
many
relationship1
E1 E2

relationship2

Each E1 may be relationship1 one or more E2


Each E2 must be relationship1 one and only one E1
Copyright - ICFAI Business
02/11/10 School 21
ICFAI Entities, Attributes
BUSINESS SCHOOL

Invoice Amount Flight No. PNR

Employee Details Department Basic

Dependent DOB Part No

Blood Group Cell No Acct Code

Invoice Line Hiredate IPC Ref

Order Line Qualification Cust Code

Order Qty Leave Supplier

Copyright - ICFAI Business


02/11/10 School 22
ICFAI BWC Video Club
BUSINESS SCHOOL

Harry runs a a video library for the members of his video club. It is
important for him to know about the titles on his shelves, of
course, but also how many copies he has, what sort of video
format they are, what their purchase price was, their condition,
what their run time is so forth.

Each copy may be eventually loaned to lots of customers, each of


whom must be a current member, at a fixed rate per day, normally
he knows when to expect the copy back, in case other people
inquire about that title.

Copyright - ICFAI Business


02/11/10 School 23
ICFAI BWC Video Club
BUSINESS SCHOOL

of
LOAN VIDEO COPY
• From_date • Format
ο Exp_return subject of ο Condition
at
to of

used
in DAILY RATE
• Amount
ο St_date
party to
source of
CUSTOMER
• Memb_No VIDEO TITLE
ο Name • Name
ο Renew_Dt ο Run_Time
ο Distributor

Copyright - ICFAI Business


02/11/10 School 24
ICFAI Anywhere Credit Cards
BUSINESS SCHOOL

The most important thing in my business is to know which credit


cards are held by whom. Normally we are interested in the credit
card holder for whom the account is held but obviously, as with
the Visa and other systems there may be several cards for one
account held by wife, mistresses etc.

We have three types of card at the moment and it is important to


be able to find the date of issue of cards by card type when we
are checking for authority to issue a replacement card. From a
fraud point of view it is useful to know who has what card
identified by simple unique card number, and when it was
issued/withdrawn/replaced/notified as lost etc.

Just to be awkward, we also have a Business Credit Card System


where the account is owned by a company and cards issued to
selected employees.

Copyright - ICFAI Business


02/11/10 School 25
ICFAI Anywhere Credit Cards
BUSINESS SCHOOL

Copyright - ICFAI Business


02/11/10 School 26
ICFAI Normalization – 12 Step process
BUSINESS SCHOOL

1. Collect raw data


2. List the raw data with its key
3. Remove repeating groups
4. Remove part key dependencies
5. Remove inter-data dependencies
6. Remove inter-key dependencies
7. Apply tests
8. Identify transitive dependencies
9. Optimize
10.Re-apply the tests
11.Draw Entity – Relationship Diagram
12.Use the model to design database

Copyright - ICFAI Business


02/11/10 School 27
ICFAI
BUSINESS SCHOOL
Collect Raw Data
• Identify possible source.
• Include all data that is required to support the system
• Understand the data and its purpose
• Use completed copies of forms and reports
• Record and assumptions

Sales Report by Product


Product No: 714-56 Description: Microwave Oven
Invoice Invoice Date Contact Customer Quantity Price
Name Name
4387 20/03/05 S. Davies S. Davies 1 76.00
5183 14/04/05 M. Scott M. Scott 2 152.00
6420 17/06/05 I. Ramsay I. Ramsay 1 76.00
6786 10/09/05 G. Tell G. Tell 1 76.00
7543 28/10/05 B. Twain B. Twain 3 226.00

Copyright - ICFAI Business


02/11/10 School 28
ICFAI List Raw Data – 0 NF
BUSINESS SCHOOL

Use a working space as show below


List all data items in col. 1
Make sure data names are from users’ vocabulary and are meaningful
Make sure data names are unique
Select a key and mark it with (#) symbol
This key must have a unique value
As few items as possible (multi-part key)
Non-textual if possible
Any item may be chosen. But appropriate choice simplifies the process
Source document title or layout may suggest the best keys.
Sometimes generated keys may be necessary

Copyright - ICFAI Business


02/11/10 School 29
ICFAI Remove Repeating Groups – 1 NF
BUSINESS SCHOOL

• Identify and list in col. 2 all items which have more than single value while
the remains single valued. This is a repeating group. There can be more
than one.
• Copy the original key to join the new key in 1 NF relation. Mark it as a
Foreign key (@)
• The foreign key copied will be the primary key of another relation
• Check for nested repeating groups
• List remaining data items and original keys as a final group in 1 NF

Copyright - ICFAI Business


02/11/10 School 30
ICFAI Remove part-key dependencies – 2 NF
BUSINESS SCHOOL

• In each data group at 1 NF identify all data items that depend on only on a
part of the key.
• List these as a new relation. Copy the part key. The key also remains with
the original group.

Copyright - ICFAI Business


02/11/10 School 31
ICFAI Remove inter-data dependencies – 3 N
BUSINESS SCHOOL

• For each non-key items, list all those items which are dependent on another
item(s) and not the key.
• List these as a new relation. Copy the determinant items as the key. The
key also remains with the original group as a foreign key.

Copyright - ICFAI Business


02/11/10 School 32
ICFAI
BUSINESS SCHOOL

Copyright - ICFAI Business


02/11/10 School 33
ICFAI Remove inter-key dependencies – BCN
BUSINESS SCHOOL

• Boyce – Codd Normal Form


• Check only multi-part keys
• Ask; for key A is there only one possible value for key B?
• Mark the new item as foreign key
• Data item B – prime key elsewhere

A # Product No. A # Product No. A # Product No.


B #Supplier B Supplier B @Supplier

Copyright - ICFAI Business


02/11/10 School 34
ICFAI Apply 3 NF Tests
BUSINESS SCHOOL

• Each data item depends on whole key


• Data Item uni-valued for a given key

Copyright - ICFAI Business


02/11/10 School 35
ICFAI Identify Transitive Dependencies
BUSINESS SCHOOL

# Inv. No. # Cust. Name


Inv. Date Contact Name
@ Cust. Name

# Inv. No. # Cust. No.


Inv. Date Cust. Name
@ Cust. No @ Contact Name

Copyright - ICFAI Business


02/11/10 School 36
ICFAI Optimize
BUSINESS SCHOOL

The example normalization was done using a sales report. In another


form we may find another data group with the same key but different
data. They can be combined as a single group

Doc. 1 Doc. 2

# Prod. No. # Prod. No.


Prod. Desc. Prod. Size
Reorder Level

# Prod. No.
Prod. Desc.
Prod. Size
Reorder Level

Copyright - ICFAI Business


02/11/10 School 37
ICFAI Optimize
BUSINESS SCHOOL

Customer Delinquent Customer


# Cust. No.
Cust. Name # Cust. No.
Cust. Addr. Cust. Name
Cust. Contact. Cust. Addr.
Cust. Contact
A/C Bal Last Payment
A/C Bal

Optimized
# Cust. No.
Cust. Name
Cust. Addr.
Cust. Contact
Last Payment
A/C Bal
Delinquency Indicator

Copyright - ICFAI Business


02/11/10 School 38
ICFAI Draw E-R Diagram
BUSINESS SCHOOL

Invoice Line Product


#@ Inv. No. # Prod. No.
#@ Prod. No. Prod. Desc
Quantity Prod. Size
Price Reorder Level

Invoice
#@ Inv. No.
Inv. Date
@ Cust. No.

Customer
# Cust. No.
Order Cust. Name
# Ord. No. Cust. Addr.
Ord. Date Cust. Contact
@ Cust. No. Last Payment
A/C Bal
Delinquency Indicator

Copyright - ICFAI Business


02/11/10 School 39

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