Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

Contenido:
5. Diseo de bases de datos relacionales 5.1. Introduccin 5.1.1. Documentacin del esquema conceptual de datos (modelo E/R) 5.1.1.1. Reglas de negocio 5.1.1.2. Las reglas de negocio en el proceso de diseo 5.1.1.3. Ejemplo de documentacin 5.2. Diseo conceptual 5.2.1. Paso previo: Recoleccin y anlisis de requisitos 5.2.1.1. Reglas para escribir especificaciones de requisitos 5.2.1.2. Operaciones referidas a los datos 5.2.2. Criterios generales para la representacin de datos 5.2.3. Estrategias de diseo 5.2.3.1. Diseo descendente 5.2.3.2. Diseo ascendente 5.2.3.3. Diseo inverso (inside-out) 5.2.3.4. Diseo mixto 5.2.4. Calidad de un esquema conceptual 5.2.5. Mtodo completo del diseo conceptual 5.2.5.1. Elaboracin del esquema conceptual. 5.2.5.2. Documentacin 5.2.5.3. Ejemplo 5.3. Diseo lgico 5.3.1. Anlisis de rendimiento de esquemas E/R 5.3.2. Reestructuracin de esquemas E/R 5.3.2.1. Anlisis de redundancias 5.3.2.2. Eliminacin de generalizaciones 5.3.2.3. Divisin y mezcla de entidades y relaciones 5.3.2.4. Seleccin de claves primarias 5.3.3. Traduccin al modelo relacional 5.3.3.1. Entidades y relaciones varios a varios 5.3.3.2. Relaciones uno a varios 5.3.3.3. Entidades con claves externas 5.3.3.4. Relaciones uno a uno 5.3.3.5. Resumen de transformaciones del modelo E/R al relacional 5.3.3.6. Documentacin de los esquemas lgicos 5.3.4. Ejemplo de un diseo lgico 5.3.4.1. Fase de reestructuracin 5.3.4.2. Esquema resultante de la reestructuracin 5.3.4.3. Traduccin al modelo relacional 5.4. Normalizacin 5.4.1. Introduccin 5.4.2. Redundancias y anomalas 5.4.2.1. Redundancia de datos 5.4.2.2. Anomalas de actualizacin 5.4.2.3. Obtencin de datos incorrectos 5.4.3. Formas normales y normalizacin 5.4.3.1. Primera forma normal 5.4.3.2. Segunda forma normal 5.4.3.3. Tercera forma normal 5.4.3.4. Forma normal de Boyce-Codd 5.4.3.5. Preservacin de dependencias en la descomposicin 5.4.3.6. Descomposicin y reuniones no aditivas o sin prdida 5.4.3.7. Preservacin de dependencias en la descomposicin y reuniones no aditivas 5.4.3.8. Cuarta forma normal 5.4.3.9. Otras formas normales 5.4.4. Resumen Bibliografa

5. Diseo de bases de datos relacionales

5.1. Introduccin
El proceso de diseo de bases de datos est involucrado en el ciclo de vida de un sistema de informacin: 1. Recoleccin y anlisis de requisitos 2. Diseo 2.1. Diseo de la base de datos 2.2. Diseo de los programas de aplicacin 3. Implementacin 4. Validacin y pruebas 5. Operacin La metodologa de diseo de bases de datos relacionales se ha consolidado a lo largo de los aos satisfaciendo las propiedades de generalidad (independencia de la plataforma hardware/software), calidad del producto (precisin, completitud y eficacia) y facilidad de uso. Consta de las siguientes fases: 1. Diseo conceptual. Herramienta: Modelo conceptual de datos. Se usa alguna variante del modelo entidadrelacin. Resultado: Esquema conceptual de la base de datos. 2. Diseo lgico. Herramienta: Modelo lgico de datos. Se usa el modelo lgico que implemente el sistema de gestin de bases de datos objetivo, pero es independiente de los aspectos fsicos. Se usan tcnicas formales para verificar la calidad del esquema lgico; la ms usual es la normalizacin. Resultado: Esquema lgico de la base de datos. 3. Diseo fsico. Herramienta: Modelo fsico de datos. Detalles de la implementacin fsica: organizacin de archivos e ndices para el SGBD considerado. Resultado: Esquema fsico de la base de datos. Requisitos (Especificaciones escritas en lenguaje natural) Diseo conceptual Esquema conceptual (Modelo entidad-relacin) Diseo lgico Diseo de tablas Diseo fsico Organizacin de archivos e ndices

5-1

5-2

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.1.1.

Documentacin del esquema conceptual de datos (modelo E/R)

5.1.1.2.

Las reglas de negocio en el proceso de diseo

El modelo entidad relacin no es suficiente para representar toda la informacin necesaria para razonar sobre el diseo conceptual: Slo aparecen los nombres de los conceptos (entidades, relaciones), pero no su significado. Limitacin del poder expresivo: No se pueden expresar todas las restricciones de integridad (Ejemplo: dominios, predicados, ...). El modelo E/R vendr acompaado de documentacin complementaria para facilitar la comprensin del modelo E/R y para describir las propiedades de los datos que no se puedan expresar directamente con las constructoras del modelo.

Las reglas de negocio para las restricciones de integridad y para las derivaciones se deben implementar despus del proceso de diseo de la base de datos (diseo conceptual, lgico y fsico). Para ello se puede: - Usar SQL para definir asertos y restricciones (predefinidas y genricas). - Usar disparadores (reglas activas). - Usar sentencias apropiadas de SQL desde los programas de aplicacin.

5.1.1.3.

Ejemplo de documentacin

5.1.1.1.

Reglas de negocio

Permiten la especificacin de reglas del dominio de la aplicacin particular que se considere. Tipo de reglas de negocio: 1. Descripcin de conceptos. Definicin de una entidad, atributo o relacin del modelo E/R. Se utiliza el lenguaje natural. 2. Restricciones de integridad. Documentacin de restricciones que puedan ser representadas o no por el modelo E/R. Admiten expresin formal, pero no hay un estndar. 3. Derivaciones. Conceptos que pueden ser derivados mediante inferencia o clculo aritmtico a partir de otros conceptos del esquema (Informacin implcita, Ejemplo: si se sabe la fecha de ingreso y la fecha de nacimiento de un paciente, se puede conocer su edad). Admiten expresin formal, pero no hay un estndar. 5.1.1.1.1. Reglas de negocio para las restricciones de integridad Las restricciones de integridad pueden expresarse mediante asertos, es decir, sentencias declarativas que debe satisfacer la base de datos. No se expresa cmo se hace la comprobacin, slo lo que se debe comprobar. Forma general de un aserto: <concepto> debe/no debe <expresin sobre conceptos> Ejemplo:: - el director de un departamento debe pertenecer a este departamento. - el empleado de un departamento no debe tener un salario superior al del director del departamento. Estas reglas no tienen por qu hablar directamente sobre entidades, atributos o relaciones del modelo E/R, pueden hablar de informacin que se derive de l.
Director Empleado Miembro Departamento

Compaa con varias sucursales. Cada sucursal de la compaa est en una ciudad y tiene un domicilio. Una sucursal est organizada en departamentos, y cada departamento tiene un nombre y un nmero de telfono. Los empleados de la compaa pertenecen a estos departamentos desde una fecha determinada. Algunos empleados dirigen estos departamentos. Se tiene informacin del nombre, salario , edad y cdigo de identificacin de cada empleado. Los empleados trabajan en proyectos que comienzan en una fecha determinada. Cada proyecto tiene un nombre, presupuesto y fecha de vencimiento.
Cdigo Nombre Salario Edad Empleados (0,N) Participa Fecha (1,N) Proyectos (0,1) Fecha Presupuesto Nmero Nombre (0,1) Miembro (0,1) (1,1) (1,N) Departamentos (1,N) Compuesto (1,N) Fecha Ciudad Domicilio Calle Cdigo postal Sucursales (1,1)

Nombre Dirige Telfono

5.1.1.1.2. Reglas de negocio para las derivaciones Forma general: <concepto> se obtiene de <expresin sobre conceptos> Ejemplo:: El nmero de empleados de un departamento se obtiene de contar los empleados que pertenecen a l

5-3

5-4

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.1.1.3.1. Reglas de negocio descriptivas (descripcin de conceptos) Se organizan como diccionario de datos. Compuestos de dos tablas: - Entidades. Describe las entidades del esquema con sus nombres, una definicin en lenguaje natural, la lista de todos los atributos (posiblemente con descripciones) y las claves. - Relaciones. Describe las relaciones con sus nombres, una descripcin informal, la lista de atributos (posiblemente con descripciones) y la lista de entidades involucradas, junto con sus cardinalidades de participacin. Tabla Entidades: Entidad Descripcin Atributos Clave Empleados Empleados que Cdigo, Nombre, Cdigo trabajan en la Salario, Edad compaa. Proyectos Proyectos de la Nombre, Presupuesto, Nombre compaa en los que Fecha trabajan empleados Departamentos Departamentos de una Telfono, Nombre Nombre, sucursal de la Sucursal.Ciudad compaa Sucursales Sucursal de la Direccin (Calle, Ciudad compaa en una Nmero, Ciudad, ciudad Cdigo postal) Relacin Dirige Miembro Participa Compuesto Entidades involucradas Asocia un director con Empleados (0,1) un departamento Departamentos (1,1) Asocia un empleado Empleados (0,1) con un departamento Departamentos (1,N) Asocia empleados con Empleados (0,N) proyectos Proyectos (1,N) Asocia un Departamentos (1,1) departamento con una Sucursales (1,N) sucursal Descripcin Atributos

5.2. Diseo conceptual

El objetivo es la construccin de un esquema E/R a partir de los requisitos del usuario. El proceso de construccin es incremental: el esquema conceptual se refina y enriquece durante una serie de transformaciones y correcciones.

5.2.1.

Paso previo: Recoleccin y anlisis de requisitos

Fecha Fecha

5.1.1.3.2.

(RN1) (RN2) (RN3) (RN4)

(RN5)

