Aplicacions Web

Introducció a la normalització de bases de dades

30 d'octubre de 2021

Tenir dades coherents, no redundants i relacionables al base de dades és molt beneficiós. Amb aquesta finalitat, el normalització de bases de dades es realitza el procés. Som molt conscients que la base de dades és un sistema que organitza qualsevol dada de manera estructurada. Per tant, el normalització de bases de dades El procés us permet gestionar les dades de les bases de dades d'una manera ben estructurada i precisa.

Taula de continguts

Què és la normalització de bases de dades?

El normalització de bases de dades procés elimina redundància de dades i millora Integritat de les dades . Redundància de dades implica dades repetitives. Ocupa un espai més gran al disc i provoca un malbaratament de memòria del disc. Si es modifiquen les dades d'un sol lloc, s'han de canviar a totes les ubicacions on estiguin presents. Per tant, no és factible tenir dades redundants i repetitives a les taules de la base de dades.

Un altre terme, Integritat de les dades , significa la integritat i la coherència de les dades. Les dades de la base de dades han de ser precises i significatives. Per tant, per garantir la integritat i la no repetitivitat de les dades, s'utilitza la normalització de la base de dades.

A més d'eliminar la redundància de dades i millorar la integritat de les dades, el normalització de bases de dades El procés elimina diverses anomalies de la base de dades, com ara la inserció, la supressió i l'actualització. Una anomalia a la base de dades debilita la integritat de les dades.

L'objectiu principal de la normalització és dividir taules o relacions més grans de la base de dades en taules més petites i introduir la relació entre elles. Cada taula o relació hauria de tenir uns valors d'atribut, anomenats valors atòmics. La taula de la base de dades només hauria de tenir les dades relacionables i no cap altra dada irrellevant.

Objectius de la normalització de bases de dades

Quan normalitzeu la base de dades, assegureu-vos d'assolir els objectius següents:

  • Les dades de la base de dades s'han d'emmagatzemar de manera lògica. Les taules més grans s'agrupen en taules més petites. Cada grup més petit ha de reflectir la part del grup més gran.
  • Redundància de dadess'hauria d'eliminar ja que consumeix una quantitat més massiva d'espai de base de dades.
  • Assegureu-vos que la vostra base de dades sigui coherent. Qualsevol modificació a la base de dades, com ara la inserció, la supressió i una actualització, no hauria de perjudicar la integritat de les dades.
  • Si les mateixes dades estan presents en diferents ubicacions, cal que les modifiqueu a totes les àrees. Mentre normalitzeu la base de dades, assegureu-vos que només heu d'actualitzar les dades en una única ubicació.

Anomalies en la normalització de bases de dades

En a gestió de bases de dades sistema (DBMS), hi ha tres tipus diferents d'anomalies, a saber, inserció, supressió i actualització. Aquestes tres anomalies afecten el principi d'integritat de les dades.

imatge 617dd30c81f8b

Parlem de cadascuna de les tres anomalies. Però, primer considerem una relació o taula Employee. Té quatre atributs, Emp_ID, Emp_Name, Emp_Add i Ep_Dept, que emmagatzemen les dades dels empleats.

Empleat

Emp_IDEmp_NomEmp_AddEmp_Dept
301JoanCalifòrniaD01
301JoanCalifòrniaD022
323SammyWashington dcD08
366efecteChicagoD10
366efecteChicagoD14

La taula anterior emmagatzema les dades dels empleats. Però, no està en una forma normalitzada. Quan la taula no està d'una manera normalitzada, és possible que tingueu diversos problemes mentre s'interessen dades noves, esborran les dades existents o actualitzen les dades actuals.

    Insereix:

L'anomalia d'inserció no permet als usuaris afegir cap dada nova a la base de dades. Això es deu a l'absència d'algunes dades específiques. Tingueu en compte la relació anterior amb els empleats. Si algun empleat nou s'incorpora a l'empresa i no se li assigna cap departament, les dades d'aquest empleat en concret no es poden inserir a la taula. Això és perquè no podem inserir NULL a Emp_Dept.

    Suprimeix:

