Dbms basics 02

Unit No. - II
DBMS
By Dr. Dhobale J V
Assistant Professor
IBS, IFHE, Hyderabad.
IBS Hyderabad 1

Objectives
 E-R Diagram.
 Features of RDBMS.
 Normalization Process(upto 3NF).
 Functional Dependencies.
 Decomposition.
2IBS Hyderabad

Database Design and the E-R Model
 In designing of database schema, we must
ensure that we avoid two major pitfalls –
1. Redundancy
2. Incompleteness
3IBS Hyderabad

 The Entity-Relationship Model: The E-R Model
was developed to facilitate database design by
allowing specification of an enterprise schema
that represents the overall logical structure of
a database.
 The E-R Model is very useful in mapping the
meaning and interactions of real-world
enterprises onto a conceptual schema.
4IBS Hyderabad

 The E-R data model employs three basic
concepts – entity sets, relationship sets and
attributes.
 An entity is a “thing” or “object” in the real
world that is distinguishable from all other
objects.
 Ex- student, instructor, book.
5IBS Hyderabad

 An entity has a set of properties, and the
values for some set of properties may uniquely
identify an entity.
 Ex. – A person may have person_Id property
whose value uniquely identifies that person.
 An entity set is a set of entities of the same
type that share the same properties.
6IBS Hyderabad

 An entity is represented by a set of attributes.
 Attributes are the descriptive properties
possessed by each member of an entity set.
 Each entity has a value for each of its
attributes.
7IBS Hyderabad

8IBS Hyderabad

 Relationship: A relationship is an association
among several entities.
 Ex. Instructor Crick advisor to student Zhang.
 A relationship set is a set of relationships of
the same type.
9IBS Hyderabad

 Consider the two entity sets instructor and
student
 We define relationship advisor to denote the
association between instructor and student,
shown below -
10IBS Hyderabad

11IBS Hyderabad

 Recursive Relationship – The same entity set
participates in a relationship set more than
once in different roles.
 Descriptive attribute
12IBS Hyderabad

13IBS Hyderabad

 The number of entity sets that participate in a
relationship set is the degree of the
relationship set.
 A binary relationship set is of degree 2; & a
ternary relationship set is of degree 3.
14IBS Hyderabad

 Attributes: For each attribute, there is a set of
permitted values, called domain, or value.
 An attribute of an entity set is a function that
maps form the entity set into a domain.
 Different types of attributes –
1. Simple attribute – The attribute which can not
be divided into subparts is called simple
attribute; Ex- Enrol_No.
15IBS Hyderabad

 Attributes:
2. Composite attribute – The attribute which can
be divided into subparts is called composite
attribute;
 Ex- name can be divided into subparts like
fist_name, middle_name & last_name.
16IBS Hyderabad

 Attributes:
3. Single-valued attribute – attribute which has a
single value only.
 Ex. Account_No.
4. Multi-valued attribute – attributes which has a
set of values.
 Ex. Phone_No.
17IBS Hyderabad

 Attributes:
5. Derived attribute – The value for this type of
attribute can be derived from the values of
other related attributes or entities.
 Ex. From DOB value we can derive age
attribute.
 An attribute takes a null value when an entity
does not have a value for it.
18IBS Hyderabad

 Constraints: An E-R enterprise schema may
define certain constraints to which the
contents of a database must conform.
 Mapping Cardinalities/Cardinality ratios:
express the number of entities to which
another entity can be associated via a
relationship set
 For a binary relationship set R between entity
sets A and B, the mapping cardinalities must
be one of the following -
19IBS Hyderabad

 Constraints:.
1. One-to-one – An entity in A is associated with
at most one entity in B, and an entity in B is
associated with at most one entity in A.
20IBS Hyderabad

 Constraints:.
2. One-to-many – An entity in A is associated
with any number (zero or more) of entities in
B. An entity in B, however, can be associated
with at most one entity in A.
21IBS Hyderabad

 Constraints:.
