Normalització Joan Puigcerver Ibáñez j.puigcerveribanez@edu.gva.es Llicència: CC BY-NC-SA 4.0 (Reconeixement - NoComercial - CompartirIgual) 🅭 Introducció La normalització en les bases de dades relacionals és un procés de disseny que s'utilitza per a organitzar i estructurar les dades de manera eficient, on l'objectiu principal és reduir la redundància i millorar la integritat de les dades. Si és necessari aplicar la normalització, significa que el model d'entitat relació, o la transformació a model relacional no s'ha fet correctament i existeixen atributs redundants; per tant, serveix per a corregir allò que no ha sigut correctament dissenyat. 1NF: Primera Forma Normal La Primera Forma Normal (1NF) especifica que les taules no poden contindre valors repetits i que totes les cel·les d'una taula han de contindre valors atòmics. Un atribut és atòmic si i sols si no es pot dividir en altres atributs, per tant, no es permeten atributs compostos. La millor manera d'evitar valors repetits és definint una clau primària. L'objectiu d'aquesta normalització és augmentar la flexibilitat i la independència de les dades, i simplificar la definició d'aquestes. També obri la porta a una normalització addicional, que elimina la redundància i les anomalies. La majoria de SGBD relacionals no suporten registres ennierats (nested), per tant, les taules estan en primera forma normal per defecte. Exemple 1NF En el cas de la taula PERSONA(#dni, nom, cognom, data_naixement, telefons), podríem trobar els següents valors: Taula Persona #DNI Nom Cognoms Data Naixement Telèfons 91471118A Carles Perelló 08/12/2000 643857623, 638741285, 669852237 23986973C Òscar Peris 02/01/2001 687418459 24211153L Andreu Pastor 02/04/2001 602145235 76064612R Isabel Mora 28/11/2001 674125596, 632147852 Es pot observar que la columna Telèfons emmagatzema múltiples valors i, per tant, aquesta taula no està en Primera Forma Normal. La solució és crear una taula relacional addicional: Taula Persona #DNI Nom Cognoms Data Naixement 91471118A Carles Perelló 08/12/2000 23986973C Òscar Peris 02/01/2001 24211153L Andrès Pastor 02/04/2001 76064612R Isabel Mora 28/11/2001 Taula Telefon_Persona #DNI #Telèfon 91471118A 643857623 91471118A 638741285 91471118A 669852237 23986973C 687418459 24211153L 602145235 76064612R 674125596 76064612R 632147852 2NF: Segona Forma Normal Es diu que una taula relacional està en Segona Forma Normal (2NF) quan està en 1NF, i a més, tots els atributs que no siguen cap clau tenen una dependència funcional completa cap a la clau primària. Es defineix com dependència funcional la relació entre dos atributs en una taula relacional, que defineix la manera en què els valors d'una columna determinen de manera única els valors d'una altra. Hi ha dos tipus: Dependència Funcional Completa: Un atribut Y es diu que està totalment dependent funcionalment de l'atribut \(X\) en una taula si, per a cada valor de \(X\), només hi ha un valor corresponent de \(Y\). En altres paraules, donat un valor específic de \(X\), pots determinar de manera única el valor de \(Y\). Això sol representar-se com \(X → Y\). Dependència Funcional Parcial: Un atribut Y es diu que està parcialment dependent funcionalment de l'atribut \(X\) en una taula si, per a alguns valors de \(X\), hi ha més d'un valor corresponent de \(Y\). En aquest cas, la dependència és parcial, ja que no tots els valors de Y es poden determinar per \(X\). Les dependències funcionals parcials poden provocar anomalies de dades i, generalment, no són desitjables. Exemple Dependència Funcional En el cas de la taula PERSONA(#dni, nom, cognom, data_naixement). Dependència Funcional Completa: \(dni \rightarrow nom\) Donat un DNI sempre pots determinar el nom de la persona. Dependència Funcional Parcial: \(data\_naixement \rightarrow nom\) Donada una data de naixement no pots identificar de manera única al nom d'una persona, ja que múltiples persones amb un mateix nom poden tindre dates de naixement diferents. Exemple 2NF En la taula DETALLS_COMANDA(#id_comanda, #producte, preu_producte, unitats) podríem trobar els següents valors: Taula Detalls Comanda #ID Comanda #Producte Preu Producte Unitats 1 Barra de pa 0.7 2 1 Botella aigua 0.5L 0.3 1 2 Botella aigua 0.5L 0.3 1 2 Pot Coca-Cola 33 cL 1.5 1 2 Napolitana xocolate 1.5 2 Aquesta taula està en 1NF, però, no obstant això, podem determinar que no està en 2NF, ja que l'atribut preu_producte, no té una dependència funcional completa cap a la clau primària (id_comanda, producte), però sí cap a producte. És a dir, el preu del producte no depén de la comanda. Per solucionar-ho, podem separar la informació en dues taules relacionals: Taula Producte #Producte Preu Barra de pa 0.7 Botella aigua 0.5L 0.3 Pot Coca-Cola 33 cL 1.5 Napolitana xocolate 1.5 Taula Detalls Comanda #ID Comanda #Producte Unitats 1 Barra de pa 2 1 Botella aigua 0.5L 1 2 Botella aigua 0.5L 1 2 Pot Coca-Cola 33 cL 1 2 Napolitana xocolate 2 3NF: Tercera Forma Normal Es diu que una taula relacional està en Tercera Forma Normal (3NF) quan està en 2NF, i a més, i que cap atribut no primari és transitivament dependent de la clau primària. Donats els atributs \(A\), \(B\), i \(C\), es diu que \(C\) és transitivament dependent de \(A\) si: \(A \rightarrow B\): \(B\) té una dependència funcional completa amb \(A\). \(B \rightarrow C\): \(C\) té una dependència funcional completa amb \(B\). \[A \rightarrow B \rightarrow C\] Exemple 3NF En la taula TORNEIG(#nom, #edicio, guanyador, data_naixement_guanyador) podríem trobar els següents valors: Taula Torneig #Nom #Edició Guanyador Data Naixement Guanyador Roland Garros 2020 Rafael Nadal 03/06/1986 Roland Garros 2021 Novak Đoković 22/05/1987 Roland Garros 2022 Rafael Nadal 03/06/1986 Roland Garros 2023 Novak Đoković 22/05/1987 Wimbledon 2021 Novak Đoković 22/05/1987 Wimbledon 2022 Novak Đoković 22/05/1987 Wimbledon 2023 Carlos Alcaraz 05/05/2003 Aquesta taula està en 2NF, ja que es pot justificar que tots els atributs no primaris depenen d'una manera funcionalment completa de la clau primària. No obstant això, l'atribut data_naixement_guanyador depén de l'atribut guanyador, on aquest depén de la clau primària (nom, edicio), per tant, l'atribut data_naixement_guanyador té una dependència transitiva amb la clau primària. \[ (nom, edicio) \rightarrow guanyador \rightarrow data\_naixement\_guanyador \] Per solucionar-ho, hem de separar la informació en dues taules relacionals: Taula Torneig #Nom #Edició Guanyador Roland Garros 2020 1 Roland Garros 2021 2 Roland Garros 2022 1 Roland Garros 2023 2 Wimbledon 2021 2 Wimbledon 2022 2 Wimbledon 2023 3 Taula Jugador #ID Nom Data Naixement 1 Rafael Nadal 03/06/1986 2 Novak Đoković 22/05/1987 3 Carlos Alcaraz 05/05/2003 BCNF: Forma Normal de Boyce-Codd Una taula està en Forma Normal de Boyce-Codd (BCNF) si i sols si està en 3NF i totes les relacions de dependència funcional depenen de la clau primària. Aquesta forma normal no és molt comuna, però apareix quan hi ha diferents claus candidates que haurien pogut esdevindre claus primàries i se solapen, és a dir, tenen almenys un atribut comú. Una relació formada pels atributs \(A\), \(B\), \(C\) i \(D\) on hi ha dues claus candidates compostes \((A, B)\) i \((B, C)\) i existeix una dependència funcional en els dos sentits entre \(A\) i \(C\), \((A \longleftrightarrow C)\), pot ser modelada de dues maneres: \(R1(A, C)\) i \(R2(A, B, D)\) \(R1(A, C)\) i \(R2(C, B, D)\) La relació \(R(A, B, C, D)\) no estaria en BCNF. Exemple La taula CONDUCTOR_COTXE(#matricula, n_bastidor, #dni_conductor(PERSONA:#dni), data_inici) podríem trobar els següents valors: Taula Conductor Cotxe #Matrícula N. Bastidor #DNI Conductor Data inici 4231 KJL 16483920 91471118A 08/12/2000 4231 KJL 16483920 24211153L 02/01/2001 4078 CMP 23948756 91471118A 02/04/2001 4078 CMP 23948756 23986973C 28/11/2001 3091 LSF 12347003 23986973C 05/12/2001 3091 LSF 12347003 24211153L 05/12/2001 Aquesta taula està en 3NF, però no en BCNF. En aquest cas, existeixen dues claus candidates matricula i n_bastidor, que poden ser utilitzades indistintament com a clau primària (\(matricula \longleftrightarrow n\_bastidor\)). Per tant, existeixen les relacions: \((matricula, conductor) \rightarrow data\_inici\) \((n\_bastidor, conductor) \rightarrow data\_inici\) Per evitar la redundància de dades i determinar que totes les relacions de dependència han de dependre de la clau primària, podem eliminar les claus candidates que no formen part de la clau primària i emmagatzemar-les en una altra relació. Taula Conductor Cotxe #Matrícula #DNI Conductor Data inici 4231 KJL 91471118A 08/12/2000 4231 KJL 24211153L 02/01/2001 4078 CMP 91471118A 02/04/2001 4078 CMP 23986973C 28/11/2001 3091 LSF 23986973C 05/12/2001 3091 LSF 24211153L 05/12/2001 Taula Cotxe #Matrícula N. Bastidor 4231 KJL 16483920 4078 CMP 23948756 3091 LSF 12347003 4NF: Quarta Forma Normal Una taula està en Quarta Forma Normal (4NF) si i sols si està en 3NF o BCNF (qualsevol de les dues) i no existeixen dependències multivaluades. Una dependència multivaluada es dona en relacions on hi ha almenys tres atributs (\(A\), \(B\) i \(C\)) que formen part de la clau primària de la relació i per a un valor donat de \(A\) existeix un conjunt de valors ben definit dels atributs \(B\) i \(C\), però \(B\) i \(C\) són independents entre ells. Podeu consultar la definició formal a: https://en.wikipedia.org/wiki/Multivalued_dependency Exemple 4NF En la taula RESTAURANT_TIPUSPIZZA_AREAENVIAMENT(#restaurant, #tipus_pizza, #area_enviament) podríem trobar els següents valors: Taula Restaurant / Tipus Pizza / Àrea Enviament #Restaurant #Tipus Pizza #Àrea Enviament Vincenzo's Pizza Vora grossa Russafa Vincenzo's Pizza Vora grossa Mislata Vincenzo's Pizza Vora fina Russafa Vincenzo's Pizza Vora fina Mislata Elite Pizza Vora fina Universitats Elite Pizza Vora farcida Universitats A1 Pizza Vora grossa Russafa A1 Pizza Vora grossa Mislata A1 Pizza Vora grossa Universitats A1 Pizza Vora farcida Russafa A1 Pizza Vora farcida Mislata A1 Pizza Vora farcida Universitats Cada fila indica que un restaurant concret pot entregar un tipus de pizza donat en una zona donada, el que podria constituir una relació ternària. Aquesta taula està en FNBC, ja que sols conté una clau primària única i no té cap atribut no-clau. No obstant això, si la varietat de la pizza és independent de l'àrea d'enviament, existeix una dependència multivaluada i una redundància de les dades. Si A1 Pizza comença a produir pizzes del tipus Vora de formatge, hem d'afegir un registre per cada àrea d'enviament. Per satisfer la 4NF cal separar cada relació en una taula: Taula Restaurant / Tipus Pizza #Restaurant #Tipus Pizza Vincenzo's Pizza Vora grossa Vincenzo's Pizza Vora fina Elite Pizza Vora fina Elite Pizza Vora farcida A1 Pizza Vora grossa A1 Pizza Vora farcida Taula Restaurant / Àrea Enviament #Restaurant #Àrea Enviament Vincenzo's Pizza Russafa Vincenzo's Pizza Mislata Elite Pizza Universitats A1 Pizza Russafa A1 Pizza Mislata A1 Pizza Universitats No obstant això, si les varietats de pizza que poden ser oferides per un restaurant varien dependent de l'àrea d'enviament, la taula original sí que satisfaria la 4FN. 5NF: Quinta Forma Normal Una taula està en Quinta Forma Normal (5NF), també coneguda com la Forma Normal de Projecció-Unió (PJ/NF), si i sols si està en 4NF i cada dependència d'unió en ella està implicada amb claus candidates i no existeixen restriccions imposades per la base de dades. Explicació i exemple: Quinta Forma Normal - Wikipedia Desnormalització El procés de normalització implica la creació de taules relacionals addicionals per evitar la redundància de dades, però pot afectar el rendiment de les bases de dades, ja que el motor de bases de dades ha de relacionar i combinar els valors de moltes taules per realitzar les consultes. El procés de desnormalització consisteix en la duplicació intencionada de les dades per evitar crear moltes taules addicionals i afectar el rendiment i la complexitat del disseny de la base de dades. Normalment, es busca un equilibri entre buscar que la redundància de dades siga mínima, sense afectar massa el rendiment de la base de dades. Un bon nivell per parar està entre 3NF, BCNF i 4NF, encara que està bé considerar totes les possibilitats i triar entre els dissenys resultants. https://stackoverflow.com/questions/2065227/when-is-a-good-time-to-break-normalization-rules https://stackoverflow.com/questions/12327859/what-is-the-best-normal-form-in-large-scale-system Bibliografia Ahijado Sánchez, A, Bases de datos, Ed. Marcombo. https://en.wikipedia.org/wiki/First_normal_form https://es.wikipedia.org/wiki/Tercera_forma_normal https://es.wikipedia.org/wiki/Forma_normal_de_Boyce-Codd https://en.wikipedia.org/wiki/Fourth_normal_form https://en.wikipedia.org/wiki/Multivalued_dependency https://en.wikipedia.org/wiki/Denormalization 📌 Aquest document pot quedar desactualitzat després d’imprimir-lo. Pots consultar la versió més recent a la pàgina web. 🌿 Abans d’imprimir aquest document, considera si és realment necessari. Redueix el consum de paper i ajuda a protegir el nostre entorn.

CC BY-NC-SA 4.0 (Reconeixement - NoComercial - CompartirIgual) 🅭 Joan Puigcerver Ibáñez