Una altra anomalia és l'anomalia de supressió. En aquesta circumstància, la supressió de dades no seria factible, ja que podria provocar la pèrdua de dades. Considereu la taula d'empleats anterior. Suposem que es tanca el departament D08, les dades relacionades amb Sammy s'eliminarien de la taula de l'empleat. Per tant, l'empresa perdrà les dades de Sammy, ja que només treballa en un departament.

    Actualització:

Una anomalia d'actualització és un altre element que produeix inconsistència de dades. Prenem un exemple de la taula de l'empleat per entendre una anomalia d'actualització. Penseu en l'empleat John, que treballa als departaments D01 i D022. Si voleu modificar l'adreça de John, heu d'actualitzar les dues files de D01 i D022; pot danyar el principi d'integritat de les dades. Si l'adreça es canvia en una fila i l'altra es manté igual que l'anterior, s'acaba amb una anomalia d'actualització.

El normalització de bases de dades és útil per eliminar les tres anomalies anteriors que donen lloc a una taula de base de dades feble. Hi ha diverses regles o formes de normalització. Abans d'aprofundir en les formes de normalització, primer aprendrem diferents tipus de claus en el sistema de bases de dades. Heu de conèixer els tipus de claus abans d'aprendre la normalització de la base de dades.

Claus a la base de dades

Les claus de la base de dades tenen un paper fonamental a l'hora d'identificar les dades presents en ella. Amb les tecles, podeu trobar qualsevol dada de la taula de manera ràpida i senzilla. Les taules grans es divideixen en de més petites i s'utilitzen claus per connectar les taules més petites.

Vegeu també Els 20 millors programes de gestió de flux de treball normalització de bases de dades

Vegem els diferents tipus de claus utilitzades al SGBD.

    Clau primària:

El clau primària és un atribut de la taula que identifica qualsevol fila o tupla de manera única. Heu de triar la clau primària que trobarà de manera única les dades de la taula.

Considereu una relació d'empleat. Té atributs com Emp_ID, Emp_Name, Emp_Add, Passport_Number i License_Number. La clau principal de la relació de l'empleat serà Emp_ID, ja que identificarà de manera única les dades de cada empleat. A més, Passport_Number i License_Number també poden servir com a claus primàries, ja que són úniques per a cada empleat.

    Clau del candidat:

El clau del candidat de qualsevol taula és un conjunt d'atributs mínims i pot identificar qualsevol fila de manera única en la relació. Hi pot haver una o més claus candidates per a una única relació.

Considereu la relació anterior de l'empleat. Hem vist que la clau principal és Emp_ID, que és única i no repetitiva per a tots els empleats. Els altres dos atributs, Passport_Number i License_Number, tampoc no són repetitius. Per tant, tots dos poden servir com a claus candidates.

    Super clau:

Com el clau primària i clau del candidat identifica cada tupla de manera única, la superclau també ajuda a trobar la tupla única de la taula. La clau candidata és el subconjunt de la superclau. Hi pot haver una o moltes súper claus.

Utilitzarem la mateixa relació d'empleat per tenir una idea clara sobre la superclau. L'atribut Emp_ID pot esbrinar de manera única les dades de qualsevol empleat. L'atribut Emp_Name no es pot utilitzar com a clau primària, ja que dos empleats poden tenir el mateix nom. Però, la combinació de Emp_ID i Emp_Name pot trobar les dades dels empleats de manera única. Per tant, (Epm_ID, Emp_Name) serveix com a superclaus per a la relació de l'empleat.

Passprt_Number i License_Number també són súper claus de la relació Employee.

    Clau estrangera:

La clau estrangera és força diferent de les tres claus anteriors. S'utilitza per establir una connexió entre dues relacions. Considereu dues relacions A i B. Suposem que qualsevol atribut de la relació A és la clau primària de la relació B; aquest atribut es coneix com a clau estrangera.

Mirarem l'exemple senzill per entendre el concepte de clau estrangera. Posem l'exemple dels treballadors de l'empresa. Cada empleat està assignat a diferents departaments. Per tant, fem servir dues relacions, Empleat i Departament.

Definim les relacions amb els empleats com a empleat ( Emp_ID , Emp_Name, Passport_Number, License_Number, Dept_ID) i la relació del departament com a departament ( Dept_ID , Nom_departament).

A la relació Employee, Emp_ID és la clau primària, mentre que Dept_ID és la clau primària de la relació de departament. L'atribut Dept_Id és un atribut de la relació Employee, que és la clau principal de la relació Departament. Per tant, Dept_ID serveix com a clau estrangera.

    Clau composta:

Una clau composta és un grup d'atributs que troba de manera única les dades dels empleats de la relació. La clau composta és la combinació de dos i més de dos atributs.

A partir de la relació de treballador anterior Emp ( Emp_ID , Emp_Name, Passport_Number, License_Number), la clau composta és (Emp_name, Emp_ID).

Abans de la normalització de dades, un altre concepte que heu d'aprendre són les dependències funcionals juntament amb els tipus de clau. Feu-nos saber les dependències funcionals en detall.

Dependències funcionals a la base de dades

E.F. Codd va desenvolupar el concepte de dependència funcional per evitar o eliminar dades redundants. La dependència funcional és la relació entre dos atributs o columnes qualsevol de la mateixa relació. En altres paraules, un atribut troba un altre atribut de manera única. Tots dos atributs pertanyen a la mateixa relació.

Per exemple, considereu dues columnes, A i B, de la mateixa taula. La dependència funcional existeix entre A i B només si la columna A troba de manera única la columna B. Es representa com A -> B i es llegeix com que B depèn funcionalment d'A. Podeu referir-vos a A com a determinant i B com a dependent. .

Hi ha diferents tipus de dependències funcionals. Vegem aquí algunes d'aquestes dependències funcionals.

    Dependència funcional trivial:

Considereu dos atributs, A i B, de la mateixa relació. La dependència funcional trivial només es manté si B és el subconjunt de A.

A -> B, si B és el subconjunt de A.

Penseu en una relació amb un empleat. Preneu dos atributs, Emp_ID i Emp_Name. L'atribut Emp_Id depèn funcionalment de {Emp_ID, Emp_Name}.

{Emp_ID, Emp_Name} -> Emp_ID

Aquí, Emp_ID és el subconjunt de l'{Emp_ID, Emp_Name}. Per tant, {Emp_ID, Emp_Name} -> Emp_ID és una dependència funcional trivial.

    Dependència funcional no trivial:

La dependència funcional no trivial és el contrari de la dependència funcional trivial. Pren dues columnes, P i Q, de la mateixa relació. La dependència funcional no trivial es manté si Q no és el subconjunt de P.

P -> Q, si Q no és el subconjunt de P

Si P intersecció Q és NULL, aleshores és una dependència funcional no trivial completa.

Considereu les tres columnes de la relació Employee, Emp_ID, Emp_Name i Emp_Add.

Vegeu també Les 15 millors eines de reparació de Windows

Emp_ID -> Emp_Name

La dependència anterior és una dependència funcional no trivial, ja que Emp_Name no és el subconjunt de Emp_ID.

    Dependència funcional transitiva:

Una dependència funcional transitiva implica dues dependències funcionals diferents. Es forma indirectament implicant dues dependències. Considereu tres atributs, A, B i C, de la mateixa taula. La dependència trivial A -> C es compleix, si

  • A -> B
  • B no té A
  • B -> C

Considereu la taula Estudiants. Preneu tres columnes, Stud_ID, Stud_Name i Stud_Age. La dependència funcional transitiva Stud_ID -> Stud_Age es manté, si

  • Stud_Id -> Stud_Name
  • Stud_Name no conté Stud_Id.
  • Stud_Name -> Stud_Age

Per tant, si coneixem el DNI de l'alumne, podem esbrinar la seva edat.

    Dependència multivalorada:

Per a un únic determinant en qualsevol dependència funcional, hi ha dos o més dependents. Considereu la dependència funcional X -> Y. En la dependència multivalor, per a cada X, hi ha múltiples valors de Y.

Per satisfer la dependència multivalor, hi hauria d'haver un mínim de tres atributs a la relació. Per exemple, R(X, Y, Z). Si hi ha una dependència funcional multivalor entre X i Y, aleshores els atributs Y i Z haurien de ser independents entre si.

Hem vist tots els elements essencials necessaris per entendre el normalització de bases de dades . Ara, anem cap al tema central, el normalització de bases de dades formes.

    Uneix-te a la dependència:

Considereu una relació R amb atributs A, B, C i D. La relació R es descomposa en les altres dues relacions, R1 i R2, on R1 té atributs A, B i C, i R2 té atributs C i D. Si unim R1 i R2 utilitzant l'atribut comú, C, i la relació resultant és la mateixa que la de R, aleshores el unir-se a la dependència existeix.

