Slides Rdbmscore Db92 01

ER/CORP/CRS/DB92 Ver. No.: 0.1 Copyright © 2008, Infosys Technologies Ltd.

Education and Research We enable you to leverage knowledge anytime, anywhere!

Confidential

RDBMS- Core Day1

Ver. No.:4.0

Copyright © 2008, Infosys Technologies Ltd. Confidential

General Guideline

© (2008) Infosys Technologies Ltd.

This document contains valuable confidential and proprietary information of Infosys. Such confidential and proprietary information includes, amongst others, proprietary intellectual property which can be legally protected and commercialized. Such information is furnished herein for training purposes only. Except with the express prior written permission of Infosys, this document and the information contained herein may not be published, disclosed, or used for any other purpose.

2


Confidential Information

This Document is confidential to Infosys Technologies Limited. This document contains information and data that Infosys considers confidential and proprietary (“Confidential Information”).

Confidential Information includes, but is not limited to, the following: Corporate and Infrastructure information about Infosys Infosys’ project management and quality processes Project experiences provided included as illustrative case studies

Any disclosure of Confidential Information to, or use of it by a third party, will be damaging to Infosys.

Ownership of all Infosys Confidential Information, no matter in what media it resides, remains with Infosys.

Confidential information in this document shall not be disclosed, duplicated or used – in whole or in part – for any purpose other than reading without specific written permission of an authorized representative of Infosys.

This document also contains third party confidential and proprietary information. Such third party information has been included by Infosys after receiving due written permissions and authorizations from the party/ies. Such third party confidential and proprietary information shall not be disclosed, duplicated or used – in whole or in part – for any purpose other than reading without specific written permission of an authorized representative of Infosys.

3


Learning approach

The following are strongly suggested for a better learning and understanding of this course: Noting down the key concepts in the class, explained by the

educator Analyze all the examples / code snippets provided Study and understand the self study topics Completion and submission of all the assignments, on time Completion of the self review questions in the lab guide Study and understand all the artifacts including the reference

materials / e-learning / supplementary materials specified Completion of the project (if applicable for this course) on time

inclusive of individual and group activities Taking part in the self assessment activities Participation in the doubt clearing sessions

4


C Map- RDBMS Core

5

Copyright © 2008, Infosys Technologies Ltd. Confidential6

Course Objectives

Introduction of basic RDBMS concepts

Familiarization with SQL

Commands of DDL,DML and DCL Languages

Concept of Joins

Concept of Sub Queries

Views


Session PlanDay1

• Traditional Approach, • Why DBMS ?• Users of DBMS• Data Models• RDBMS, Keys• ER Modeling• ERD Case Studies

Day2• Transforming an ER model to Relational Schema• Functional Dependencies• Normalization

Day3• Introduction to SQL and SQL Plus• DDL• DML (Till Order By)

Day 4• Aggregate Functions• Group By and Having clause• Joins

Day 5• Independent Sub Queries• Correlated Sub queries • Use of EXISTS and NOT EXISTS

Day 6• Views• DCL

7


References

Henry F Korth, Abraham Silberschatz, “Database system concepts”, McGraw-Hill International editions, Computer Science Series(1991), Second ed.,

Elmasri, Navathe, "Fundamentals of Database Systems", Addison Wesley, Third ed

C.J.Date, "An introduction to Database Systems", Narosa Publications, Sixth ed.,


Session Plan Day1

Traditional File Approach Advantages of a DBMS Three layers of abstraction Users of DBMS Database Models Types of Databases Relational Model Basics Keys Conceptual Design

ER Modelling ER Modelling Notations ERD Case study Merits & Demerits of ER Modeling


Traditional Method of Data Storage

File System

Loan_Processing(Application Program) Fixed_Deposit_Processing

(Application Program)

Transaction_Processing(Application Program)

Customer_Details.dat Customer_Loan.dat Customer_Fixed_Deposit.dat Customer_Transaction.dat


Problems: Traditional Approach

• Data Security

• Data Redundancy

• Data Isolation

• Program / Data Dependence

• Lack of Flexibility

• Concurrent Access Anomalies

11


Database Management System

• DBMS is consist of collection of interrelated files and set of programs.

• These set of programs allow users to access and modify files

• Primary Goal is to provide a convenient and efficient way to store, retrieve and modify information

• Layer of abstraction between the application programs and the file system

12


Where does the DBMS fit in?

File System

Loan_Processing(Application Program) Fixed_Deposit_Processing

(Application Program)

Transaction_Processing(Application Program)

