Professional Documents
Culture Documents
Relational Database Management System
Relational Database Management System
Course Objectives
To introduce basic RDBMS concepts To create familiarity with SQL To introduce the concept of transaction processing and discuss certain issues in the same
Day2
Transforming an ER model to Relational Schema Functional Dependencies Normalization
Day3
Introduction to SQL and SQL Plus DDL DML (Till Order By) Aggregate Functions
Session Plan (2 of 3)
Day 4
Group By and Having, Relational Algebra Joins Independent Sub Queries Use of EXISTS and NOT EXISTS
Day 5
Correlated Sub queries + Exists Views DCL + Embedded SQL
Day 6
Transaction, OLTP, ACID Serial Transactions and Serializability Issues of Concurrency Locking
Session Plan (3 of 3)
Day 7
Time Stamping Immediate Update + Deferred Update + Check Point Difference between OLTP and OLAP OLAP Data Ware Housing Data Mart Summary
References
Database system concepts, Henry F Korth, Abraham Silberschatz, Second ed., McGraw-Hill International editions, Computer Science Series(1991) "Fundamentals of Database Systems", Elmasri, Navathe, Third ed, Addison Wesley "An introduction to Database Systems", C.J.Date, Sixth ed., Narosa Publications
RDBMS-Day1
Data Processing Basic DBMS concepts Basic RDBMS concepts Conceptual Database Design ER Modeling Notations
Data processing
Data Collection Recording Sorting Classifying Calculating Retrieving Summarizing Communicating
File System
Customer_Details.dat
Customer_Loan.dat
Customer_Fixed_Deposit.dat
Customer_Transaction.dat
Predefined length
AniruddhaSarkar SBU1 ManojSaha SBU1 MoushumiDharchoudhury SBU1 SuryanarayanaD.V.S. SBU1 Vivek Rai SBU1
Data Security
Data Redundancy Data Isolation Program / Data Dependence Lack of Flexibility Concurrent Access Anomalies
Database Management System Collection of interrelated files and set of programs which allows 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
DBMS
File System
Bank Database
DBMS
Types of Databases
Tokyo Workstation
Telecom Line, LAN or Direct Line ATM
Database server
ATM
Network
Server
Database Server
Database Server
ATM
Chicago
Workstation Workstation
ATM
Centralized Database
Distributed Database
TYPES OF DATABASES
Centralized
All data is located at a single site Allows for greater control over accessing and updating data Vulnerable to failure as they depend on the availability of resources at the central site Example: The account information of customers is stored in a particular branch office of a bank. This information must be shared across all Automated Teller Machines (ATM), so that customers can withdraw money from their accounts. Instead of storing the customer information in every ATM machine it can be stored at a common place (the branch office of the bank) and shared over a network.
Distributed
The database is stored on several computers - from personal computers up to mainframe systems Computers in a distributed system communicate with one another through various communication media, such as high speed networks or telephone lines Distributed databases are geographically separated and managed Distributed databases are separately administered Distributed databases have a slower interconnection Example: Consider the bank system. The banks head office is located at Chicago and the branch offices are at Melbourne and Tokyo. The bank database is distributed across the branch offices. The branch offices are connected through a network
ER/CORP/CRS/DB07/003 Version No: 2.0
Three-layer Architecture
External / View Level
(Individual User View)
External Schema A
External Schema B
External Schema C
Conceptual Schema
Internal Schema
External Schemas
External View A
External View B
DBMS
Conceptual Schema
Conceptual view
Customer_Loan Cust_ID : 101 Loan_No : 1011 Amount_in_Dollars : 8755.00 CREATE TABLE Customer_Loan ( Cust_ID NUMBER(4) Loan_No NUMBER(4) Amount_in_Dollars NUMBER(7,2)) Cust_ID Loan_No Amount_in_Dollars TYPE = BYTE (4), OFFSET = 0 TYPE = BYTE (4), OFFSET = 4 TYPE = BYTE (7), OFFSET = 8
External
Conceptual
Internal
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
Advantages of a DBMS
Data independence Reduction in data redundancy
Better security
Better flexibility Effective data sharing
Data Models
Definition of data model :
A conceptual tool used to describe Data Data relationships Data semantics Consistency constraints
1011 8755.00 1011 8755.00 103 Langer G. Justin 3421 Savings Plainsboro [email protected]
2010 2555.00
2015 2000.00
102 Smith S. Graham 2348 Checking Bridgewater [email protected] 2010 2555.00 103 Langer G. Justin 3421 Savings Plainsboro [email protected] 2015 2000.00 104 Quails D. Jack 2367 Checking Downtown [email protected] [email protected] 2056 3050.00
Cust_ID Cust_Last_ Cust_Mid Cust_First Account Account_ Bank_Branch Name _Name _Name _No Type 101Smith A. Mike 1020Savings Downtown 102Smith S. Graham 2348Checking Bridgewater 103Langer G. Justin 3421Savings Plainsboro 104Quails D. Jack 2367Checking Downtown 105Jones E. Simon 2389Checking Brighton Customer_Detail records from Customer_Details table
Keys
Candidate key
A Candidate key is a set of one or more attributes that can uniquely identify a row in a given table.
Cust_ID Cust_Last_ Cust_Mid Cust_First Account Account_ Bank_Branch Name _Name _Name _No Type 101Smith A. Mike 1020Savings Downtown 102Smith S. Graham 2348Checking Bridgewater 103Langer G. Justin 3421Savings Plainsboro 104Quails D. Jack 2367Checking Downtown 105Jones E. Simon 2389Checking Brighton Customer_Detail records from Customer_Details table
Assumptions One customer can have only one account An account can belong to only one customer
Keys
Super key
Any superset of a candidate Key is a super key.
Keys
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.
Primary Key of the table, Customer_Details
Cust_ID Cust_Last_ Cust_Mid Cust_First Account Account_ Bank_Branch Name _Name _Name _No Type 101Smith A. Mike 1020Savings Downtown 102Smith S. Graham 2348Checking Bridgewater 103Langer G. Justin 3421Savings Plainsboro 104Quails D. Jack 2367Checking Downtown 105Jones E. Simon 2389Checking Brighton Customer_Detail records from Customer_Details table
Give preference to numeric column(s) Give preference to single attribute Give preference to minimal composite key
Keys
Foreign key
A Foreign Key is a set of attribute (s) whose values are required to match values of a Candidate key in the same or another table.
Prerequisite is the Foreign Key referencing Course_ID
Course_ID
Duration_in_ Prerequisite Days 121Computer Hardware & System Software Concepts 4 NULL 122Programming Fundamentals 7 121 123Relational Database Management System 7 122 124User Interface Design 1 122 125Object Oriented Concepts 1 122
Course_Title
Point 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 The constraint that values of a given Foreign Key must match the values of the corresponding Candidate Key is known as Referential constraint A table which has a Foreign Key referring to its own Candidate Key is known as SelfReferencing table Any superset of a Candidate Key is a Super Key The attributes other than the Primary Key attributes in a table/relation are called Non-Key attributes
Keys
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 any of the Candidate keys..
Conceptual
design
Bottom Up approach
Normalization
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.
Entity instance: a particular member of the entity type e.g. a particular student Attributes: Properties/characteristics that describe entities Relationships: Associations between entities
Attributes
The set of possible values for an attribute is called the domain of the attribute Example:
The domain of attribute marital status is just the four values: single, married, divorced, widowed The domain of the attribute month is the 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.
If the key consists of two or more attributes in combination, it is called a composite key
Weak entity: Entity that depends on other entity for its existence and doesnt have key
attribute of its own E.g. : spouse of employee
Relationships
A relationship type between two entity types defines the set of all associations between these entity types
Each instance of the relationship between members of these entity types is called a relationship instance
Degree of a Relationship
Degree: the number of entity types involved
One Two Three Unary Binary Ternary
E.g.: employee manager-of employee is unary employee works-for department is binary customer purchase item, shop keeper is a ternary relationship
Cardinality
Relationships can have different connectivity
one-to-one one-to-many many-to- One many-to-many (1:1) (1:N) (M:1) (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)
P1 P2 P3 P4
C1 C2 C3 C4
Person
Chair
One instance of entity type Person is related to one instance of the entity type Chair.
Organization
Employee
One instance of entity type Organization is related to multiple instances of entity type Employee
Cardinality Many-to-One
E1 E2 E3 E4 E5
D1 D2 D3
Employee
Department
Cardinality Many-to-Many
S1 S2 S3 S4
C1 C2 C3 C4
Student
Course
Multiple instances of one Entity are related to multiple instances of another Entity.
Copyright 2004, # Infosys Technologies Ltd
ER/CORP/CRS/DB07/003 Version No: 2.0
Relationship Participation
Total : Every entity instance must be connected through the relationship to another
instance of the other participating entity types
ER Modeling -Notations
ER Modeling -Notations
An Entity is an object or concept about which business user wants to store information. A weak Entity is dependent on another Entity to exist. Example Order Item depends upon Order Number for its existence. Without Order Number it is impossible to identify Order Item uniquely. Attributes are the properties or characteristics of an Entity
A multivalued attribute can have more than one value. For example, an employee Entity can have multiple skill values.
ER Modeling -Notations
A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's basic salary and House rent allowance.
Relationships illustrate how two entities share information in the database structure.
To connect a weak Entity with others, you should use a weak relationship notation.
ER Modeling -Notations
Cardinality specifies how many instances of an Entity relate to one instance of another Entity. M,N both represent MANY and 1 represents ONE Cardinality
In some cases, entities can be self-linked. For example, employees can supervise other employees
Attributes
DOB Name Address
E#
Employee
Designatio n
Key attribute
DOB Name Address
E#
Employee
Designatio n
Multivalued Attribute
DOB Name Designatio n Employee skill set
Address
E#
Composite attribute
floor
building
E#
Employee
Designatio n
Relationship
student
enrols in
course
Unary Relationship
Employee
Manages
Role names
Role names may be added to make the meaning more explicit
subordinate
Employee
Manager
Manages
Binary Relationship
Employee
Works for
Department
Ternary Relationship
Medicine
Doctor
Prescription
Patient
Relationship participation
Employee
head of
department
Attributes of a Relationship
Medicine
Doctor
Prescription
Patient
Weak entity
E#
id
name
Employee
has
dependant
The dependant entity is represented by a double lined rectangle and the identifying relationship by a double lined diamond
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
The department offers many courses and each course belongs to only one department, hence the cardinality between department and course is One to Many.
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. Each department there is a Head of department and one instructor is Head of department ,hence the cardinality is one to one . 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.
ER/CORP/CRS/DB07/003 Version No: 2.0
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
Step 5: Draw complete E-R diagram with all attributes including Primary Key
Department Name Location
Department
Pre Requisite
1 Offers
1 Headed by
1 Has
Course Name
Room#
Enrolled by
Student#
Student Name
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
Step 5: Draw complete E-R diagram with all attributes including Primary Key
Name Bank Code Address
Bank 1
has
Offers Loan#
Loan
Account
Loan Type
Availed By N
M Held By
Account Type
N Customer
Customer#
Address
Name
Telephone#
Summary
Most of the application errors are because of miscommunication between the application user and the designer and between the designer and the developer. 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.
Thank You!