3. Many-to-One: An entity in A is associated
with at most one entity in B. An entity in B,
however, can be associated with any number
(zero or more) of entities in A.
22IBS Hyderabad

 Constraints:.
4. Many-to-Many: An entity in A is associated
with any number (zero or more) of entities in
B, and an entity in B is associated with any
number (zero or more) of entities in A.
23IBS Hyderabad

 Keys: The values of the attribute for an entity
must be such that they can uniquely identify
the entity.
 A key for an entity is a set of attributes that
suffice to distinguish entities from each other.
24IBS Hyderabad

 Keys:
 A super key of an entity set is a set of one or
more attributes whose values uniquely
determine each entity.
 A candidate key of an entity set is a minimal
super key
 Social-security is candidate key of customer.
 Account-number is candidate key of account.
 Although several candidate keys may exist,
one of the candidate keys is selected to be the
primary key.
25IBS Hyderabad

 Keys:
 The combination of primary keys of the
participating entity sets forms a candidate key
of a relationship set.
 Must consider the mapping cardinality and the
semantics of the relationship set when selecting the
primary key.
 (social-security, account-number) is the primary key
of depositor.
26IBS Hyderabad

 Components of E-R Diagram:
 Rectangles represent entity sets.
 Ellipses represent attributes.
 Diamonds represent relationship sets.
 Lines link attributes to entity sets and entity sets to
relationship sets.
 Double ellipses represent multivalued attributes.
 Dashed ellipses denote derived attributes.
 Primary key attributes are underlined.
27IBS Hyderabad

 Components of E-R Diagram:
28IBS Hyderabad

 Entity – Relationship Diagram:
29IBS Hyderabad

30IBS Hyderabad

31IBS Hyderabad

 Weak Entity Sets:
 An entity set that does not have a primary key
is referred to as a weak entity set.
 The existence of a weak entity set depends on
the existence of a strong entity set; it must
relate to the strong set via a one-to-many
relationship set.
 The discriminator (or partial key) of a weak
entity set is the set of attributes that
distinguishes among all the entities of a weak
entity set.
32IBS Hyderabad

 The primary key of a weak entity set is formed
by the primary key of the strong entity set on
which the weak entity set is existence
dependent, plus the weak entity set’s
discriminator.
 We depict a weak entity set by double
rectangles.
 We underline the discriminator of a weak entity
set with a dashed line.
33IBS Hyderabad

 payment-number – discriminator of the
payment entity set
 Primary key for payment – (loan-number,
payment-number)
34IBS Hyderabad

 Specialization:
 Top-down design process; we designate
subgroupings within an entity set that are
distinctive from other entities in the set.
 These subgroupings become lower-level entity
sets that have attributes or participate in
relationships that do not apply to the higher-
level entity set.
 Depicted by a triangle component labeled ISA
(i.e., savings-account “is an” account)
35IBS Hyderabad

 Specialization:
36IBS Hyderabad

 Generalization:
 A bottom-up design process – combine a
number of entity sets that share the same
features into a higher-level entity set
 Specialization and generalization are simple
inversions of each other; they are represented
in an E-R diagram in the same way.
 Attribute Inheritance – a lower-level entity
set inherits all the attributes and relationship
participation of the higher-level entity set to
which it is linked.
37IBS Hyderabad

 Design Constraints on a Generalization:
 Constraint on which entities can be members
of a given lower-level entity set.
 condition-defined
 user-defined
 Constraint on whether or not entities may
belong to more than one lower-level entity set
within a single generalization.
 Disjoint
 overlapping
38IBS Hyderabad

 Completeness constraint – specifies whether or not an
entity in the higher-level entity set must belong to at
least one of the lower-level entity sets within a
generalization.
 Total
 partial
39IBS Hyderabad

40IBS Hyderabad

 Aggregation: Aggregation is a process when