DBMS

Bank Database

Customer_DetailsCustomer_Loan

Customer_Fixed_DepositCustomer_Transaction


Difference Between File and DBMS Operations

End User

Application Programs

Interface through high level language

READ CUSTOMER_DETAILS-FILE AT ENDSTOP RUN

Operating System (Disk Manager, File Manager)

File System (Disk Storage)

End User

Application Programs

Interface through Query (SQL)

SELECT * FROM Customer_Details

Operating System (Disk Manager, File Manager)

Database(Disk Storage)

DBMS

File system Interface DBMS Interface

Customer_Details fileCustomer_Loan file

Customer_Details tableCustomer_Loan table


Three-layer Architecture

15

Conceptual Schema

Internal Schema

ExternalSchema B

ExternalSchema A

ExternalSchema C

Internal Level

(Storage View)

Conceptual View

(Common User View)

External / View Level

(Individual User View)


Detailed System Architecture

16

Storagestructuredefinition(InternalSchema)

Conceptual / Internal mapping

Conceptual view

External / conceptual mapping

External View A External View B

Mike (User)

Graham(User)

Jack(User)

Justin(User)

ExternalSchemas

Conceptual Schema

Database ( Internal view)

Database Administrator(DBA)

Schemas & mappings built& maintained by the DBA

DBMS


An example of the three levels

17


Users of a DBMS

Database Administrator (DBA) Managing information contents Liaison with users Enforcing security and integrity rules Strategizing backup & recovery Monitoring performance

Database designers

Application programmers

End users

18


Advantages of a DBMS

Data independence

Reduction in data redundancy

Better security

Better flexibility

Effective data sharing

Enforces integrity constraints

Enables backup and recovery


Data Models

Definition of data model :

A conceptual tool used to describe :

Data

Data relationships

Data semantics

Consistency constraints

20


Types of data models

Object based logical model

Entity relationship model

Record based logical model

Hierarchical data model

Network data model

Relational data model


Record based data model – Hierarchical data model

101 Smith MikeA. 1020 Savings Downtown [email protected]

1011 8755.00

2010 2555.00 2015 2000.00

102 Smith GrahamS. 2348 Checking Bridgewater [email protected]

ROOT

1011 8755.00

103 Langer JustinG. 3421 Savings Plainsboro [email protected]

E.g.: Information Management System (IMS) from IBM


Record based data model – Network data model

101 Smith MikeA. 1020 Savings Downtown [email protected] 1011 8755.00

102 Smith GrahamS. 2348 Checking Bridgewater [email protected]

103 Langer JustinG. 3421 Savings Plainsboro [email protected]

104 Quails JackD. 2367 Checking Downtown [email protected]

105 Jones SimonE. 2389 Checking Brighton [email protected]

2010 2555.00

2056 3050.00

2015 2000.00

E.g.: Integrated Data Management System(IDMS) from Honeywell


Record based data model – Relational data model


Relational model basics Data is viewed as existing in two dimensional tables known as relations

A relation (table) consists of unique attributes (columns) and tuples (rows)

Sometimes the value to be inserted into a particular cell may be unknown, or it may have no value. This is represented by a NULL

Null is not the same as zero, blank or an empty string

Relational Database: Any database whose logical organization is based on relational data model.

RDBMS: A DBMS that manages the relational database.


Keys in relational model

Candidate keyA Candidate key is a set of one or more attributes(minimal) that can uniquely identify a row in a given table.

Primary Key During the creation of the table, the Database Designer chooses one of the Candidate Key from amongst the several available, to uniquely identify row in the given table.

Alternate KeyThe candidate key that is chosen to perform the identification task is called the primary key and the remaining candidate keys are known as alternate keys.

No of Alternate Keys = No of Candidate Keys - 1


Key and Non-key Attributes in Relational Model

Key AttributesThe attributes that participate in the Candidate key are Key attributes

Non-Key Attributes The attributes other than the Candidate Key attributes in a table/relation are

called Non-Key attributes.OR

The attributes which do not participate in the Candidate key.


Example

Given a relation Trainee(Empno, FirstName, LastName, Email, PhoneNo)

Assumptions:i. Empno for each trainee is different.ii. Email for each trainee is differentiii. PhoneNo for each trainee is differentiv. Combination of FirstName and LastName for each trainee is different

Candidate key: {Empno},{Email},{PhoneNo},{FirstName,LastName}

Primary key: {Empno}

Alternate Key: {Email},{PhoneNo},{FirstName,LastName}


Exercise on Key attributes

