NORMALIZACIN

(1) Normalizar, por qu normalizar?

La normalizacin es un ejercicio de sentido comn convenientemente traducido a un
lenguaje formal que, por cierto, nosotros no vamos a utilizar para conseguir esquemas
de base de datos eficientes. El trmino clave es redundancia. No la queremos. La
odiamos.
El ejemplo clsico es el vecino que un da descubri el Access dentro de su disco duro y
que a fuerza de autoaprendizaje ha declarado al mundo que las bases de datos son su
pasin. Regenta un kiosko de peridicos que, como es habitual, tambin vende chuches y
juguetillos de plstico de todo a 1. Pues este seor nuestro ha diseado la siguiente
base de datos, consistente en una nica tabla.
artculo descripcin precio dni
P1

Informacin 1,10

nombre localidad

21 22 Pepe

fecha

El Campello 1/1/2009

El problema de ser un feliz de la vida, en estas cosas concretamente, es que claves

primarias o ajenas son artefactos perfectamente prescindibles. Qu hay ms elegante
que una tabla donde pongo qu vendo y a quin se lo vendo? Bueno, vamos a suponer
que tus clientes no huyen de tu kiosko porque cada vez que se llevan el Informacin les
preguntas por su DNI, nombre y localidad de residencia. Supongamos que Pepe es as de
majo, y vuelve.
artculo descripcin precio dni

nombre localidad

fecha

P1

Informacin 1,10

21 22 Pepe

El Campello 1/1/2009

P1

Informacin 1,10

21 22 Pepe

El Campello 2/1/2009

La paciencia es una virtud pero t ya te ests agobiando y empiezas a meter gazapos.

artculo descripcin precio dni

nombre localidad

fecha

P1

Informacin 1,10

21 22 Pepe

El Campello 1/1/2009

P1

Informacin 1,10

21 22 Pepe

El Campello 2/1/2009

P1

Informasin 1,20

2122 Peper

El Camello 3/1/2009

Hasta ahora, la cosa es manejable, pero supongamos que tu kiosko es el nico en 100 Km
a la redonda y no hay ms narices que ir al tuyo para conseguir la prensa: 1000? 10.000?
100.000 filas?
La redundancia es eso, repetir informacin innecesariamente. Un mal diseo como este
genera problemas de integridad de datos. Existe una poblacin que se llama El
Camello o es que tus gordos dedos se han comido una p? Pepe tiene dos nombres?
(1)

Qu peridico es el Informasin? Si era el Informacin, por qu le has cobrado 10

cntimos de ms?
Eliminar la redundancia, normalizar esta tabla, consiste en separar los datos que son de
uno y de otro y relacionar esta informacin.
CLIENTE
dni

nombre localidad

2 12 2 Pepe

El Campello

ARTCULO
artculo descripcin precio
P1

Informacin 1,10

V E N TAS
artculo cliente fecha
P1

2122

1/1/2009

P1

2122

2/1/2009

P1

2122

3/1/2009

Obviamente, la clave primaria de Ventas, junto con la fecha, es la composicin de dos

claves ajenas definidas para asegurar la integridad referencial, y dni y artculo son las
claves primarias de sus respectivas tablas.
Durante un par de semanas profundizaremos en los problemas que genera un mal diseo
del esquema de base de datos relacional y en cmo tratar las dependencias funcionales
implcitas en la propia definicin de los datos a manejar. En un principio, la
normalizacin era el proceso de diseo de bases de datos relacionales. Ahora hay otros
mtodos y modelos mucho ms cmodos y ricos, la normalizacin se puede ver como la
justificacin de por qu los esquemas son como son pero, tambin, como un
procedimiento de verificacin de la calidad de un diseo.
En definitiva, una herramienta ms que incrementar nuestra habilidad para decir cosas
con el modelo relacional.

(2) problemas del esquema relacional

Una vez obtenido el esquema relacional resultante del esquema entidad/relacin que
representa la base de datos, normalmente tendremos una buena base de datos. Pero
otras veces, debido a fallos en el diseo o a problemas indetectables, tendremos un
esquema que puede producir una base de datos que incorpore estos problemas:
Redundancia. Se llama as a los datos que se repiten continua e
innecesariamente por las tablas de las bases de datos. Cuando es excesiva es
evidente que el diseo hay que revisarlo, es el primer sntoma de problemas y
se detecta fcilmente.
Ambigedades. Datos que no clarifican suficientemente el elemento al que
(2)

representan. Los datos de cada fila podran referirse a ms de un ejemplar de

esa tabla o incluso puede ser imposible saber a qu ejemplar exactamente se
estn refiriendo. Es un problema muy grave y difcil de detectar.
Prdida de restricciones de integridad. Normalmente debido a dependencias
funcionales. Ms adelante se explica este problema. Se arreglan fcilmente
siguiendo una serie de pasos concretos.
Anomalas en operaciones de modificacin de datos. El hecho de que al
insertar un solo elemento haya que repetir tuplas en una tabla para variar unos
pocos datos. O que eliminar un elemento suponga eliminar varias tuplas
necesariamente (por ejemplo que eliminar un cliente suponga borrar seis o
siete filas de la tabla de clientes, sera un error muy grave y por lo tanto un
diseo terrible).
El principio fundamental reside en que las tablas deben referirse a objetos o situaciones
muy concretas, relacionados exactamente con elementos reconocibles por el sistema de
informacin de forma inequvoca. Cada fila de una tabla representa inequvocamente un
elemento reconocible en el sistema. Lo que ocurre es que conceptualmente es difcil
agrupar esos elementos correctamente.
En cualquier caso la mayor parte de problemas se agravan si no se sigue un modelo
conceptual y se decide crear directamente el esquema relacional. En ese caso, el diseo
tiene una garanta casi asegurada de funcionar mal.
Cuando aparecen los problemas enumerados, entonces se les puede resolver usando
reglas de normalizacin. Estas reglas suelen forzar la divisin de una tabla en dos o ms
tablas para arreglar ese problema.

(3) formas normales

Las formas normales se corresponde a una teora de normalizacin iniciada por el propio
Codd y continuada por otros autores (entre los que destacan Boyce y Fagin). Codd
defini en 1970 la primera forma normal, desde ese momento aparecieron la segunda,
tercera, la Boyce-Codd, la cuarta y la quinta forma normal.
Una tabla puede encontrarse en primera forma normal y no en segunda forma
normal, pero no al contrario. Es decir los nmeros altos de formas normales son ms
restrictivos (la quinta forma normal cumple todas las anteriores).
La teora de formas normales es una teora absolutamente matemtica, pero en el
presente manual se describen de forma ms intuitiva.
Hay que tener en cuenta que muchos diseadores opinan que basta con llegar a la
forma Boyce-Codd, ya que la cuarta, y sobre todo la quinta, forma normal es polmica.
Hay quien opina que hay bases de datos peores en quinta forma normal que en tercera.
En cualquier caso debera ser obligatorio para cualquier diseador llegar hasta la forma
normal de Boyce-Codd.

(3.1.1) primera forma normal (1FN)

Es una forma normal inherente al esquema relacional. Es decir toda tabla realmente
relacional la cumple.
Se dice que una tabla se encuentra en primera forma normal si impide que un
atributo de una tupla pueda tomar ms de un valor. La tabla:
TRABAJADOR
(3)

DNI
12121212A
12345345G

Nombre
Andrs
Andrea

Departamento
Mantenimiento
Direccin
Gestin
Visualmente es un tabla, pero no una tabla relacional (lo que en terminologa de bases
de datos relacionales se llama relacin). No cumple la primera forma normal.
Sera primera forma normal si los datos fueran:
TRABAJADOR
DNI
Nombre
12121212A
Andrs
12345345G
Andrea
12345345G
Andrea
Esa tabla s esta en primera forma normal.

Departamento
Mantenimiento
Direccin
Gestin

(3.1.2) dependencias funcionales

dependencia funcional
Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de
atributos (X) si para cada valor de X hay un nico valor posible para Y. Simblicamente
se denota por XY.
Por ejemplo el nombre de una persona depende funcionalmente del DNI; es decir
para un DNI concreto slo hay un nombre posible. En la tabla del ejemplo anterior, el
departamento no tiene dependencia funcional, ya que para un mismo DNI puede haber
ms de un departamento posible. Pero el nombre s que depende del DNI.
Al conjunto X del que depende funcionalmente el conjunto Y se le llama
determinante. Al conjunto Y se le llama implicado.

dependencia funcional completa