Reglas de negocio no descriptivas (restricciones de integridad y derivaciones) Restricciones El director de un departamento debe pertenecer a este departamento. Un empleado no debe tener un salario mayor que el del director de su departamento. Un departamento de la sucursal de Roma debe ser dirigido por un empleado con ms de 10 aos de antigedad en la compaa. Un empleado que no pertenezca a algn departamento no puede participar en ningn proyecto. Derivaciones El presupuesto de un proyecto se obtiene de multiplicar la suma de los salarios de los empleados que participan en el multiplicado por 3.

Recoleccin de requisitos: Identificacin completa de los problemas que se deben resolver. Esto es, aspectos estticos (los datos) y dinmicos (operaciones sobre los datos). Se recogen en una descripcin en lenguaje natural: son ambiguos y desorganizados. Anlisis de requisitos: Clarificacin y organizacin de la especificacin de requisitos. Las fuentes de los requisitos son los usuairos de la aplicacin, la documentacin existente sobre el problema (formularios, procedimientos, leyes, ...) y aplicaciones antiguas. Consejos: Hacer comprobaciones de consistencia de la informacin recopilada. Cmo: ejemplos prcticos, preguntar por definiciones y clasificaciones precisas. Identificar aspectos esenciales y marginales. Ejemplo: Se va a analizar un documento de especificacin para eliminar las imprecisiones y trminos ambiguos. Compaa de formacin 1 Deseamos crear una base de datos para una compaa que imparte cursos de formacin. 2 Para ello debemos almacenar datos sobre los alumnos y los instructores. Por 3 cada participante en un curso (alrededor de 5000), identificados por un cdigo, deseamos 4 almacenar el nmero de seguridad social, el nombre, la edad, el sexo, el lugar de nacimiento, 5 el nombre del empleado, el domicilio y el nmero de telfono, empresarios anteriores 6 (y periodo de empleo), los cursos recibidos (hay alrededor de 200 7 cursos) y la evaluacin final del curso. Necesitamos tambin 8 representar los seminarios que cada participante est recibiendo actualmente 9 y, para cada da, los lugares y momentos en que se imparten las clases. Cada curso 10 tiene un cdigo y un ttulo, y cualquier curso puede impartirse cualquier nmero de veces. 11 Cada vez que se imparte un curso, lo denominamos una edicin del 12 curso. Para cada edicin representamos la fecha de inicio, la fecha final 13 y el nmero de participantes. Si un alumno es un profesional autnomo, 14 necesitamos saber su rea de especializacin y, si se aplica, 15 su ttulo. Para alguien que trabaje para una compaa, almacenamos el nivel y 16 el puesto. Para cada instructor (alrededor de 300), representaremos el 17 nombre, la edad, el lugar de nacimiento, la edicin del curso impartido, los 18 que imparti en el pasado y los cursos que el tutor est cualificado para impartir. 19 Se almacenan todos los nmeros de telfono de los instructores. Un instructor 20 debe estar empleado permanentemente por la compaa de formacin o puede ser 21 un freelance. Ambigedades e imprecisiones: Participantes alumnos, Tutores instructores, Cursos seminarios.

5-5

5-6

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.2.1.1.

Reglas para escribir especificaciones de requisitos

Elegir el nivel apropiado de abstraccin. Hay que evitar los trminos demasiado generales o particulares. Ejemplo: periodo (lnea 6) ->fecha inicial y fecha final, puesto (15) -> puesto profesional, evaluacin (7) -> puntuacin sobre 10. Estandarizar la estructura de las frases. Conservar el mismo estilo, Ejemplo:: para <concepto> se cumple <propiedades> Evitar frases complejas. Es mejor empleado en lugar de alguien que trabaje para una compaa (15). Identificar sinnimos y homnimos y estandarizar los trminos. Sinnimos: {tutor (18), instructor (16)}, {participante en un curso (3), alumno}. Homnimos: lugar -> {lugar de nacimiento (4), clases donde se imparten los cursos (9)}. Hacer explcitas las referencias cruzadas. Para alguien que trabaje para una compaa (15) no se sabe si se refiere a instructores o alumnos. Construir un glosario de trminos Descripcin, posibles sinnimos y referencias a otros trminos. Ejemplo: Trmino Descripcin Sinnimo Referencias Alumno Participante en un Participante Curso, Compaa curso. Puede ser un empleado o un autnomo. Curso Instructor Profesor de un curso. Tutor Puede ser un freelance. Curso Curso ofertado. Puede Seminario Instructor, Alumno tener varias ediciones. Alumno Compaa Compaa por la que est o se ha empleado un participante. Con esto, las modificaciones que hay que hacer al texto son las siguientes: Cambiar participante en un curso por alumno. Cambiar Lugar de nacimiento por Ciudad de nacimiento (4,17). Cambiar tiempo por fecha inicial y fecha final (6). Cambiar evaluacin por puntuacin sobre 10 (7). Cambiar seminarios por edicin de un curso (8). Cambiar Lugar por Clase (9). Cambiar puesto por puesto profesional (15). Cambiar tutor por instructor ().

En este punto se debe reescribir la especificacin usando las modificaciones, dividiendo el texto en grupos de frases homogneas que se refieran al mismo concepto: Frases de naturaleza general: Deseamos crear una base de datos para una compaa que imparte cursos de formacin. Deseamos almacenar datos sobre los alumnos y los instructores. Frases referidas a los alumnos: Por cada alumno (alrededor de 5000), identificados por un cdigo, deseamos almacenar el nmero de seguridad social, el nombre, la edad, el sexo, la ciudad de nacimiento, el empresario actual, los empresarios anteriores (junto con la fecha inicial y final del periodo de empleo), las ediciones de los cursos a los que est asistiendo actualmente y a los que haya asistido en el pasado, con las puntuaciones sobre 10. Frases referidas a los empresarios de los alumnos: Para cada empresario de un alumno almacenaremos el nombre, direccin y nmero de telfono. Frases referidas a los cursos: Para cada curso (alrededor de 200) almacenaremos el nombre y el cdigo. Cada vez que se imparta un curso particular lo llamaremos edicin de un curso. Para cada edicin almacenaremos la fecha inicial, la fecha final y el nmero de participantes. Para las ediciones que se estn celebrando actualmente almacenaremos las fechas, las aulas y el horario en que se imparten las clases. Frases referidas a tipos especficos de alumnos: Para un alumno que sea autnomo almacenaremos su rea de especializacin y, si se aplica, el puesto profesional. Para un alumno que sea un empleado, almacenaremos el nivel y el puesto. Frases referidas a los instructores: Por cada instructor (alrededor de 300) almacenaremos el nombre, la edad, la ciudad de nacimiento, todos los nmeros de telfono, la edicin de los cursos impartidos, los cursos impartidos en el pasado y los cursos que est cualificado a impartir. Los instructores pueden estar empleados permanentemente por la compaa de formacin o pueden ser freelance.

5.2.1.2.

Operaciones referidas a los datos

Se deben enumerar, describir y dar una idea de su frecuencia (importante para la fase de diseo lgico). Operacin 1: Insertar un nuevo alumno incluyendo todos sus datos (40 veces al da). Operacin 2: Asignar un alumno a una edicin de un curso (50 veces al da). Operacin 3: Insertar un nuevo instructor, incluyendo todos sus datos y los cursos que est cualificado impartir (2 veces al da). Operacin 4: Asignar un instructor cualificado a una edicin de un curso (15 veces al da). Operacin 5: Mostrar toda la informacin de ediciones pasadas de un curso con el ttulo, los horarios de clase y el nmero de alumnos (10 veces al da). Operacin 6: Mostrar todos los cursos ofertados con informacin de los instructores que estn cualificados para impartirlos. Operacin 7: Para cada instructor encontrar los alumnos de todos los cursos que est impartiendo o ha impartido (5 veces a la semana). Operacin 8: Realizar anlisis estadstico de todos los alumnos con toda su informacin, acerca de las ediciones de los cursos a los que hayan asistido y la puntuacin obtenida (10 veces al mes).

5-7

5-8

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.2.2.

Criterios generales para la representacin de datos

5.2.3.
5.2.3.1.

Estrategias de diseo
Diseo descendente

Las siguientes son directrices para traducir las especificaciones informales en constructores del modelo E/R. Si un concepto tiene propiedades significativas y/o describe clases de objetos con una existencia autnoma, es apropiado representarlo con una entidad. Por ejemplo: instructor, porque tiene propiedades como nombre, edad y ciudad de nacimiento, y porque su existencia es independiente de otros conceptos. Si un concepto tiene una estructura simple, y no tiene propiedades relevantes asociadas, es conveniente representarlo por un atributo de otro concepto al que se refiera. Por ejemplo: Edad. Ciudad puede tener propiedades significativas, pero no son relevantes para nosotros, as que lo dejamos como atributo. Si los requisitos contienen un concepto que proporciona un vnculo lgico entre dos (o ms) entidades, este concepto se puede representar por una relacin. Por ejemplo: Asistir a un curso como relacin entre las entidades que representan a los alumnos y a las ediciones de los cursos. Puede darse el caso de dudar entre representar un concepto como entidad o como relacin. Un concepto se debe representar como entidad si el concepto representa una accin que puede repetirse. Ejemplo: Curso, examen, alumno. Si un alumno puede examinarse ms de una vez del mismo examen en el mismo curso -> como entidad. Si uno o ms conceptos son casos particulares de otro concepto, es conveniente representarlos mediante generalizacin. Profesional y empleado son ejemplos particulares del concepto de Alumno, por lo que es buena idea definir una generalizacin entre las entidades que representan estos conceptos.

Se utilizan las estrategias habituales de cualquier otro proceso de ingeniera.

El esquema conceptual se produce por refinamientos sucesivos, partiendo de un esquema inicial con pocos conceptos abstractos. Tipos de transformaciones en los sucesivos refinamientos: Entidad -> Entidades conectadas por una relacin. Una entidad describe dos conceptos diferentes vinculados lgicamente entre s. Ejemplo:: Cursos -> Tipos de curso (con cdigo y ttulo) y Ediciones de cursos (fecha inicial y fecha final) conectadas por la relacin Tipo. Entidad -> Generalizacin. Ejemplo:: los alumnos pueden ser empleados o profesionales. Relacin -> Relaciones. Una relacin describe dos o ms conceptos diferentes que vinculan dos entidades. Ejemplo:: Relacin Imparte entre Instructores y Cursos -> Imparte actualmente, Imparti Relacin -> Entidad y dos relaciones. Una relacin describe un concepto independiente. Ejemplo:: Relacin Contrato (con muchos atributos) entre Consultores y Compaas. Entidad -> Agregar atributos. Relacin -> Agregar atributos.

5.2.3.2.

Diseo ascendente

Las especificaciones iniciales se descomponen en componentes pequeos. Se disean los esquemas conceptuales de cada uno de los componentes y se integran en un esquema final y global. El esquema final se obtiene de primitivas de transformacin ascendente: Generacin de una entidad. Identificar un concepto y asociarlo a una entidad. Generacin de una relacin. Identificar el vnculo entre dos conceptos. Generacin de una generalizacin. Se identifica una generalizacin. Adicin de atributos a una entidad. Adicin de atributos a una relacin.

5-9

5-10

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.2.3.3.

Diseo inverso (inside-out)

5.2.4.

Calidad de un esquema conceptual

Se identifican algunos conceptos, se inicia el diseo y se ampla segn se van identificando conceptos cercanos a los ya identificados. Ejemplo:

Propiedades de un esquema conceptual: Correccin. Sintctica y semntica. Completitud. Un esquema conceptual es completo si incluye lo necesario para representar todos los requisitos de datos y permite todas las operaciones de la especificacin. Legibilidad. Agrupacin lgica y elegante de los constructores. Mnimo. No hay redundancias.

Cdigo Nombre Salario Edad Empleados (0,N) Participa Fecha (1,N) Proyectos (0,1) Fecha Presupuesto Nmero Nombre (0,1) Miembro (0,1) (1,1) (1,N) Departamentos (1,N) Compuesto (1,N) Fecha Ciudad Domicilio Calle Cdigo postal Sucursales (1,1)

5.2.5.
Nombre

Mtodo completo del diseo conceptual

Elaboracin del esquema conceptual.

5.2.5.1.
Telfono

Dirige

Ventaja: No requiere pasos de integracin. Inconveniente: Examen cuidadoso para buscar conceptos no representados.

5.2.3.4.

Diseo mixto

La especificacin se descompone en pequeos componentes (ascendente), pero no hasta el extremo de separar componentes. Al mismo tiempo se define un esquema esqueleto que contiene en un nivel abstracto los conceptos principales de la aplicacin. Da un visin del diseo global y favorece la integracin de los esquemas desarrollados independientemente. Ejemplo:
Alumno Asiste Curso Imparte Instructor

Se sigue una estrategia mixta. 1. Anlisis de requisitos. (a) Construccin de un glosario de trminos. (b) Anlisis de requisitos y eliminacin de ambigedades. (c) Organizar los requisitos en grupos 2. Paso bsico (a) Identificacin de los conceptos ms relevantes y representacin en un esquema esqueleto. 3. Paso de descomposicin. Se usa si es necesario o apropiado. (a) Descomposicin de los requisitos con referencia a los conceptos del esquema esqueleto. 4. Paso iterativo. Se repite para todos los esquemas hasta que se represente toda especificacin. (a) Refinamiento de los conceptos del esquema, basado en los requisitos. (b) Adicin de nuevos conceptos al esquema para describir las partes de los requisitos an no representadas. 5. Paso de integracin. Se usa si se ha realizado el paso 3. (a) Integracin de los diferentes subesquemas en el esquema final en relacin al esquema esqueleto. 6. Anlisis de calidad. (a) Verificacin de la correccin y modificacin. (b) Verificacin de la completitud y modificacin. (c) Verificacin de la propiedad de mnimo y modificacin. (d) Verificacin de la legibilidad y modificacin. Si los pasos 3 y 5 se omiten, y en el 4 slo se hacen refinamientos, estamos en el diseo descendente. Si el paso bsico se omite y en el paso iterativo slo se aaden nuevos conceptos, estamos en el diseo ascendente. En las transformaciones ascendentes se puede proceder con el diseo inverso.

5.2.5.2.

Documentacin

Procedimiento paralelo. 1. Elaboracin del diccionario de datos. 2. Especificacin de las reglas de negocio. (a) Especificacin de las restricciones. (b) Especificacin de las derivaciones.

5-11

5-12

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.2.5.3.

Ejemplo

Compaa de formacin. Fase 1 Anlisis de requisitos. Completada anteriormente. Fase 2 Paso bsico. Completada anteriormente. Fase 3. Paso de descomposicin. Se dividen los requisitos con respecto al esquema esqueleto (Alumnos, Instructores y Cursos). Fase 4. Paso iterativo. 4.1 Alumnos Tipos identificables: Profesionales y Empleados. Entidades especializadas de Alumnos. Es necesario introducir los empresarios: entidad Empresarios, relacionada con la entidad Empleados. Es necesario introducir dos conceptos diferentes: empleo pasado y actual. Se subdivide la relacin en dos: Empleo actual y Empleo pasado. sta tiene fecha inicial y fecha final y est vinculada a la entidad Alumno (ya que los profesionales tambin pueden tener un empleo pasado). La primera slo tiene fecha inicial y est vinculada a la entidad Empleado. Aadiendo atributos, cardinalidades y claves se obtiene:

4.2 Instructores. Es necesario distinguir entre los empleados por la compaa de formacin y los freelance. Se hace una generalizacin. Aadiendo atributos, cardinalidades y claves se obtiene:

Otra alternativa: aadir un atributo que defina el tipo de empleado. Cundo es vlido? Cuando las especializaciones no contengan a su vez atributos. 4.3 Cursos Dos conceptos distintos enlazados: concepto abstracto de curso (con nombre y cdigo) y la edicin del curso (fecha inicial, fecha final y nmero de alumnos): entidades vinculadas por la relacin Tipo. Clases de los cursos: entidad vinculada con las ediciones de los cursos por la relacin Composicin. Se aaden atributos, cardinalidades y claves. Claves: Clases: aula, horario y fecha. Ediciones de los cursos: Fecha inicial y Curso. El resultado es:

5-13

5-14

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

Fase 5. Paso de integracin. 5.1 Integracin de Instructores y Cursos La relacin Imparte que los une se refina. Tres tipos de vnculos: Imparticin actual, Imparticin pasada y Cualificacin para impartir un curso. Las dos primeras vinculan a Instructor con Ediciones de cursos, la ltima Instructor con Cursos. 5.2 Integracin de Alumnos y Cursos Asistencia actual y Asistencia pasada (con la puntuacin): dos relaciones entre las entidades Alumnos y Ediciones de cursos. Fase 6. Anlisis de calidad. 6.a. Completitud. Comprobar datos y operaciones. Ejemplo:: Operacin 7 (alumnos de todos los cursos impartidos por un instructor). Se empieza con la entidad Instructor, se va por las relaciones Imparticin actual e Imparticin pasada, la entidad Ediciones de los cursos y las relaciones Asistencia actual y Asistencia pasada, alcanzando Alumnos. 6.c. Minimalidad. Redundancia: El atributo Nmero de participantes de la entidad Ediciones de los cursos se puede derivar, por cada edicin, contando el nmero de ejemplares de la entidad Alumnos que estn vinculados con esta edicin. En la siguiente etapa de diseo (lgico) se discute si se mantiene o no. Documentacin. 2. Reglas de negocio. Un instructor imparte (o ha impartido) un curso slo si est cualificado para ello.

5.3. Diseo lgico

Objetivo: crear un esquema lgico que represente correcta y eficientemente al esquema conceptual. No es un paso automtico: hay conceptos que no tienen traduccin nica (Ejemplo: generalizaciones). Pasos fundamentales del diseo lgico: Reestructuracin del esquema E/R. Entrada: esquema conceptual y carga de la BD. Traduccin al modelo lgico. Entrada: esquema conceptual reestructurado. Salida: esquema lgico. Operaciones: normalizacin (tcnica de anlisis) Resultado del diseo lgico: Esquema lgico Restricciones de integridad Documentacin

5.3.1.

Anlisis de rendimiento de esquemas E/R

Indicadores de rendimiento: Coste de una operacin: nmero de entidades y relaciones visitadas para realizar una operacin. Requisito de almacenamiento: nmero de bytes para almacenar los datos. Para evaluarlos es necesario conocer: Volumen de datos: nmero de entidades y relaciones, y tamao de cada atributo. Caractersticas de la operacin: Tipo (por lotes o interactiva) Frecuencia Datos implicados

5-15

5-16

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

Ejemplo: Compaa con sucursales.

Cdigo Nombre Salario Edad Empleados (0,N) Participa Fecha (1,N) Proyectos (0,1) Fecha Presupuesto Nmero Nombre (0,1) Miembro (0,1) (1,1) (1,N) Departamentos (1,N) Compuesto (1,N) Fecha Ciudad Domicilio Calle Cdigo postal Sucursales (1,1)

Nombre Dirige Telfono

Notas: Volumen de Compuesto = Volumen de Departamentos (cada departamento pertenece a slo una sucursal). Volumen de Miembro poco menor que Volumen de Empleados (algunos no estn asignados a proyectos) Si cada empleado est asignado en media a tres proyectos, el Volumen de Participa es 2000x3=6000. Para cada operacin: esquema de navegacin. Ejemplo para la Operacin 2:
Cdigo Nombre Salario Telfono Edad Empleados (0,N) Participa Fecha (1,N) Proyectos (0,1) Fecha Presupuesto Nombre (0,1) Miembro (1,N) Departamentos (1,N)

Nombre

Operacin 1: Asignar un empleado a un proyecto. Operacin 2: Encontrar datos de un empleado para el departamento en que trabaja y para los proyectos en que est implicado. Operacin 3: Encontrar los datos de todos los empleados de un departamento. Operacin 4: Para cada sucursal, encontrar sus departamentos con los nombres de los directores y la lista de empleados de cada departamento. Regla 80-20: El 80% de la carga est generado por el 20% de las operaciones. Tabla de volmenes de datos Concepto Tipo Volumen Sucursales E 10 Departamentos E 80 Empleados E 2000 Proyectos E 500 Compuesto R 80 Miembro R 1900 Dirige R 80 Participa R 6000 Leyenda: E=Entidad, R=Relacin Tabla de operaciones Operacin Tipo Frecuencia Operacin 1 I 10 Operacin 2 I 80 Operacin 3 I 2000 Operacin 4 L 500 Leyenda: I=Interactivo, L=Procesamiento por lotes

Fecha

Clculo del coste: Nmero de accesos a entidades y relaciones necesarios para realizar la operacin. Ejemplo para la Operacin 2: Acceso a un ejemplar de Empleados, acceso a un ejemplar de Miembro, acceso a un ejemplar de Departamentos, acceso a tres ejemplares (en media) de Participa, acceso a tres ejemplares (en media) a Proyectos. Resultado: Tabla de accesos Concepto Tipo Accesos Tipo Empleados E 1 L Miembro R 1 L Departamentos E 1 L Participa R 3 L Proyectos E 3 L Leyenda: E=Entidad, R=Relacin, L=Lectura

5-17

5-18

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

Primer caso: con redundancia.

5.3.2.
5.3.2.1.

Reestructuracin de esquemas E/R

Anlisis de redundancias

Personas

(1,N)

Reside

(1,N)

Ciudades

Atributos cuyos valores pueden ser derivados de otros de la misma entidad. Ejemplo:: Entidad Facturas con atributos ntegro, Neto, IVA. Atributos que se pueden derivar de otras entidades o relaciones generalmente con funciones de agregacin. Ejemplo:
Compras (1,N) Compuesta (1,N) Productos

Habitantes

Volumen de los datos: 4 bytes por Habitantes->4x200=800 bytes < 1KB (despreciable) Coste de las operaciones: Tabla de accesos Operacin 1 Concepto Tipo Accesos Tipo Personas E 1 E Reside R 1 E Ciudades E 1 L Ciudades E 1 E Operacin 2 Ciudades E 1 L Leyenda: E=Entidad, R=Relacin, L=Lectura, E=Escritura Operacin 1: Acceso de escritura a Personas, acceso de escritura a Reside, acceso de lectura a Ciudades y acceso en escritura a Ciudades (para actualizar el atributo). 500 veces al da: 1500 escrituras y 500 lecturas. El coste de la Operacin 2 es despreciable (200 lecturas). Si el coste de escritura es el doble que el de lectura: 1500x2+500=3500.

Total

Precio

Atributos que se pueden derivar de operaciones de contabilidad de ejemplares. Ejemplo::

Personas (1,N) Reside (1,N) Ciudades

Habitantes

Relaciones que pueden derivarse de otras en presencia de ciclos. Ejemplo::

(0,N) ProfesorDe (1,N)

Alumno

(0,N)

Asiste

(1,N)

Curso

(1,1)

Imparte

(1,1)

Instructor

Segundo caso: sin redundancia.

Personas (1,N) Reside (1,N) Ciudades

Ventajas de la redundancia: Reduccin del nmero de accesos para completar las operaciones. Inconvenientes: Mayor capacidad de almacenamiento y operaciones adicionales para mantener la informacin extra actualizada. Decisin: Comparar el coste de las operaciones. Ejemplo: personas que residen en ciudades para una aplicacin electoral, con las operaciones: Operacin 1: Agregar una nueva persona con su ciudad de residencia. Operacin 2: Imprimir los datos de una ciudad. Tabla de volmenes de datos Concepto Tipo Volumen Ciudades E 200 Personas E 1000000 Reside R 1000000 Leyenda: E=Entidad, R=Relacin Tabla de operaciones Operacin Tipo Frecuencia Operacin 1 I 500 Operacin 2 I 2 Leyenda: I=Interactivo, L=Procesamiento por lotes

Tabla de accesos Operacin 1 Concepto Tipo Accesos Tipo Personas E 1 E Reside R 1 E Operacin 2 Ciudades E 1 L Reside R 5000 L Leyenda: E=Entidad, R=Relacin, L=Lectura, E=Escritura Operacin 1: Acceso de escritura a Personas, acceso de escritura a Residencia, 500 veces al da: 1000 escrituras. Operacin 2: Acceso en lectura a Ciudades (despreciable), 5000 (nmero de personas/nmero de ciudades) accesos de lectura a Reside. Si el coste de escritura es el doble que el de lectura: 1000x2+5000=7000. Conclusin: El doble de accesos al da slo por ahorrar 1KB.

5-19

5-20

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.3.2.2.

Eliminacin de generalizaciones

El modelo relacional no puede representarlas directamente. Ejemplo:

3. Sustituir la generalizacin por relaciones. Adecuada cuando la generalizacin no es total y las operaciones se refieren a atributos de E1(E2) o de E0 (se distinguen los padres de los hijos). Se ahorra espacio con respecto a la alternativa 1 (no hay atributos NULL), pero hay ms accesos para mantener la consistencia.

Principales alternativas para transformar generalizaciones: 1. Plegar las entidades hijo en la entidad padre. Adecuada cuando las operaciones implican a los atributos de E0, E1 y E2 ms o menos de la misma forma. Aunque mayor espacio de almacenamiento, requiere menos accesos.

Parece que la alternativa 3 nunca se usara. Sin embargo, produce entidades con menos atributos, y los detalles fsicos pueden hacerla ms efectiva.

2. Plegar las entidades padre en las entidades hijo. Slo es posible si la generalizacin es total. Si no, las E0 que no son ni de E1 ni de E2 no se representaran. Adecuada cuando para operaciones que se refieren slo a E1 o E2, se ahorra almacenamiento con respecto a la alternativa 1 (no hay atributos NULL) y hay menos accesos que en la alternativa 3 (no es necesario acceder a E0 para obtener atributos de E1 y E2).

5-21

5-22

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

Divisin de relaciones.

5.3.2.3.

Divisin y mezcla de entidades y relaciones

Principio: Los accesos se reducen separando atributos del mismo concepto que se acceden por diferentes operaciones y mezclando atributos de diferentes conceptos que se aceden por las mismas operaciones. Divisin de entidades.

Eliminacin de atributos multivalorados. Es necesario porque, al igual que las generalizaciones, los atributos multivalorados no tienen representacin en el modelo relacional.

5.3.2.4.

Seleccin de claves primarias

Criterios de seleccin de claves primarias: Los atributos con valores nulos no pueden formar parte de ninguna clave. Mnimo conjunto de atributos. Razones de espacio. Es mejor (pocos) atributos internos que uno externo. Se crean claves con varios atributos. Es preferible elegir atributos implicados en las operaciones porque los SGBD generan automticamente ndices para ellos. Si ninguno de los identificadores candidatos satisface lo anterior, es posible introducir un nuevo atributo en la entidad que sirva de clave (Autonumrico en Access). Mezcla de entidades. Efecto colateral: atributos NULL. Generalmente se hace sobre relaciones uno a uno, rara vez sobre uno a varios y prcticamente nunca sobre varios a varios.

5-23

5-24

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

Para relaciones n-arias es similar:

5.3.3.

Traduccin al modelo relacional

A partir de un esquema conceptual se construye un esquema conceptual equivalente sin generalizaciones ni atributos multivalorados y slo con claves primarias. Despus se traduce este esquema conceptual equivalente al modelo relacional.

5.3.3.1.

Entidades y relaciones varios a varios

Por cada entidad, una tabla con el mismo nombre, con los mismos atributos y clave. Por cada relacin, una tabla con el mismo nombre, con los atributos de la relacin y las claves de las entidades vinculadas, que formarn la clave de la tabla. No hay que olvidar anotar los atributos con posibles valores nulos. Ejemplo:

Proveedores(IDProveedor, NombreProveedor) Productos(Cdigo, Tipo) Departamentos(Nombre, Telfono) Suministra(Proveedor, Producto, Departamento, Cantidad) Restricciones de integridad referencial: - Atributos Proveedor, Producto y Departamento de Suministra y los atributos respectivos de Proveedores, Productos y Departamentos.

Empleados(Nmero, Nombre, Salario) Proyectos(Cdigo, Nombre, Presupuesto) Participa(Nmero, Cdigo, Fecha inicial) Renombramiento de atributos: Participa(Empleado, Proyecto, Fecha inicial) Restricciones de integridad referencial: -Atributo Empleado de Participa con atributo Nmero de Empleados.

Pr oveedor ( Suministra ) ID Pr oveedor (Pr oveedores) Pr oducto ( Suministra ) Cdigo (Pr oductos) Departamento ( Suministra ) Nombre ( Departamentos )
Nota: Si un nico proveedor suministra un producto determinado a un departamento en concreto, entonces Proveedor, Producto, Departamento son superclave, pero no clave candidata. Se elige Producto, Departamento como clave primaria de la relacin. La cardinalidad sigue siendo vlida.

Nmero ( Participa ) Nmero ( Empleados)

-Atributo Proyecto de Participa con atributo Cdigo de Proyectos.

Cdigo ( Participa) Cdigo (Pr oyectos)

El renombramiento es obligado con relaciones recursivas

Productos(Cdigo, Nombre, Coste) Compuesto(Parte, Subparte, Cantidad) Restricciones de integridad referencial: - Atributo Parte de Compuesto y el atributo Cdigo de Productos

Parte (Compuesto) Cdigo (Pr oductos)

Atributo Subparte de Compuesto y el atributo Cdigo de Productos

Subparte (Compuesto) Cdigo (Pr oductos)

5-25

5-26

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.3.3.2.
Ejemplo:

Relaciones uno a varios

5.3.3.3.

Entidades con claves externas

Al representar la clave externa se representa tambin la relacin entre las entidades.

Jugadores(Nombre, Fecha de nacimiento, Posicin) Equipos(Nombre, Ciudad, Colores) Fichado(Nombre del jugador, Fecha de nacimiento del jugador, Equipo, Salario) La relacin Fichado puede simplificarse por la clave: Fichado(Nombre del jugador, Fecha de nacimiento del jugador, Equipo, Salario) Jugadores y Fichado tienen ahora la misma clave -> Hay una relacin uno a uno entre ambos, por lo tanto, se pueden fundir en una nica tabla: Jugadores(Nombre, Fecha de nacimiento, Posicin, Equipo, Salario) Restricciones de integridad referencial: - Atributo Equipo de Fichado y Nombre de Equipos.

Alumnos(Nmero de registro, Universidad, Nombre, Ao de ingreso) Universidades(Nombre, Ciudad, Direccin) Integridad referencial entre el atributo Universidad de Alumnos y la tabla Universidades.

Equipo ( Fichado) Nombre ( Equipos)