Given a relation R1(X,Y,Z,L) and the following attribute(s) can uniquely identify the records of relation R1.

1)X 2)X,L 3)Z,L

Identify the following in relation R1?

Candidate Key(s) Primary Key Alternate Key Key attribute(s) Non-key attribute(s)


What are the candidate keys?

30

Cust_ID Cust_Last_Name

Account_No

Bank_Branch Cust_Email

101Smith 1020 Downtown [email protected]

105Jones 2389 Brighton [email protected] 2367 Downtown [email protected] 3421 Plainsboro [email protected] 2348 Bridgewater [email protected]

Account_Type

SavingsCheckingSavingsCheckingChecking

Cust_Mid_Name

A.S.G.D.E.

Cust_First_Name

MikeGrahamJustinJackSimon

Customer_Detail records from Customer_Details table

while deciding the Candidate key do not get misguided by the

data present in the table.

Case 1Assumptions

One customer can have only one account

An account can belong to only one customer




Account_No




Account_Type


Cust_Mid_Name

A.S.G.D.E.

Cust_First_Name



Case 2Assumptions

One customer can have many accounts

An account can belong to only one customer



32


Account_No




Account_Type


Cust_Mid_Name

A.S.G.D.E.

Cust_First_Name



Case 3 :

Assumptions

One customer can have many accounts.

An account can belong to more than one customer (joint account)


Choosing a Primary key from Candidate keys -Guidelines

Give preference to numeric column(s) Give preference to single attribute Give preference to minimal composite key

Primary Key of the table, Customer_Details


Account_No




Account_Type


Cust_Mid_Name

A.S.G.D.E.

Cust_First_Name




Foreign Key Foreign key

• A Foreign Key is a set of attribute (s) whose values are required to match values of a column in the same or another table.

DEPT EMP(Parent /Master/Referenced Table) (Child /Referencing Table)

Points to remember Foreign key values do not (usually) have to be unique. Foreign keys can also be null . To enter the data in child table corresponding data must be present in master table or

NULL is the default entry in child table in the referenced column ( FK column)

DeptNo DNameD1 IVS

D2 ENR

EmpNo EName EDeptNo1001 Elsa D11002 John D21003 Maria Null1004 Maida D1


Foreign Key

Foreign key

Points to remember A Foreign Key is a set of attributes of a table, whose values are

required to match values of some Candidate Key in the same or another table

Foreign Key column must match the values of the corresponding Candidate Key column. This is known as Referential constraint.

A table which has a Foreign Key referring to its own Candidate Key is known as Self-Referencing table

Demos



DATABASE DESIGN TECHNIQUE

36


Database Design Techniques

Top down Approach

In Top down approach we start defining the data set and then we go on defining data elements in those sets. This approach generally leads to redundant information in one or more table.

Some references call this Entity - Relationship modeling.

Bottom Up approachIn Bottom up approach we start defining required attribute first and then group these attribute to form the entities. Another term used for this method isnormalization from functional dependencies.



ER MODELING -TOP DOWN APPROACH

38


ER modeling ER modeling: A graphical technique for understanding and organizing the

data independent of the actual database implementation.

Entity: Any thing that may have an independent existence and about which we intend to collect data. also known as Entity type. e.g.: Trainee

Relationships: Associations between entities. e.g.: Trainee belongs to a Batch

Attributes: Properties/characteristics that describe entities. e.g.: Trainee Name, BatchName, DOB, Address, etc.


Entity Types

Regular Entity: Entity that has its own key attribute (s).

e.g.: Employee, student ,customer, policy holder etc.

Weak entity: Entity that depends on other entity for its existence and doesn’t have key attribute (s) of its own

e.g. : spouse of employee


Attributes The set of possible values for an attribute is called the domain of

the attributee.g.:

1. The domain of attribute marital status is having four values: single, married, divorced or widowed.

2. The domain of the attribute month is having twelve values ranging from January to December.

Key attribute: The attribute (or combination of attributes) that is unique for every entity instance e.g.: the account number of an account, the employee id of an

employee etc.


Attributes Types

Types of Attributes Definition ExampleSimple attribute Cannot be divided into simpler

components Gender of the employee

Composite attribute Can be split into components Address of the employee

Single valued Can take on only a single value for each entity instance

Age of the employee

Multi-valued Can take up many values Skill set of the employee

Stored Attribute Attribute that need to be stored permanently

Date of joining of the employee

Derived Attribute Attribute that can be calculated based on other attributes.

Years of service of the employee


Degree of a Relationship

Degree: the number of entity types involved» One Unary» Two Binary» Three Ternary

e.g.: 1. employee manager-of employee is unary

2. employee works-for department is binary

3. Customer purchases items from a shop keeper» Here customer purchase item, shop keeper is a ternary

relationship


Cardinality

Relationships can have different connectivity one-to-one (1:1) one-to-many (1:N) many-to-one (M:1) many-to-many (M:N)

e.g.: Employee head-of department (1:1)

Lecturer offers course (1:N) assuming a course is taught by a single lecturer

Student enrolls course (M:N)


Relationship Participation

Total : Every entity instance must be connected through the relationship to another instance of the other participating entity types

Partial: All instances need not participate

e.g.: Employee Head-of DepartmentEmployee: partialDepartment: total

45



ER MODELING - NOTATIONS


ER Modeling -Notations

Entity An Entity can be defined as an object or concept about which user wants to store information.

EntityA weak Entity requires another Entity for it’s existence. Example Order Item depends upon Order Number for its existence. Without Order Number it is impossible to identify Order Item uniquely.

Attribute Properties or characteristics of an Entity is called Attributes of entity

AttributeIf an attribute is the unique or distinguishing characteristic of the Entity it is called Key Attribute

AttributeAttribute

If an attribute can have more than one value then it is called multi-valued attribute.For example, an employee Entity can have multiple skill values.



AttributeIf the value of an attribute can be derived from another attribute it is called derived attribute. For example, an employee's monthly salary is based on the employee's basic salary and House rent allowance.

RelationshipRelationships in ER Diagram illustrate how two entities of database share information.

RelationshipRelationshipWe connect a weak entity through a strong entity using a weak relationship notation.



Cardinality of relationship tells how many instances of an Entity type is relate to one instance of another Entity Type. M,N both represent ‘MANY’ and 1 represents ‘ONE’ Cardinality

Employee

An entity can be self linked. For example, employees can supervise other employees

Customer

Account Transaction

1

N

1 M

http://www.smartdraw.com/tutorials/software-erd/erdcardinality.htm


Composite attribute

EmployeeE#

NameDOB

Address

Designation

floor building


Unary Relationship

EmployeeManages


Role names

Role names may be added to make the meaning more explicit

M

1

EmployeeManages

Manager

subordinate


Binary Relationship

Employee Works for

DepartmentM 1


Ternary Relationship

Doctor

Medicine

PatientPrescription


Relationship participation

departmentEmployee headof

1 1

partial Total


Attributes of a Relationship

Doctor

Medicine

PatientPrescription

dosage

Number of days


Weak entity

Employee

E#

has dependant

Id----

1 N

name

The dependant entity is represented by a double lined rectangle and the identifying relationship by a double lined diamond


Assumptions :

A college contains many departments Each department can offer any number of courses Many instructors can work in a department An instructor can work only in one department For each department there is a Head An instructor can be head of only one department Each instructor can take any number of courses A course can be taken by only one instructor A student can enroll for any number of courses Each course can have any number of students

Case Study – ER Model For a college DB


Steps in ER Modeling Identify the Entities

Find relationships

Identify the key attributes for every Entity

Identify other relevant attributes

Draw complete E-R diagram with all attributes including Primary Key

Review your results with your Business users

59


Step 1: Identify the Entities

DEPARTMENT

STUDENT

COURSE

INSTRUCTOR

Steps in ER Modeling



Step 2: Find the relationships

One course is enrolled by multiple students and one student enrolls for multiple courses, hence the cardinality between course and student is Many to Many.

M N

The department offers many courses and each course belongs to only one department, hence the cardinality between department and course is One to Many.

1 M

One department has multiple instructors and one instructor belongs to one and only one department , hence the cardinality between department and instructor is one to Many.

1 M

COURSE STUDENTENROLLED BY

DEPARTMENT COURSEOFFERS

DEPARTMENT INSTRUCTORHAS



Step 2: Find the relationships(Cont..)

Each department there is a “Head of department” and one instructor is “Head of department “,hence the cardinality is one to one .

1 1

One course is taught by only one instructor, but the instructor teaches many courses, hence the cardinality between course and instructor is many to one.

M 1

DEPARTMENT INSTRUCTORHEADED BY

COURSE INSTRUCTOROFFERS


Step 3: Identify the key attributes

Deptname is the key attribute for the Entity “Department”, as it identifies the Department uniquely.

Course# (CourseId) is the key attribute for “Course” Entity. Student# (Student Number) is the key attribute for “Student” Entity. Instructor Name is the key attribute for “Instructor” Entity.