Un conjunto de atributos (Y) tiene una dependencia funcional completa sobre otro
conjunto de atributos (X) si Y tiene dependencia funcional de X y adems no se puede
obtener de X un conjunto de atributos ms pequeo que consiga una dependencia
funcional de Y (es decir, no hay en X un determinante formado por atributos ms
pequeos).
Por ejemplo en una tabla de clientes, el conjunto de atributos formado por el
nombre y el dni producen una dependencia funcional sobre el atributo apellidos. Pero
no es plena ya que el dni individualmente, tambin produce una dependencia funcional
sobre apellidos. El dni s produce una dependencia funcional completa sobre el campo
apellidos.
Una dependencia funcional completa se denota como XY

dependencia funcional elemental

Se produce cuando X e Y forman una dependencia funcional completa y adems Y es un
nico atributo.

dependencia funcional transitiva

Es ms compleja de explicar, pero tiene tambin utilidad. Se produce cuando tenemos
tres conjuntos de atributos X, Y y Z. Y depende funcionalmente de X (XY), Z depende
(4)

funcionalmente de Y (YZ). Adems X no depende funcionalmente de Y (Y-/X).

Entonces ocurre que X produce una dependencia funcional transitiva sobre Z.
Esto se denota como: (X Z)
Por ejemplo si X es el atributo Nmero de Clase de un instituto, e Y es el atributo
Cdigo Tutor. Entonces XY (el tutor depende funcionalmente del nmero de clase).
Si Z representa el Cdigo del departamento, entonces YZ (el cdigo del
departamento depende funcionalmente del cdigo tutor, cada tutor slo puede estar en
un departamento). Como ocurre que Y-/X (el cdigo de la clase no depende
funcionalmente del cdigo tutor, un cdigo tutor se puede corresponder con varios
cdigos de clase). Entonces X Z (el cdigo del departamento depende
transitivamente del cdigo de la clase).

(3.2) segunda forma normal (2FN)

Ocurre si una tabla est en primera forma normal y adems cada atributo que no sea
clave, depende de forma funcional completa respecto de cualquiera de las claves. Toda
la clave principal debe hacer dependientes al resto de atributos, si hay atributos que
depende slo de parte de la clave, entonces esa parte de la clave y esos atributos
formarn otra tabla. Ejemplo:
ALUMNOS
ALUMNOS
DNI

Cod Curso

Nombre

Apellido1

Nota

12121219A

34

Pedro

Valiente

12121219A

25

Pedro

Valiente

3457775G

34

Ana

Fernndez

5674378J

25

Sara

Crespo

5674378J

34

Sara

Crespo

Suponiendo que el DNI y el cdigo de curso formen una clave principal para esta tabla,
slo la nota tiene dependencia funcional completa. El nombre y los apellidos dependen
de forma completa del DNI. La tabla no es 2FN, para arreglarlo:
ALUMNOS
ALUMNOS
DNI

Nombre

Apellido1

12121219A

Pedro

Valiente

3457775G

Ana

Fernndez

5674378J

Sara

Crespo

DNI
12121219A
12121219A
3457775G

ASISTENCIA
Cod Curso
34
25
34
(5)

Nota
9
8
6

5674378J
5674378J

25
34

7
6

(6)

(3.3) tercera forma normal (3FN)

Ocurre cuando una tabla est en 2FN y adems ningn atributo que no sea clave
depende transitivamente de las claves de la tabla. Es decir no ocurre cuando algn
atributo depende funcionalmente de atributos que no son clave.
Ejemplo:

DNI
12121349A
12121219A
3457775G
5674378J
3456858S

ALUMNOS
Apellido1
Velasco
Valiente
Fernndez
Crespo
Serrat

Nombre
Salvador
Pedro
Ana
Sara
Marina

Cod Provincia
34
34
47
47
08

Provincia
Palencia
Palencia
Valladolid
Valladolid
Barcelona

La Provincia depende funcionalmente del cdigo de provincia, lo que hace que no est
en 3FN. El arreglo sera:

DNI
12121349A
12121219A
3457775G
5674378J
3456858S

Nombre
Salvador
Pedro
Ana
Sara
Marina

ALUMNOS
Apellido1
Velasco
Valiente
Fernndez
Crespo
Serrat

PROVINCIA
Cod Provincia
Provincia
34
Palencia
47
Valladolid
08
Barcelona

(7)

Cod Provincia
34
34
47
47
08

(3.5) forma normal de Boyce-Codd (FNBC o BCFN)