El unir-se a la dependència es diu que no té pèrdues si els atributs de la relació resultants després de la unió són els mateixos que els atributs de R.

Diferents formes de normalització de bases de dades

Diverses formes de normalització de bases de dades estan desenvolupats per eliminar i millorar la redundància de dades Integritat de les dades . A continuació es mostren els diferents formularis de normalització de bases de dades, juntament amb les seves instàncies.

normalització de bases de dades
    Primera forma normal (1NF):

La primera forma de normalització de bases de dades és la primera forma normal. La relació de base de dades es troba en la primera forma normal només quan tots els seus atributs tenen un valor únic o atòmic. Cap atribut de la taula ha de contenir diversos valors. Vegem un exemple de com la taula compleix amb la primera forma normal.

Penseu en una taula d'empleats, amb Emp_ID, Emp_Name, Emp_Add i Emp_Mobile_Number com a atributs.

Empleat

Emp_IDEmp_NomEmp_AddEmp_Mobile_Number
E01JoanNova Delhi8389097676
E02MichelleBombai7878689878
E03SamRanchi98765432197656463686
E04OliverCalcuta9087654547

La taula anterior no es troba en la primera forma normal (1NF); com a empleat, Sam té dos números de mòbil. Per tant, la taula anterior no compleix la primera forma normal. La primera forma normal estableix que cada atribut hauria de tenir un valor atòmic. Per tant, hem de fer la taula anterior en la primera forma normal.

Empleat 1

Emp_IDEmp_NomEmp_AddEmp_Mobile_Number
E01JoanNova Delhi8389097676
E02MichelleBombai7878689878
E03SamRanchi9876543219
E03SamRanchi7656463686
E04OliverCalcuta9087654547

La relació Employee1 anterior es troba en la primera forma normal, ja que cada atribut té un únic valor.

Abans de començar la segona forma normal, heu de conèixer els atributs primers i no primers. L'atribut principal és el que està present a la clau candidata. I l'atribut no primer és el que no està present a la clau candidata.

    Segona forma normal (2NF):

Un altre normalització de bases de dades forma és la segona forma normal. Qualsevol relació o taula de base de dades compleix amb la segona forma normal si compleix les condicions següents:

  • La taula ha de complir la primera forma normal.
  • Qualsevol atribut no primer de la taula no hauria de dependre del subconjunt adequat de la clau candidata.

Podeu tenir una idea clara de la segona forma normal després de mirar l'exemple següent.

Considereu una relació de professor amb Teacher_Id, Subject i Teacher_Age com a atributs. La taula és la següent:

Mestra

Teacher_IDAssignaturaProfessor_Edat
T01Java35
T01Estructures de dades35
T02Python35
T03Estructures de dades40
T03DBMS40

Aquí, les claus candidates són {Teacher_ID, Subject}, que cerca de manera única les dades dels professors. Com que l'atribut Teacher_Age no es troba a la clau candidata, funciona com a atribut no principal.

Després de mirar la relació anterior, podem concloure que la taula compleix amb la primera forma normal de normalització de bases de dades . Cada atribut té un sol valor. Però, no està en la segona forma normal. Només podem identificar l'edat de qualsevol professor mitjançant l'atribut Teacher_ID. Com que Teacher_Age és un atribut no principal i Teacher_ID és el subconjunt adequat de la clau candidata, trenca la regla 2NF.

Per fer la relació anterior en la segona forma normal, hem de dividir-la en dues taules de la següent manera:

Vegeu també 16 solucions per a la ubicació no disponible al problema de l'iPhone

Professor_Edat

Teacher_IDProfessor_Edat
T0135
T0235
T0340

Assignatura

Teacher_IDAssignatura
T01Java
T01Estructures de dades
T02Python
T03Estructures de dades
T03DBMS

Les dues relacions anteriors es troben en la segona forma normal.

    Tercera forma normal:

La tercera forma normal és el niu normalització de bases de dades forma. Es diu que qualsevol relació està a la tercera normal si compleix les condicions següents:

  • La relació ha de complir amb la segona forma normal (2NF).
  • Qualsevol atribut no primer no hauria de tenir una dependència funcional transitiva de la superclau.

També podeu definir la tercera forma normal de normalització de bases de dades ja que la taula hauria d'estar a la 2NF i la dependència funcional X -> Y hauria de seguir qualsevol de les condicions següents:

  • X hauria de ser la superclau de la relació.
  • Y hauria de ser l'atribut principal de la relació.

Veurem com la taula compleix amb la tercera forma normal. Considereu una relació d'empleat que tingui Emp_ID, Emp_Name, Emp_Zip, Emp_State, Emp_City i Emp_District. Aquesta relació es representa de la següent manera:

Empleat

Emp_IDEmp_NomEmp_ZipEmp_EstatEmp_CityEmp_District
E01Joan267778MaharashtraKalyanBombai
E02Sam234567Tamil NaduChennaiM-Ciutat
E06Johnny278967UttarakhandPauriBhagwan
E07Rosa209876Tamil NaduChennaiUrrapakkam.
E08Steve215647Madhya PradeshGwaliorRatan

Les súper claus de la relació Employee són {Emp_ID}, {Emp_ID, Emp_Name}, {Emp_ID, Emp_Name, Emp_Zip} i moltes altres. La clau candidata és {Emp_ID}. Per tant, l'EMP_ID és l'atribut principal i tots els altres són atributs no primers.

Podeu veure que els tres atributs, Emp_State, Emp_City i Emp_District, depenen funcionalment de l'atribut Emp_Zip. Podem trobar el número postal mitjançant l'atribut Emp_ID. Per tant, Emp_Zip depèn d'Emp_ID.

Els tres atributs, Emp_State, Emp_City i Emp_District, són atributs no principals. Depenen indirectament de l'atribut Emp_ID, que trenca les regles 3NF. Perquè la relació de l'empleat compleixi amb la tercera forma normal (3NF), hem de dividir la taula en taules més petites de la següent manera:

ID_empleat

Emp_IDEmp_NomEmp_Zip
E01Joan267778
E02Sam234567
E06Johnny278967
E07Rosa209876
E08Steve215647

Employee_Zip

Emp_ZipEmp_EstatEmp_CityEmp_District
267778MaharashtraKalyanBombai
234567Tamil NaduChennaiM-Ciutat
278967UttarakhandPauriBhagwan
209876Tamil NaduChennaiUrrapakkam.
215647Madhya PradeshGwaliorRatan

Les dues taules anteriors es troben en la tercera forma normal.

    Forma normal de Boyce Codd (BCNF):

La forma normal de Boyce Codd normalització de bases de dades és una versió ampliada del 3NF. Es coneix com a 3.5NF. Qualsevol taula o relació compleix amb el BCNF si compleix les condicions següents:

  • La relació ha d'estar en la tercera forma normal (3NF).
  • Per a qualsevol dependència funcional A -> B de la relació, A hauria de ser la superclau.

Podeu entendre clarament el concepte BCNF a través d'un exemple d'empleats que treballen en departaments de diverses empreses. Considereu una relació d'empleats amb Emp_ID, Emp_Nationality, Emp_Department, Dept_Type, No_of_Employees com a atributs. La relació té els valors següents:

Empleat

Emp_IDEmp_NacionalitatEmp_DepartamentDept_TypeNo_d'empleats
E01indiProduccióD01250
E01indiGestióD02300
E02americàSuport tècnicD03400
E02americàCompraD04450

El candidat per a la relació anterior és {Emp_ID, Emp_Dept}. Ni l'atribut Emp_ID únic pot proporcionar la informació del departament, ni Emp_Dept pot determinar la informació dels empleats. Per tant, la relació anterior no compleix amb el BCNF. Per fer la taula anterior a BCNF, dividiu-la en tres taules de la següent manera:

Empleat_Nacionalitat

Emp_IDEmp_Nacionalitat
E01indi
E02americà

Aquí, Emp_ID és la clau candidata. La dependència funcional és Emp_ID -> Emp_Nationality. Per tant, està al BCNF.

Departament_empleat

Emp_DepartamentDept_TypeNo_d'empleats
ProduccióD01250
GestióD02300
Suport tècnicD03400
CompraD04450

Aquí, Emp_Dept és la clau candidata i la dependència funcional és {Emp_Dept -> Dept_Type, No_of_Employees}. Per tant, la relació anterior també compleix amb BCNF.