Step 4: Identify other relevant attributes

For the department entity, the relevant attribute is location For course entity, course name, duration,prerequisite For instructor entity, room#, telephone# For student entity, student name, date of birth



ER diagram for the University


Step 5: Draw the E-R diagram


Case Study – Online Retail Application(self study)

Draw an ER diagram of Online Retail Application which allows customer to purchase items from a Retail shop.

A customer can register to purchase an item. The customer will provide bank account number and bank name ( the customer may have multiple account no ).

After registration each customer will have unique customer Id, user id and password.

Customer can purchase one or more items in different quantities . The items can be of different classes based on their prices.

Based on the quantity , price of item and discount(if any) on the purchased items, the bill will be generated. A bank account number is required to settle the bill.

The application also mentions the information of suppliers who supply the items to the retail shop. The retail shop may give orders to supply the items based on some statistics they maintain about different items.

65


Step 1: Identify the Entities

CUSTOMER

ITEM

SUPPLIER

BILL

Steps in ER Modeling (self study)


Step 2: Find the relationships

Customer can purchase an item and each purchase will be corresponding to a bill. So it is a ternary relation ship.

Items can be ordered to one or more suppliers. One supplier may take order of many items. So many to many relationship between item and supplier.

One customer can pay many bill and one bill can be paid by only one customer. So one to many relation ship between customer and bill.

Steps in ER Modeling(self study)


Step 3: Identify the key attributes

Customer entity will be identified by CustomerId Item entity will be identified by ItemId Supplier entity will be identified by SupplierId Bill entity will be identified by BillId




Step 4: Identify other relevant attributes of Entities and Relationships

For Customer entity the relevant attributes will be (CustomerId,CustomerName, DateOfRegistration, UserId, Password, AccountNo)

For Item entity the relevant attributes will be (ItemId, ItemName, UnitOfMeasurement, UnitPrice, Discount, QuantityOnHand, SupplierId,ReOrderLevel,ReOrderQuantity,Class)

For Supplier entity the relevant attributes will be (SupplierID, SupplierName, SupplierContactNo)

For Bill entity the relevant attributes will be ( BillId, AccountNo, BillAmount, BillDate)



Step 4: Identify other relevant attributes of entities and Relationships (Cont..)

For Purchase Relation the relevant attributes will be (QtyPurchased, NetPrice)

For OrderedTo relation the relevant attributes will be (OtyOfOrder, OrderDate, DeliveryDate, DeliveryStatus)

For Pays relation the relivent attributes will be (AccountNo)


Step 5:

Draw complete E-R diagram with all attributes

Steps in ER Modeling (self study)

Microsoft Office Word Document


Merits and Demerits of ER Modeling

Merits Easy to understand. Represented in Business Users Language. Can be

understood by non-technical specialist. Intuitive and helps in Physical Database creation. Can help in database design. Gives a higher level description of the system.

Demerits Physical design derived from E-R Model may have some amount of

redundancy which may lead to inconsistency. (This will be discussed when we study Normalization on day two)

Sometime diagrams may lead to misinterpretations because of limited information present in the diagram.

72


Summary of ER Modeling Miscommunication between the application user and the designer is the major source

of error.

It is always better to represent business findings in terms of picture to avoid miscommunication

It is practically impossible to review the complete requirement document by business users.

An E-R diagram is one of the many ways to represent business findings in pictorial format.

E-R Modeling will also help the database design

E-R modeling has some amount of inconsistency and anomalies associated with it.

73


Summary

Traditional File Approach Advantages of a DBMS Three layers of abstraction Users of DBMS Database Models Types of Databases Relational Model Basics Keys Conceptual Design

ER Modelling ER Modelling Notations ERD Case study Merits & Demerits of ER Modeling

74

Copyright © 2008, Infosys Technologies Ltd. ConfidentialConfidential75

Thank You

“The contents of this document are proprietary and confidential to Infosys Technologies Ltd. and may not be disclosed in whole or in part at any time, to any third party without the prior written consent of Infosys Technologies Ltd.”

“© 2008 Infosys Technologies Ltd. All rights reserved. Copyright in the whole and any part of this document belongs to Infosys Technologies Ltd. This work may not be used, sold, transferred, adapted, abridged, copied or reproduced in whole or in part, in any manner or form, or in any media, without the prior written consent of Infosys Technologies Ltd.”

Slides Rdbmscore Db92 01

Documents

specific written

prior written

leverage knowledge

custemail

represent

database design

foreign key

business users