Relaciones n-arias Si una de las entidades en una relacin n-aria participa con una cardinalidad mxima de uno, se puede ahorrar una tabla. Ejemplo:
(1,1)

Proveedores(IDProveedor, NombreProveedor) Departamentos(Nombre, Telfono) Productos(Cdigo, Tipo, Proveedor, Departamento, Cantidad) Integridad referencial entre los atributos Proveedor de Productos y Proveedores, y entre el atributo Departamento de Productos y Departamentos.

5-27

5-28

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.3.3.4.

Relaciones uno a uno

5.3.3.5.

Resumen de transformaciones del modelo E/R al relacional

Se distinguen tres casos: a) Participacin obligada Ejemplo:

Posibilidades: Directores(Nmero, Nombre, Salario, Departamento, Fecha de inicio) Departamentos(Nombre, Telfono, Sucursal) Integridad referencial entre Departamento de Directores y Departamentos. Directores(Nmero, Nombre, Salario) Departamentos(Nombre, Telfono, Sucursal, Director, Fecha de inicio) Integridad referencial entre Director de Departamentos y Directores.

No se deberan unir en una nica tabla porque en el diseo se deben haber considerado aspectos que han decidido esta organizacin del esquema conceptual. b) Participacin opcional de una entidad Ejemplo:

Empleados(Nmero, Nombre, Salario) Departamentos(Nombre, Telfono, Sucursal, Director, Fecha de inicio) Integridad referencial entre Director de Departamentos y Empleados. Esta alternativa es preferible para evitar valores nulos en Empleados cuando un empleado en concreto no dirige un departamento. c) Participacin opcional de ambas entidades Supongamos que en el ejemplo anterior se admita que haya departamentos sin un director asignado. Adems de las dos alternativas del apartado a), aparece una tercera: Empleados(Nmero, Nombre, Salario) Departamentos(Nombre, Telfono, Sucursal) Dirige(Director, Departamento, Fecha de inicio) Integridad referencial entre Director de Dirige y Empleados, y entre Departamento de Dirige y Departamentos. Ventaja: No hay valores NULL. Inconveniente: Se necesita otra tabla. Es una alternativa adecuada cuando la cardinalidad de la relacin es muy pequea con respecto a las cardinalidades de las entidades.

5-29

5-30

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.3.3.6.

Documentacin de los esquemas lgicos

Se hereda la documentacin del esquema conceptual. Se aade la documentacin acerca de las restricciones de integridad referencial. Se subrayan las claves y se marcan con flechas las restricciones de integridad referencial. Ejemplo::

5-31

5-32

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.3.4.

Ejemplo de un diseo lgico

5.3.4.1.

Fase de reestructuracin

Operaciones: Operacin 1: Insertar un nuevo alumno incluyendo todos sus datos (40 veces al da). Operacin 2: Asignar un alumno a una edicin de un curso (50 veces al da). Operacin 3: Insertar un nuevo instructor, incluyendo todos sus datos y los cursos que est cualificado impartir (2 veces al da). Operacin 4: Asignar un instructor cualificado a una edicin de un curso (15 veces al da). Operacin 5: Mostrar toda la informacin de ediciones pasadas de un curso con el ttulo, los horarios de clase y el nmero de alumnos (10 veces al da). Operacin 6: Mostrar todos los cursos ofertados con informacin de los instructores que estn cualificados para impartirlos (20 veces al da). Operacin 7: Para cada instructor encontrar los alumnos de todos los cursos que est impartiendo o ha impartido (5 veces a la semana). Operacin 8: Realizar anlisis estadstico de todos los alumnos con toda su informacin, acerca de las ediciones de los cursos a los que hayan asistido y la puntuacin obtenida (10 veces al mes).

Tabla de volmenes de datos Concepto Tipo Volumen Clases E 8000 Ediciones de cursos E 1000 Cursos E 200 Instructores E 300 Freelances E 250 Fijos E 50 Alumnos E 5000 Empleados E 4000 Profesionales E 1000 Empresarios E 8000 Asisti en el pasado R 10000 Asiste actualmente R 500 Compuesto R 8000 Tipo R 1000 Imparti en el R 900 pasado Imparte R 100 actualmente Cualificacin R 500 Empleo actual R 4000 Empleo pasado R 10000 Leyenda: E=Entidad, R=Relacin Tabla de operaciones Operacin Tipo Operacin 1 I Operacin 2 I Operacin 3 I Operacin 4 I Operacin 5 I Operacin 6 I Operacin 7 I

Frecuencia 40 veces al da 50 veces al da 2 veces al da 15 veces al da 10 veces al da 20 veces al da 5 veces a la semana Operacin 8 L 10 veces al mes Leyenda: I=Interactivo, L=Procesamiento por lotes

5-33

5-34

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.3.4.1.1. Anlisis de redundancias Slo uno: Nmero de participantes en Ediciones de cursos, que se puede derivar de Asisti en el pasado y Asiste actualmente. Requisito de almacenamiento: 4x1000=4000 bytes. Operaciones implicadas: 2, 5 y 8. 8 no relevante por su baja frecuencia. Cada edicin de curso tiene en media 8 clases y 10 alumnos. Se obtienen las siguientes tablas: Primer caso: con redundancia. Coste de las operaciones: Tabla de accesos Operacin 2 Concepto Tipo Accesos Tipo Alumnos E 1 L Asiste R 1 E actualmente Ediciones de E 1 L cursos Ediciones de E 1 E cursos Operacin 5 Ediciones de E 1 L cursos Tipo R 1 L Cursos E 1 L Compuesto R 8 L Clases E 8 L Leyenda: E=Entidad, R=Relacin, L=Lectura, E=Escritura Operacin 2: 2x50=100 accesos en lectura y otros tantos en escritura. Operacin 5: 19x10=190 accesos en lectura Total: 100+100x2+190=490 Tabla de accesos Operacin 2 Concepto Tipo Accesos Tipo Alumnos E 1 L Asiste R 1 E actualmente Operacin 5 Ediciones de E 1 L cursos Tipo R 1 L Cursos E 1 L Compuesto R 8 L Clases E 8 L Asisti en el R 10 L pasado Leyenda: E=Entidad, R=Relacin, L=Lectura, E=Escritura Operacin 2: 50 accesos en lectura y otros tantos en escritura. Operacin 5: 29x10=290 accesos en lectura Total: 50+50x2+290=440 Por tanto, se escoge sin redundancia.

5.3.4.1.2. Eliminacin de generalizaciones Hay dos: Instructores y Alumnos. Instructores. Las operaciones relevantes: 3, 4, 6 y 7 no distinguen entre freelance y fijos. Adems las entidades no tienen atributos extra. Se decide borrar las entidades hijo y aadir el atributo Tipo a la entidad Instructor. Alumnos. Al igual que antes, las operaciones relevantes (1, 2 y 8) no hacen distinciones. Sin embargo las entidades hijo tienen atributos extra. Por lo tanto, se dejan las entidades Empleados y Profesionales y se aaden relaciones uno a uno entre stas y Alumnos. Nota: se evitan valores NULL en la entidad padre.

5.3.4.1.3. Divisin y mezcla de conceptos Se pueden observar muchas alternativas: Divisin de la entidad Ediciones de cursos. La operacin 5 se refiere slo a las ediciones pasadas y que las relaciones Imparti en el pasado y Asisti en el pasado se refieren slo a esas ediciones. Se puede descomponer horizontalmente, pero las relaciones Compuesto y Tipo se duplicaran. Adems las operaciones 7 y 8 no hacen grandes distinciones entre las ediciones actuales y las pasadas, por lo que necesitaran ms accesos. Por tanto, no se divide. Mezcla de las relaciones Imparti en el pasado y Imparte actualmente (Asisti en el pasado y Asiste actualmente). Dos conceptos similares sobre los que las operaciones (7 y 8) no distinguen. Otra ventaja: No hay que transferir ejemplares de una relacin a la otra al final de la edicin del curso. Inconveniente: atributo Puntuacin, que no se aplica a las ediciones actuales (NULL). Ya que Asiste actualmente tiene un volumen de 500-> 500*4=2KB de espacio desperdiciado. Se decide la mezcla. Se aaden dos restricciones no expresables en el esquema: - Un instructor no puede impartir ms de una edicin de un curso en cualquier periodo. - Un alumno no puede asistir a ms de una edicin de un curso en un momento determinado. Eliminacin del atributo multivalorado Telfonos de Instructores. Se aade la entidad Telfonos vinculada por la relacin Posee uno a varios con la entidad Instructor.

5-35

5-36

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.3.4.1.4. Seleccin de claves primarias La entidad Alumnos posee dos claves candidatas: Nmero de la Seguridad Social y Cdigo interno. Se elige la segunda. Ediciones de cursos. Entidad dbil, clave compuesta con la clave de Cursos. Esta clave se deber utilizar en la representacin relacional para implementar las relaciones Asiste e Imparte. Como son pocas las ediciones de un curso para cada curso, se puede aadir un atributo con un dominio pequeo para identificar las ediciones. Esta transformacin no corresponde a ninguna de las estudiadas.

5.4. Normalizacin
5.4.1. Introduccin
La traduccin del esquema conceptual al lgico no es nica. Es necesario contar con una medida de la calidad de la agrupacin de los atributos en relaciones. Como herramienta principal se usan las dependencias funcionales para agrupar los atributos en esquemas de relacin, que se dice que se encuentran en una determinada forma normal. La forma normal de un esquema de relacin determina su grado de calidad con respecto a reducir dos efectos no deseados: la redundancia de datos y las anomalas que produce esta redundancia. En este tema se estudia el anlisis de esquemas de relacin para determinar en qu forma normal se encuentra y el procedimiento, conocido como normalizacin, para descomponerlos en otros esquemas de relacin que se encuentren en formas normales ms exigentes.

5.3.4.2.

Esquema resultante de la reestructuracin

5.3.4.3.

Traduccin al modelo relacional