relation between two entity is treated as a
single entity.
 Here the relation between Center and Course,
is acting as an Entity in relation with Visitor..
41IBS Hyderabad

 Aggregation: Relationship sets borrower and
loan-officer represent the same information
 Eliminate this redundancy via aggregation
 Treat relationship as an abstract entity.
 Allows relationships between relationships.
 Abstraction of relationship into new entity.
 Without introducing redundancy, the following
diagram represents that:
 A customer takes out a loan.
 An employee may be a loan officer for a customer-
loan pair.
42IBS Hyderabad

 How to draw a basic ER diagram:
1. Purpose and scope: Define the purpose and
scope of what you’re analyzing or modeling.
2. Entities: Identify the entities that are
involved. When you’re ready, start drawing
them in rectangles (or your system’s choice
of shape) and labeling them as nouns.
43IBS Hyderabad

 How to draw a basic ER diagram:
3. Relationships: Determine how the entities are all
related. Draw lines between them to signify the
relationships and label them. Some entities may not
be related, and that’s fine. In different notation
systems, the relationship could be labelled in a
diamond, another rectangle or directly on top of the
connecting line.
4. Attributes: Layer in more detail by adding key
attributes of entities. Attributes are often shown as
ovals.
5. Cardinality: Show whether the relationship is 1-1, 1-
many or many-to-many.
44IBS Hyderabad

Important Features of RDBMS
 RDBMS is a database management
system based on relational model defined by
E.F.Codd.
 Data is stored in the form
of rows and columns and also provides ACID
properties functionality.
 A transaction in a database system must
maintain Atomicity, Consistency, Isolation, and
Durability − commonly known as ACID
properties − in order to ensure accuracy,
completeness, and data integrity.
45IBS Hyderabad

 Atomicity:
 Atomicity requires that each transaction be "all
or nothing": if one part of the transaction fails,
then the entire transaction fails, and the
database state is left unchanged.
 An atomic system must guarantee atomicity in
each and every situation, including power
failures, errors and crashes.
46IBS Hyderabad

 Consistency:
 The consistency property ensures that any
transaction will bring the database from one
valid state to another.
 Any data written to the database must be valid
according to all defined rules, including
constraints, cascades, triggers, and any
combination thereof.
47IBS Hyderabad

 Isolation:
 The isolation property ensures that the
concurrent execution of transactions results in
a system state that would be obtained if
transactions were executed sequentially, i.e.,
one after the other.
 Providing isolation is the main goal of
concurrency control. Depending on the
concurrency control method, the effects of an
incomplete transaction might not even be
visible to another transaction.
48IBS Hyderabad

 Durability:
 The durability property ensures that once a
transaction has been committed, it will remain
so, even in the event of power loss, crashes,
or errors.
 In a relational database, for instance, once a
group of SQL statements execute, the results
need to be stored permanently.
49IBS Hyderabad

Normalization
 Without Normalization, it becomes difficult to
handle and update the database, without
facing data loss.
 Insertion, Updation and Deletion Anamolies
are very frequent if Database is not
Normalized.
 To understand these anomalies let us take an
example of Student table.
50IBS Hyderabad

Normalization
 Updation Anomaly : To update address of a student
who occurs twice or more than twice in a table, we will
have to update S_Address column in all the rows,
else data will become inconsistent.
51IBS Hyderabad

Normalization
 Insertion Anomaly : Suppose for a new
admission, we have a Student id(S_id), name
and address of a student but if student has not
opted for any subjects yet then we have to
insert NULLthere, leading to Insertion
Anomaly.
 Deletion Anomaly : If (S_id) 401 has only one
subject and temporarily he drops it, when we
delete that row, entire student record will be
deleted along with it.
52IBS Hyderabad

Normalization
 Normalization rule are divided into following
normal form.
1. First Normal Form
2. Second Normal Form
3. Third Normal Form
4. BCNF
53IBS Hyderabad

Normalization
1. First Normal Form :
 As per the rule of first normal form, an
attribute (column) of a table cannot hold
multiple values. It should hold only atomic
values.
 Example: Suppose a company wants to store
the names and contact details of its
employees. It creates a table that looks like
this:
54IBS Hyderabad

Normalization
1. First Normal Form:
55IBS Hyderabad

Normalization
 Two employees (Jon & Lester) are having
two mobile numbers so the company stored
them in the same field as you can see in the
table above.
 This table is not in 1NF as the rule says
“each attribute of a table must have atomic
(single) values”, the emp_mobile values for
employees Jon & Lester violates that rule.
56IBS Hyderabad

Normalization
 To make the table complies with 1NF we
should have the data like this:.
57IBS Hyderabad

Functional Dependencies
 The attributes of a table is said to be
dependent on each other when an attribute of
a table uniquely identifies another attribute of
the same table.
 For example: Suppose we have a student
table with attributes: Stu_Id, Stu_Name,
Stu_Age.
 Here Stu_Id attribute uniquely identifies the
Stu_Name attribute of student table because
if we know the student id we can tell the
student name associated with it.
58IBS Hyderabad

 This is known as functional dependency and
can be written as Stu_Id->Stu_Name or in
words we can say Stu_Name is functionally
dependent on Stu_Id.
 Formally:
 If column A of a table uniquely identifies the
column B of same table then it can
represented as A->B (Attribute B is
functionally dependent on attribute A).
59IBS Hyderabad

 Types of of Functional Dependencies:
1. Trivial functional dependency
2. Non-trivial functional dependency
3. Multivalued dependency
4. Transitive dependency
60IBS Hyderabad

1. Trivial functional dependency:
 The dependency of an attribute on a set of attributes is
known as trivial functional dependency if the set of
attributes includes that attribute.
 Symbolically: A ->B is trivial functional dependency if
B is a subset of A.
 The following dependencies are also trivial: A->A & B-
>B.
61IBS Hyderabad

1. Trivial functional dependency:
 For example: Consider a table with two columns
Student_id and Student_Name.
 {Student_Id, Student_Name} -> Student_Id is a trivial
functional dependency as Student_Id is a subset of
{Student_Id, Student_Name}.
 That makes sense because if we know the values of
Student_Id and Student_Name then the value of
Student_Id can be uniquely determined.
 Also, Student_Id -> Student_Id & Student_Name ->
Student_Name are trivial dependencies too.
62IBS Hyderabad

2. Non-Trivial functional dependency: a functional
dependency X->Y holds true where Y is not a subset
of X then this dependency is called non trivial
Functional dependency.
63IBS Hyderabad

2. Non-Trivial functional dependency:
 For example:
An employee table with three attributes: emp_id,
emp_name, emp_address.
The following functional dependencies are non-trivial:
emp_id -> emp_name (emp_name is not a subset of
emp_id)
emp_id -> emp_address (emp_address is not a subset
of emp_id)
 On the other hand, the following dependencies are
trivial:
{emp_id, emp_name} -> emp_name [emp_name is a
subset of {emp_id, emp_name}]
64IBS Hyderabad

2. Non-Trivial functional dependency:
 Completely non trivial FD:
If a FD X->Y holds true where X intersection Y is null
then this dependency is said to be completely non
trivial function dependency.
65IBS Hyderabad

3. Multivalued dependency: Multivalued dependency
occurs when there are more than
one independent multivalued attributes in a table.
 For example: Consider a bike manufacture
company, which produces two colors (Black and
white) in each model every year.
66IBS Hyderabad

3. Multivalued dependency:
 Here columns manuf_year and color are independent
of each other and dependent on bike_model. In this
case these two columns are said to be multivalued
dependent on bike_model.
67IBS Hyderabad

3. Multivalued dependency:
 These dependencies can be represented like this:
 bike_model ->> manuf_year
