Gua de Estudio

Diseo y normalizacin de bases de datos relacionales

Diseando la Base de Datos.
Para disear una base de datos se parte de la recoleccin de atributos o campos que va a tener,
y de la defnicin de sus tipos de dato. a manera m!s pro"esional es realizando el an!lisis de
requisitos con todas las personas que van a #acer uso de los datos. Pero por e$periencia ya
sabes que esto se #ace muy a o%o& piden realizar una aplicacin y se'(n los requisitos de la
aplicacin #aces el diseo de la BD.
El primer m)todo est! m!s estandarizado, y suele ser m!s lento pero a cambio es improbable
que el diseo salga mal. El se'undo es ms rpido porque directamente se piensa en las tablas y
sus datos sobre la marc#a. *e utiliza principalmente en la metodolo'a de pro'ramacin
conocida como +pro'ramacin e$trema, y en las dem!s de la "amilia +desarrollo !'il de
so"t-are,. y es ms propenso a fallos de diseo, proporcionalmente inversos al tiempo que se
dedique a su defnicin y valoracin /m!s tiempo, menos probabilidad de "allos0.
Normalizacin de una base de datos.
a normalizacin es un mtodo de anlisis de BD para conseguir una BD relacional , que respete
la integridad referencial, y que no ten'a redundancia de datos. *e divide en "ormas normales, y
aunque #ay un montn y es toda una ciencia, e$plicar) por encima las 1 primeras ya que el nivel
3 es sufciente para la mayora de casos.
2ay que destacar que la normalizacin se puede #acer a nivel completo de la BD, o a nivel de
tablas o esquemas. a t)cnica es la misma& analizar el con%unto de campos y en base a eso
desi'nar una clave inicial que identifque a un 'rupo de datos. Por e%emplo si estamos
normalizando todo un esquema de "acturacin podemos partir de los datos del cliente aadiendo
la clave del cliente, y se'(n vayamos normalizando nos saldr!n todas las tablas y les iremos
dando claves primarias nuevas. *i lo que normalizamos es una tabla, el procedimiento es el
mismo y ya ir!n saliendo otras tablas subordinadas si acaso.a normalizacin se adopt porque
el vie%o estilo de poner los datos en un solo lu'ar, como un arc#ivo o una tabla de la base de
datos, era inefciente y conduca a errores de l'ica cuando se trataba de manipular los datos.
Por lo tanto, el proceso de normalizacin de bases de datos consiste en aplicar una serie de
re'las a las relaciones obtenidas tras el paso del modelo entidad3relacin al modelo relacional.
as bases de datos relacionales se normalizan para&
Evitar la redundancia de los datos.
Evitar problemas de actualizacin de los datos en las tablas.
Prote'er la inte'ridad de los datos.
B!sicamente, en un proceso de conversin de las relaciones entre las entidades, evitando&
a redundancia de los datos& repeticin de datos en un sistema.
4nomalas de actualizacin& inconsistencias de los datos como resultado de datos redundantes y
actualizaciones parciales.
4nomalas de borrado& p)rdidas no intencionadas de datos debido a que se #an borrado otros
datos.
4nomalas de insercin& imposibilidad de adicionar datos en la base de datos debido a la
ausencia de otros datos.
En el modelo relacional es "recuente llamar tabla a una relacin, aunque para que una tabla sea
considerada como una relacin tiene que cumplir con al'unas restricciones&
5ada tabla debe tener su nombre (nico.
6o puede #aber dos flas i'uales. 6o se permiten los duplicados.
7odos los datos en una columna deben ser del mismo tipo.
as reglas de !odd
4dem!s de la normalizacin #ay unas re'las, las re'las de 5odd, que a"udan a disear una BD
relacional perfecta /desde el punto de vista de 5odd, claro0 que merece la pena estudiarlas pues
son casi de lgica com#n y nos #ar!n la vida m!s "!cil en todos los sentidos. a idea de estas
8
re'las sur'i porque la normalizacin no era sufciente para que una BD fuera relacional$
consistente e independiente.
2ay ocasiones en las que los diseadores de las BD con"eccionan la BD para satis"acer
necesidades l'icas y "uncionales de una aplicacin, por e%emplo almacenando los datos en un
"ormato que lue'o la aplicacin se encar'a de trans"ormar. Esto es bastante tpico cuando el
diseador es el pro'ramador de la aplicacin, y lo #ace por comodidad o "alta de conocimiento.
a morale%a es que una BD debe ser independiente de la aplicacin, y si lo piensas bien es me%or
as. *e'(n las re'las de 5odd la BD tiene que ser completamente operativa desde su lengua%e de
consultas /tpicamente *90, y las restricciones en los datos deben ser propiedad de la BD /no
vale controlar la entrada desde la aplicacin0. 5on esto conse'uiremos que mediante el *9 no
se puedan realizar operaciones que #a'an que la aplicacin no "uncione /introduciendo datos en
un "ormato inesperado para la aplicacin, por e%emplo0, y entre otras cosas, que si tenemos que
realizar in"ormes puntuales o sacar listados los podremos #acer desde un simple cliente y sin
tener que parsear nada ni realizar consultas sobre consultas.
Defnicin de la clave
4ntes de proceder a la normalizacin de la tabla lo primero que debemos de defnir es una clave,
esta clave deber! contener un valor (nico para cada re'istro /no podr!n e$istir dos valores
i'uales en toda la tabla0 y podr! estar "ormado por un (nico campo o por un 'rupo de campos.
Claves primarias: se llama clave primaria a un campo, o a una combinacin de campos, que
identifca en "orma (nica a cada re'istro. Por e%emplo, para una tabla de clientes se podra usar,
como clave primaria, una de las si'uientes opciones&
a c)dula de identidad del cliente.
a combinacin de nombre y apellido. Esto es dudoso, ya que un dos clientes pueden tener el
mismo nombre y el mismo apellido.
:n cdi'o de cliente, asi'nado por la empresa.
:na clave primaria es aquella columna /pueden ser tambi)n dos columnas o m!s0 que identifca
(nicamente a esa fla. a clave primaria es un identifcador que va a ser (nico para cada fla. *e
acostumbra poner la clave primaria como la primera columna de la tabla pero esto no tiene que
ser necesario, si no es m!s una conveniencia. ;uc#as veces la clave primaria es autonum)rica.
En una tabla puede que ten'amos m!s de una clave, en tal caso se puede esco'er una para ser
la clave primaria, las dem!s claves son las claves candidatas. 4dem!s es la posible clave
primaria.
:na clave "or!nea es aquella columna que e$istiendo como dependiente en una tabla, es a su
vez clave primaria en otra tabla.
:na clave alternativa es aquella clave candidata que no #a sido seleccionada como clave
primaria, pero que tambi)n puede identifcar de "orma (nica a una fla dentro de una tabla.
E%emplo& *i en una tabla clientes defnimos el n(mero de documento /id<cliente0 como clave
primaria, el n(mero de se'uro social de ese cliente podra ser una clave alternativa. En este caso
no se us como clave primaria porque es posible que no se conozca ese dato en todos los
clientes.
:na clave compuesta es una clave que est! compuesta por m!s de una columna.
&rados de normalizacin
E$isten b!sicamente tres niveles de normalizacin& Primera =orma 6ormal /86=0, *e'unda =orma
6ormal />6=0 y 7ercera =orma 6ormal /16=0. 5ada una de estas "ormas tiene sus propias re'las.
5uando una base de datos se con"orma a un nivel, se considera normalizada a esa "orma de
normalizacin. 6o siempre es una buena idea tener una base de datos con"ormada en el nivel
m!s alto de normalizacin, puede llevar a un nivel de comple%idad que pudiera ser evitado si
estuviera en un nivel m!s ba%o de normalizacin.
En 'eneral, las primeras tres "ormas normales son sufcientes para cubrir las necesidades de la
mayora mayora de las bases de datos. El creador de estas 1 primeras "ormas normales /o
re'las0 "ue 'dgar (. !odd.
En la tabla si'uiente se describe brevemente en qu) consiste cada una de las re'las, y
posteriormente se e$plican con m!s detalle.
>
?e'la Descripcin
Primera =orma 6ormal /8=60
@ncluye la eliminacin de todos los 'rupos
repetidos.
*e'unda =orma 6ormal />=60
4se'ura que todas las columnas que no son llave
sean completamente dependientes de la llave
primaria /PA0.
7ercera =orma 6ormal /1=60
Elimina cualquier dependencia transitiva. :na
dependencia transitiva es aquella en la cual las
columnas que no son llave son dependientes de
otras columnas que tampoco son llave.
!onceptos usados en la normalizacin
Dependencia =uncional. Es la relacin que e$iste entre dos atributos. E%emplo&
Dado un valor de B e$iste un valor de C entonces C es "uncionalmente dependiente de C.
E;PE4DD
5od<empleado 6ombre
EE8 Fuan Perez
EE> 4na 9uiroz
B C
5laves o llaves.3 Es el atributo que le da la di"erencia a cada tabla este atributo #ace que no
ten'amos tuplas o flas repetidas.
5od<cliente 6ombre<cliente
EE8 Fuan Perez
EE> 4na 9uiroz
EE1 4na 9uiroz
EEG Fuan Perez
EEH Fos) opez
Dependencia transitoria.3 Es la dependencia que esta encadenada.
B C I J Dado un valor de +B, e$iste un valor de +C, y dado un valor de +C, e$iste un valor
de +I, entonces se dice que +z, es transitivamente dependiente de +B,.
6ormalizando la BD& primera "orma normal /8=60
:na tabla est! en Primera =orma 6ormal si&
Eliminar la repeticin de 'rupos /redundancia de datos0
5rear una tabla di"erente para cada con%unto de datos relacionados.
1
7odos los atributos son atmicos. :n atributo es atmico si los elementos del dominio son
indivisibles, mnimos.
a tabla contiene una clave primaria unica.
a clave primaria no contiene atributos nulos.
6o debe de e$istir variacin en el n(mero de columnas.
os 5ampos no clave deben identifcarse por la clave.
Debe E$istir una independencia del orden tanto de las flas como de las columnas, es decir, si los
datos cambian de orden no deben cambiar sus si'nifcados
:na tabla no puede tener m(ltiples valores en cada columna. os datos son atmicos. /*i a cada
valor de B le pertenece un valor de C y viceversa0. Esta "orma normal elimina los valores
repetidos dentro de una BD
No se permiten vectores de campos en una columna.
:n e%emplo de esto es cuando en un campo de te$to metemos varios valores del mismo dominio,
como por e%emplo tres n(meros de tel)"ono, o dos direcciones e3mail. o tpico en estos casos es
separar los datos por comas, espacios u otro car!cter y despu)s procesarlo mediante la
aplicacin. Para evitar esto )a" que defnir una nueva tabla que tendr! el identifcador de la
tabla de la que parte y el campo multivaluado, #aciendo %untos de clave #nica compuesta /se
puede defnir otra incremental si se desea, pero el con%unto de los otros dos campos tiene que
ser #nico0. 4dem!s en esta tabla se puede a're'ar campos que ayuden a describir el tipo de
re'istro.
'%emplo
@ncorrecto
5lientes
@D5lient
e
6ombre 7ele"ono
GH
=rancisc
o
GGGGGGGGG
>KH ;i'uel
HHHHHHHHH,LLLLLLL
LL
5orrecto
5lientes 7ele"onos<cliente
@D5lient
e
6ombre
GH
=rancisc
o
>KH ;i'uel
No se permiten grupos repetidos en varias columnas
Esto es una variante de lo anterior& separamos los campos de un mismo
dominio en varias columnas, #aciendo un 'rupo di"cilmente
procesable a la #ora de consultarlo. En el e%emplo anterior sera tener el campo tele"ono8,
tele"ono>M y as. Es evidente que este "allo del diseo es incluso peor que el anterior pues )abr
muc)os campos nulos, y en caso de necesitar m!s tendramos que redimensionar la tabla con un
nuevo campo /tele"ono10. Pero la solucin es sencilla& la misma que en el anterior caso.
'%emplo
@ncorrecto
5lientes
@D5lient
e
6ombre 7ele"ono 7ele"ono>
7ele"ono
1
GH =rancisc GGGGGGGG 6: 6:
G
@D5lient
e
7ele"ono
GH
GGGGGGGG
G
>KH
HHHHHHHH
H
>KH
LLLLLLLL
L
o G
>KH ;i'uel
HHHHHHHH
H
LLLLLLLL
L
6:
5orrecto
5lientes tele"onos<cliente
@D5lient
e
6ombre
GH
=rancisc
o
>KH ;i'uel
No se permiten campos nulos
Esta re'la es al'o discutible, pero tiene su l'ica. Para empezar, si un
campo va a tener valores nulos, Nqu) proporcin de re'istros tendr!n ese
campo con valor nuloO En mi opinin esta re'la nos ayuda a separar unas entidades de otras,
porque si una cantidad de re'istros tienen unos atributos que otros no, Nno ser! que pertenecen
a otra claseO Por e%emplo, si en una tabla de productos defnimos los campos talla, Pilates y
potencia se ve que los productos tendr!n clases diversas y entonces #abr! que crear una
entidad para cada clase /ropas, %oya y el)ctricos, por e%emplo0 construyendo lo que se llama una
generalizacin.
'%emplo
@ncorrecto
productos
@DProduct
o
6ombre 7alla
Ailate
s
Potenci
a
8GK Blusa "as#ion GG 6: 6:
8HH Broc#e duquesa 6: >G 6:
>>8
*ub-oo"er
e$treme
6: 6: 8HEE
5orrecto
Productos ropas
@DProduct
o
6ombre
8GK Blusa "as#ion
8HH Broc#e duquesa
>>8
*ub-oo"er
e$treme
Foyas electricos
@DProduct
o
Ailate
s
8HH >G
6ormalizando la BD& se'unda "orma normal />=60
H
@D5lient
e
7ele"ono
GH
GGGGGGGG
G
>KH
HHHHHHHH
H
>KH
LLLLLLLL
L
@DProduct
o
7alla
8GK GG
@DProduct
o
Potenci
a
>>8 8HEE
*e'unda "orma normal se refere a las relaciones y dependencias "uncionales entre atributos noQ
claves.
:na entidad que cumplas *e'unda "orma normal tiene que tener las si'uientes caractersticas&
a entidad debe estar en primera "orma normal.
9ue todos los atributos no claves sean dependientes totalmente de la clave primaria
@ndicando los dos puntos de una "orma di"erente, eliminar los campos que son independientes de
la clave principal.
5rear una nueva tabla para separar la parte parcialmente dependientes de la clave principal y
sus dependientes campos.
Dependencia "uncional&
Es una cone$in entre uno o m!s atributos, es decir, es una relacin entre > atributos de una
tabla. Por e%emplos si conocemos el valor de =ec#a De 6acimiento podemos conocer el valor de
Edad.
as dependencias "uncionales del sistema se escriben utilizando una Rec#a, de la si'uiente
manera&
=ec#aDe6acimiento Edad
4qu a =ec#aDe6acimiento se le conoce como un determinante. *e puede leer de dos "ormas
=ec#aaDe6acimiennto determina Edad o Edad es "uncionalmente dependiente de
=ec#aDe6acimiento. De la normalizacin /l'ica0 a la implementacin /"sica o real0 puede ser
su'erible tener )stas dependencias "uncionales para lo'rar la efciencia en las tablas. =i'ura G.
'%emplo*
:na tabla est! en se'unda "orma normal siempre que est) en primera "orma normal y todos sus
atributos /campos0 dependan totalmente de la clave candidate sin ser parte de ella. Siene a ser
que, si un campo de la tabla no depende totalmente de una clave (nica /que pueden ser
compuestas0, debe sacarse "uera con la parte de la clave principal de la que es dependiente.
Dtro e%emplo TD6@, @D<P?DCE57DU 2D?4*<7?4B4FD /con el D6@ de un empleado y el @D de un
proyecto sabemos cu!ntas #oras de traba%o por semana traba%a un empleado en dic#o proyecto0
es completamente dependiente dado que ni D6@ 2D?4*<7?4B4FD ni @D<P?DCE57D
2D?4*<7?4B4FD mantienen la dependencia. *in embar'o TD6@, @D<P?DCE57DU
L
6D;B?E<E;PE4DD es parcialmente dependiente dado que D6@ 6D;B?E<E;PE4DD
mantiene la dependencia.
E%emplo
@ncorrecto
lineas<pedido
@D5lient
e
@DProduct
o
5antida
d
6ombre<producto
>V G> 8 Iapatillas deportivas de tenis
GL V H
Baln re'lamentario de
baloncesto
>EG G> 8 Iapatillas deportivas de tenis
8GG 8E 8
Iapatillas deportivas de
ru'by
5orrecto
lineas<pedido productos
@D5lient
e
@DProduct
o
5antida
d
>V G> 8
GL V H
>EG G> 8
8GG 8E 8
5omo vemos en la tabla +lineas<pedido, del e%emplo incorrecto, la (nica clave candidata es
@D5liente W @DProducto, ya que en con%unto son #nicas en la tabla /podramos tener un
@Dinea<pedido (nico tambi)n, pero a(n as esos dos campos se'uran siendo una clave
candidata0. El campo 5antidad es dependiente de la clave candidata, pues el cliente #a pedido
de ese producto una cantidad determinada de artculos, pero el nombre en cambio es
dependiente slo del producto$ no del cliente. *i de%aramos esa tabla como est!, tendramos por
una parte una redundancia de datos innecesaria pues el nombre del producto lo podemos sacar
uniendo la tabla de productos, y adem!s podran darse inconsistencias de datos si cambiamos el
nombre del producto en un re'istroM Ncu!l sera el nombre real del producto G> si en varios
re'istros tiene un nombre distintoO
!onclusiones
Por lo tanto los pasos para aplicar la se'unda "orma normal son muy sencillos& encontrar las
claves candidatas /compuestas0, que identifcan de manera (nica el re'istro. comprobar que los
campos que no "orman parte de la clave candidata y no son parte de ella /en el e%emplo de antes
ni @D5liente ni @DProducto deben ser analizados0 dependen totalmente de la clave candidata.
Para el se'undo paso puede ayudar pre'untarse lo si'uiente&
Npuedo saber el valor del campo B sabiendo el valor del campo C /siendo C parte de la clave
candidata y B no siendo parte de ella0O Pero como todo lo relacionado con el an!lisis esto
requiere un mnimo de a'udeza, pues puede que casualmente el valor de un campo se repita
para una parte de la clave /por casualidad todos los que compran unas pelotas de tenis lo #acen
en cantidades de H0 pero sabemos que no es dependiente de ella.
Por (ltimo, aclarar que #ay ocasiones en las que el anlisis no tiene que ser tan cerrado, ya que
a veces las apariencias en'aan. :n e%emplo de ello es una tabla de "acturas que tiene el
nombre, direccin, 6@=, y dem!s datos del cliente& a simple vista esos datos estn duplicados "
dependen del cliente " no de la factura, pero resulta que esos datos deben permanecer a# pues
K
@DProduct
o
6ombre<producto
V
Baln re'lamentario de
baloncesto
8E
Iapatillas deportivas de
ru'by
G> Iapatillas deportivas de tenis
fscalmente debemos saber a qu) datos se emiti una "actura. esos datos son realmente
dependientes de la factura$ no del cliente. *i no los incluy)ramos en la tabla de "acturas, al
modifcar el re'istro del cliente en la tabla de clientes no sabramos a qu) datos fscales se
emiti la "actura. 4s que una vez m!s, #ay que utilizar un poco de in'enio y no aplicar normas
como una mquina " sin pensar.
6ormalizando la BD& tercera "orma normal /1=60
7ercera "orma normal se refere a las relaciones y dependencia "uncional transitiva entre los
atributos no3clave.
Para que una entidad est) en tercera "orma normal deben cumplirse dos condiciones&
9ue la entidad est) en se'unda "orma normal.
9ue todos los atributos no claves son independientes del resto de los atributos no clave.
5onsiste en eliminar la dependencia transitiva que queda en una se'unda "orma normal, en
pocas palabras una relacin esta en tercera "orma normal si est! en se'unda "orma normal y no
e$isten dependencias transitivas entre los atributos, nos re"erimos a dependencias transitivas
cuando e$iste m!s de una "orma de lle'ar a re"erencias a un atributo de una relacin.
Para defnir "ormalmente la 1=6 necesitamos defnir dependencia "uncional transitiva.
*ean +$ ,$ - tres atributos /o 'rupos de atributos0 de la misma entidad. *i , depende
"uncionalmente de + y - de ,, pero + no depende "uncionalmente de ,, se dice entonces que -
depende transitivamente de +. *imblicamente sera&
+ , - entonces + -
(ec)aDeNacimiento 'dad
'dad !onducir
(ec)aDeNacimiento 'dad !onducir
Entonces tenemos que (ec)aDeNacimiento determina a 'dad y la 'dad determina a !onducir,
indirectamente podemos saber a trav)s de (ec)aDeNacimiento a !onducir /En muc#os pases,
una persona necesita ser mayor de cierta edad para poder conducir un automvil, por eso se
utiliza este e%emplo0.
4#ora bien, para estar m!s claro con la defnicin tenemos que una relacin est! en tercera
"orma normal si,3MM
:na tabla est! en tercera "orma normal siempre que est) en se'unda "orma normal /y por
consi'uiente en primera0 y todos sus campos no primarios /campos que no "orman parte de una
clave candidata0 dependen #nicamente de la clave candidata. *uena como la se'unda "orma
X
normal, pero es muy distinta& ning#n campo que no sea parte de la clave candidata puede
depender
de otro campo que no sea la clave candidata.
E%emplo
@ncorrecto
car'a<diaria
@D*ervido
r
=ec#a
@D*ervici
o
6ombre<servic
io
5ar'
a
>8
>EEV3E83
8G
8 Dracle 8EE
>8
>EEV3E83
8H
V ;y*9 8EE
>8
>EEV3E83
8L
>> 4pac#e XH
1G
>EEV3E83
8G
1 Post're*9 KG
1G
>EEV3E83
8H
>> 4pac#e HX
1G
>EEV3E83
8L
>> 4pac#e LK
LL
>EEV3E83
8G
V ;y*9 VX
LL
>EEV3E83
8H
>> 4pac#e VG
LL
>EEV3E83
8L
8 Dracle 8E' XG
5orrecto
car'a<diaria servicios
@D*ervido
r
=ec#a
@D*ervici
o
5ar'
a
@D*ervici
o
6ombre<servic
io
>8
>EEV3E83
8G
8 8EE 8 Dracle
>8
>EEV3E83
8H
V 8EE V ;y*9
>8
>EEV3E83
8L
>> XH >> 4pac#e
1G
>EEV3E83
8G
1 KG 1 Post're*9
1G
>EEV3E83
8H
>> HX >> 4pac#e
1G
>EEV3E83
8L
>> LK >> 4pac#e
LL
>EEV3E83
8G
V VX V ;y*9
LL
>EEV3E83
8H
>> VG >> 4pac#e
LL
>EEV3E83
8L
8 XG 8 Dracle 8E'
V
@ma'inad que una tabla se encar'a de re'istrar el primer servicio que m!s car'a los servidores
cada da. Del e%emplo incorrecto deducimos que el @D*ervidor y la =ec#a son la clave candidata,
pues identifcan de manera #nica los registros. 4nalizando vemos que el @D*ervicio, que no es un
campo primario, depende (nicamente de la clave candidata, y que la car'a tambi)n. Pero resulta
que el 6ombre<servicio depende de esa clave candidata pero tambi)n depende del @D*ervicio,
pues con el .D/ervicio podemos averiguar qu Nombre0servicio tiene el registro. Para solucionar
esto sacamos el campo 6ombre<servicio de la tabla, y nos llevamos el .D/ervicio para que sea la
clave principal pues es el campo del que depende.C con este e%emplo vemos qu) "!cil es
librarnos de las inconsistencias de no cumplir la tercera "orma normal, y de la redundancia de
datos. *i no #ubieramos normalizado tendramos que en un re'istro el @D*ervicio >> es 4pac#e y
nadie nos ase'ura que en otro el @D*ervicio >> tambi)n lo sea pues puede #aberse modifcado el
campo 6ombre<servicio. C si resulta que la tabla "uese un #istrico de HEE servidores durante
8EEE das, tendramos HEE mil re'istros con un campo innecesario que estar1a duplicado
muc#simas veces.
Diseando la BD sobre la marcha
*i en vuestro desempeo #abitual del traba%o os encontr!is con que no pod)is aplicar, de una
manera "ormal y detallada, la normalizacin a la #ora de disear BD, no os alarm)is pues le pasa
a muc#a 'ente. o que puede ocurrir es que nos quede una BD no relacional, y eso es siempre
ne'ativo, pero a base de e$periencia ir)is adquiriendo una soltura " capacidad anal1tica
automticas.
a normalizacin, al basarse en re'las l'icas, se puede memorizar muy "!cilmente y al fnal
forma parte del instinto del diseador& no necesitar)is bol'ra"o y papel para ver que una tabla
no est! normalizada. De #ec#o cuando sep!is que datos necesita la aplicacin pensar)is
directamente en las tablas que saldr!n.
Primero, documentarse
o m!s importante para disear la BD sobre la marc#a es tener la mente amplia$ conocer las
bases de la normalizacin$ " de%arse aconse%ar por los e2pertos. 7odo esto de las BD relacionales
no es nuevo y #ay muc#os 'ur(s /5odd, Ed'ar =ranP 5odd, es el padre de todos0 que os pueden
ayudar a entender qu) caractersticas debe cumplir una BD para ser relacional. De modo que si
no sab)is del tema, lo me%or es que os olvidis de las malas enseanazas que ten'!is imbuidas&
una BD con muc#as tablas no est mal diseada /una con pocas es m!s probable que s lo est)0.
llevarse el cdi'o del cliente a todas las tablas /lo necesiten o no0 no es la forma de tener una
BD relacional. 'uardar los datos serializados en un campo no te )ace la vida ms fcil. tener un
campo que #ace re"erencia a una tabla unas veces y a otra en otras ocasiones no es un buen
diseo /un campo referencial slo puede referenciar a una tabla, as que usad la 'eneralizacin
en esas situaciones0.
Errores #abituales
:n error #abitual a la #ora de usar este m)todo de diseo es tener un campo re"erencial que
admite valores nulos o vacos /tpico clave<re"erencia E cuando no re"erencia a nada0. *i la BD es
relacional, un campo referencial tiene que apuntar a otro registro en la BD. 4 veces tenemos un
campo @DPadre que #ace re"erencia a un mismo re'istro de la tabla, o vale E cuando el re'istro
es padre en sM pero lo correcto en una relacin re3e2iva /una tabla relacionada consi'o misma0
que da lu'ar a otro tabla que contiene el @D2i%o y el @DPadre. consultando esa tabla podemos
saber si un re'istro es #i%o /tiene entradas con su @D en @D2i%o0 o padre /su @D est! en al'(n
@DPadre0 y sacar todos los #i%os de un padre.
!onse%os*Dtro buen conse%o, que no est! limitado a este m)todo de disear, es tener en cuenta
el tamao de las tablas en cuanto a lon'itud de fla /en bytes0. De #ec#o recuerdo que me
#ablaron de una re'la de diseo de BD que deca que una tabla no deba contener m!s de B
camposM y bueno, siempre es discutible pero es m!s ptimo que la lon'itud de la fla no sea
muy lar'a, sobre todo en las tablas que se consultan con frecuencia. Es una pr!ctica muy
8E
recomendada que si tenemos campos 'randes, tipo 7EB7 o BDB, saquemos esos datos a otra
tabla para que las b(squedas y FD@6 'enerales que no necesiten ese campo sean ms rpidas.
2ay que tener en cuenta que el sistema de 'estin de BD /*GBD0 en ocasiones no puede
optimizar las consultas y necesita escanear por completo la tabla, o tiene que volcarla a la
memoria "sica o virtual.
En defnitiva& recordad que una BD relacional no puede ser dependiente de la aplicacin, sino al
rev)s. 4s que olvidaros de disearla pensando qu) es lo me%or para la aplicacin, y pensad qu
es lo correcto para que sea ms ptima " sencilla de mane%ar independientemente del cliente
que la mane%e /aplicacin, consultas directas, #erramientas de in"ormeM0.
88