Aplicando las traducciones vistas, se llega a: Ediciones de cursos(Cdigo, Fecha inicial, Fecha final, Curso, Instructor) Clases(Hora, Aula, Fecha, Edicin) Instructores(Nmero de la Seguridad Social, Nombre, Edad, Ciudad de nacimiento, Tipo) Telfonos(Nmero, Instructor) Cursos(Cdigo, Nombre) Cualificacin(Curso, Instructor) Alumnos(Cdigo, Nmero de la Seguridad Social, Nombre, Edad, Ciudad de nacimiento, Sexo) Asiste(Alumno, Edicin, Puntuacin*) Empresarios(Nombre, Direccin, Telfono) Empleo pasado(Alumno, Empresario, Fecha inicial, Fecha final) Profesionales(Alumno, Especialidad, Puesto profesional*) Empleados(Alumno, Nivel, Puesto, Empresario, Fecha inicial)

5-37

5-38

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.4.2.
5.4.2.1.

Redundancias y anomalas
Redundancia de datos

5.4.2.2.

Anomalas de actualizacin

Un objetivo del diseo de bases de datos relacionales es agrupar atributos en relaciones de forma que se reduzca la redundancia de datos y as el espacio de almacenamiento necesario. Ejemplo 10. Los siguientes dos esquemas Empleados(Id_empleado, NombreP, DireccinP, Puesto, Salario, Centro) Centros(NombreC, DireccinC, Telfono) contienen la misma informacin que el siguiente: Empleados_Centros(Id_empleado, NombreP, DireccinP, Puesto, Salario, NombreC, DireccinC, Telfono)
Empleados DireccinE Puesto c/ Argentales Profesor c/ Barcelona Administrativo c/ Cruz Catedrtico c/ Daroca Ayudante

Id_empleado 123A 456B 789C 012D

NombreE Ana Almansa Bernardo Botn Carlos Crespo David Daz

Salario 20.000 15.000 30.000 10.000

Centro Informtica Matemticas CC. Empresariales Informtica

Anomalas de insercin. Se produce en dos casos. En primer lugar, cuando se inserta una nueva fila sin respetar las dependencias funcionales. En el ejemplo anterior puede ocurrir si se aade una fila de un empleado adscrito a Informtica y con un telfono distinto de 123. En segundo lugar, la imposibilidad de aadir nuevos datos para el consecuente de la dependencia funcional sin que exista un antecedente para ella. En el ejemplo anterior no se puede dar de alta un centro a menos que exista un empleado destinado en l. Sera necesario dejar valores nulos en la clave (Id_empleado). Anomalas de modificacin. Se produce cuando se modifican las columnas con datos redundantes de slo un subconjunto de las filas con el mismo dato. En el ejemplo puede ocurrir cuando se modifica el telfono de Informtica slo en la primera fila. Anomalas de eliminacin. Se produce cuando se eliminan todas las filas en las que aparecen los datos redundantes por lo que se pierde los datos de la dependencia funcional. Si se elimina la segunda fila porque el empleado se da de baja, se pierden tambin los datos del centro. Las anomalas de actualizacin aparecen tambin en los modelos de red y jerrquico, y se resuelven con campos virtuales y tipos de registros virtuales implementados con punteros. Los modelos orientados a objetos evitan el problema mediante la referencia en lugar de la copia.

N o m bre C Informtica Matemticas CC. Empresariales

Cen t r os DireccinC Complutense Complutense Somosaguas

Telfono 123 456 789

Em p l ea d os_Cen t r os Puesto Salario Centro Profesor 20.000 Informtica Administrativo Catedrtico Ayudante 15.000 Matemticas

Id_empleado 123A 456B 789C 012D

NombreP Ana Almansa Bernardo Botn Carlos Crespo David Daz

DireccinP c/ Argentales c/ Barcelona c/ Cruz c/ Daroca

DireccinC Complutense Complutense

Telfono 123 456 789 123

30.000 CC. Somosaguas Empresariales 10.000 Informtica Complutense

La relacin Empleados_Centros presenta redundancia de datos porque se repite para cada empleado la informacin asociada al centro. Las relaciones con datos redundantes presentan diferentes anomalas de actualizacin: son las anomalas de insercin, borrado y modificacin.

5-39

5-40

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.4.2.3.

Obtencin de datos incorrectos

5.4.3.

Formas normales y normalizacin

Dividir una relacin de forma inadecuada puede producir resultados incorrectos al aplicar la operacin Join natural (|) para recuperar la informacin original. Ejemplo 11. Al dividir la tabla Empleados_Centros anterior de la siguiente forma:
Ubicaciones_Empleados NombreE DireccinC Ana Almansa Complutense Bernardo Botn Complutense Carlos Crespo Somosaguas David Daz Complutense
Id_empleado 123A 456B 789C 012D DireccinE c/ Argentales c/ Barcelona c/ Cruz c/ Daroca D a t os_Em p l ea d os Puesto Salario Centro Profesor 20.000 Informtica Administrativo 15.000 Matemticas Catedrtico 30.000 CC. Empresariales Ayudante 10.000 Informtica DireccinC Complutense Complutense Somosaguas Complutense Telfono 123 456 789 123

La forma normal de una relacin se refiere a la mayor condicin de forma normal que satisface un esquema de relacin indicando as el grado hasta el que se ha normalizado. La indicacin del grado de calidad de un esquema de relacin se refiere en general en el contexto global del esquema de la base de datos relacional, es decir, en el conjunto de todos los esquemas de relacin de la base de datos. Dos propiedades que se deben cumplir para poder asegurarlo son: La propiedad de preservacin de dependencias, que asegura que las dependencias funcionales originales se mantienen en algn esquema de relacin despus de la descomposicin. La propiedad de reunin (join) no aditiva (o sin prdida), que evita el problema de la generacin de tuplas incorrectas comentado anteriormente. Las formas normales ms habituales, por orden ascendente de exigencia de las propiedades deseadas, son: Primera (1FN) Segunda (2FN) Tercera (3FN) Boyce/Codd (FNBC) Cuarta (4FN)

Id_empleado 123A 123A 123A 456B 456B 456B 789C 012D 012D 012D

Em p l ea d os_Cen t r os = U b i ca ci on es_Em p l ea d os ! D a t os_Em p l ea d os NombreE DireccinE Puesto Salario Centro DireccinC David Daz c/ Argentales Profesor 20.000 Informtica Complutense Bernardo Botn c/ Argentales Profesor 20.000 Informtica Complutense Ana Almansa c/ Argentales Profesor 20.000 Informtica Complutense David Daz c/ Barcelona Administrativo 15.000 Matemticas Complutense Bernardo Botn c/ Barcelona Administrativo 15.000 Matemticas Complutense Ana Almansa c/ Barcelona Administrativo 15.000 Matemticas Complutense Carlos Crespo c/ Cruz Catedrtico 30.000 CC. Empresariales Somosaguas David Daz c/ Daroca Ayudante 10.000 Informtica Complutense Bernardo Botn c/ Daroca Ayudante 10.000 Informtica Complutense Ana Almansa c/ Daroca Ayudante 10.000 Informtica Complutense

Telfono 123 123 123 456 456 456 789 123 123 123

En general, los diseos prcticos exigen al menos 3FN. Hay otras formas normales ms exigentes y que se refieren a otras propiedades deseables. Sin embargo, la utilidad prctica de estas formas normales es cuestionable cuando las restricciones en que se basan son difciles de entender o identificar por los diseadores y usuarios. As, en la prctica se usan hasta la forma normal de Boyce/Codd o hasta la cuarta. El proceso de asegurar una forma normal para un esquema se denomina normalizacin. A continuacin se estudiarn las formas normales mencionadas y para cada una de ellas se indicar el procedimiento que asegura que un esquema que no est en una forma normal determinada se convierta en un conjunto de esquemas que asegure esa forma normal.

El atributo que relaciona las tablas originales es DireccinC, que no es clave de ninguna de las relaciones. Como conclusin se deben dividir las tablas de forma que estn relacionadas por atributos clave. Es una conclusin informal que se formaliza al estudiar ms adelante la propiedad de reunin no aditiva. La propiedad de reunin no aditiva asegura recuperar exactamente la informacin original.

5-41

5-42

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.4.3.1.

Primera forma normal

3. Si se conoce la cardinalidad mxima del atributo multivalorado, se pueden crear tantas columnas como la cardinalidad mxima. Presenta como inconveniente el uso de valores Null.
NombreC Informtica Matemticas CC. Empresariales DireccinC Complutense Complutense Somosaguas Telfono1 123 456 789 Telfono2 321 Null 987 Telfono3 213 Null Null

Actualmente se considera como parte de la definicin formal de relacin, porque establece que los dominios de los atributos slo pueden ser atmicos, para evitar atributos multivalorados, compuestos y sus combinaciones. En definitiva evita las relaciones dentro de las relaciones. Ejemplo 12. Si se asume que en la entidad Centros, un centro puede tener ms de un telfono, podramos tener una representacin como la siguiente.
NombreC Informtica Matemticas CC. Empresariales Cen t r os DireccinC Complutense Complutense Somosaguas Telfonos {123, 321, 213} {456} {789, 987}

Sin embargo, esto supondra el uso del atributo multivalorado Telfonos. Hay tres posibilidades de representar la entidad para satisfacer la primera forma normal: 1. Eliminar el atributo Telfonos y crear una nueva relacin que asocie en cada fila un centro con un telfono. La clave de la primera relacin debe formar parte de la clave de la segunda relacin. Presenta como inconveniente aadir una nueva relacin al esquema de la base de datos y redundancia. Presenta anomalas cuando se borra un centro y no se borran los telfonos asociados. La integridad referencial asegura evitar las anomalas.
Cen t r os NombreC DireccinC Informtica Complutense Matemticas Complutense CC. Empresariales Somosaguas
T el fon os NombreC Telfono Informtica 123 Informtica 321 Informtica 213 Matemticas 456 CC. Empresariales 789 CC. Empresariales 987

Si el atributo multivalorado es compuesto, como es el caso de representar varias direcciones para un empleado: Empleados(Id_empleado, NombreP, {Direcciones(Calle, Ciudad, CdigoPostal)}) Esta relacin se puede descomponer en dos: Empleados(Id_empleado, NombreP) DireccionesP(Id_empleado, Calle, Ciudad, CdigoPostal) Este procedimiento de desanidamiento se puede aplicar recursivamente a cualquier relacin con atributos multivalorados. teniendo en cuenta que es necesario propagar la clave de la relacin original a la clave de la nueva relacin, que contiene adems la clave que identifica unvocamente al atributo multivalorado.

