OtherPapers.com - Other Term Papers and Free Essays
Search

Database Normalization Explanation

Essay by   •  January 13, 2014  •  Essay  •  426 Words (2 Pages)  •  1,611 Views

Essay Preview: Database Normalization Explanation

Report this essay
Page 1 of 2

Database normalization explanation

The normalization level that I chose to use for my database was the 3NF level. This level of normalization was chosen because it would be easy enough to add and delete data to without any complications or problems in the database.

This level of normalization states that and is described as follows (Stephens, 2009):

1. Each column must have a unique name.

2. The order of the rows and columns does not matter.

3. Each column must have a single data type.

4. No two rows can contain identical values

5. Each column must contain a single value.

6. Columns cannot contain repeating groups.

7. All of the non-key fields depend on all of the key fields.

8. It contains no transitive dependencies.

This level is sufficient enough for the database created because many other databases are created at this level of normalization. It is easy to add or delete data to the database in this level and not have to worry about relationships being destroyed or running into major database design flaws. The relationships and keys depend on each other to be in the database and cannot be deleted because the database depends on them. The keys that were chosen to be used in the database were chosen for the fact that the field they are in would never be deleted. This in turn would then make the relationships stronger and enforce them that they would also stay and not be deleted or changed by any alterations to the database.

The changes that were made to the database were more on a formatting need and to identify the entities more in the database and the tables they were included in. There are no other changes that can be thought of to change the database design. Some fields could be shortened and recreated to another field, but then this would leave fields that may possibly end up being empty in the database and have no data. This would be why they would just stay the same with no change to them. This comes into an example when you look at the Own/Lease Field names in the database. In the end though this database design has been gone over many times and evaluated to be the final end product of the database along with the level of normalization. It leaves it easy and simple to understand in the database and formatting and also to add or remove data from the database.

...

...

Download as:   txt (2.3 Kb)   pdf (54.3 Kb)   docx (9.2 Kb)  
Continue for 1 more page »
Only available on OtherPapers.com