Ocurre si una tabla est en tercera forma normal y adems todo determinante es una
clave candidata. Ejemplo:

Trabajador
Alex
Arturo
Carlos
Carlos
Gabriela
Luisa
Luisa
Manuela
Pedro

ORGANIZACIN
Departamento
Produccin
Produccin
Ventas
Produccin
Produccin
Ventas
Produccin
Ventas
Ventas

Responsable
Felipa
Martn
Julio
Felipa
Higinio
Eva
Martn
Julio
Eva

La cuestin es que un trabajador o trabajadora puede trabajar en varios

departamentos. En dicho departamento hay varios responsables, pero cada trabajador
slo tiene asignado uno. El detalle importante que no se ha tenido en cuenta, es que el
o la responsable slo puede ser responsable en un departamento.
Este detalle ltimo produce una dependencia funcional ya que:
Responsable Departamento
Por lo tanto hemos encontrado un determinante que no es clave candidata. No est
por tanto en FNBC. En este caso la redundancia ocurre por mala seleccin de clave. La
redundancia del departamento es completamente evitable. La solucin sera:
PERSONAL
Trabajador
Responsable
Alex
Felipa
Arturo
Martn
Carlos
Julio
Carlos
Felipa
Gabriela
Higinio
Luisa
Eva
Luisa
Martn
Manuela
Julio
Pedro
Eva

(8)

RESPONSABLES
Responsables
Departamento
Felipa
Produccin
Martn
Produccin
Julio
Ventas
Higinio
Produccin
Eva
Ventas
En las formas de Boyce-Codd hay que tener cuidado al descomponer ya que se podra
perder informacin por una mala descomposicin

(9)

(4) Cuarta y quinta forma Normal (4FN y 5FN)

Siempre se ha dicho que esto de las formas normales, a partir de la tercera, es cosa de
analistas puntillosos que buscan la perfeccin, el detalle mnimo y el matiz nfimo,
exagerando hasta la caricatura, claro.
El caso es que rescato un comentario en la entrada sobre la 4FN de Wikipedia que me ha
parecido curioso.
4NF en la prctica
"Un artculo de 1992 de Margaret S. Wu observa que la enseanza de la normalizacin de
la base de datos se detiene tpicamente justo antes de la 4NF, quizs debido a una
creencia que las tablas que violan la 4NF (pero que hacen frente a todas las formas
normales ms bajas) son raramente encontradas en aplicaciones empresariales. Sin
embargo, esta creencia puede no ser exacta. Wu reporta que en un estudio de cuarenta
bases de datos de organizaciones, ms del 20% contena una o ms tablas que violaban
la 4NF mientras que satisfacen todas las formas normales ms bajas."
Venga, supongamos que una muestra de 40 bases de datos (de ... "tropecientos" millones
que "andarn" por ah?) es lo suficientemente grande como para que el dato resulte
estadsticamente significativo.
Si pensamos un poco en ello, parece que todo termina por engarzarse. Decimos que una
de las ventajas de modelar en Entidad-Relacin (E-R) es que obtiene tablas en 3FN. Dicho
as, y por qu no en 5FN? Si nos detenemos un momento a observar diferencias entre la
3FN (y su hermana, la de Boyce-Codd) y las formas normales superiores, un dato
interesante es que estas ltimas se definen por relaciones posibles en modelo relacional
(MR) pero que nunca nos saldran de un correcto diseo en E-R. Si trabajamos
directamente en MR podemos llegar a obtener estas tablas y no tienen ningn fallo
aparente de diseo; E-R, simplemente, obliga a utilizar otras pautas de diseo (que no se
entienda que estamos diciendo que E-R es "peor" que MR, o viceversa, que no es as).
Tambin es notorio que la normalizacin hasta 3FN es sistemtica, siempre das los
mismos pasos hasta el resultado final que, adems, es determinista, siempre obtienes la
misma solucin (suponiendo que las dependencias funcionales estn bien definidas). Pero
a partir de Boyce-Codd ya empieza la cosa a complicarse, a veces tienes que retocar
tablas porque una columna se ha movido de sitio. Y en 4FN y 5FN no se generan claves
ajenas, ya no se habla de proyectar (en el sentido del operador de lgebra relacional)
columnas sino de "descomponer".
En realidad, los problemas resueltos por 4FN y 5FN surgen porque se han diseado tablas
que respetan la optimizacin de las dependencias funcionales pero en las que se detecta
una cierta redundancia de datos: "estas tablas estn en 3FN, estn bien, pero si hago
esto y lo otro...". Se trata de que, respetando los requisitos del sistema de informacin,
se elimine todo lo que se pueda la facilidad de introducir incosistencias en la base de
datos. Con todo, la diferencia puede llegar a ser tan sutil que a veces no merece la pena
ni descomponer por 4FN o 5FN, ser cosa de los administradores de la base de datos
decidir si se hace o no dependiendo de la cantidad de filas a manejar y de la ganancia
que se pueda obtener.
(1
0)

