6-1 Artificial, Composite, and Secondary UIDs

- Sometimes an entity can have more than once candidate UID

- UID is very important in relational databases
- UID= the value or combination of values that enables the user to find that one
unique item among (printre) all the rest.
- UID enables you to find a specific piece of data in a database

1. Simple UIDs vs. Composite UIDs

- Simple UID – a UID with a single attribute
- Composite UIDs - a UID with a combination of attributes

2. Artificial UIDs
- = don’t occur in the natural world but are created for purposes of identification in
a system; ex : id, student numbers, customer IDs, credit card numbers, social
security numbers, passport numbers, shoe ID ,etc.
- Often it is simpler and more straightforward to create an artificial attribute and
make it the UID
- A UID can be both artificial and composite

3. UIDs from Barred Relationships

- Sometimes the UID is a combination of an attribute and a relationship

4. UIDs from Barred Relationships Intersection Entity

5. Artificial UIDs Intersection Entity

- Each MANUFACTURER may produce one or more PRODUCTs
- Each PRODUCT may be produced by one or more MANUFACTURERs
- An item in a catalob can be uniquely identified by the manufacturer number and the product
code, or by an articifiacl UID (catalog number)
6. Candidate UIDs
- Sometimes 2 or more possible UIDs exists
- Only one of the candidate UIDs is chosen as the actual UID that is called the
primary UID
- The other candidates are called secondary UIDs
- Candidate UIDs= one of several UIDs that could be used to identity something
- primary UID =a candidate UID that is the primary identifier of something
- secondary UIDs= a candidate UID that also identifies something, but is not the
primary UID; can be useful as an alternative means of searching for data

7. Identification: Database vs. Real World

- UID make it possible to distinguish one instance of an entity from another
- UID become primary key in the database
- Pk allows you to access a specific record in a database
6-2 Normalization and First Normal Form
- Normalization can go from 1NF all the way to Fifth Normal Form (5FN) and beyond
(6FN and &FN- mostly academic exercises)
- For most business models, 3FN is enough.
- The data modeler’s goal is to eliminate redundancy.
- The rules of normalization are formal statements that can involve complex
language.
- Normalization= a series of steps followed to obtain a database design that allows
for efficient access and storage of data in a relational database. These steps
reduce data redundancy and the chances of data becoming inconsistent.
- One way of stating the normalization rules is that “Every non-UID attribute must
be dependent on the UID, the whole UID, and nothing but the UID”.
- Database designer goals : to store information in one place and in the best possible
place

1. First Normal Form (1FN)

- Requires: No multi-valued attributes exist.
- To check for 1FN: validate that each attribute has a single value for each instance
of the entity

- Classroom is multi- valued and violates 1NF because many classrooms exist in a
school building
- If an attribute is multi-valued: -> create and additional entity an relate it to the
original entity with 1:M relationship
- 1NF eliminates repeating groups (multiple values) within an attribute by
transferring the attribute to a new entity and then connecting the entities with a 1:M
relationship

2. 1FN Violations

3. 1FN Solutions

- First Normal Form requires that there be no multi-valued attributes and no

repeating groups. To check for First Normal Form, validate that each attribute has
a single value for each instance of the entity.
 6-3 Second Normal Form

1. Second Normal Form Example

- If one suppliers supplies ‘n’ different products, then ‘n’ different instances are
created
- If the supplier name will be changed, then would need to be changed in ‘n’
different instances
- The supplier name is dependent only on part of the UID- the supplier number,
and not with the product number

2. Second Normal Form Description

- Requires: any non-UID attribute be dependent on the entire UID
- Following the rules of 2NF allows us to validate that every attribute is in the
correct entity, and identify entities that may have been missed in our original
ERD.
- An entity is considered to be in 2NF if the UID of the entity is simple

3. Second Normal Form Bar Relationship

- This slide example is in 2NF. Both non UID attributes are dependent on both
Account number and Bank number.
- Remember that the Barred Relationship is part of the UID. The UID for
ACCOUNT is the combination of ACCOUNT number and BANK number (from
the Barred relationship).
 4. Second Normal Form Violation
- This is a violation of 2NF, as the bank location attribute is not dependent on the
entire UID for ACCOUNT.
- This attribute should therefore be removed from ACCOUNT and placed in the
BANK entity.

5. Order ERD
6-4 Third Normal Form
- Find transitive dependencies in a data model
- Examine a non-normalized entity

1. Third Normal Form Rule

- No non-UID attribute can be dependent on another non-UID attribute
- 3FN prohibits transitive dependencies
- A transitive dependency exists when any attribute in a entity is dependent on any
other non-UID attribute in that entity
- To check if an entity is in Third Normal Form, examine each non-UID attribute,
and check for Transitive Dependency with other non-UID attributes.

 

2. Third Normal Form Transitive Dependency

- Third Normal Form Violations are hiding another entity.
- For an entity to be in Third Normal Form, it must also be in Second Normal Form.
- To resolve a 3FN violation: create a new Entity, move the attributes that were
causing the violation to the new entity (adding a UID) , and draw a relationship to
the original entity.

3. Third Normal Form Example

- Another way to look at the rule of third Normal Form is: Attributes can’t have
attributes of their own.
4. Third Normal Form Example solution
5.
6.