68IBS Hyderabad

4. Transitive dependency: A functional dependency is
said to be transitive if it is indirectly formed by two
functional dependencies. For e.g.
 X -> Z is a transitive dependency if the following three
functional dependencies hold true:
 X->Y
 Y does not ->X
 Y->Z
 Note: A transitive dependency can only occur in a
relation of three of more attributes. This dependency
helps us normalizing the database in 3NF (3rd Normal
Form).
69IBS Hyderabad

4. Transitive dependency:
 Example: Let’s take an example to understand it
better:
70IBS Hyderabad

4. Transitive dependency:
 Example: Let’s take an example to understand it
better:
{Book} ->{Author} (if we know the book, we knows the
author name)
{Author} does not ->{Book}
{Author} -> {Author_age}
 Therefore as per the rule of transitive dependency:
{Book} -> {Author_age} should hold, that makes sense
because if we know the book name we can know the
author’s age.
71IBS Hyderabad

Normalization
2. Second normal form (2NF):
 A table is said to be in 2NF if both the
following conditions hold:
1. Table is in 1NF (First normal form)
2. No non-prime attribute is dependent on the
proper subset of any candidate key of table.
 An attribute that is not part of any candidate
key is known as non-prime attribute.
72IBS Hyderabad

Normalization
 Ex. Suppose a school wants to store the data
of teachers and the subjects they teach. They
create a table that looks like this: Since a
teacher can teach more than one subjects,
the table can have multiple rows for a same
teacher.
73IBS Hyderabad

Normalization
 Ex.
Candidate Keys: {teacher_id, subject}
Non prime attribute: teacher_age
74IBS Hyderabad

Normalization
 The table is in 1 NF because each attribute
has atomic values. However, it is not in 2NF
because non prime attribute teacher_age is
dependent on teacher_id alone which is a
proper subset of candidate key.
 This violates the rule for 2NF as the rule says
“no non-prime attribute is dependent on the
proper subset of any candidate key of the
table”.
75IBS Hyderabad

Normalization
 To make the table complies with 2NF we can
break it in two tables like this:
 teacher_details table:.
76IBS Hyderabad

Normalization
 To make the table complies with 2NF we can
break it in two tables like this:
 teacher_subject table:
 Now the tables comply with Second normal
form (2NF). 77IBS Hyderabad

Normalization
3. Third normal form (3NF): A table design is
said to be in 3NF if both the following
conditions hold:
1. Table must be in 2NF
2. Transitive functional dependency of non-
prime attribute on any super key should be
removed.
 An attribute that is not part of any candidate
key is known as non-prime attribute.
78IBS Hyderabad

Normalization
3. Third normal form (3NF): In other words
3NF can be explained like this: A table is in
3NF if it is in 2NF and for each functional
dependency X-> Y at least one of the
following conditions hold:
 X is a super key of table
 Y is a prime attribute of table
 An attribute that is a part of one of the
candidate keys is known as prime attribute.
79IBS Hyderabad

Normalization
3. Third normal form (3NF):
 Example: Suppose a company wants to store
the complete address of each employee, they
create a table named employee_details that
looks like this:
80IBS Hyderabad

Normalization
 Example:
 Super keys: {emp_id}, {emp_id, emp_name},
{emp_id, emp_name, emp_zip}…so on
Candidate Keys: {emp_id}
Non-prime attributes: all attributes except
emp_id are non-prime as they are not part of
any candidate keys.
81IBS Hyderabad

Normalization
 Example:
 Here, emp_state, emp_city & emp_district
dependent on emp_zip. And, emp_zip is
dependent on emp_id that makes non-prime
attributes (emp_state, emp_city &
emp_district) transitively dependent on super
key (emp_id). This violates the rule of 3NF.
 To make this table complies with 3NF we have
to break the table into two tables to remove
the transitive dependency:
82IBS Hyderabad

