Database Management System - Classroom

ICFAIBUSINESS SCHOOL

04/08/2304/08/23Copyright - ICFAI Business Copyright - ICFAI Business

SchoolSchool 11

Database Management SystemDatabase Management System



SchoolSchool 22

Chapter ObjectivesChapter Objectives

Understand Concept of DatabaseUnderstand Concept of Database

Data Analysis using ER modelingData Analysis using ER modeling

Normalization Normalization

Structured Query Language Structured Query Language



SchoolSchool 33

File SystemsFile Systems

ET>EM

EM Read EM

START

ET Read ET

Read EM

ADD SAL



SchoolSchool 44

Databases

• Hierarchical Databases

• Network Database

• Relational Databases

Dept

Orgn

Dept Dept

EmpEmp Emp

Emp

OrgnDept Proj

DeduAllow Depen

Orgn

Dept

Emp

HierarchicalIBM’s Total

NetworkDBMS-11

RelationalORACLE



SchoolSchool 55



SchoolSchool 66

Database Management SystemDatabase Management System

Database

Data Entry

• Forms• SQL• Reports

Data Management

• IMP, EXP• Backup• Recovery

Security

• Users• Privileges• Views

Performance• Indexes• Threads• PQs

Transaction

• Locks• Commit

Integrity

• Keys• Constraints

Monitoring• Alerts• OEM

Utilities

• Explain Plan• DBMS Pkgs



SchoolSchool 77

RDBMS PackagesRDBMS Packages

ProductProduct ScopeScope ProviderProvider

OracleOracle EnterpriseEnterprise Oracle Oracle CorporationCorporation

DB2DB2 Enterprise Enterprise IBMIBM

InformixInformix DepartmentDepartment InformixInformix

MySQLMySQL DepartmentDepartment Linux, GNULinux, GNU

SybaseSybase EnterpriseEnterprise SybaseSybase

SQL ServerSQL Server DepartmentDepartment MicrosoftMicrosoft

MS AccessMS Access PersonalPersonal MicrosoftMicrosoft



SchoolSchool 88

Characteristics of RDBMSCharacteristics of RDBMS

Information RuleInformation Rule

Guaranteed Access RuleGuaranteed Access Rule

Null Value supportNull Value support

Data DescriptionData Description

Sublanguage Sublanguage

View UpdatingView Updating

Insert update ruleInsert update rule

Physical Data independencePhysical Data independence

Logical Data independenceLogical Data independence

Integrity independenceIntegrity independence

Distribution ruleDistribution rule

Non-subversionNon-subversion



SchoolSchool 99

The design process follows five steps:

• Planning and Analysis • Conceptual Design • Logical Design• Physical Design• Implementation

Planning and

Analysis

Data Modeling

ER Diagram

Data ModelingData Modeling



SchoolSchool 1010

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

Data ModelingData Modeling



SchoolSchool 1111

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.

E-R ModelE-R Model



SchoolSchool 1212

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.

Utility of E-R ModelUtility of E-R Model



SchoolSchool 1313

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.

Basic Constructs of E-R ModelingBasic Constructs of E-R Modeling



SchoolSchool 1414

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.




SchoolSchool 1515

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.




SchoolSchool 1616

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.

Classifying RelationshipsClassifying Relationships



SchoolSchool 1717

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 isa department has many employees

each employee is assigned to one department

ConnectivityConnectivity



SchoolSchool 1818

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.

ConnectivityConnectivity



SchoolSchool 2020

In this course we will follow the following notation.

Entities are represented by

Rectangular boxes with rounded cornersNamed in singular UPPER CASEAttributes are listed inside the box

Attributes should be

Named in Title CasePrefixed with ● if mandatoryо if optional# if whole or part of unique identifier @is used to indicate foreign key

SALES

# Order Numberо Order Date● Dely Date

ORDERLINE

#@ Order Number# Line Numberо Quantity● Unit Price

E-R NotationE-R Notation



SchoolSchool 2121

• 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• single line for “1” degree

E2

mandatory

optional

one

many

Relationship Notation

Each E1 may be relationship1 one or more E2Each E2 must be relationship1 one and only one E1

relationship1

relationship2

E1

E-R NotationE-R Notation



SchoolSchool 2222

Invoice Amount

Employee Details

Blood Group

Dependent

Invoice Line

Order Line

Order Qty

Flight No.

Department

DOB

Cell No

Hiredate

Qualification

Leave

PNR

Basic

Part No

Acct Code

IPC Ref

Cust Code

Supplier

Entities, AttributesEntities, Attributes



SchoolSchool 2323

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.

BWC Video ClubBWC Video Club



SchoolSchool 2424

BWC Video ClubBWC Video Club

LOAN From_date Exp_return

VIDEO COPY Format Condition