2. Ampliar la clave de la relacin de manera que incluya al atributo multivalorado. Presenta como inconveniente aadir redundancia que provoca anomalas.
NombreC Informtica Informtica Informtica Matemticas CC. Empresariales CC. Empresariales Cen t r os DireccinC Complutense Complutense Complutense Complutense Somosaguas Somosaguas Telfono 123 321 213 456 789 987

5-43

5-44

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.4.3.2.

Segunda forma normal

5.4.3.3.

Tercera forma normal

Ejemplo 13. En el ejemplo a continuacin se puede observar que existen anomalas de actualizacin causadas por las dependencias funcionales DF2 y DF3, ya que como sus antecedentes no son clave, puede haber varias filas con el mismo consecuente. Se usa una notacin grfica para la expresin de las dependencias funcionales. As:

DF1 = {Id _ empleado, NmeroP} {Horas} DF 2 = {Id _ empleado} {NombreE} DF 3 = {NmeroP} {NombreP}

Ejemplo 15. En el ejemplo a continuacin se puede observar que existen anomalas de actualizacin causadas por la dependencia funcional DF2. Sin embargo, este esquema est en segunda forma normal porque los dos ltimos atributos, que son los que causan las anomalas, dependen completa (y transitivamente) del nico atributo que forma la clave primaria.
Empleados_Departamentos Id_empleado NombreE DireccinE CdigoD NombreD DirectorD 123A Ana c/ Argentales DS Sistemas 999Z Almansa 012D David c/ Daroca DS Sistemas 999Z Daz

Id_empleado 123A 012D 012D DF1 DF2

Personal_Proyectos NmeroP Horas NombreE P-1 16 Ana Almansa P-1 8 David Daz P-2 4 David Daz

NombreP Proyecto 1 Proyecto 1 Proyecto 2

DF1 DF2

La tercera forma normal se basa en el concepto de dependencia funcional transitiva. Definicin 14. Dependencia funcional transitiva Una dependencia funcional X Y es una dependencia funcional transitiva si existe un conjunto de atributos Z que ni forman clave candidata ni son subconjunto de ninguna clave y adems se cumple X Z y Z Y . En el ejemplo anterior, DF3 es una dependencia funcional transitiva:
Empleados_Departamentos Id_empleado NombreE DireccinE CdigoD NombreD DirectorD 123A Ana c/ Argentales DS Sistemas 999Z Almansa 012D David c/ Daroca DS Sistemas 999Z Daz

DF3

La segunda forma normal evita este tipo de anomalas. Para evitarlas se basa en el concepto de dependencia funcional completa. Definicin 12. Dependencia funcional completa Una dependencia funcional X Y es una dependencia funcional completa si no se cumple X {Ai } Y , Ai X . Cuando se cumple se dice que se trata de una dependencia funcional parcial. Definicin 13. Segunda forma normal Una relacin est en segunda forma normal si cada atributo que no forme parte de la clave primaria depende funcional y completamente de cada clave. Un esquema que no se encuentre en segunda forma normal puede traducirse en varios esquemas que s lo estn. El procedimiento es crear tantas nuevas relaciones como dependencias funcionales no sean completas. Ejemplo 14. As, el ejemplo anterior se traduce en:
PP1 Id_empleado NmeroP PP2 Id_empleado NombreE DF2 PP3 NmeroP NombreP DF3

DF1 DF2 DF3

Horas

DF1

Hay que observar que este procedimiento asegura que el resultado est, al menos, en segunda forma normal. En particular, y como se puede contrastar con la definicin de otras formas normales, el resultado conseguido en este ejemplo se encuentra en 4FN, como se podr comprobar ms adelante.

Definicin 15. Tercera forma normal Codd: Un esquema est en tercera forma normal si satisface la segunda forma normal y ninguno de los atributos que no forman parte de una clave candidata depende transitivamente de la clave primaria. Esta definicin se puede reformular como: Un esquema est en tercera forma normal con respecto a un conjunto de dependencias funcionales S si para toda dependencia funcional no trivial X Y de S + se cumple que o bien X es superclave o bien Y forma parte de una clave candidata. La reformulacin admite una implementacin del test de tercera forma normal ms inmediata con la definicin de cierre de un conjunto de dependencias funcionales. El procedimiento para normalizar esta relacin consiste en descomponerla en los atributos definidos por la dependencia funcional responsable de la transitividad.
ED1 Id_empleado NombreE DireccinE DF1 CdigoD CdigoD DF2 ED2 NombreD DirectorD

5-45

5-46

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.4.3.4.

Forma normal de Boyce-Codd

La forma normal de Boyce-Codd (FNBC) se propuso como una forma ms simple que la tercera, pero en realidad es ms estricta porque cada relacin en FNBC est en 3FN pero lo contrario no se cumple. Ejemplo 16. La siguiente relacin est en 3FN, pero no en FNBC, que evita otras redundancias que la 3FN no puede. En este ejemplo se almacena informacin de los investigadores participantes en proyectos, que pueden ser codirigidos, pero los investigadores principales no pueden dirigir ms de uno.
Proyectos Proyecto Proyecto 1 Proyecto 1 Proyecto 1 Proyecto 2 Proyecto 1 DF2

Ejemplo 17. Con esta definicin se detecta que el ejemplo anterior no est en FNBC. La descomposicin del esquema no es inmediata, hay tres posibilidades:
P1a Investigador IPrincipal P2a Proyecto IPrincipal Proyecto P1b Investigador Proyecto P2b Investigador

P3a IPrincipal Proyecto IPrincipal

P3b Investigador

Investigador 111A 222B 333C 444D 444D DF1

IPrincipal 123A 012D 123A 789C 123A

Todas estas descomposiciones pierden la dependencia funcional DF1 porque las dependencias funcionales se refieren al contexto local de un esquema, no hacen referencia a esquemas externos. An peor, las dos primeras generan tuplas incorrectas en la operacin join. Por ejemplo, en la primera descomposicin se pierde la informacin de los investigadores principales de cada proyecto:
P1a Investigador IPrincipal 111A 123A 222B 012D 333C 123A 444D 123A 444D 789C P1b Investigador Proyecto 111A Proyecto 1 222B Proyecto 1 333C Proyecto 1 444D Proyecto 1 444D Proyecto 2

En este ejemplo, que cumple la 3NF, hay una anomala que se debera poder evitar, porque si no se vigila la dependencia funcional DF2 se podra aadir una tupla de manera que una persona fuese investigadora principal de dos proyectos. La definicin de la FNBC es ms estricta que la reformulacin de la 3FN: Definicin 16. Forma normal de Boyce-Codd Un esquema est en forma normal de Boyce-Codd con respecto a un conjunto de dependencias funcionales S si para toda dependencia funcional no trivial X Y de S + se cumple que X es superclave.

Investigador 111A 222B 333C 444D 444D 444D 444D

P1a ! P1b Proyecto Proyecto 1 Proyecto 1 Proyecto 1 Proyecto 2 Proyecto 2 Proyecto 1 Proyecto 1

IPrincipal 123A 012D 123A 123A 789C 123A 789C

Por tanto, ninguna de estas dos ltimas descomposiciones es aceptable. Sin embargo, hay otras descomposiciones, como la del ejemplo ::14 de la segunda forma normal que presenta en particular FNBC, y no pierde ninguna dependencia funcional.
PP1 Id_empleado NmeroP DF1 PP2 Id_empleado NombreE DF2 PP3 NmeroP NombreP DF3

Horas

En la prctica, la mayora de los esquemas que estn en 3NF lo estn tambin en FNBC. Es necesario, por tanto, encontrar el modo de crear descomposiciones que, como mnimo, no generen tuplas incorrectas en la reunin. Si las dependencias funcionales no se aseguran en la descomposicin, como en el ejemplo anterior, el diseador debe tenerlas presente y asegurarlas por programacin. Esto implica mantenerlas en el contexto global de varios esquemas, no en el contexto local de uno solo, realizar su reunin y comprobar las dependencias funcionales perdidas, lo cual no es prctico. Por lo tanto, se debe asegurar en un buen diseo que no se pierdan dependencias funcionales.

5-47

5-48

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.4.3.5.

Preservacin de dependencias en la descomposicin

5.4.3.6.

Descomposicin y reuniones no aditivas o sin prdida

Para poder determinar formalmente la condicin de preservacin de dependencias en la descomposicin es necesario una definicin preliminar: Definicin 17. Proyeccin de un conjunto de dependencias funcionales La proyeccin de un conjunto de dependencias funcionales S sobre los atributos Ri , denotada por Ri ( S ) , con Ri R y R esquema de relacin, es el conjunto de dependencias funcionales X Y en S + tales que todos los atributos X Y Ri . Con esta definicin se determinan las dependencias asociadas a cada esquema Ri resultado de la descomposicin de R . Slo queda determinar cundo se preservan todas. Definicin 18. Preservacin de dependencias funcionales Una descomposicin D = {R1 , K , Rm } del esquema R preserva las dependencias funcionales con respecto al conjunto de dependencias funcionales S sobre R si la unin de las proyecciones de S sobre cada Ri es equivalente a S , es decir:

Una propiedad necesaria de mantener en la descomposicin es que no se creen tuplas con valores incorrectos cuando una descomposicin se rene con la operacin join. Hay que asegurar que la descomposicin no pierda la informacin de integridad en las dependencias funcionales que asegure que no se crean tuplas incorrectas. La prdida se refiere a la prdida de informacin de integridad y la no aditividad se refiere a no producir ms tuplas de las que estaban en la relacin antes de la descomposicin. Con la siguiente definicin se caracteriza la propiedad de reunin sin prdida o no aditiva. Definicin 19. Propiedad de reunin no aditiva Una descomposicin D = {R1 , K , Rm } del esquema R presenta la propiedad de reunin no aditiva con respecto al conjunto de dependencias funcionales S sobre R si para todo estado de la relacin r de R que satisfaga S , se cumple: | R1 ( r ), K , Rm ( r ) = r .

R1

( S ) L Rm ( S ) = S

