www.techstudent.co.cc er model. er model concepts entity –a thing in real world with independent...

www.techstudent.co.cc

ER Model


ER Model Concepts

• Entity– A thing in real world with independent

existence– A thing which can be distinctly identified– May be an object of physical existence or

conceptual existence– Eg: person, car, house, employee

company, job, university, course


ER model concepts

• Attribute– Property of an entity– Example

• Employee– Name, Age, DOB, Sex, salary, address,…

• Course– Number, name, duration, …..


Types of attributes

• Simple or Composite– Composite –attributes that can be subdivided– Simple – attributes that are not divisible

• Single-valued or Multi-valued– Depending on the number of values of an attribute

• Base or Derived– Related attribute values

• Key– Unique, within some context


Entity type

• Defines a set of entities that can have the same attributes

• Each entity type has a name and a set of attributes

• Entity type describes the intension for a set of entities sharing the same structure

• Individual entities of a entity type is called extension of the entity type


ER notations

• Entity type – labelled rectangular box

• Attributes – ovals, attached to entities by straight lines

• Composite attributes are attached to component attributes by straight line

• Multivalued attributes – double oval

• Derived attribute – dotted oval


Example

Employee

Name

Address

DOBAge

Qual

Street.Addr

City

State


Key attributes

• Attribute whose values are distinct for each individual entity

• A set of attributes that possess this property are grouped into composite attribute

• In ER notation each attribute has its name underlined inside the oval

Emp.no


Value sets or Domains of attributes

• The set of values that may be assigned to that attribute for each individual entity

• Not displayed in ER diagrams• Example

– Employee age –between 25 and 58– Name – string of alphabetic characters with

blanks in between


Domain

• Mathematical Notation:

• If A – attribute E – Entity type

V-value set

A: E P(V)

A is a function from E to the power set of V


• Multivalued attributes – within { }• Composite attributes – between

paranthesis• Example

{AddressPhone({Phone(Areacode, Ph.number)}, Address(StreetAddr(number,Street, Apt.no), city, state, zip) )}


Relationships

• An association among entities• The entities involved in a relationship are called

the participants of the relationship• The number of participants in a given

relationship is the degree of the relationship• An ER-relationship can be one-to-one, one-to-

many or many-to-many


Relationships

• Relationship – association between 2 or more entities

• Example– Employees are assigned to projects– Projects have subtasks– Department manages one or more projects


Relationships

• Representation in ER diagram- diamond shaped boxes connected to entity types

• The entities involved in a relationship are called the participants of the relationship

• The number of participants in a given relationship is the degree of the relationship


Degree of relationship

• Number of participating entities

• Relationship type of degree 2 – binary

• Degree three – ternary

• Relationship can be of any degree

• Common one is binary


Constraints on Relationship type

• Cardinality – actual number of related occurrences for each of the two entities

• Basic types for binary relationships:– One-to-many (1 : N)– One-to-one (1 : 1)– Many-to-many(M : N)


Cardinality

• One-to-one : – at most one instance of a entity A is

associated with one instance of B

– Example

Employee can manage one department and a department has only one manager


One-to-many

– for one instance of entity A, there are zero, one, or many instances of entity B, but for one instance of entity B, there is only one instance of entity A

– Example:• A department has many employees

• An employee is assigned to one department


Many-to-many

• for one instance of entity A, there are zero, one, or many instances of entity B and for one instance of entity B there are zero, one, or many instances of entity A

• Example:

employees can be assigned to no more than two projects at the same time; projects must have assigned at least three employees


Attributes of relationships

• Relationships can have attributes similar to entity types

• Example– Number of hours that an employee works on a

project


Weak entity types

• Entity types that do not have any key attributes of their own

• Identified by relating to specific entities from another entity type

• The other entity type is called identifying owner• Relationship that relates a weak entity type to its

owner is identifying relationship


Weak entity types

• Partial key – Set of attributes that can uniquely identify

weak entities related to the same owner entity

• ER notation– Weak entity type –double rectangle– identifying relationship-double diamond– Partial key – dotted or dashed line


ER diagram example


• A company has a number of employees. The attributes of employee include employee_id (identifier), name, address, and date of birth.

• The company also has several projects. Attributes of project include project identifier, name and start date. Each employee may be assigned to one or more projects, or may not be assigned to a project.

• A project must have at least one employee assigned, and may have any number of employees assigned. An employee's billing rate may vary by project, and the company wishes to record the applicable billing rate for each employee when assigned to a particular project.


Identify the entities (in blue)

A company has a number of employees. The attributes of employee include employee_id (identifier), name, address, and date of birth.

The company also has several projects. Attributes of project include project identifier, name and start date. Each employee may be assigned to one or more projects, or may not be assigned to a project.