DAILY RATE Amount St_date

CUSTOMER Memb_No Name Renew_Dt

VIDEO TITLE Name Run_Time Distributor

party to

to

at

of

subject of

used in

of

source of



SchoolSchool 2525

Anywhere Credit CardsAnywhere Credit Cards

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.



SchoolSchool 2626

Anywhere Credit CardsAnywhere Credit Cards



SchoolSchool 2727

Normalization – 12 Step processNormalization – 12 Step process

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



SchoolSchool 2828

Sales Report by ProductSales Report by ProductProduct No: 714-56Product No: 714-56 Description: Microwave OvenDescription: Microwave OvenInvoiceInvoice Invoice Invoice

DateDateContact Contact NameName

Customer Customer NameName

QuantityQuantity PricePrice

43874387 20/03/0520/03/05 S. DaviesS. Davies S. DaviesS. Davies 11 76.0076.0051835183 14/04/0514/04/05 M. ScottM. Scott M. ScottM. Scott 22 152.00152.0064206420 17/06/0517/06/05 I. RamsayI. Ramsay I. RamsayI. Ramsay 11 76.0076.0067866786 10/09/0510/09/05 G. TellG. Tell G. TellG. Tell 11 76.0076.00

75437543 28/10/0528/10/05 B. TwainB. Twain B. TwainB. Twain 33 226.00226.00

Collect Raw DataCollect 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



SchoolSchool 2929

List Raw Data – 0 NFList Raw Data – 0 NF

Use a working space as show belowList all data items in col. 1Make sure data names are from users’ vocabulary and are meaningfulMake sure data names are uniqueSelect a key and mark it with (#) symbolThis key must have a unique valueAs few items as possible (multi-part key)Non-textual if possibleAny item may be chosen. But appropriate choice simplifies the processSource document title or layout may suggest the best keys.Sometimes generated keys may be necessary



SchoolSchool 3030

Remove Repeating Groups – 1 NFRemove Repeating Groups – 1 NF

• 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



SchoolSchool 3131

Remove part-key dependencies – 2 NFRemove part-key dependencies – 2 NF

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



SchoolSchool 3232

Remove inter-data dependencies – 3 NFRemove inter-data dependencies – 3 NF

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



SchoolSchool 3333



SchoolSchool 3434

Remove inter-key dependencies – BCNFRemove inter-key dependencies – BCNF

• 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.B #Supplier

A # Product No.B Supplier

A # Product No.B @Supplier



SchoolSchool 3535

Apply 3 NF TestsApply 3 NF Tests

• Each data item depends on whole key

• Data Item uni-valued for a given key



SchoolSchool 3636

Identify Transitive DependenciesIdentify Transitive Dependencies

# Inv. No.Inv. Date

@ Cust. Name

# Inv. No.Inv. Date

@ Cust. No

# Cust. NameContact Name

# Cust. No.Cust. Name

@ Contact Name



SchoolSchool 3737

OptimizeOptimize

# Prod. No.Prod. Desc.

# Prod. No.Prod. SizeReorder Level

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. Desc.Prod. SizeReorder Level



SchoolSchool 3838

OptimizeOptimize

CustomerCustomer## Cust. No.Cust. No.

Cust. NameCust. NameCust. Addr.Cust. Addr.Cust. Cust.

Contact.Contact.A/C BalA/C Bal

Delinquent Delinquent CustomerCustomer

## Cust. No.Cust. No.Cust. NameCust. NameCust. Addr.Cust. Addr.Cust. ContactCust. Contact

Last Payment Last Payment A/C BalA/C Bal

OptimizedOptimized## Cust. No.Cust. No.

Cust. NameCust. NameCust. Addr.Cust. Addr.Cust. ContactCust. Contact


Delinquency Delinquency IndicatorIndicator



SchoolSchool 3939

Draw E-R DiagramDraw E-R Diagram

Invoice LineInvoice Line#@#@Inv. No.Inv. No.#@#@Prod. No.Prod. No.

QuantityQuantity

PricePrice

ProductProduct## Prod. No.Prod. No.

Prod. DescProd. DescProd. SizeProd. SizeReorder Reorder

LevelLevel

InvoiceInvoice#@#@Inv. No.Inv. No.

Inv. DateInv. Date@@ Cust. No.Cust. No.

CustomerCustomer## Cust. No.Cust. No.

Cust. NameCust. NameCust. Addr.Cust. Addr.Cust. ContactCust. Contact


Delinquency Delinquency IndicatorIndicator

OrderOrder## Ord. No.Ord. No.

Ord. DateOrd. Date@@ Cust. No.Cust. No.

Database Management System - Classroom

Documents

icfaibusiness school

relational model

conceptual model

entityrelationship er

relational database

data structures

data objects

entities entities