Scribd
Upload
2 views28 pages

Mapping ER Model to Func_model & Functioal Dependencies u2

The document discusses the process of mapping an ER model to a relational database, detailing the steps involved in converting ER diagrams into relational schemas. It explains functional dependencies, including types such as trivial, non-trivial, transitive, and partial dependencies, with examples to illustrate each concept. The document emphasizes the importance of understanding these dependencies to prevent data redundancy and improve database design.

Uploaded by

afifajan187
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
2 views28 pages

Mapping ER Model to Func_model & Functioal Dependencies u2

The document discusses the process of mapping an ER model to a relational database, detailing the steps involved in converting ER diagrams into relational schemas. It explains functional dependencies, including types such as trivial, non-trivial, transitive, and partial dependencies, with examples to illustrate each concept. The document emphasizes the importance of understanding these dependencies to prevent data redundancy and improve database design.

Uploaded by

afifajan187
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 28

DATABASE DESIGN

Mapping ER- Model to relational Database


 ER Model is a conceptual thing-a conceptual design of the
database. Practical implementation of the ER model is
converting it into a database using an RDBMS.
 ER diagrams can be mapped to relational schema, that is, it
is possible to create relational schema using ER diagram. We
cannot import all the ER constraints into relational model,
but an approximate schema can be generated. Converting
ER model to a relational schema is called mapping of ER
model to relational Database.
 There are several steps which are to be followed for
converting an ER diagram into a relational schema. These
steps are explained as follows.
 For understanding the procedure let take the example of an
ER diagram for creating a company database, shown on next
slide.
Functional Dependency
• Functional dependency in DBMS, as the name
suggests is a relationship between attributes of a
table dependent on each other. Introduced by E. F.
Codd, it helps in preventing data redundancy and
gets to know about bad designs.
• To understand the concept thoroughly, let us
consider P is a relation with attributes A and B.
Functional Dependency is represented by -> (arrow
sign)
• Then the following will represent the functional
dependency between attributes with an arrow sign −
A -> B
 Example:
 We have a Department table with two attributes
− DeptId and DeptName.
 The DeptId is our primary key. Here, DeptId uniquely
identifies the DeptName attribute. This is because if you want
to know the department name, then at first you need to have
the DeptId.

DeptId DeptName

001 Finance

002 Marketing

003 HR
 Therefore, the above functional dependency
between DeptId and DeptName can be determined
as DeptName is functionally dependent on DeptId
 DeptId -> DeptName
 Note: Functional dependency exists between the primary key
and non primary key attribute of a table.
Types of Functional Dependency
Functional dependencies are of the following types.
Trivial FD: A trivial functional dependency is a dependency
where the right-hand side (RHS) is a subset of the left-hand side
(LHS)
Definition:
A functional dependency X→Y is trivial if Y is a subset of X
i.e Y⊆X.
Example:
• Let X={A,B} then
• {A,B}→{A} is trivial also
• {A,B}→{A,B} is trivial.
NonTrivial Functional dependencies
Non-Trivial Functional Dependencies:
A non-trivial functional dependency is one where the RHS is not
a subset of the LHS.
Definition:
A functional dependency X→Y is non-trivial if Y⊈X.
Example:
Given a relation R(A, B, C), suppose:
• A→B, This is non-trivial, because B is not subset of A
Another case is a completely non-trivial FD, where X∩Y=∅,That
means the LHS and RHS share no attributes.
Real life Examples of trivial, nontrivial
and completely nontrivial FD’s
• In order to understand the above topic, Let us take the
example of a relation employee given below:

EmpID Name Dept DeptID

101 Alice HR D01

102 Bob IT D02

103 Charlie HR D01


 Trivial dependency example:
Let's consider the attribute set:
• X={EmpID,Name}
Then:
• {EmpID,Name}→{EmpID} is trivial, because EmpID is a subset
of the left-hand side. It doesn't provide any new insight—it's
always true just because EmpID is part of the LHS.
 Non-Trivial Functional Dependency
Now, suppose:
• EmpID→Name
This is non-trivial, because:
• Name is not a subset of EmpID.
• It tells us that each employee ID uniquely determines a name,
which is useful information.
Example of a Completely Non-Trivial Functional
Dependency
•FD: CourseID→Professor
This means:
Each course is taught by one professor.
This is a completely non-trivial functional dependency
because:
•LHS = CourseID
•RHS = Professor
•CourseID ∩ Professor = ∅ (they’re entirely different
attributes)
So this FD adds new knowledge: knowing the CourseID
tells us exactly who teaches it..
Transitive and Non Transitive FD
 Transitive Functional Dependency:
A transitive dependency occurs when a non-prime attribute
depends on another non-prime attribute, which in turn depends
on a primary key.
Definition:
If A → B and B → C, then A → C is a transitive dependency,
provided A is a candidate key and C is not a prime attribute.

 Non Transitive Functional Dependency:


A non-transitive dependency is a direct dependency that doesn’t
involve any intermediate attribute.
Definition:
• If A → B, and there is no attribute C such that A → C and C →
B, then A → B is non-transitive.
Examples of Transitive and Non Transitive FDs

 Transitive FD Example
Scenario: University Student Records
• Relation:
student(student_ID,Department_ID,Department_name)
• Dependencies:
• Student_ID-Department_ID
• Department_id-Department_name
• Therefore, Student_ID- Department_name(Transitive)
Because Student_ID determines Department_name through
Department_ID, not directly.
Non Transitive Functional dependency example:
In the relation :Employee(EmpID, EmpName, Salary)
EmpID → EmpName
EmpID → Salary
Here, both are non-transitive dependencies, because
there is no intermediate attribute involved.
Fully Functional dependency and Partial Functional
dependency
Fully Functional Dependency
A fully functional dependency occurs when an attribute is
functionally dependent on the entire primary key, and not on just a
part of it. This typically occurs in tables where the primary key is
composed of more than one attribute (a composite key).
Example:
Consider a relation:
StudentCourse(StudentID, CourseID, Grade)
Where the primary key is (StudentID, CourseID).
• Grade depends on both StudentID and CourseID
together (i.e., you can’t determine the grade with
just one of them),
Then:
• Grade is fully functionally dependent on the
primary key (StudentID, CourseID).
Partial Dependency:
A partial dependency occurs when an attribute is functionally
dependent on part of a composite primary key, but not on the
whole key.
Example:
Consider a relation:
StudentCourse(StudentID, CourseID, StudentName)
With (StudentID, CourseID) as the primary key.
If:
• StudentName only depends on StudentID (and not
CourseID),
Then:
• StudentName is partially dependent on the primary key.

You might also like