Skip to document
This is a Premium Document. Some documents on Studocu are Premium. Upgrade to Premium to unlock it.

DATABASE MANAGEMENT SYSTEM

NOTES ON DATABASE MANAGEMENT SYSTEM ABOUT TOPICS ON INFORMAL GUIDELINES.
Course

Btech (kcs-701)

478 Documents
Students shared 478 documents in this course
Academic year: 2021/2022
Uploaded by:
Anonymous Student
This document has been uploaded by a student, just like you, who decided to remain anonymous.
Rajasthan Technical University

Comments

Please sign in or register to post comments.

Preview text

Informal Design Guidelines for Relation Schemas

4 informal guidelines that may be used as measures to determine the quality of relation schema design:

■ Making sure that the semantics of the attributes is clear in the schema

■ Reducing the redundant information in tuples

■ Reducing the NULL values in tuples

■ Disallowing the possibility of generating spurious tuples

GUIDELINE 1:Informally,each tuple in a relation should represent one entity or relationship instance.

-Attributes of different entities should not be mixed in the same relation.

-Only foreign keys should be used to refer to other entities.

-Entity and relationship attributes should be kept apart as much as possible.

GUIDELINE 2: -Design a schema that does not suffer from the insertion,deletion and update anomalies.

-If there are any anomalies present,then note them so that applications can be made to take them in to account.

GUIDELINE 3:-Relations should be designed such that their tuples will have as few NULL values as possible.

  • Attrributes that are NULL frequently could be placed in separate relations(with the primary key).

-Reasons for NULLs

-Attribute not applicable or invalid

-Attribute value unknown

-value known to exist,but unavailable

GUIDELINE4: Design relation schemas so that they can be joined with equality conditions on attributes that are appropriately related pairs in a way that guarantees that no spurious tuples are generated. Avoid relations that contain matching attributes that are not (foreign key, primary key) combinations because joining on such attributes may produce spurious tuples

- spurious tuples are those they represent spurious information that is not valid. The spurious tuples

are marked by asterisks (*)

FUNCTIONAL DEPENDENCIES

A functional dependency, denoted by X → Y, between two sets of attributes X and Y that are subsets of R specifies a constraint on the possible tuples that can form a relation state r of R. The constraint is that, for any two tuples t1 and t2 in r that have t1[X] = t2[X], they must also have t1[Y] = t2[Y].

This means that the values of the Y component depend on, or are determined by, the values of the X component; alternatively, the values of the X component of a tuple uniquely determine the values of the Y component. We also say that there is a functional dependency from X to Y,It is denoted byFD or

f.

NORMALIZATION OF RELATIONS

The normalization process, takes a relation schema through a series of tests to certify whether it satisfies a certain normal form.

Normalization of data can be considered as a process of analyzing the given relation schemas based on their FDs and primary keys to achieve the desirable properties of (1) minimizing redundancy (2) minimizing the insertion, deletion, and update anomalies

Definition : The normal form of a relation refers to the highest normal form condition that it meets, and hence indicates the degree to which it has been normalized.

1) First normal form (1NF)

-It was defined to disallow multivalued attributes, composite attributes, and their combinations. It states that the domain of an attribute must include only atomic values and that the value of any attribute in a tuple must be a single value from the domain of that attribute. REMEDY:Form new relations for each multivalued attribute or nested relation.

2) Second normal form(2NF)

-Second normal form (2NF) is based on the concept of full functional dependency. A functional dependency X → Y is a full functional dependency if removal of any attribute A from X means that the dependency does not hold anymore. A functional dependency X → Y is a partial dependency if some attribute A ε X can be removed from X and the dependency still holds. Definition: A relation schema R is in 2NF if every nonprime attribute A in R is fully functionally dependent on the primary key of R. The test for 2NF involves testing for functional dependencies whose left-hand side attributes are part of the primary key. REMEDY: Decompose and set up a new relation for each partial key with its dependent attribute(s). Make sure

to keep a relation with the original primary key and any attributes that are fully functionally dependent on it.

3) Third Normal Form(3NF)

-It is based on the concept of transitive dependency. A functional dependency X → Y in a relation schema R is a transitive dependency if there exists a set of attributes Z in R that is neither a candidate key nor a subset of any key of R, and both X → Z and Z → Y hold. Definition: A relation schema R is in 3NF if it satisfies 2NF and no nonprime attribute of R is transitively dependent on the primary key. REMEDY: Decompose and set up a relation that includes the nonkey attribute(s) that functionally determine(s) other nonkey attribute(s)

Was this document helpful?
This is a Premium Document. Some documents on Studocu are Premium. Upgrade to Premium to unlock it.

DATABASE MANAGEMENT SYSTEM

Course: Btech (kcs-701)

478 Documents
Students shared 478 documents in this course
Was this document helpful?

This is a preview

Do you want full access? Go Premium and unlock all 3 pages
  • Access to all documents

  • Get Unlimited Downloads

  • Improve your grades

Upload

Share your documents to unlock

Already Premium?
Informal Design Guidelines for Relation Schemas
4 informal guidelines that may be used as measures to determine the quality of relation schema
design:
Making sure that the semantics of the attributes is clear in the schema
Reducing the redundant information in tuples
Reducing the NULL values in tuples
Disallowing the possibility of generating spurious tuples
GUIDELINE 1:Informally,each tuple in a relation should represent one entity or relationship instance.
-Attributes of different entities should not be mixed in the same relation.
-Only foreign keys should be used to refer to other entities.
-Entity and relationship attributes should be kept apart as much as possible.
GUIDELINE 2: -Design a schema that does not suffer from the insertion,deletion and update
anomalies.
-If there are any anomalies present,then note them so that applications can be made to take them in
to account.
GUIDELINE 3:-Relations should be designed such that their tuples will have as few NULL values as
possible.
-Attrributes that are NULL frequently could be placed in separate relations(with the primary key).
-Reasons for NULLs
-Attribute not applicable or invalid
-Attribute value unknown
-value known to exist,but unavailable
GUIDELINE4: Design relation schemas so that they can be joined with equality conditions on
attributes that are appropriately related pairs in a way that guarantees that no spurious tuples are
generated. Avoid relations that contain matching attributes that are not (foreign key, primary key)
combinations because joining on such attributes may produce spurious tuples
-spurious tuples are those they represent spurious information that is not valid. The spurious tuples
are marked by asterisks (*)
FUNCTIONAL DEPENDENCIES
A functional dependency, denoted by X → Y, between two sets of attributes X and Y that are subsets
of R specifies a constraint on the possible tuples that can form a relation state r of R. The constraint is
that, for any two tuples t1 and t2 in r that have t1[X] = t2[X], they must also have t1[Y] = t2[Y].

Why is this page out of focus?

This is a Premium document. Become Premium to read the whole document.