Proposicin 1. Siempre es posible encontrar una descomposicin D que preserve las dependencias con respecto a S tal que cada relacin Ri D est en 3FN. Algoritmo 4. El siguiente algoritmo permite encontrar la descomposicin en esquemas en 3FN que preserva las dependencias: Entrada: Un esquema R y un conjunto de dependencias funcionales S . Salida: Una descomposicin D que preserve las dependencias con respecto a S en 3FN. 1. Encontrar un recubrimiento mnimo T para S . (Se puede usar el algoritmo del tema Restricciones de integridad) }, 2. Para cada X Y T crear un esquema en D con atributos {X {A1 } L {Ak }

Propiedad 1. Una descomposicin D = {R1 , R2 } del esquema R presenta la propiedad de reunin no aditiva con respecto al conjunto de dependencias funcionales S sobre R si y slo si se cumple alguna de las dos condiciones siguientes: ((R1 R2 ) (R1 R2 )) S + , o bien

((R1 R2 ) (R2 R1 )) S +

Propiedad 2. Si se cumple que: Una descomposicin D = {R1 , K , Rm } del esquema R presenta la propiedad de reunin no aditiva con respecto al conjunto de dependencias funcionales S sobre R , y Una descomposicin D1 = { Q1 , K , Qk } del esquema Ri presenta la propiedad de reunin no aditiva con respecto a Ri ( S ) ,

entonces la descomposicin D = {R1 , K , Ri 1 , Q1 , K , Qk , Ri +1 , K , Rm } tambin presenta la propiedad de reunin no aditiva con respecto al conjunto de dependencias funcionales S sobre R. Con estas dos propiedades se puede construir un algoritmo que realice una descomposicin de un esquema de relacin que preserve la propiedad de reunin no aditiva. Algoritmo 5. Entrada: un esquema R y un conjunto de dependencias funcionales S sobre R . Salida: una descomposicin en FNBC que preserva la propiedad de reunin no aditiva. 1. D := { R }. 2. while Q D , tal que Q no est en FNBC do { encontrar una dependencia funcional X Y de Q que viole la FNBC; reemplazar Q por dos esquemas de relacin Q Y y X Y ; };

donde X {A1 }, K , X {Ak } son todas las dependencias funcionales en T cuya parte izquierda es X . (Por tanto, X es clave para el nuevo esquema). 3. Poner el resto de atributos en una nica relacin para asegurar la preservacin de atributos.

5-49

5-50

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

5.4.3.7.

Preservacin de dependencias en la descomposicin y reuniones no aditivas

5.4.3.8.

Cuarta forma normal

Si se desean preservar estas dos propiedades, en general slo se puede asegurar que el resultado se encuentre en 3FN. Ejemplo 18. El esquema Proyectos se encuentra en 3FN. Admite tres descomposiciones y ninguna de ellas preserva la dependencia DF1. Slo la ltima descomposicin preserva reuniones no aditivas. Para comprobarlo: ((R1 R2 ) (R1 R2 )) = ({IPrincipal} {Proyecto}) S + , que de hecho se trata de la dependencia funcional DF2. Con el siguiente algoritmo, que es una modificacin del 4, se puede realizar una descomposicin en 3FN que preserve ambas propiedades. Algoritmo 6. Entrada: un esquema R y un conjunto de dependencias funcionales S sobre R . Salida: una descomposicin en 3FN que preserva dependencias y reuniones no aditivas. 1. Encontrar un recubrimiento mnimo T para S . (Se puede usar el algoritmo del tema Restricciones de integridad) }, 2. Para cada X Y T crear un esquema en D con atributos {X {A1 } L {Ak }

La cuarta forma normal es una generalizacin de la forma normal de Boyce/Codd que se aplica a esquemas con dependencias multivaloradas. Ejemplo 19. En el ejemplo del tema Restricciones de integridad referido a este tipo de dependencias, que se reproduce a continuacin, se observan dos atributos, Direccin y Telfono, que son multivalorados.
Empleados

Nombre Direccin Telfono Ana Almansa c/ Argentales 1 Ana Almansa c/ Argentales 2 Ana Almansa c/ Argentales 3 Ana Almansa c/ Amaniel 1 Ana Almansa c/ Amaniel 2 Ana Almansa c/ Amaniel 3 La idea de la cuarta forma normal es descomponer esta relacin en otras dos, como se muestra a continuacin, preservando las dependencias multivaloradas:
Direcciones

donde X {A1 }, K , X {Ak } son todas las dependencias funcionales en T cuya parte izquierda es X . (Por tanto, X es clave para el nuevo esquema). 3. Si ninguno de los esquemas contiene una clave de R , crear un nuevo esquema que contenga atributos para formar una clave de R .

Nombre Ana Almansa Ana Almansa

Direccin c/ Argentales c/ Amaniel

Telfonos

Nombre Ana Almansa Ana Almansa Ana Almansa

Telfono 1 2 3

Definicin 20. Cuarta forma normal Un esquema de relacin R est en cuarta forma normal con respecto a conjunto de dependencias S , tanto funcionales como multivaloradas, sobre R si por cada dependencia multivalorada no trivial X Y de S + , X es superclave de R .

5-51

5-52

Bases de datos y sistemas de informacin

Bases de datos y sistemas de informacin

y {Nombre} {Telfono} , y {Nombre} no es superclave.

Ejemplo 20. Segn esta definicin se puede comprobar que la relacin de este ltimo ejemplo no est en 4FN. En este ejemplo se tienen las dependencias multivaloradas {Nombre} {Direccin}

5.4.3.9.

Otras formas normales

La definicin de 4FN es anloga a la de 3FN, la nica diferencia es usar dependencias multivaloradas en lugar de dependencias funcionales. Asegurar la 4FN en esquemas con dependencias multivaloradas es esencial en trminos de ahorro de espacio debido a la redundancia. Para mantener la integridad de una relacin con k atributos multivalorados es necesario mantener

Hay otras formas normales ms exigentes que la 4FN. Las dependencias multivaloradas permiten representar restricciones que no se pueden expresar con dependencias funcionales. Otros tipos de restricciones son las dependencias de reunin que generalizan las dependencias multivaloradas y que conducen a otra forma normal denominada forma normal proyeccinreunin, o tambin denominada quinta forma normal. Ejemplo 21. En el siguiente ejemplo se tiene que un proveedor suministra un determinado material a un determinado proyecto. Se encuentra en 4FN porque no hay dependencias multivaloradas y, por lo tanto, no se debera descomponer. De hecho, todos sus atributos forman la clave. Sin embargo, supongamos que se aade la siguiente restriccin: si un proyecto usa un material que vende un determinado proveedor y necesita otro material que vende el mismo proveedor, entonces este otro material debe comprarlo al mismo proveedor. Por lo tanto, se deben aadir las dos ltimas filas.
Compras

A
i =1

tuplas. Slo con dos atributos

multivalorados de cardinalidad 4 seran necesarias 16 tuplas en lugar de las 8 necesarias en la descomposicin. La descomposicin de un esquema de relacin R en R1 = X Y y R2 = R Y con respecto a la dependencia multivalorada X Y asegura las reuniones no aditivas. La siguiente propiedad lo asegura: Propiedad 3. Una descomposicin D = {R1 , R2 } del esquema R presenta la propiedad de reunin no aditiva con respecto al conjunto de dependencias funcionales S sobre R si y slo si se cumple alguna de las dos condiciones siguientes: ((R1 R2 ) (R1 R2 )) S + , o bien

((R1 R2 ) (R2 R1 )) S +

Proveedor Proveedor A Proveedor A Proveedor B Proveedor C Proveedor B Proveedor B Proveedor A

Material Toner Papel Toner Papel Clips Toner Toner

Proyecto Proyecto 1 Proyecto 2 Proyecto 2 Proyecto 3 Proyecto 1 Proyecto 1 Proyecto 2

Esta propiedad es anloga a la usada para la caracterizacin de la descomposicin en la FNBC, salvo que se usan dependencias multivaloradas en lugar de funcionales. Se puede plantear un algoritmo de descomposicin en esquemas en 4FN que preserve reuniones sin prdida, aunque no se puede asegurar preservar las dependencias funcionales. Algoritmo 7. Entrada: un esquema R y un conjunto de dependencias multivaloradas S sobre R . Salida: una descomposicin en 4FN que preserva la propiedad de reunin no aditiva. 1. D := { R }. 2. while Q D , tal que Q no est en 4FN do { encontrar una dependencia multivalorada X Y de Q que viole la 4FN; reemplazar Q por dos esquemas de relacin Q Y y X Y ; };

No obstante, este tipo de dependencias surgen en muy raras ocasiones y hay que buscar ejemplos forzados. La forma normal de claves y dominios intenta ser una forma normal definitiva. Se dice que un esquema est en forma normal de claves y dominios cuando todas las restricciones de la relacin estn expresadas como restricciones de clave y de dominio. La comprobacin de la consistencia sera fcil de determinar. Sin embargo, la dificultad de expresar restricciones de integridad generales hacen que esta forma normal sea de escasa utilidad.

5.4.4.

Resumen

Las formas normales buscan que las claves sean las protagonistas en el mantenimiento de la integridad, con el objetivo de que el diseo est protegido por las claves. La idea es detectar las posibles fuentes de redundancias y anomalas y descomponer la relacin. Hay dos propiedades que son deseables mantener en el proceso de normalizacin: - Preservar las dependencias funcionales. - Preservar las reuniones no aditivas. La segunda es de importancia fundamental, la primera no siempre se puede asegurar. El mejor diseo que siempre se puede alcanzar conservando ambas propiedades es la 3FN. En otros casos slo a veces ser posible alcanzar formas normales superiores conservando estas propiedades.

5-53

5-54

Bases de datos y sistemas de informacin

Bibliografa
[ACPT00] [EN00] [SKS98] [Ull98] P. Atzeni, S. Ceri, S. Paraboschi y R. Torlone, Database Systems. Concepts, Languages and Architectures, McGraw-Hill, 2000. Apartados 5.1, 5.2, 5.3 R. Elmasri y S.B. Navathe, "Fundamentals of Data Base Systems", AddisonWesley, 2000. Apartados A. Silberschatz, H.F. Korth y S. Sudarshan, "Fundamentos de Bases de Datos", 3 edicin, McGraw-Hill, 1998. Apartados J.D. Ullman, "Principles of Database and Knowledge Base Systems", Vol. I y II, Computer Science Press, 1998. Apartados

5-55