Todo eso, y que los casos en que se hace necesario aplicar 4FN y 5FN son poco habituales
(comparando con la 3FN) hace que sea muy goloso detenerse antes de entrar a explicar
en qu consisten. En definitiva, un apunte que parece corroborar aquello de que "una
cosa es la teora y otra la prctica" pero, en este caso, parece, acercndolas la una a la
otra.

(4.1) cuarta forma normal (4FN). dependencias

multivaluadas
dependencia multivaluada
Para el resto de formas normales (las diseadas por Fagin, mucho ms complejas), es
importante definir este tipo de dependencia, que es distinta de las funcionales. Si las
funcionales eran la base de la segunda y tercera forma normal (y de la de Boyce-Codd),
stas son la base de la cuarta forma normal.
Una dependencia multivaluada de X sobre Y (es decir X->>Y), siendo X e Y atributos
de la misma tabla, ocurre cuando Y tiene un conjunto de valores bien definidos sobre
cualquier valor de X. Es decir, dado X sabremos los posibles valores que puede tomar Y.
Se refiere a posibles valores (en plural) y se trata de que los valores de ese atributo
siempre son los mismos segn el valor de un atributo y no del otro.
Ejemplo:
N Curso
17
17
17
17
25
25
25

Profesor
Eva
Eva
Julia
Julia
Eva
Eva
Eva

Material
1
2
1
2
1
2
3

La tabla cursos, profesores y materiales del curso. La tabla est en FNBC ya que no hay
dependencias transitivas y todos los atributos son clave sin dependencia funcional hacia
ellos. Sin embargo hay redundancia. Los materiales se van a repetir para cualquier
profesor dando cualquier curso, ya que los profesores van a utilizar todos los materiales
del curso (de no ser as no habra ninguna redundancia).
Los materiales del curso dependen de forma multivaluada del curso y no del profesor
en una dependencia multivaluada (no hay dependencia funcional ya que los posibles
valores son varios). Para el par N de curso y Profesor podemos saber los materiales;
pero lo sabemos por el curso y no por el profesor.

(1
1)

cuarta forma normal

Ocurre esta forma normal cuando una tabla est en forma normal de Boyce Codd y toda
dependencia multivaluada no trivial es una dependencia funcional. Son triviales
aquellas dependencias multivaluadas en las que el conjunto formado por el
determinante y el implicado no forman la clave primaria de la tabla y adems el
implicado no forma parte del determinante: es decir si X->>Y y adems Y X y X,Y no
es la clave de la tabla, tenemos una dependencia multivaluada no trivial (como ocurre
en el ejemplo anterior).
Para la tabla anterior la solucin seran dos tablas:
N Curso
17
17
25
25
25

Material
1
2
1
2
3

N Curso
17
17
25

Profesor
Eva
Julia
Eva

Un teorema de Fagin indica cuando hay tres pares de conjuntos de atributos X, Y y Z si

ocurre X->>Y y X->>Z (Y y Z tienen dependencia multivaluada sobre X), entonces las
tablas X, Y y X, Z reproducen sin perder informacin lo que posea la tabla original. Este
teorema marca la forma de dividir las tablas hacia una 4FN

(4.2) quinta forma normal (5FN)

dependencias de JOIN o de reunin
Una proyeccin de una tabla es la tabla resultante de tomar un subconjunto de los
atributos de una tabla (se trata de la operacin proyeccin, , del lgebra relacional).
Es decir una tabla formada por unas cuantas columnas de la tabla original.
La operacin JOIN procedente tambin del lgebra relacional, consiste en formar
una tabla con la unin de dos tablas. La tabla resultante estar formada por la
combinacin de todas las columnas y filas de ambas, excepto las columnas y filas
repetidas.
Se dice que se tiene una tabla con dependencia de unin (o de tipo JOIN) si se
puede obtener esa tabla como resultado de combinar mediante la operacin JOIN varias
proyecciones de la misma.

