Blog 4
Posted by Sarah Leichty
My Summary:
I learned that normalizing a design in a relational database is smart in order to avoid being redundant and making mistakes if one part of the record is updated and the rest are not (Second Normal Form). I would definitely consider using this in the future in order to avoid a mistake such as the one mentioned in the article about not having the correct warehouse address in the record if the record is not correctly updated whenever the part stored in the warehouse changes. I would be very disappointed in that situation if I wasted time looking for a part that wasn’t housed where it said it was. Next, I learned to be careful not to have two or more non-keys that relate to each other in a table (Third Normal). Also, care needs to be taken to provide unique identifiers to fields in order to establish functional dependencies. Another thing to keep in mind is separating many-to-many relationships so as to create more than one record for those relationships (Fourth Normal). For example, if I have taken multiple soils courses and become proficient in multiple lab techniques, I would put those in two separate records. This could come in handy in the future since I will be able to tell if the different relationships are connected and can be in the same record or need to reside in different records.Subsequently, I learned that even though more record types may be needed, the actual number of record ocurrances could be smaller than if all were in one record (Fifth Normal). While the article admits that redundancies will occur based on if the relationship between the records are dependent rather than independent, normalization could still help limit that number.
