Posar una base de dades en segon formulari normal
Durant l'últim mes, hem analitzat diversos aspectes de normalitzar una taula de base de dades. En primer lloc, es van tractar els principis bàsics de normalització de la base de dades. L'última vegada, vam explorar els requisits bàsics establerts per la primera forma normal (1NF). Ara, continuem el nostre viatge i cobrem els principis de la segona forma normal (2NF).
Recordeu els requisits generals de 2NF:
- Elimineu subconjunts de dades que s'apliquen a diverses files d'una taula i col·loqueu-les en taules separades.
- Creeu relacions entre aquestes noves taules i els seus predecessors mitjançant l'ús de claus estrangeres.
Aquestes regles es poden resumir en una simple afirmació: 2NF intenta reduir la quantitat de dades redundants en una taula mitjançant l'extracció, col·locant-la en una (s) taula (s) nova i creant relacions entre aquestes taules.
Vegem un exemple. Imagineu una botiga en línia que manté la informació del client en una base de dades. Podrien tenir una sola taula anomenada Clients amb els elements següents:
- CustNum
- Nom
- Cognom
- adreça
- ciutat
- Estat
- ZIP
Una breu mirada a aquesta taula revela una petita quantitat de dades redundants. Estem emmagatzemant les entrades "Sea Cliff, NY 11579" i "Miami, FL 33157" dues vegades cadascuna. Ara bé, pot ser que això no sembli un emmagatzematge massa afegit en el nostre senzill exemple, però imagineu l'espai perdut si teníem milers de files a la nostra taula. A més, si el codi postal de Sea Cliff canviés, haurem de fer aquest canvi en molts llocs de la base de dades.
En una estructura de base de dades compatible amb 2NF, aquesta informació redundant s'extreu i s'emmagatzema en una taula separada. La nostra nova taula (anomenem ZIP) pot tenir els següents camps:
- ZIP
- ciutat
- Estat
Si volem ser super eficients, fins i tot podem omplir aquesta taula amb antelació: l'oficina de correus proporciona un directori de tots els codis postals vàlids i les seves relacions ciutat / estat. Segurament, heu trobat una situació en què es va utilitzar aquest tipus de base de dades. És possible que algú realitzi una comanda que us hagi sol·licitat el vostre codi postal per primera vegada i que, després, coneixeu la ciutat i l'estat de la trucada. Aquest tipus d'arranjament redueix l'error de l'operador i augmenta l'eficiència.
Ara que hem eliminat les dades duplicades de la taula Customers, hem satisfet la primera regla de la segona forma normal. Encara necessitem utilitzar una clau externa per unir les dues taules junts. Utilitzarem el codi postal (la clau principal de la taula ZIP ) per crear aquesta relació. Aquesta és la nostra nova taula de clients:
- CustNum
- Nom
- Cognom
- adreça
- ZIP
Ara hem minimitzat la quantitat d'informació redundant emmagatzemada a la base de dades i la nostra estructura està en la segona forma normal.
Si voleu assegurar-vos que la vostra base de dades estigui normalitzada, explora els nostres altres articles d'aquesta sèrie:
- Fonaments bàsics de normalització de bases de dades
- Posar la vostra base de dades en el primer formulari normal
- Posar la vostra base de dades en segon formulari normal
- Posar la vostra base de dades en el Tercer formulari normal