Normalization
 Example: employee table
83IBS Hyderabad

Normalization
 Example: employee_zip table:
84IBS Hyderabad

Decomposition
 A functional decomposition is the process of
breaking down the functions of an
organization into progressively greater (finer
and finer) levels of detail.
 In decomposition, one function is described in
greater detail by a set of other supporting
functions.
85IBS Hyderabad

Decomposition
 The decomposition of a relation scheme R
consists of replacing the relation schema by
two or more relation schemas that each
contain a subset of the attributes of R and
together include all attributes in R.
 Decomposition helps in eliminating some of
the problems of bad design such as
redundancy, inconsistencies and anomalies.
86IBS Hyderabad

Decomposition
 There are two types of decomposition :
1. Lossy Decomposition
2. Lossless Join Decomposition
87IBS Hyderabad

Decomposition
1. Lossy Decomposition: The decomposition of
relation R into R1 & R2 is lossy when the join
(union) of R1 & R2 does not yield the same
relation as inn R”.
 One of the disadvantages of decomposition
into two or more relational schemes (or
tables) is that some information is lost during
retrieval of original relation or table.
88IBS Hyderabad

Decomposition
1. Lossy Decomposition: Consider that we have
table STUDENT with three attribute roll_no ,
s_name and department.
 This relation is decomposed into two relation
S_name and Dept_name
89IBS Hyderabad
Roll_no S_name Dept
111 Parimal Computer
222 Soham Electrical
333 Parimal Electrical

Decomposition
1. Lossy Decomposition:
 S_name
 Dept_name
90IBS Hyderabad
Roll_no S_name
111 Parimal
222 Soham
333 Parimal
S_name Dept
Parimal Computer
Soham Electrical
Parimal Electrical

Decomposition
1. Lossy Decomposition:
 In lossy decomposition ,spurious tuples are
generated when a natural join is applied to
the relations in the decomposition
 The above decomposition is a bad
decomposition or Lossy decomposition.
91IBS Hyderabad
Roll_no S_name Dept

Decomposition
2. Lossyless join Decomposition: “The
decomposition of relation R into R1 and R2
is lossless when the join of R1 and R2 yield
the same relation as in R.“
 A relational table is decomposed (or factored)
into two or more smaller tables, in such a way
that the designer can capture the precise
content of the original table by joining the
decomposed parts. This is called lossless-
join (or non-additive join) decomposition.
92IBS Hyderabad

Decomposition
2. Lossyless join Decomposition: This is also
refferd as non-additive decomposition.
 The lossless-join decomposition is always
defined with respect to a specific set F of
dependencies.
 Consider that we have table STUDENT with
three attribute roll_no , s_name and
department.
93IBS Hyderabad

Decomposition
2. Lossyless join Decomposition:
 This relation is decomposed into two relation
S_name and Dept_name
94IBS Hyderabad
Roll_no S_name Dept_Name

Decomposition
 S_name
 Dept_name
95IBS Hyderabad
Roll_no S_name
111 Parimal
222 Soham
333 Parimal
Roll_No Dept_Name
111 Computer
222 Electrical
333 Electrical

Decomposition
 Now ,when these two relations are joined on
the common column 'roll_no' ,the resultant
relation will look like stu_joined.
 In lossless decomposition, no any spurious
tuples are generated when a natural joined is
applied to the relations in the decomposition. 96IBS Hyderabad
Roll_no S_name Dept_Name

Reviews
 DBMS Architecture & Users.
 E-R Diagram.
 Features of DBMS.
 Normalization Process(upto 3NF).
 Functional Dependencies.
 Decomposition.
97IBS Hyderabad

Dbms basics 02

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Dbms basics 02

Similar to Dbms basics 02 (20)

More from Jaipal Dhobale

More from Jaipal Dhobale (20)

Recently uploaded

Recently uploaded (20)

Dbms basics 02