quinta forma normal o forma normal de proyeccin-unin

Ocurre cuando una tabla est en 4FN y cada dependencia de unin (JOIN) en ella es
implicada por las claves candidatas.
(1
2)

Es la ms compleja y polmica de todas. Polmica pues no est claro en muchas

ocasiones est muy claro que el paso a 5FN mejore la base de datos. Fue definida
tambin por Fagin.
Es raro encontrarse este tipo de problemas cuando la normalizacin llega a 4FN. Se
deben a restricciones semnticas especiales aplicadas sobre la tabla. Ejemplo:
Proveedor
1
1
2
1

Material
1
2
1
1

Proyecto
2
1
1
1

Indican cdigos de material suministrado por un proveedor y utilizado en un

determinado proyecto. As vista la tabla, no permite ninguna proyeccin en la que no
perdamos datos.
Pero si ocurre una restriccin especial como por ejemplo: Cuando un proveedor nos
ha suministrado alguna vez un determinado material, si ese material aparece en
otro proyecto, haremos que el proveedor anterior nos suministre tambin ese
material para el proyecto.
Eso ocurre en los datos como el proveedor nmero 1 nos suministr el material
nmero 1 para el proyecto 2 y en el proyecto 1 utilizamos el material 1, aparecer la
tupla proveedor 1, material 1 y proyecto 1. Si un nuevo proyecto necesitara el material
1, entonces habr que pedirlo a los proveedores 1 y 2 (ya que en otros proyectos les
henos utilizado)
La dependencia de reunin que produce esta restriccin es muy difcil de ver ya que
es lejana. Para esa restriccin esta proyeccin de tablas sera vlida:
Proveedor
1
1
2

Material
1
2
1

Material
1
2
1

Proyecto
2
1
1

Proveedor
1
1
2

Proyecto
2
1
1

Esa descomposicin no pierde valores en este caso, sabiendo que si el proveedor nos
suministra un material podremos relacionarle con todos los proyectos que utilizan ese
material.
(1
3)

Resumiendo, una tabla no est en quinta forma normal si hay una descomposicin de
esa tabla que muestre la misma informacin que la original y esa descomposicin no
tenga como clave la clave original de la tabla.

(4.3) forma normal de dominio clave (FNDC)

Se la conoce ms con sus siglas en ingls DKNF. Se trata de una forma normal enunciada
tambin por Fagin en 1981 al darse cuenta de los problemas de redundancia que
ocurran con algunos dominios.
En este caso no se bas en dependencias entre los datos, sino que se bas en
restricciones de dominio y restricciones de clave.
Restricciones de dominio. Se trata de la restriccin que hace que un
determinado atributo obtenga slo ciertos valores, los que estn de acuerdo a
la definicin de un determinado dominio.
Restriccin de clave. Es la restriccin que permite que un atributo o un
conjunto de atributos forme una clave candidata.
Fagin dice que una tabla est en FNDC si toda restriccin sobre la tabla es consecuencia
lgica de aplicar las restricciones de dominio y clave sobre la misma. Fagin demostr
que si esto ocurra la tabla incluso estaba en 5FN.
Ejemplo:
Alumno
Nivel logrado
Nota
Antonio
Muy alto y eficiente
9
Marisa
Muy alto aunque sin trabajo constante 9
Mario
Alto con trabajo habitual
7
Luisa
Medio aunque con trabajo
5
Observando los datos de la tabla se observa que cuando la nota es superior a 9, en el
nivel aparece la palabra alto, cuando es un 7 o un 8 medio, y un 5 o 6 sera medio. Es
decir tenemos restricciones que no son ni de dominio ni de clave en esa tabla. Lo lgico
sera:
Alumno
Nivel de trabajo
Nota
Antonio
Eficiente
9
Marisa
Trabajo
9
constante
Mario
Trabajo habitual
7
Luisa
Trabajo medio
5
Nivel acadmico
Muy alto
Alto
Medio
Bajo

Nota mnima
9
7
5
0

(1
4)

Nota mxima
10
8,99
6,99
4,99

No se pierde informacin al disear las tablas de esta forma y de hecho es

ms eficiente para la base de datos.

(1
5)