|
|
|
Full functional dependence further qualifies the relationship when the entity key is composite; that is, composed of multiple attributes. Full functional dependence occurs when non-key attributes are dependent on all the key attributes, not just some of them.
The following is an example of functional dependence:
Supplier
K Supplier number
Supplier name
Supplier city
Supplier postal code
Full functional dependence further qualifies this relationship. For example, this term states that the attribute(s) N of entity T is fully functionally dependent on the attribute(s) K of entity T, if N is functionally dependent on every attribute of K but not on any subset of K. This means that if an entity is uniquely identified by more than one attribute (a composite key), each of its non-key attributes must be functionally dependent on the entire key. If an attribute is dependent on a subset of the key, then such dependency indicates that the attribute belongs in an entity having that subset of the key as its unique identifier.
In the following example, the non-key attributes are not fully functionally dependent on a composite key:
Supplier
K Supplier number
K Supplier status
Supplier name
Supplier city
Supplier postal code
When the Supplier Status is introduced as part of the primary key, the other non-key attributes are not fully functionally dependent on the key. The non-key attributes can be functionally dependent on just the Supplier Number. For example, the Supplier Name is the same regardless of the Supplier Status value. The non-key attributes are functionally dependent on the primary key but they are not fully functionally dependent on the whole key.
If the non-key attributes are functionally dependent but not fully functionally dependent, the primary key must be a composite.
A composite key can have fully functionally dependent attributes. For example, you might want a composite key of Date and Time, where both are necessary and required. All of the attributes will be fully functionally dependent on the composite key:
Transaction
K Transaction date
K Transaction time
Transaction quantity
Transaction type
Transaction product
Normalization is the last task you perform to finalize your conceptual data model before entering it into . Now that you have completed an ERD for your data model, you can begin this task.
The purpose of this task is to help you refine your entities and attributes to arrive at a third normal form by applying the three normalization rules: first normal form (1NF), second normal form (2NF), and third normal form (3NF).
During normalization, an unnormalized entity can be analyzed, reorganized, and progressively transformed into new entities. The process is reversible, therefore no information will be lost during transformation.
This task consists of the following steps:
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |