CET-BENI

BASE DE DATOS I

NormalizacindeBasesdeDatos

Bsicamente,lasreglasdeNormalizacinestnencaminadasaeliminarredundanciase
inconsistenciasdedependenciaeneldiseodelastablas.Mstardeexplicarloqueesto
significamientrasvemosloscincopasosprogresivosparanormalizar,tienesqueteneren
cuentaquedebescrearunaBDfuncionalyeficiente.Tambiendetallarlostiposde
relacionesquetuestructuradedatospuedetener.

Digamosquequeremoscrearunatablaconlainformacindeusuarios,ylosdatosa
guardarsonelnombre,laempresa,ladireccindelaempresayalgunemail,obien
URLsilastienen.Enprincipiocomenzariasdefiniendolaestructuradeunatablacomo
esta:

FormalizacinCERO

usuarios
nombre empresa direccion_empresa url1 url2
Joe ABC 1WorkLane abc.com xyz.com
Jill XYZ 1JobStreet abc.com xyz.com

DiramosquelaanteriortablaestaenniveldeFormalizacionCeroporqueningunade
nuestrasreglasdenormalizacinhasidoaplicada.Observaloscamposurl1yurl2
Quharemoscuandoennuestraaplicacinnecesitemosunaterceraurl?Quieres
tenerqueaadirotrocampo/columnaatutablaytenerquereprogramartodalaentrada
dedatosdetucdigoPHP?Obviamenteno,tuquierescrearunsistemafuncionalque
puedacreceryadaptarsefcilmentealosnuevosrequisitos.Hechemosunvistazoalas
reglasdelPrimerNiveldeFormalizacinNormalizacin,ylasaplicaremosanuestra
tabla.

PrimerniveldeFormalizacin/Normalizacin.(F/N)

1. Eliminarlosgruposrepetitivosdelatablasindividuales.
2. Crearunatablaseparadaporcadagrupodedatosrelacionados.
3. Identificarcadagrupodedatosrelacionadosconunaclaveprimaria.
CET-BENI
BASE DE DATOS I

Vesqueestamosrompiendolaprimerareglacuandorepetimosloscamposurl1
yurl2?Yquepasaconlaterceraregla,laclaveprimaria?Lareglatres
bsicamente significa que tenemos que poner una campo tipo contador
autoincrementableparacadaregistro.Deotraforma,Qupasariasituvieramos
dosusuariosllamadosJoeyqueremosdiferenciarlos.Unavezqueaplicaramosel
primerniveldeF/Nnosencontrariamosconlasiguientetabla:

usuarios
userId nombre empresa direccion_empresa url
1 Joe ABC 1WorkLane abc.com
1 Joe ABC 1WorkLane xyz.com
2 Jill XYZ 1JobStreet abc.com
2 Jill XYZ 1JobStreet xyz.com

Ahora diremos que nuestra tabla est en el primer nivel de F/N. Hemos
solucionadoelproblemadelalimitacindelcampourl.Perosinembargovemos
otros problemas....Cada vez que introducimos un nuevo registro en la tabla
usuarios,tenemosqueduplicarelnombredelaempresaydelusuario.Noslo
nuestraBDcrecermuchsimo,sinoquesermuyfacilquelaBDsecorrompa
siescribimosmalalgunodelosdatosredundantes.Aplicaremospueselsegundo
niveldeF/N:

SegundoniveldeF/N

1. Creartablasseparadasparaaquellosgruposdedatosqueseaplicanavarios
registros.
2. Relacionarestastablasmedianteunaclaveexterna.

Hemosseparadoelcampourlenotratabla,deformaquepodemosaadirmsen
elfuturositenerqueduplicarlosdemsdatos.Tambienvamosausarnuestra
claveprimariapararelacionarestoscampos:

usuarios
userId nombre empresa direccion_empresa
1 Joe ABC 1WorkLane
2 Jill XYZ 1JobStreet

urls
urlId relUserId url
CET-BENI
BASE DE DATOS I

1 1 abc.com
2 1 xyz.com
3 2 abc.com
4 2 xyz.com

Vale,hemoscreadotablasseparadasylaclaveprimariaenlatablausuarios,userId,esta
relacionadaahoraconlaclaveexternaenlatablaurls,relUserId.Estoestamejor.Pero
que ocurre cuando queremos aadir otro empleado a la empresa ABC ? o 200
empleados?Ahoratenemoselnombredelaempresaysudireccinduplicandose,otra
situacinquepuedeinducirnosaintroducirerroresennuestrosdatos.Asquetendrmos
queaplicareltercerniveldeF/N:

TercerniveldeF/N.

1. Eliminaraquelloscamposquenodependandelaclave.

NuestronombredeempresaysudireccinnotienennadaqueverconelcampouserId,
asiquetienenquetenersupropioempresaId:

usuarios
userId nombre relEmpresaId
1 Joe 1
2 Jill 2

empresas
emprId empresa direccion_empresa
1 ABC 1WorkLane
2 XYZ 1JobStreet

urls
urlId RelUserId url
1 1 abc.com
2 1 xyz.com
3 2 abc.com
4 2 xyz.com

Ahoratenemos laclaveprimariaemprIdenla tablaempresas relacionadaconlaclave

externarecEmpresaIdenlatablausuarios,ypodemosaadir200usuariosmientrasqueslo
tenemosqueinsertarelnombre'ABC'unavez.
Nuestras tablas de usuarios y urls pueden crecer todo lo que quieran sin
duplicacinnicorrupcindedatos.Lamayoriadelosdesarrolladoresdicenque
eltercerniveldeF/Nessuficiente,quenuestroesquemadedatospuedemanejar
facilmentelosdatosobtenidosdeunacualquierempresaensutotalidad,yenla
mayoriadeloscasosestosercierto.

PerohechemosunvistazoanuestrocampourlsVesduplicacindedatos?
Estoesperfectamenteaceptablesilaentradadedatosdeestecampoessolicitada
alusuarioennuestraapliacinparaquetecleelibrementesuurl,yporlotantoes
slounacoincidenciaqueJoeyJillteclearonlamismaurl.Peroquepasasien
lugardeentradalibredetextousramosunmendesplegablecon20oincluso
msurlspredefinidas?EntoncestendramosquellevarnuestrodiseodeBDal
siguienteniveldeF/N,elcuarto,muchosdesarrolladoreslopasanporalto
porquedependemuchodeuntipomuyespecficoderelacin,larelacin'varios
convarios',lacualannohemosencontradennuestraaplicacin.

RelacionesentrelosDatos

AntesdedefinirelcuartoniveldeF/N,veremostrestiposderelacionesentrelos
datos:unoauno,unoconvariosyvariosconvarios.Miralatablausuariosen
elPrimerNiveldeF/Ndelejemplodearriba.Porunmomentoimaginmosque
ponemoselcampourlenunatablaseparada,ycadavezqueintroducimosun
registroenlatablausuariostambienintroducimosunasolafilaenlatablaurls.
Entoncestendramosunarelacionunoauno:cadafilaenlatablausuariostendra
exactamenteunafilacorrespondienteenlatablaurls.Paralospropsitosde
nuestraaplicacinnoseratillanormalizacin.

AhoramiralastablasenelejemplodelSegundoNiveldeF/N.Nuestrastablas
permitenaunslousuariotenerasociadasvariasurls.Estaesunarelacinuno
convarios,eltipoderelacinmscomn,yhastaquesenospresenteldilema
delTercerNiveldeF/N.lanicaclasederelacinquenecesitamos.

Larelacinvariosconvarios,sinembargo,esligeramentemscompleja.
ObservaennuestroejemplodelTercerNiveldeF/Nquetenemosaunusuario
relacionadoconvariasurls.Comodijmos,vamosacambiarlaestructurapara
permitirquevariosusuariosestenrelacionadosconvariasurlsyastendremos
unarelacinvariosconvarios.Veamoscomoquedarannuestrastablasantesde
seguirconesteplanteamiento:

usuarios
userId nombre relEmpresaId
1 Joe 1
2 Jill 2

empresas
emprId empresa direccion_empresa
 1 ABC 1WorkLane
2 XYZ 1JobStreet

urls
urlId url
1 abc.com
2 xyz.com

url_relations
relationId relatedUrlId relatedUserId
1 1 1
2 1 2
3 2 1
4 2 2

Paradisminuirladuplicacindelosdatos(esteprocesonosllevaral
CuartoNiveldeF/N),hemoscreadounatablaqueslotieneclaves
externasyprimariasurl_relations.Hemossidocapacesderemoverla
entradasduplicadasenlatablaurlscreandolatablaurl_relations.Ahora
podemosexpresarfielmentelarelacinqueambosJoeandJilltienen
entrecadaunodeellos,yentreambos,lasurls.Asqueveamos
exctamentequeesloqueelCuartoNiveldeF/N.supone:

CuartoNiveldeF/N.

1. Enlasrelacionesvariosconvarios,entidadesindependientesnopueden
seralmacenadasenlamismatabla.

Ya que slo se aplica a las relaciones variosconv arios, la mayoria de los

desarrolladorespuedenignorarestaregladeformacorrecta.Peroesmuytilen
ciertas situaciones, tal como esta. Hemos optimizado nuestra tabla urls
eliminadoduplicadosyhemospuestolasrelacionesensupropiatabla.

Osvoyaponerunejemploprtico,ahorapodemosseleccionartodaslasurlsde
JoerealizandolasiguienteinstruccinSQL:

SELECT nombre, url FROM usuarios, urls, url_relations WHERE

url_relations.relatedUserId=1ANDusuarios.userId=1ANDurls.urlId=
url_relations.relatedUrlId

Ysiqueremosrecorrertodaslasurlsdecadaunodelosusuarios,hariamosalgo
as:

SELECT nombre, url FROM usuarios, urls, url_relations WHERE

usuarios.userId = url_relations.relatedUserId AND urls.urlId =
url_relations.relatedUrlId
QuintoNiveldeF/N.

Existeotroniveldenormalizacinqueseaplicaaveces,peroesdehechoalgoesotrico
yenlamayoriadeloscasosnoesnecesarioparaobtenerlamejorfuncionalidadde
nuestraestructuradedatosoaplicacin.Suprincipiosugiere:

1. Latablaoriginaldebeserreconstruidadesdelastablasresultantesenlascualesa
sidotroceada.

Los beneficios de aplicar esta regla aseguran que no has creado ninguna columna
extraaentustablasyquelaestructuradelastablasquehascreadoseadeltamaojusto
quetienequeser.Esunabuenaprcticaaplicaresteregla,peroanoserqueestes
tratandoconunaextensaestructuradedatosprobablementenolanecesitars.