Date post: | 26-Nov-2015 |
Category: |
Documents |
Upload: | pitchairaj-bhuvaneswari |
View: | 50 times |
Download: | 0 times |
1
Relational Database Management Systems
Welcome to this course on Relational Database Management Systems!
2
ER/CORP/CRS/DB07/003
Version No: 2.02Copyright © 2004,
Infosys Technologies Ltd
Course Objectives
To introduce basic RDBMS concepts
To create familiarity with SQL
To create familiarity with Embedded-SQL
To introduce the concept of transaction processing and discuss certain issues in the same.
3
ER/CORP/CRS/DB07/003
Version No: 2.03Copyright © 2004,
Infosys Technologies Ltd
Session Plan (1of 3)
Day1–Data Processing–Basic DBMS concepts–ER modeling
Day2–ER modeling continued–Extended ER features–Logical database design–Functional dependencies–Normalization–Denormalization
Day3–DDL–DML–Aggregate functions
4
ER/CORP/CRS/DB07/003
Version No: 2.04Copyright © 2004,
Infosys Technologies Ltd
Session Plan (2 of 3)
Day 4– Grouped results– Sub queries– Relational algebra– Use of EXISTS and NOT EXISTS
Day 5
– Views– Concept of an index– Embedded SQL
Day 6– Transaction processing concepts– OLTP– Database integrity– Security– Concurrency
5
ER/CORP/CRS/DB07/003
Version No: 2.05Copyright © 2004,
Infosys Technologies Ltd
Session Plan (3 of 3)
Day 7– Concurrency continued– Database Recovery– Log file– Deferred Database update– Immediate Database update
6
ER/CORP/CRS/DB07/003
Version No: 2.06Copyright © 2004,
Infosys Technologies Ltd
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., NarosaPublications
7
RDBMS-Day1Data ProcessingBasic DBMS conceptsBasic RDBMS conceptsConceptual Database DesignER Modeling Notations
8
ER/CORP/CRS/DB07/003
Version No: 2.08Copyright © 2004,
Infosys Technologies Ltd
Data Processing
Data collection
Recording
Sorting
Classifying
Calculating
Storing & retrieving
Summarizing
Communicating
9
ER/CORP/CRS/DB07/003
Version No: 2.09Copyright © 2004,
Infosys Technologies Ltd
Data Processing modes
� Batch processing :
� Transactions are collected in a group & processed together.
� On-line (interactive) processing :
� Transactions are processed as & when they appear.
� Real-time processing :
� It is a parallel time relationship with on-going activity & the information produced is useful in controlling the current/dynamic activity.
10
ER/CORP/CRS/DB07/003
Version No: 2.010Copyright © 2004,
Infosys Technologies Ltd
Traditional Method of Storage Traditional Method of Storage
ApplicationPrograms
File System
FilesA B C D
•In the traditional approach, we used to store information in flat files which are maintained by the file system under the operating system’s control.
•Application programs go through the file system to access these flat files
11
ER/CORP/CRS/DB07/003
Version No: 2.011Copyright © 2004,
Infosys Technologies Ltd
Ways of storing data in files
4176 Aniruddha Sarkar SBU14181 Manoj Saha SBU14183 Moushumi Dharchoudhury SBU14203 Suryanarayana D.V.S.S. SBU14204 Vivek Rai SBU1
4176 AniruddhaSarkar SBU14181 ManojSaha SBU14183 MoushumiDharchoudhury SBU14203 SuryanarayanaD.V.S. SBU14204 Vivek Rai SBU1
Predefined length
•Data used to be stored in the form of records in the files.
•Records consist of various fields which are delimited by a space , comma , tab etc.
•There used to be special characters to mark end of records and end of files.
12
ER/CORP/CRS/DB07/003
Version No: 2.012Copyright © 2004,
Infosys Technologies Ltd
DATADEPENDENCY
INCONSISTENCY
REDUNDANCY
LOSS OFFLEXIBILITY
MULTIPLEFILES
UPDATEPROBLEM
Problems:Traditional approach
•Data spread across multiple files where dependent on each other . This led to loss of flexibility. Since data was spread across multiple files and there was no formal way of maintaining relationships between these files, the same information was repeated in multiple files. This led to redundancy.
•When a particular data had to be updated , say for example, an employee’s information to be deleted, it has to be done in all the files where the employee data occurs. If the deletion is missed out on even one of the files, it would leave the data inconsistent.
13
ER/CORP/CRS/DB07/003
Version No: 2.013Copyright © 2004,
Infosys Technologies Ltd
The Database Technology
Database
Computer based record-keeping systemCollection of interrelated (persistent) dataRecords & maintains data
Database Management System
Collection of files that contain related data
Managed by a specialized piece of software known as a database
management system (DBMS)
Layer of abstraction between the application programs and the file system
•Application programs request the DBMS to retrieve, modify, insert or delete data for them
14
ER/CORP/CRS/DB07/003
Version No: 2.014Copyright © 2004,
Infosys Technologies Ltd
Where does the RDBMS fit in?
File System interface DBMS interfacePosition of DBMS
• Now, the DBMS acts as a layer of abstraction on top of the File system.
• You might have observed that, for interacting with the file system, we were using high level language functions for example, the ‘c’ file handling functions. For interacting with the DBMS we would be using a Query language called SQL
15
ER/CORP/CRS/DB07/003
Version No: 2.015Copyright © 2004,
Infosys Technologies Ltd
Conceptual layer
Internal layer
ExternalView
ExternalView
ExternalView
DBMS interface
DBMS interface
Three-layer Architecture
Services provided by a DBMS
•Data management
•Data definition
•Transaction support
•Concurrency control
•Recovery
•Security & integrity
•Utilities- facilities like data import & export, user management, backup, performance analysis, logging & audit, physical storage control
16
ER/CORP/CRS/DB07/003
Version No: 2.016Copyright © 2004,
Infosys Technologies Ltd
Advantages of a DBMS
Data independenceReduction in data redundancyBetter securityBetter flexibilityEffective data sharing
1. Users and application programs need not know exactly where or how the data is stored in order to access it
2. Proper database design can reduce or eliminate data redundancy and confusion
3.Support for unforeseen (ad hoc) information requests are better supported - better flexibility
4. Data can be more effectively shared between users and/or application programs
Data can be stored for long term analysis (data warehousing)
17
ER/CORP/CRS/DB07/003
Version No: 2.017Copyright © 2004,
Infosys Technologies Ltd
Users of a DBMS
Database Administrator (DBA)– Managing information contents– Liaison with users– Enforcing security and integrity rules– Strategizing backup & recovery– Monitoring performance
Database designersApplication ProgrammersEnd users
•DBA is a key person and takes care of most administrative tasks as mentioned in the slide
•Database designers, design the database elements
•Application programmers, make use of the various database elements and write programs to retrieve data from them
•End users use the DBMS
18
ER/CORP/CRS/DB07/003
Version No: 2.018Copyright © 2004,
Infosys Technologies Ltd
Hierarchical Model Network ModelRelational ModelObject-Oriented
Database Technologies
Commercial Packages
•Hierarchical Model - IMS
•Network Model - IDMS
•Relational Model - Oracle, DB2
19
ER/CORP/CRS/DB07/003
Version No: 2.019Copyright © 2004,
Infosys Technologies Ltd
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)
Tuples are unique
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.
•Though logically data is viewed as existing in the form of two dimensional tables, actually, the data is stored under the file system only.
•The RDBMS provides an abstraction on top of the file system and gives an illusion that data resides in the form of tables.
20
ER/CORP/CRS/DB07/003
Version No: 2.020Copyright © 2004,
Infosys Technologies Ltd
A sample relation
Emp table
18,40023Hari1098
14,00022Raj1067
19,00025Shyam1049
25,000
Salary
23
Age
Ram
EmpName
1023
E#
Attributes
tuples
21
ER/CORP/CRS/DB07/003
Version No: 2.021Copyright © 2004,
Infosys Technologies Ltd
Keys
Super keyCandidate keyPrimary keyForeign key
Superkey
An attribute, or group of attributes, that is sufficient to distinguish every tuple in the relation from every other one.
Each super key is called a candidate key
A candidate key is all those set of attributes which can uniquely identify a row. However, any subset of these set of attributes would not identify a row uniquely
For example, in a shipment table, “S# , P# ” is a candidate key. But, S# alone or P# alone would not uniquely identify a row of the shipment table.
Primary key
The candidate key that is chosen to perform the identification task is called the primary key and any others are alternate keysEvery tuple must have, by definition, a unique value for its primary key. A primary key which is a combination of more than one attribute is called a composite primary key
Foreign key•A foreign key is a “copy” of a primary key that has been exported from one relation into another to represent the existence of a relationship between them. A foreign key is a copy of the whole of its parent primary key i.e if the primary key is composite, then so is the foreign key•Foreign key values do not (usually) have to be unique•Foreign keys can also be null•A composite foreign key cannot have some attribute(s) null and others non-null
Overlapping candidate keys : Two candidate keys overlap if they involve any attribute in common. For e.g, in an Employee table, E#,Enameand Emailid, Ename are two overlapping candidate keys. (they have Ename in common)
Attribute that does not participate in any candidate key is called a Non-key attribute
22
Conceptual design
Entity Relationship modeling
23
ER/CORP/CRS/DB07/003
Version No: 2.023Copyright © 2004,
Infosys Technologies Ltd
Data modeling
Study of basic properties and inter-relationshipsamong data items to properly represent them in the basic data structures of a database
Two popular techniques: ER modeling and Normalization
24
ER/CORP/CRS/DB07/003
Version No: 2.024Copyright © 2004,
Infosys Technologies Ltd
Design levels of a database
Conceptual design
Logical design
Physical database design
The outcome of each stage is correspondingly called the conceptual schema, the database schema and the physical design
25
ER/CORP/CRS/DB07/003
Version No: 2.025Copyright © 2004,
Infosys Technologies Ltd
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 whichwe 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
26
ER/CORP/CRS/DB07/003
Version No: 2.026Copyright © 2004,
Infosys Technologies Ltd
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
27
ER/CORP/CRS/DB07/003
Version No: 2.027Copyright © 2004,
Infosys Technologies Ltd
Simple Vs composite attribute
Simple attribute : cannot be divided into simpler components
E.g age of an employee
Composite attribute : can be split into components
E.g Date of joining of the employee.
» Can be split into day, month and year
28
ER/CORP/CRS/DB07/003
Version No: 2.028Copyright © 2004,
Infosys Technologies Ltd
Single Vs Multi-valued Attributes
Single valued : can take on only a single value for each entity instance
E.g. age of employee. There can be only one value for this
Multi-valued : can take many values
E.g. skill set of employee
29
ER/CORP/CRS/DB07/003
Version No: 2.029Copyright © 2004,
Infosys Technologies Ltd
Stored Vs Derived attribute
Stored Attribute : Attribute that need to be stored permanently.
• E.g. name of an employee
Derived Attribute : Attribute that can be calculated based on other attributes
.• E.g. : years of service of employee can be calculated from date of
joining and current date
30
ER/CORP/CRS/DB07/003
Version No: 2.030Copyright © 2004,
Infosys Technologies Ltd
Regular Vs. Weak entity type
Regular Entity : Entity that has its own key attribute.
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 of its own
E.g. : spouse of employee
The spouse data is identified with the help of the employee id to which it is related
31
ER/CORP/CRS/DB07/003
Version No: 2.031Copyright © 2004,
Infosys Technologies Ltd
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
E.g if Works-for is the relationship between the Employee entity and the department entity, then Ram works for Comp.sc department, shyam works –for electrical department ..etc are relationship instances of the relationship, works-for
32
ER/CORP/CRS/DB07/003
Version No: 2.032Copyright © 2004,
Infosys Technologies Ltd
Degree of a Relationship
Degree : the number of entity types involved• One Unary• Two Binary• Three Ternary
E.g employee manager-of employee is unaryemployee works-for department is binarycustomer purchase item, shop keeper is a ternary relationship
33
ER/CORP/CRS/DB07/003
Version No: 2.033Copyright © 2004,
Infosys Technologies Ltd
Cardinality
Relationships can have different connectivity– one-to-one (1:1)
– one-to-many (1:N)– many-to-many (M:N)
E.g employee head-of department (1:1)student enrolls course (m:n)
lecturer offers course (1:n) assuming a course is taught by a single lecturer
The minimum and maximum values of this connectivity is called the cardinality of the relationship
34
ER/CORP/CRS/DB07/003
Version No: 2.034Copyright © 2004,
Infosys Technologies Ltd
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
All employees will not be head-of some department. So
only few instances of employee entity participate in the
above relationship. But each department will be headed
by some employee. So department entity’s participation is total and employee entity’s participation is partial in the above relationship
35
ER modeling -Notations
36
ER/CORP/CRS/DB07/003
Version No: 2.036Copyright © 2004,
Infosys Technologies Ltd
Entity
Employee
Usually a noun in singularRepresented by a rectangle with a labelFirst letter in capitals
37
ER/CORP/CRS/DB07/003
Version No: 2.037Copyright © 2004,
Infosys Technologies Ltd
Attributes
EmployeeE#
Name
DOB
Address
Designation
Represented by ellipses connected to the entity type by straight lines
38
ER/CORP/CRS/DB07/003
Version No: 2.038Copyright © 2004,
Infosys Technologies Ltd
Key attribute
EmployeeE#
Name
DOB
Address
Designation
The key attributeis underlined
39
ER/CORP/CRS/DB07/003
Version No: 2.039Copyright © 2004,
Infosys Technologies Ltd
Multivalued Attribute
EmployeeE#
Name
DOB Address
Designation
skill set
Indicated by a double lined ellipse as shown in the figure
40
ER/CORP/CRS/DB07/003
Version No: 2.040Copyright © 2004,
Infosys Technologies Ltd
Composite attribute
EmployeeE#
Name
DOB
Address
Designation
floor building
Represented by an ellipse from which other ellipses emanate and represent the component attributes. E.g Address
41
ER/CORP/CRS/DB07/003
Version No: 2.041Copyright © 2004,
Infosys Technologies Ltd
Relationship
student enrolsin
course
•A relationship is represented as a diamond between two entity types.
•It has a label that explains the relationship. Usually the convention is to read the ER diagram from top to bottom and from left to right.
•So, the relationship name is so chosen as to make sense when read from left to right.
•The relationship above is read as student enrolls-in course
42
ER/CORP/CRS/DB07/003
Version No: 2.042Copyright © 2004,
Infosys Technologies Ltd
Unary Relationship
EmployeeManages
•A unary relationship is represented as a diamond which connects one entity to itself as a loop.
•The relationship above means, some instances of employee manage other instances of Employee.
43
ER/CORP/CRS/DB07/003
Version No: 2.043Copyright © 2004,
Infosys Technologies Ltd
Role names
Role names may be added to make the meaning more explicit
EmployeeManages
Manager
subordinate
44
ER/CORP/CRS/DB07/003
Version No: 2.044Copyright © 2004,
Infosys Technologies Ltd
Binary Relationship
Employee Works for
Department
A relationship between two entity types
45
ER/CORP/CRS/DB07/003
Version No: 2.045Copyright © 2004,
Infosys Technologies Ltd
Ternary Relationship
Doctor
Medicine
PatientPrescription
A relationship connecting three entity types.
46
ER/CORP/CRS/DB07/003
Version No: 2.046Copyright © 2004,
Infosys Technologies Ltd
1 : 1
• C1
• C2
• C3
• C4
• P1
• P2
• P3
• P4
PERSONS CHAIRSits_on
1:1 relationship
One instance of entity type 1 is connected to exactly one other entity instance of entity type 2
47
ER/CORP/CRS/DB07/003
Version No: 2.047Copyright © 2004,
Infosys Technologies Ltd
• E1
• E2
• E4
• E6
• D1
• D2
• D3
• D4
DEPT EMPLOYEEEMPLOYS
•E8 •E7
•E5
•E3
1 : M
1:m relationship
1 m
48
ER/CORP/CRS/DB07/003
Version No: 2.048Copyright © 2004,
Infosys Technologies Ltd
M:1 relationship
Borrowed_by Customer
Name City
Street
AmountNumber
Loan
• L1
• L2
• L4
• C1
• C2
• C3
•L8
•L5
•L3
49
ER/CORP/CRS/DB07/003
Version No: 2.049Copyright © 2004,
Infosys Technologies Ltd
• T1
• T2
• T4
• T6
STUDENTS TEACHERSTaught_by
•T8 •T7
•T5
•T3
• S1
• S2
• S4
• S6
•S8 •S7
•S5
•S3
M : N
M:N relationship
M N
50
ER/CORP/CRS/DB07/003
Version No: 2.050Copyright © 2004,
Infosys Technologies Ltd
Summary
The file based approach has problems of redundancy, inconsistency etcThe Database model consists of three layersRDBMS handles data in the form of relations, tuples and fieldsKeys identify tuples uniquelyER modeling is a diagrammatic representation of the conceptual design of a databaseEntity types represent things Entity type could be strong or weakAttributes represent characteristics.Attributes can be simple/composite, single valued/multivalued, stored/derivedRelationship types represent collaboration between entity types.Relationships could be unary/binary/ternary.Cardinality of relationships could be 1:1, 1:M, N:M
51
ER/CORP/CRS/DB07/003
Version No: 2.051Copyright © 2004,
Infosys Technologies Ltd
Thank You!