4. Diseño de Bases de Datos Relacionales
4.1 Características del diseño relacional
Es un nivel de abstracción más bajo
que el modelo E-R y es la representación en tablas (esquema) del
problema, el cual es práctimente un paso antes del nivel físico.
En la unidad anterior se mencionaron 3 tipos de modelado: conceptual, lógico y físico.
El modelo E-R se considera un modelo
conceptual ya que permite a un nivel alto el ver con claridad la
información utilizada en algun problema o negocio.
En esta unidad nos concentraremos en desarrollar un buen modelo "lógico" que se conoce como "esquema de la base de datos" (database schema)
a partir del cual se podrá realizar el modelado físico en el DBMS, es
importante mencionar que es un paso necesario, no se puede partir de
un modelo conceptual para realizar un físico.
Puede resultar confuso el concepto de
modelo Entidad-Relación vs Modelo Relacional, quizás porque ambos
comparten casi las mismas palabras. Como se mencionó en la
anteriormente, el objetivo del Modelo Relacional es crear un "esquema" (schema),
lo cual como se mencionará posteriormente consiste de un conjunto de
"tablas" que representan "relaciones", relaciones entre los datos.
Estas tablas, pueden ser construídas de diversas maneras:
- Creando un conjunto de tablas iniciales y aplicar operaciones de normalización hasta conseguir el esquema más óptimo. Las técnicas de nomalización se explican más adelante.
- Convertir el diagrama E-R a tablas y posteriormente aplicar también operaciones de normalización hasta conseguir el esquema óptimo.
La primer técnica fue de las primeras
en existir y, como es de suponerse, la segunda al ser más reciente es
mucho más conveniente en varios aspectos:
- El partir de un diagrama visual es muy útil para apreciar los detalles, de ahí que se llame modelo conceptual.
- El crear las tablas iniciales es mucho más simple a través de las reglas de conversión.
- Se podría pensar que es lo mismo porque finalmente hay que "normalizar" las tablas de todas formas, pero la ventaja de partir del modelo E-R es que la "normalización" es mínima por lo general.
- Lo anterior tiene otra ventaja, aún cuando se normalice de manera deficiente, se garantiza un esquema aceptable, en la primer técnica no es así.
Tablas
El modelo relacional proporciona un manera simple de representar los datos: una tabla bidimensional llamada relación.
título
|
año
|
duración
|
tipo
|
| Star Wars | 1977 | 124 | color |
| Mighty Ducks | 1991 | 104 | color |
| Wayne's World | 1992 | 95 | color |
Relación Películas
La relación Películas tiene la intención de manejar
la información de las instancias en la entidad Películas, cada renglón
corresponde a una entidad película y cada columna corresponde a uno
de los atributos de la entidad. Sin embargo las relaciones pueden
representar más que entidades, como se explicará más adelante.
Atributos
Los atributos son las columnas de un relación y describen características particulares de ella.
Esquemas
Es el nombre que se le da a una relación y el conjunto de atributos en ella.
Películas (título, año, duración, tipo)
En un modelo relación, un diseño consiste de uno o
más esquemas, a este conjunto se le conoce como "esquema relacional de
base de datos" (relational database schema) o simplemente "esquema de
base de datos" (database schema)
Tuplas
Cada uno de los renglones en una relación conteniendo valores para cada uno de los atributos.
(Star Wars, 1977, 124, color)
4.2 Dominios Atómicos y la Primera Forma Normal
Se debe considerar que cada atributo
(columna) debe ser atómico, es decir, que no sea divisible, no se
puede pensar en un atributo como un "registro" o "estructura" de
datos.
Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es irrelevante.
Así mismo el orden de los atributos tampoco es relevante
año
|
título
|
tipo
|
duración
|
| 1991 | Mighty Ducks | color | 104 |
| 1992 | Wayne's World | color | 95 |
| 1977 | Star Wars | color | 124 |
Otra representación de la relación Películas
Normalización
Una vez creadas las tablas hay que verificarlas y revisar si aún se puede reducir u optimizar de alguna manera.
Los problemas tales como la redundancia que ocurren
cuando se abarrotan demasiados datos en un sola relación son llamados
anomalías. Los principales tipos son:
- Redundancia: la información se repite innecesariamente en muchas tuplas.
- Anomalías de actualización: cuando al cambiar la información en una tupla se descuida el actualizarla en otra.
- Anomalías de eliminación: si un conjunto de valores llegan a estar vacíos y se llega a perder información relacionada como un efecto de la eliminación.
Primera forma normal
Una tabla se encuentra en 1a FN, si todos sus atributos son atómicos (indivisibles)
El ejemplo clásico:
| nombre | dirección | teléfono |
En 1a. NF
| nombre | apellido_paterno | apellido_materno | dirección | teléfono |
4.3 Dependencias Funcionales
Hay veces en que los atributos est´an
relacionados entre sí de manera más específica que la de
pertenecer a una misma relación. Hay veces en que es posible determinar
que un atributo depende de otro funcionalmente, como si existiera una
función f en el ”mundo”, tal que t[A] = f(t[B]).
A --> B, la dependencia funcional, que se lee ”A determina B”.
Utilidad en el diseño de bases de datos
Las dependencias funcionales son restricciones de integridad sobre los datos. Conocer las dependencias
funcionales en el momento del diseño de la base de datos permite crear mecanismos para evitar
la redundancia (y los potenciales problemas de integridad que eso conlleva) y mejorar la eficiencia.
Un ejemplo real
Por ejemplo, sea la siguiente relación: Vehículo(serie, nombre, motor, carrocer´ıa, peso, eficiencia).
Aquí, serie es la llave. Por ende, hay sólo un [modelo de] motor por serie, sólo una [forma de]
carrocería por serie, sólo un peso por serie y sólo una eficiencia [energética] por serie: nombre = nombre(
serie), motor = motor(serie), etcétera. O sea, serie -->nombre, motor, carrocera, peso, eficiencia
(la relación es función de su llave; sólo hay una tupla por llave).
Otra observación, que requiere mucho más conocimiento del problema, nos indica que la eficiencia
energética del vehículo es una función del motor, la carrocería y el peso. Considerando esto,
tenemos que motor, carrocera, peso --> eficiencia. ¿Por qué? La eficiencia energética consiste en la
distancia que puede recorrer un vehículo por litro, a una velocidad moderadamente alta. La potencia
del vehículo reside en el motor: el modelo de motor indica la fuerza que imprime el vehículo. Sin
embargo, esta fuerza es contrarrestada por el roce aerodinámico del vehículo, que es una función
del roce viscoso del aire (es un dato fijo) y de la forma de la carrocería. Y el peso entrega la masa
del vehículo (masa = 9, 8m/s2 × peso). Si se divide la fuerza resultante del vehículo por la masa,
se obtiene la aceleración (y en un equilibrio de velocidades se obtiene la eficiencia). Luego, existe
una función tal que
eficiencia = eficiencia(motor, carrocera, peso).
Un ejemplo más sencillo
A veces es fácil encontrar
dependencias en un esquema. Esto es un indicado de un mal modelo
entidad-relación o de una mala conversión a relacional.
Por ejemplo, sea Película(título, año, estudio, presidente, fono
presidente). Digamos que ”título”
es llave de la relación (determina todo). Sin embargo, notemos que el
presidente de un estudio se
puede determinar conociendo el estudio y el año (idealmente).
Luego,
estudio, año --> presidente.
Además, es claro que presidente --> fono_presidente.
La relación ”Película” fue mal modelada desde un principio. En un
modelo entidad-relación,”Película”, ”Estudio” y ”Presidente” habrían
sido entidades distintas, luego relaciones distintas en
el modelo relacional.
Una dependencia funcional en una relación R es un enunciado de la forma "si dos tuplas de R concuerdan en los atributos A1,A2,...An (tienen los mismos valores para cada atributo), entonces deben concordar también con otro atributo B" . Esta FD se escribiría como A1,A2,....An --> B y se dice que "A1, A2,....An determina funcionalmente a B".
Movies(title, year, length, filmType, studioName, starName)
| title | year | length | filmType | studioName | starName |
| Star Wars | 1977 | 124 | color | Fox | Carrie Fisher |
| Star Wars | 1977 | 124 | color | Fox | Mark Hamill |
| Star Wars | 1977 | 124 | color | Fox | Harrison Ford |
| Mighty Ducks | 1991 | 104 | color | Disney | Emilio Estevez |
| Wayne's World | 1992 | 95 | color | Paramount | Dana Carvey |
| Wayne's World | 1992 | 95 | color | Paramount | Mike Meyers |
| ... |
title, year --> lengthtitle, year --> filmTypetitle, year --> studioNametitle, year -/-> starName
podemos entonces afirmar que: title, year --> length, filmType, studioName
Quizás las dependencias funcionales más evidentes sean las llaves.
4.4 Segunda Forma Normal
Una tabla está en la Segunda Forma Normal si:
- · Está en la Primera Forma Normal, y
- · Cada atributo que no es una clave es funcionalmente dependiente de la clave completa.
Las tablas en la Primera Forma Normal
suelen presentar características que tienden a dificultar su uso.
Estas características son reconocibles, y suelen eliminarse sometiendo
a las tablas a una o más transformaciones.
Considere la tabla siguiente, que
contiene información que describe a un grupo de estudiantes y sus
clases, y que se encuentra en la Primera Forma Normal:
ESTUDIANTES_CLASES [NOMBRE,ID-ESTUDIANTE, PROMEDIO, ID-CLASE, CALIFICACION]
Interpretaremos esto de la forma
siguiente: cada fila representa un estudiante matriculado en una
cláse. Si una fila determinada tiene un cierto valor para
CALIFICACION, entonces el estudiante ha completado con éxito esa
clase. En caso contrario, el estudiante está cursando todavía la
clase. La figura siguiente contiene unos datos de muestra para esta
tabla. Los tres primeros atributos contienen información específica
de cada estudiante, mientras que el resto de la información es
específica de la clase. El último atributo representa la calificación
alcanzada por el estudiante en esa clase concreta, y se dejará en
blanco si aún no ha concluido.
Tabla ESTUDIANTES-CLASES
|
NOMBRE
|
(Clave)
ID-ESTUDlANTE
|
PROMEDIO
|
(Clave)
ID-CLASE
|
CALIFICACION
|
Huertas, J.
|
01234
|
5.4
|
FIS-1A
|
A
|
Ferrero, A.
|
22346
|
5.1
|
FIS-1A
|
B
|
Soriano, P.
|
11349
|
4.8
|
QUIM-2B
|
A
|
Huertas, J.
|
01234
|
5.4
|
QUIM-2B
|
A
|
Clemente, C.
|
08349
|
5.9
|
MUS-5
|
B
|
Pérez, R.
|
03472
|
5.1
|
ARTE-3A
|
-
|
Ferrero, A.
|
22346
|
5.1
|
QUIM-1A
|
C
|
Huertas, J.
|
01234
|
5.4
|
MUS-5
|
B
|
Vázquez, H.
|
33461
|
4.9
|
ARTE-3A
|
-
|
Pérez, R
|
03472
|
5.1
|
MUS1
|
-
|
Redundancia de datos
Un examen de esta tabla revela
varios problemas bastante serios, el primero de ellos es que una gran
cantidad de información está siendo almacenada de forma redundante.
Por ejemplo, los valores de NOMBRE, ID-ESTUDlANTE y PROMEDIO están
siendo almacenados por triplicado para el estudiante "Huertas, J.".
También existen otras duplicaciones.
Siempre que sea posible, deberían evitarse las duplicaciones de datos, por diversas razones:
- Espacio de almacenamiento de datos. La información duplicada requiere un espacio extra de almacenamiento, habitualmente en los dispositivos de disco magnético. Aunque el coste de las unidades de disco está descendiendo con rapidez, aún no resultan gratuitas, y una buena base de datos debe siempre intentar conseguir la mínima cantidad de espacio de almacenamiento que sea capaz de satisfacer los requerimientos del usuario.
- Costes de introducción de datos. Una gran parte de la información de la base de datos debe ser introducida de forma manual, por personal específico. La existencia de datos redundantes suele implicar un tiempo de introducción de datos extra, que en el análisis final se traduce en costes adicionales.
- Inconsistencias de la base de datos. Si se introduce información redundante, las posibilidades de inconsistencias aumentan de forma proporcional. Por ejemplo, el PROMEDIO de "Huertas, J." se introduce tres veces en la tabla ESTUDIANTES-CLASES, con lo cual se triplica la probabilidad de introducción de un valor incorrecto para este dato.
Anomalías de modificación
La presencia de redundancia de
datos viene casi siempre acompañada de varias dificultades predecibles;
estas dificultades saldrán a la luz cuando comience a manipularse
la información del interior de la tabla. Estos problemas, conocidos
colectivamente bajo el nombre de anomalías de modificación, aparecen
durante la actualización, borrado e inserción de datos.
Anomalías de actualización. Suponga
que el PROMEDIO del estudiante "Huertas, J." cambia de 5.4 a algún
otro valor, quizá como resultado de un cambio en la calificación
de una clase. Como el valor de PROMEDIO está almacenado en varias
columnas de ESTUDIANTES-CLASES, es necesario buscar en toda la tabla, y
realizar cambios cada vez que aparece PROMEDIO para "Huertas, J.".
Este procedimiento de búsqueda y modificación no sólo consume una
gran cantidad de tiempo, sino que también facilita la posibilidad de
inconsistencias, bien debidas a error humano, si se realiza de forma
manual, o bien debida a fuentes del sistema, tales como interrupciones hardware durante
el proceso de actualización. En cualquiera de los casos, el
resultado sería una tabla con información inconsistente.
De cualquier forma, la alteración
de un único hecho, en este caso la modificación del valor de un
PROMEDIO, requiere la modificación de varias entradas de la tabla,
proceso que consume gran cantidad de tiempo y es propenso a los
errores. Este tipo de situaciones es lo que se conoce como anomalías
de actualización, y su existencia sugiere que el diseño de la tabla
podría mejorarse.
Anomalías de borrado.
Supongamos que un estudiante que acaba de matricularse deja de asistir
a todas sus clases. pero sin abandonar la escuela. Todas las filas de
dicho estudiante habrán de ser borradas de la tabla
ESTUDIANTES-CLASES. Sin embargo, cuando se ha hecho esto, la
información básica relativa a dicho estudiante, como el nombre y el
número de ID, se han perdido de la tabla. En otras palabras, en lo
que concierne a la base de datos, el estudiante ha dejado de existir,
incluso aunque de hecho todavía esté matriculado en la escuela. La
información de la base de datos no se corresponde ya con los hechos
del mundo real, y decimos que ha ocurrido una anomalía de borrado.
Anomalías de inserción. Supongamos
que un nuevo alumno se matricula en la escuela, pero que, por
diversas razones, no se matricula de inmediato en ninguna clase
concreta. Debido al diseño de la tabla ESTUDIANTES-CLASES, cada fila
representa a un estudiante matriculado en una clase. Por lo tanto,
cada fila debería contener un valor para ID-CLASE. Sin embargo, la
fila del nuevo estudiante puede ser introducida con un valor especial
para ID-CLASE, que indica que el estudiante no está asistiendo a
nunguna clase. Más adelante, cuando el estudiante se matricule en
algún curso concreto, esta fila original pasará a ser un estorbo en
la base de datos, y tendrá que ser eliminada. De hecho, el permitir
la existencia de este tipo especial de fila complica casi todas las operaciones que se efectúan con la tabla.
Este tipo de situación se denomina
anomalía de inserción: el hecho del mundo real, en este caso el
registro de un nuevo estudiante, no puede ser descrito
convenientemente por la base de datos, debido a su diseño.
La fuente de las anomalías de modificación
Los diversos tipos de anomalías de
modificación descritos no son problemas imposibles de abordar, pero
pueden complicar de forma seria el uso eficiente de una base de datos.
Sería preferible si las anomalías pudieran ser eliminadas, y de
hecho, esto puede hacerse, mediante el estudio de la fuente original
de las dificultades.
Veremos que el comportamiento anómalo está
relacionado directamente con la presencia de la redundancia de datos:
ambos problemas surgen de la forma en que está estructurada la tabla
ESTUDIANTES-CLASES, y ambos pueden ser eliminados mediante una
transformación adecuada de la tabla.
Para atacar el problema, formúlese
la siguiente pregunta: ¿cuáles son los hechos básicos representados
por la tabla ESTUDIANTES-CLASES? La respuesta es sencillamente que
cada fila de la tabla representa a un estudiante concreto matriculado
en una clase específica. Existe, por tanto, un segundo hecho
independiente contenido en cada fila: la propia existencia del
estudiante. Es decir, cada fila contiene información que es
específica del estudiante, tal como el PROMEDIO, y estos datos son
independientes de las clases representadas en cada fila. Este es el
núcleo del problema: cuando hay varias filas que corresponden a un
estudiante determinado, los datos específicos del estudiante se
repiten en cada una de ellas.
A la vista de esto, y estudiando los
datos de la tabla de la figura 1, se llega a la siguiente conclusión:
el problema de la redundancia de datos y de las anomalías de
actualización de la tabla ESTUDIANTES-CLASES surge específicamente
porque cada fila de la tabla contiene dos hechos independientes.
Otro punto de vista: Antes de
ilustrar la transformación de la tabla que elimina tanto la
redundancia de datos como las anomalías de modificación, volvemos a
examinar la misma situación desde una perspectiva diferente: la de
las claves, y sus dependencias funcionales. Esta aproximación
proporcionará una forma mucho más abreviada y directa de tratar las
mismas situaciones. Considere las dos preguntas siguientes:
1. ¿Cuál es la clave de la tabla ESTUDIANTES-CLASES?
2. ¿Qué dependencias funcionales existen dentro de esta tabla?
Como cada fila representa una
combinación determinada de clase y estudiante, una elección razonable
como clave sería la combinación de ID-ESTUDIANTE + ID-CLASE.
A continuación enumeramos todas las dependencias funcionales existentes entre los atributos de la tabla:
ID-ESTUDIANTE + ID-CLASE ® CALIFICACION
ID-STUDIANTE ® NOMBRE
PROMEDIO
Tabla: ESTUDIANTE
|
|
|
|
Tabla: ESTUDIANTE-CLASE
|
|
||
Podría parecer que existe aún
alguna redundancia en las nuevas tablas. Por ejemplo, un valor de
ID-ESTUDIANTE de "01234" aparece tres veces en ESTUDIANTE-CLASE. Sin
embargo, esto es una consecuencia inevitable del hecho de que este
estudiante está asociado con tres clases. Uno de los objetivos del
proceso de normalización consiste en reducir la cantidad de
redundancia de datos al mínimo absoluto, que se ha conseguido
mediante las tablas ESTUDIANTE y ESTUDIANTE-CLASE.
La descomposición de la tabla
ESTUDIANTE-CLASE ha eliminado asimismo la posibilidad de anomalías de
modificación, tratada anteriormente. Acontinuación examinaremos cada
tipo de anomalía realizada anteriormente a la luz de las nuevas
tablas.
Anomalías de actualización: Si
es necesario cambiar el valor del PROMEDIO de un estudiante
determinado, sólo es preciso alterar el valor de una única fila de la
tabla ESTUDIANTE. Recuerde que en la tabla original había que
modificar gran número de entradas para cada estudiante.
Anomalías de borrado:
Si un estudiante abandona todas sus asignaturas, pero sigue aún
matriculado en la escuela, puede existir aún una entrada en la tabla
ESTUDIANTE, incluso aunque no existan entradas para ese estudiante en
ESTUDIANTE-CLASE.
Anomalías de inserción:
También han desaparecido las posibilidades que existían de anomalías
de inserción: es posible crear una entrada en la tabla ESTUDIANTE
para un estudiante nuevo que aún no se haya matriculado en ninguna
clase. A medida que el estudiante se vaya matriculando en cursos
nuevos, se pueden ir creando entradas nuevas en la tabla
ESTUDIANTE-CLASE.
4.5 Tercera Forma Normal
En el ejemplo anterior, una tabla
en la Primera Forma Normal (ESTUDIANTES-CLASES) fue descompuesta en dos
tablas en la Segunda Forma Normal, con el fin de eliminar los
problemas asociados con la redundancia de datos y el comportamiento
anómalo. Sin embargo, algunas tablas en la Segunda Forma Normal
pueden presentar aún problemas de redundancia y anomalías. Estos
problemas pueden ser eliminados mediante transformaciones que den
como resultado tablas que se dice están en la Tercera Forma Normal.
El ejemplo siguiente ilustra este procedimiento.
Adición de datos de los profesores
Supongamos que queremos modificar
el diseño de la base de datos implícito en las tablas ESTUDIANTE y
ESTUDlANTE-CLASE, con el fin de incluir los nombres y oficinas de los
profesores de cada una de las clases.
Como la tabla ESTUDIANTE-CLASE
contiene ya datos acerca de las clases, parece que sería el lugar más
indicado para incluir información acerca de los profesores.
Conseguimos nuestro objetivo mediante la siguiente modificación de
ESTUDIANTE-CLASE:
ESTUDIANTE-CLASE-PROF[ID-ESTUDIANTE, ID-CLASE, CALIFICACION, PROFESOR, OFICINA]
hemos vuelto a renombrar la tabla para indicar su contenido. La siguiente tabla contiene unos datos de muestra.
hemos vuelto a renombrar la tabla para indicar su contenido. La siguiente tabla contiene unos datos de muestra.
| ID_ESTUDIANTE | ID-CLASE | CALIFICACION | PROFESOR | OFICINA |
| 01234 | FIS-1A | A | Vásquez, N. | M11 |
| 22346 | FIS-1A | B | Vásquez, N. | M11 |
| 11349 | QUIM-2B | A | Pardo, L. | CT2 |
| 01234 | QUIM-2B | A | Pardo, L. | CT2 |
| 08349 | MUS-5 | B | Hurtado, R | M22 |
| 03472 | ARTE-3A | - | Hurtado, R. | M22 |
| 22346 | QUIM-1A | C | Pardo, L. | CT2 |
| 01234 | MUS-5 | B | Hurtado, R. | M22 |
| 33461 | ARTE-3A | - | Hurtado, R. | M22 |
| 03472 | MUS-1 | - | Hurtado, R | M22 |
Claves y dependencias funcionales
Analicemos la tabla en términos
de claves y dependencias, al igual que lo hicimos para el ejemplo
anterior. La clave de la tabla permanece igual que hasta ahora,
concretamente ID-ESTUDIANTE + ID-CLASE, porque el hecho básico
contenido en cada fila sigue siendo una combinación determinada de
estudiante y clase. Las dependencias funcionales de la tabla son las
siguientes:
ID-CLASE --> PROFESOR
Al igual, que antes, CALIFICACION
es funcionalmente dependiente de la combinación ID-ESTUDIANTE +
ID-CLASE. Sin embargo, PROFESOR es funcionalmente dependiente tan
sólo de ID-CLASE, ya que cada clase determina de forma única el
profesor, independientemente del número de estudiantes matriculados
en la clase.
De forma similar, OFICINA es funcionalmente dependiente
solo de ID-CLASE, ya que una clase concreta determina de forma única
una oficina concretamente el del profesor que da la clase.
¿Qué forma normal? Como las
dependencias funcionales de ID-CLASE son parciales, la tabla
ESTUDIANTIE-CLASE-PROF no está en la Segunda Forma Normal. Una vez
más, el motivo de esto es que cada fila representa dos hechos
básicos: el hecho estudiante/clase es el mismo de antes, pero también
existe otro hecho ligeramente oculto: cada clase existe independientemente de los estudiantes matriculados en ella.
Transformación a la Segunda Forma Normal
La tabla ESTUDIANTE-CLASE-PROF,
debido a estas dependencias parciales, exhibirá los mismos tipos de
problemas de redundancia y anomalías que hemos señalado
anteriormente. Esto puede verificarse estudiando los datos de muestra
de la siguiente tabla:
Tabla CLASE-PROF
| ID-CLASE (clave) | PROFESOR | OFICINA |
| FIS-1A | Vázquez, N. | M11 |
| MUS-1 | Hurtado, R | M22 |
| QUIM-2B | Pardo, L. | CT2 |
| QUIM-1ª | Pardo, L. | CT2 |
| MUS-5 | Hurtado, R | M22 |
| ARTE-3A | Hurtado, R | M22 |
Tabla ESTUDIANTE-CLASE
ID-ESTUDlANTE
|
ID-CLASE
|
|
Al igual que en el ejemplo anterior,
estas dificultades pueden ser eliminadas descomponiendo las
dependencias parciales, con lo que se obtienen las siguientes nuevas
tablas:
ESTUDIANTE-CLASE[ID-ESTUDIANTE, ID-CLASE, CALIFICACION]
CLASE-PROF[ID-CLASE, PROFESOR, OFICINA]
Fíjese en que la descomposición ha dado como resultado la creación nuevamente de la tabla ESTUDIANTE-CLASE, que se indicaba anteriormente, y que se encontraba en la Segunda Forma Normal. Si enfocamos nuestra atención sobre CLASE-PROF, nos damos cuenta de que también está en la Segunda Forma Normal, debido a las dependencias funcionales mostradas. Es decir, cada uno de los atributos que no constituyen una clave son totalmente dependientes de lD-CLASE, que es la clave.
Fíjese en que la descomposición ha dado como resultado la creación nuevamente de la tabla ESTUDIANTE-CLASE, que se indicaba anteriormente, y que se encontraba en la Segunda Forma Normal. Si enfocamos nuestra atención sobre CLASE-PROF, nos damos cuenta de que también está en la Segunda Forma Normal, debido a las dependencias funcionales mostradas. Es decir, cada uno de los atributos que no constituyen una clave son totalmente dependientes de lD-CLASE, que es la clave.
Redundancia de datos y comportamiento anómalo
Estudiando una muestra de datos para
CLASE-PROF se puede percibir que, incluso aunque la tabla está en
la
Segunda Forma Normal, aún existe una redundancia de datos
considerable: los nombres y números de oficina de algunos de los
profesores aparecen más de una vez. Además, la tabla muestra los
mismos tipos de anomalías de modificación que ya se analizaron
anteriormente.
Anomalías de actualización. Si un
profesor determinado se mueve de una oficina a otra, es preciso
modificar varias entradas de la tabla. Esto constituye otro ejemplo
en el cual el cambio de un único hecho, en este caso, la asociación
entre un profesor y un oficina, exige la alteración de varias
entradas de la tabla.
Anomalías de borrado. Supongamos
que un profesor pierde todas sus clases, debido a la falta de asistencia
de los alumnos. Cuando se eliminan todas las entradas de la tabla,
sucede lo mismo con el número de oficina del profesor. Es decir, como
el profesor no tiene ninguna clase, la base de datos pierde la
información que lo relaciona con un oficina concreto. Esto es una
anomalía de borrado, y no debe producirse.
Anomalías de inserción.
Supongamos que un nuevo profesor se incorpora a la escuela, pero aún
no tiene asignada ninguna clase. No será posible añadir el nombre ni
el número de oficina de esta persona a la tabla, porque la clave de
la tabla es ID-CLASE. No tiene sentido incluir una entrada en la
tabla, que no tenga un valor de la clave, ya que dos de dichas entradas
darían como resultado dos filas con el mismo valor de la clave, lo
cual viola la estructura básica de las tablas relacionales. Por
supuesto, sería posible asignarle un valor de clave falso, de forma
que pudiera introducirse el profesor como una fila separada, pero los
problemas potenciales asociados con este método son lo
suficientemente molestos como para que se descarte este tipo de
solución.
Dependencias funcionales transitivas
Parece que hemos encontrado que,
aunque CLASE-PROF esta en la Segunda Forma Normal, presenta exactamente
los mismos tipos de problemas que existían en nuestros ejemplos
precedentes de tablas en la
Primera Forma Normal. De hecho, la razón
para este tipo de problemas es también similar a la que vimos antes:
existe todavía algún tipo de dependencia funcional dentro de la
tabla. Esta dependencia surge del hecho de que aunque OFICINA es
funcionalmente dependiente de ID-CLASE, también es funcionalmente
dependiente de
PROFESOR:
PROFESOR --> OFICINA
Esta dependencia puede observarse
estudiando los datos de la tabla CLASE-PROF, fijándose en que los
valores de OFICINA van completamente ligados a los de PROFESOR.
La relación PROFESOR -->
OFICINA es un ejemplo de una dependencia funcional transitiva, que se
define de la forma siguiente:
Se dice que existe una dependencia funcional transitiva entre dos atributos de una tabla, A y B, si:
|
La dependencia transitiva y sus
problemas asociados de redundancia de datos pueden ser eliminados
mediante una técnica similar a la que usamos para eliminar las
dependencias parciales: descomponiendo la dependencia en una tabla
aparte, de la forma siguiente:
CLASE-PROF [ID-CLASE, PROFESOR]
PROFESORES [NOMBRE, OFICINAJ
Cada una de estas tablas se dice que está en la Tercera Forma Normal, que se define de la siguiente forma:
| Tercera Forma Normal
Una tabla está en Tercera Forma Normal si:
|
Como resultado de la descomposición de la tabla, los datos de la tabla CLASE-PROF se convierten de la siguiente manera:
Tabla CLASE-PROF
| ID-CLASE (clave) | PROFESOR |
| FIS-1A | Vázquez, N. |
| MUS-1 | Hurtado, R |
| QUIM-2B | Pardo, L. |
| QUIM-1ª | Pardo, L. |
| MUS-5 | Hurtado, R |
| ARTE-3A | Hurtado, R |
Tabla PROFESORES
| PROFESOR | OFICINA |
| Vázquez, N. | M11 |
| Hurtado, R | M22 |
| Pardo, L. | CT2 |
En los de las tablas anteriores;
un examen revela que los problemas de redundancia de datos y de
comportamiento anómalo han desaparecido.
La mejor Forma Normal
La mejor Forma Normal
Las Formas Normales que se han
presentado hasta ahora, así como las que se analizarán más adelante,
son, en cierto sentido, ideales que el diseñador debe tener en mente.
Sin embargo, no es absolutamente esencial que una tabla tenga que
estar en una forma determinada para que resulte útil. Por ejemplo,
una tabla que no está en Segunda Forma Normal podría ser utilizada
tal como está para el almacenamiento, recuperación y modificación de
datos. El diseñador, sin embargo, debería ser consciente de las
dificultades potenciales relacionadas con las anomalías de
modificación, y del espacio de almacenamiento adicional requerido por
culpa de la redundancia de datos.
Descomponer o no descomponer
Con frecuencia se elige
deliberadamente no transformar una tabla a la Tercera Forma Normal,
dejándola en alguna de las otras dos formas. Considere el ejemplo
siguiente:
CLIENTES [RUT, NOMBRE, TELEFONO, CALLE, CIUDAD, REGION]
Esta tabla no está en la Tercera Forma Normal, ya que existe una dependencia transitiva entre dos de los atributos:
CIUDAD ® REGION
Con el fin de eliminar estas dependencias parciales, sería necesario descomponer la tabla CLIENTES de esta forma.
Con el fin de eliminar estas dependencias parciales, sería necesario descomponer la tabla CLIENTES de esta forma.
CLIENTES [RUT, NOMBRE, TELEFONO, CALLE, CIUDAD]
CIUDADES[CIUDAD, REGION]
Por razones de conveniencia, sin
embargo, a menudo se escogería el primer diseño en vez del segundo.
Para ilustrar esto, supongamos que estamos buscando de forma
interactiva en una base de datos una información relativa a uno o más
clientes. Si nuestra base de datos consta de una única tabla
representada mediante el primer diseño, sería posible encontrar toda
la información relativa a cada cliente con una única búsqueda.
Por otro lado, supongamos que nuestra
base de datos consta de las dos tablas (segundo diseño). En este
caso, sería necesario un proceso de dos etapas para cada cliente:
1. Localizar la entrada correcta en la tabla CLIENTES.
2. Usando el valor encontrado para
CIUDAD, buscar en la tabla CIUDADES la entrada apropiada, que contiene
la ciudad y la región correspondientes.
Cuando se escoge el primer diseño
en vez del segundo, se está adoptando un compromiso entre 1) la
conveniencia de uso; y 2) los problemas asociados con el uso de una
tabla que contiene dependencias transitivas. En este ejemplo
particular, los problemas de anomalías apenas son significativos, ya
que las relaciones entre las ciudades y las regiones no van a sufrir
cambios con toda probabilidad. Además, es posible que no existiese
ningún interés en conocer la región de una ciudad determinada, si no
existiesen clientes viviendo en esa zona. Por tanto, la existencia de
una tabla CIUDADES separada no mejoraría la utilidad de la base de
datos.
La Tercera Forma Normal es una meta
útil, pero el diseñador tendrá que afrontar a menudo la elección de
sacrificar el ideal a lo práctico.
4.6 Forma Normal Boyce-Codd
La Forma Normal de Boyce-Codd (o FNBC)
es una forma normal utilizada en la normalización de bases de datos. Es
una versión ligeramente más fuerte de la Tercera forma normal (3FN). La
forma normal de Boyce-Codd requiere que no existan dependencias
funcionales no triviales de los atributos que no sean un conjunto de la
clave candidata. En una tabla en 3FN, todos los atributos dependen de
una clave, de la clave completa y de ninguna otra cosa excepto de la
clave (excluyendo dependencias triviales, como 
).
Se dice que una tabla está en FNBC si y solo si está en 3FN y cada
dependencia funcional no trivial tiene una clave candidata como
determinante. En terminos menos formales, una tabla está en FNBC si está
en 3FN y los únicos determinantes son claves candidatas.
).
Se dice que una tabla está en FNBC si y solo si está en 3FN y cada
dependencia funcional no trivial tiene una clave candidata como
determinante. En terminos menos formales, una tabla está en FNBC si está
en 3FN y los únicos determinantes son claves candidatas.
Una forma sencilla de comprobar si una relación se
encuentra en FNBC consiste en comprobar, además de que esté en 3FN, lo
siguiente:
- (1) Si no existen claves candidatas compuestas (con varios atributos), está en FNBC.
- (2) Si existen varias claves candidatas compuestas y éstas tienen un elemento común, no está en FNBC.
El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves candidatas de la tabla son:
- {ID Tutor, ID Estudiante}
- {Número de seguro social del tutor, ID Estudiante}
4.7 Algoritmos de descomposición
Lectura del capítulo 7.4 y 7.5
FUNDAMENTOS DE BASES DE DATOS
Cuarta edición
Abraham Silberschatz
Bell Laboratories
Henry F. Korth
Bell Laboratories
S. Sudarshan
Instituto Indio de Tecnología, Bombay
Cuarta edición
Abraham Silberschatz
Bell Laboratories
Henry F. Korth
Bell Laboratories
S. Sudarshan
Instituto Indio de Tecnología, Bombay
4.8 Formas normales superiores
Lectura del capítulo 7.8 y 7.9
FUNDAMENTOS DE BASES DE DATOS
Cuarta edición
Abraham Silberschatz
Bell Laboratories
Henry F. Korth
Bell Laboratories
S. Sudarshan
Instituto Indio de Tecnología, Bombay
Cuarta edición
Abraham Silberschatz
Bell Laboratories
Henry F. Korth
Bell Laboratories
S. Sudarshan
Instituto Indio de Tecnología, Bombay
4.9 Integridad de las bases de datos
En informática, la integridad de datos puede referirse a:
* Integridad de datos en general: hace referencia a que todas las características de los datos (reglas, definiciones, fechas, etc) deben ser correctos para que los datos estén completos.
* Integridad de datos en bases de datos: Integridad de datos se refiere al estado de corrección y completitud de los datos ingresados en una base de datos.
Los SGBD relacionales deben encargarse de mantener la integridad de los datos almacenados en una base de datos con respecto a las reglas predefinidas o restricciones. La integridad también puede verificarse inmediatamente antes del momento de introducir los datos a la base de datos (por ejemplo, en un formulario empleando validación de datos).
Un ejemplo de error de integridad es el ingreso de un tipo de dato incorrecto dentro de un campo. Por ejemplo, ingresar un texto cuando se espera un número entero.
También una error en la integridad en una base de datos puede ser la existencia de un valor numérico (id cliente) en la compra de un producto por parte de un cliente que no existe en su correspondiente tabla con ese número. (integridad referencial).
También puede suceder que se elimine una fila padre con dos o más filas hijos que quedarían "huérfanas".
* Integridad de datos en general: hace referencia a que todas las características de los datos (reglas, definiciones, fechas, etc) deben ser correctos para que los datos estén completos.
* Integridad de datos en bases de datos: Integridad de datos se refiere al estado de corrección y completitud de los datos ingresados en una base de datos.
Los SGBD relacionales deben encargarse de mantener la integridad de los datos almacenados en una base de datos con respecto a las reglas predefinidas o restricciones. La integridad también puede verificarse inmediatamente antes del momento de introducir los datos a la base de datos (por ejemplo, en un formulario empleando validación de datos).
Un ejemplo de error de integridad es el ingreso de un tipo de dato incorrecto dentro de un campo. Por ejemplo, ingresar un texto cuando se espera un número entero.
También una error en la integridad en una base de datos puede ser la existencia de un valor numérico (id cliente) en la compra de un producto por parte de un cliente que no existe en su correspondiente tabla con ese número. (integridad referencial).
También puede suceder que se elimine una fila padre con dos o más filas hijos que quedarían "huérfanas".
La exigencia de integridad de los
datos garantiza la calidad de los datos de la base de datos. Por
ejemplo, si se especifica para un empleado el valor de identificador
de 123, la base de datos no debe permitir que ningún otro empleado tenga el mismo valor de identificador. Si tiene una columna employee_rating para la que se prevean valores entre 1 y 5, la base de datos no debe aceptar valores fuera de ese intervalo. Si en la tabla hay una columna dept_id
en la que se almacena el número de departamento del empleado, la base
de datos sólo debe permitir valores que correspondan a los números de
departamento de la empresa.
Dos pasos importantes en el diseño
de las tablas son la identificación de valores válidos para una
columna y la determinación de cómo forzar la integridad de los datos
en la columna. La integridad de datos pertenece a una de las
siguientes categorías:
- Integridad de entidad
-
Integridad de dominio
-
Integridad referencial
-
Integridad definida por el usuario
Tarea: Investigar y dar al menos 2 ejemplos para cada una de las categorías indicadas en el parrafo anterior.