A project must have at least one employee assigned, and may have any number of employees assigned. An employee's billing rate may vary by project, and the company wishes to record the applicable billing rate for each employee when assigned to a particular project.


Identify the relationships (in red)





Identify the attributes (in Green)

A company has a number of employees. The attributes of employee include employee_id (identifier), name,address, and date of birth. The company also has several projects. Attributes of project include project identifier, name and start date.

Each employee may be assigned to one or more projects, or may not be assigned to a project. A project must have at least one employee assigned, and may have any number of employees assigned.

An employee's billing rate may vary by project, and the company wishes to record the applicable billing rate for each employee when assigned to a particular project.


• Identify the cardinalities

• Summarize the details in a table indicating the attributes, relationship and attributes

• Draw the complete ER diagram


. Use an Entity-Relationship Diagram to depict the following requirements for a restaurant:· The restaurant employs a number of chefs. A record is kept of each chef’s name, address, phone number and salary.· Each chef can prepare a number of meals. The name of the meal and the price of the meal is recorded.· Each meal consists of a number of ingredients. The name of the ingredient and the quantity required for that particular meal is recorded.· These meals are ordered by customers. A record is kept of the customers name, address and phone number. A record is kept of the time and date the meal is ordered.State any assumptions made in the design of the E-R diagram.


Unit IV


Multivalued Dependency

• Let R be a relvar. And let A, B, and C be subsets of the attributes of R. Then we say that B is multi-dependent on A – in symbols,

A B

If and only if , in every legal value of R, the set of B values matching a given AC value pair depends only on the A value and is independent of the C value


Fourth Normal Form

• Relvar R is in 4NF, if and only if, whenever there exist subsets A and B of the attributes of R such that the nontrivial MVD A B is satisfied, then all attributes of R are also functionally dependent on A

• A record type should not contain two or more independent multi-values facts about an entity


Join Dependency

• Let R be a relvar, and let A, B, …Z be subsets of the attributes of R. Then we say that R satisfies the JD

* {A, B, ….., Z }

if and only if every legal value of R is equal to the join of its projections on A, B, …, Z.


Fifth Normal form

• A relvar R is in 5NF- if and only if every nontrivial join dependency that is satisfied by R, is implied by the candidate keys of R, where– The join dependency * {A,B,…,Z } on R is trivial if and

only if at least one of A,B,…,Z is the set of all attributes of R

– The join dependency * { A, B,…Z } on R is implied by the candidate key(s) of R if and only if each of A,B,…Z is a super key of R


• A record type cannot be reconstructed from several smaller record types


Normalization procedure summarized

• Take projections of original 1Nf to eliminate FDs that are not irreducible. This step will produce a collection of 2NF relvars

• From these eliminate transitive FDs. This step will produce a collection of 3NF relvars

• Take projections of those 3NF relvars to eliminate remaining FDs in which the determinant is not a candidate key


• Take projections of those BCNF relvars to eliminate MVDs that are not also FDs. This will produce a set of 4NF relvars

• Take projections of those 4NF relvars to eliminate JDs that are not implied by the candidate keys


To note….

• The process of taking projections at each step must be done in a non-loss way.

• The objectives of normalisation procedure is– To eliminate certain kinds of redundancy– To avoid certain update anomalies– To produce a design that is easy to understand and a

good base for future growth– To simplify the enforcement of certain integrity

constraints


To note….

• There may be good reasons for not normalizing ..

• The reasons why normalization is not the only solution is – Normalization helps to enforce certain integrity

constraints, but JDs, MVDs and FDs are not the only kinds of constraints

– The decomposition might not be unique– The normalization procedure eliminates redundancies

by taking projections , but not all redundancies can be eliminated


Denormalization

• Replacing relvars by their join R such that for all i(i=1,2,…n) projecting R over the attributes of Ri is guaranteed to yield Ri again

• The objective is to reduce the number of joins that need to be run at run time


Problems with denormalization

• It is not clear where to stop denormalization– No logical criteria has been established for deciding

where to stop

• Denormalization may be good for retrieval but bad for updation

• When we say denormalization is good for performance, we really mean that it is good for specific applications


Orthogonal design

• Initial version– Within a database, no two distinct base relvars should

have overlapped meanings

• Final version– Let A and B be distinct base relvars. Then there must

not exist nonloss decompositions of A and B into A1,A2,…,Am and B1,B2,…Bn such that some projection Ai in the set A1, A2,…Am and some projection Bj in the set B1, B2,…,Bn have overlapping meanings


Orthogonal design

• Nonloss decomposition:– Decomposition of a relvar into a set of

projections such that:• The given relvar can be reconstructed by joining