Employee_ID_Dept

Emp_IDEmp_Dept
E01Producció
E01Gestió
E02Suport tècnic
E02Compra

Per a aquesta relació, Emp_ID i Emp_Dept, totes dues són les claus candidates.

    Quarta forma normal (4NF):

Hem vist la dependència multivalora a la secció anterior. Es diu que la taula està en la quarta forma normal si conté totes les condicions següents:

  • La relació ha de complir amb la forma normal de Boyce Codd.
  • No hi hauria d'haver cap dependència multivalor entre els atributs de la taula.

Parlarem de la quarta forma normal utilitzant la relació d'estudiants. La relació Estudiants té tres atributs. Stud_ID, Stud_Course i Stud_Hobby. Els valors de la taula són els següents:

Estudiants

Stud_IDStud_CursStud_Hobby
S01MatemàtiquesHoquei
S01FísicaTennis
S02ProgramacióHoquei
S02QuímicaTennis

La relació anterior no es troba en la quarta forma normal (4NF), ja que té dependències multivalorades. Els atributs Stud_Course i Stud_Hobby depenen de l'atribut Stud_ID, que acaba en una dependència multivalor. Per tant, per fer la relació anterior a 4NF, hem de dividir la relació en dues relacions diferents de la següent manera:

Estudiants_Curs

Stud_IDStud_Curs
S01Matemàtiques
S01física
S02Programació
S02Química

Estudiants_Hobby

Stud_IDStud_Hobby
S01Hoquei
S01Tennis
S02Hoquei
S02Tennis

Les dues relacions anteriors es troben en la quarta forma normal.

    Cinquena forma normal:

Un altre normalització de bases de dades forma és la cinquena forma normal. També es coneix com la Forma Normal de Projecte-Join (PJ/NF). Qualsevol relació compleix la cinquena forma normal si compleix les condicions següents:

  • La taula es troba en la quarta forma normal (4NF).
  • No hi hauria d'haver cap dependència d'unió i la unió de relacions hauria de ser sense pèrdues.

Per entendre el concepte de la cinquena forma normal, veurem un exemple de la relació Facultat.

Facultat

Fac_TemaFac_NomFac_Sem
Ciències de la ComputacióJoanSem 1
Ciències de la ComputacióOliverSem 1
Electrònica i TelecomunicacióOliverSem 1
Electrònica i TelecomunicacióSteveSem 2
MecànicaEsteveSem 1

La relació de Facultat no compleix la cinquena forma normal (5NF). Per fer la relació de Facultat en la cinquena forma normal, descompondre-la en tres relacions diferents, tal com es mostra a continuació:

Facultat 1

Fac_SemFac_Tema
Sem 1Ciències de la Computació
Sem 1Electrònica i Telecomunicació
Sem 1Mecànica
Sem 2Electrònica i Telecomunicació

Facultat 2

Fac_SemFac_Nom
Sem 1Joan
Sem 1Oliver
Sem 1Oliver
Sem 2Steve
Sem 1Esteve

Facultat 3

Fac_TemaFac_Nom
Ciències de la ComputacióJoan
Ciències de la ComputacióOliver
Electrònica i TelecomunicacióOliver
Electrònica i TelecomunicacióSteve
MecànicaEsteve

Les tres relacions anteriors es troben en la cinquena forma normal.

Conclusió

El normalització de bases de dades El procés és extremadament útil per eliminar dades repetitives i millorar el principi d'integritat de les dades. A més, estalvia espai al disc eliminant les dades redundants de la base de dades. Quan passeu per aquesta publicació, entendreu diferent normalització de bases de dades formes i tipus de dependència funcional.

Les claus són els elements primaris de la base de dades. Permeten als usuaris recuperar dades de manera ràpida i eficient. Hem cobert els tipus de claus, clau primària, clau candidata, clau super, clau estrangera i clau composta.

El contingut d'aquest article us proporcionarà una breu idea sobre els diferents tipus de dependències funcionals. Hem tractat sis tipus diferents normalització de bases de dades formes, 1NF, 2NF, 3NF, BCNF, 4NF i 5NF i els seus respectius exemples. Esperem que trobeu tota la informació necessària per estudiar el normalització de bases de dades formes.