the projections back together again• None of those projections is redundant in that

reconstruction process


Other normal forms

• Domain-Key normal form(DK/NF)– A relvar R is said to be in DK/NF if and only if

every constraint on R is a logical consequence of the domain constraints and key constraints that apply to R, where

• A domain constraint is a constraint that the values of a given attribute are taken from some prescribed domain

• A key constraint is a constraint that a certain set of attributes constitutes a candidate key


Other normal forms

• “Restriction-union” normal form– Examining the implications of decomposing

relvars by some operation other than projection(restriction, union)

• Sixth normal form– Uses a generalized form of operators and join

dependency


Database Design with ER model

• Regular entities– Each regular entity maps to a base relvar– Each of the relvar will have a primary key

corresponding to the key in the E/R diagram


• Many-to-many relationship– All many-to-many relationships are mapped into a

relvar– The relvar must have two foreign keys corresponding

to the two participants– It should also contain a set of foreign key rules– Foreign key

• Either the combination of the foreign keys or a new attribute


Transactions


Introduction

• Recovery– Restoring the database to a correct state after

some failure has rendered the current state incorrect


Transaction

• Logical unit of work• Begins with BEGIN TRANSACTION and ends

with execution of COMMIT or ROLLBACK• The logical unit of work is a sequence of several

database operations • The purpose of the sequence is to transform a

state of database into another state without preserving the intermediate points


Transaction

• Transaction either occurs entirely or is totally cancelled

• The system component that provides this atomicity is known as the transaction manager

• Also known as transaction processing manager or TP monitor


Transaction

• COMMIT and ROLLBACK are the key for TP monitor

• COMMIT– Signals successful end-of-transaction– Tells transaction manager that the unit of work is

successfully completed and can be recorded in the database

• ROLLBACK– Signals unsuccessful end-of transaction.– Tells TP monitor that all updates done so far must be

rolled back or undone.


Transaction

• Implicit ROLLBACK– System will issue an implicit ROLLBACK for

any transaction that fails for any reason to reach its unplanned termination

• Message Handling– A typical transaction will not only update the

database but also send some kind of message back to the user indicating what has happened


Transaction

• Recovery log– System maintains a log or journal on tape or disk

which stores values before and after updation

• Statement atomicity– The system should guarantee that individual

statement executions are atomic– If an error occurs in the middle of a statement , the

database must remain totally unchanged


Transaction

• Program execution is a sequence of transactions– A single program execution will consist of a

sequence of several transactions running one after another

• No nested transactions– Assume no transactions has other

transactions nested inside itself


Transaction

• Correctness– Transactions always transform a consistent

state into a consistent state– If T is a transaction that transforms database

state D1 to database state D2, and if D1 is correct , then D2 is correct as well


Transaction Recovery

• COMMIT establishes a commit point. It corresponds to a point at which the database is supposed to be in the correct state

• When a commit point is established– All database updates made by the executing program

since the previous commit point are made permanent.– Once committed ,an update is guaranteed never to be

undone



– All database positioning is lost and all tuple locks are released

• Transactions are not only a unit of work but also a unit of recovery

• Write-ahead log rule– The log record for a given database must be

physically written to the log before that update is physically written to the database

– COMMIT processing for a given transaction must not complete until the COMMIT log record for that transaction is physically written to the log



• ACID properties– Atomicity

• Transactions are atomic

– Correctness• Transactions transform a correct state of database into

another

– Isolation• Transactions are isolated from one another

– Durability• Once a transaction commits, its updates persist in the

database


System Recovery

• Failures fall into two broad categories– System failures

• Also called soft crash• Affects all transactions currently in progress but do not

damage database physically• Eg: power outage

– Media Failures• Also called hard crash• Causes damage to the database• Eg: head crash on the disk


Transaction categories

T1

T2

T3

T4

T5

Check point System Failure


• Start with two lists UNDO lists and the REDO lists

• Set the UNDO list equal to the list of all transactions given in the most recent checkpoint record and the REDO list to empty

• Search forward, starting from the checkpoint record

• If a Begin transaction log record is found add T to UNDO list

• IF COMMIT found, move T from UNDO list to REDO list


System Recovery

• ARIES– Stands for “Algorithms for Recovery and

Isolation Exploiting Semantics”– Performs REDO operations first– Operates in three broad phases

• Analysis– Build REDO and UNDO list

• Redo• Undo


Two-phase commit

• Important when a transaction can interact with several independent resource managers

• In this case the transaction issues a system-wide COMMIT or ROLLBACK

• This is handled by a system component called the coordinator

• Coordinator guarantees for the two-phase commit for a commit or rollback


• The coordinator goes to two process:– Prepare– Commit


ER Model