Capitulo 4

4,176 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,176
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
193
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Capitulo 4

  1. 1. 4 TEMA 4. DISEÑO DE BASES DE DATOS 4 TEMA 4. DISEÑO DE BASES DE DATOS........................................................... 1 4.1 Metodologías de diseño .................................................................................... 2 4.1.1 Introducción.............................................................................................. 2 4.1.2 Metodologías de diseño de bases de datos ............................................... 3 4.2 Diseño Conceptual. El Modelo Entidad-Relación (E/R).................................. 6 4.2.1 Conceptos fundamentales ......................................................................... 6 4.2.2 Control de redundancia de los diagramas E/R.......................................... 8 4.2.3 Modelo E/R extendido.............................................................................. 9 4.3 Diseño Lógico. Normalización....................................................................... 13 4.3.1 Transformación de diagramas E/R en relaciones ................................... 13 4.3.2 Normalización. Formas Normales.......................................................... 15 4.3.3 Dependencias funcionales ...................................................................... 16 4.3.4 Primera, segunda y tercera formas normales.......................................... 17 4.3.5 Forma normal de Boyce/Codd................................................................ 19 4.3.6 Cuarta forma normal............................................................................... 20 4.3.7 Quinta forma normal .............................................................................. 21 4.4 Diseño Físico .................................................................................................. 23 4.4.1 Introducción al diseño físico................................................................... 23 4.4.2 Criterios para la selección de índices ..................................................... 24 Tema 4: Diseño de bases de datos 1
  2. 2. 4.1 Metodologías de diseño 4.1.1 Introducción Un sistema de información (SI) es un conjunto de elementos que funcionan conjuntamente con el objetivo de recoger, tratar, manipular y aportar la informaciones necesarias para el desarrollo de las actividades de una empresa u organización. Un SI puede incluir procesos manuales o automáticos. Uno de los elementos principales de un SI es la base de datos (BD). Las BD son ejemplos típicos de grandes sistemas de software con tres características importantes: • Hay una gran cantidad de datos que deben ser almacenados en memoria externa y que deben ser organizados de forma que los datos elementales puedan ser recuperados y actualizados fácil y eficientemente. • Los datos guardan entre sí complejas interrelaciones. La información incluye restricciones estáticas y dinámicas, como los valores permitidos o las posibles evoluciones. • Los datos deben ser compartidos entre diferentes usuarios y el sistema debe mantener la integridad de la información. Un modelo es una representación de un sistema que pretende simplificar su comprensión poniendo en evidencia ciertos aspectos del sistema mientras otros son ocultados. Los modelos se utilizan para facilitar la tarea de diseño de los SI complejos, ya que facilitan ‘pensar en lo que se está haciendo’ y permiten comprobar la corrección y adecuación al problema de los resultados. Los modelos pueden tener distintos niveles de abstracción. En los SI se utilizan tres tipos de modelos con diferentes niveles de abstracción: • El modelo físico, que describe completamente el sistema: circulación y tratamiento de la información, elementos informáticos y elementos manuales. Para la BD el modelo físico representa la organización de la información sobre los soportes de almacenamiento. • El modelo lógico, que describe las informaciones y las manipulaciones a que son sometidas. Este modelo hace abstracción de los soportes materiales de almacenamiento. El modelo lógico sobre una BD representa la definición de la información sobre el SGBD elegido para el desarrollo del SI. • El modelo conceptual, que describe el contenido subyacente al modelo lógico, esto es, el significado de las informaciones y las relaciones que las unen. Este modelo hace abstracción de las manipulaciones de la información. En los siguientes capítulos se establecen los conceptos y técnicas necesarios para diseñar bases de datos. Los criterios que definen un buen diseño de la BD, según Gardarín, son: Tema 4: Diseño de bases de datos 2
  3. 3. • Independencia física • Independencia lógica • Manipulación de datos por no informáticos • Eficacia del acceso a los datos • Administración centralizada de los datos • No redundancia de los datos • Coherencia de los datos • Compatibilidad de los datos • Seguridad de los datos 4.1.2 Metodologías de diseño de bases de datos Existen distintas metodologías para el diseño de SI y de BD, que identifican las etapas del diseño, los subproductos que se obtienen en cada una de ellas, así como las utilerías necesarias para desarrollar esta actividad. Algunas de las metodologías más utilizadas son MERISE y SSADM. En este capítulo describiremos una de las metodología para el desarrollo de BD relacionales, que sigue las recomendaciones más comunes encontradas en la literatura. 4.1.2.1 Análisis de requisitos de usuario El objetivo de esta etapa es describir con precisión el contenido de información de la base de datos y determinar las demandas de transacción que sufrirá el sistema. Las especificaciones del sistema pueden describirse informalmente utilizando descripciones narrativas, o formalmente utilizando un modelo de datos. El modelo de datos a utilizar debe ser suficientemente ‘expresivo’ como para poder representar toda la información de la BD. Al integrar la BD las necesidades de información de distintos grupos de usuarios y de distintas aplicaciones dentro de la empresa u organización, será un previo identificar todos los grupos de usuarios que interactúan con la BD. Posteriormente se obtendrá para cada uno de estos grupos la descripción detallada de sus requisitos. Cada grupo de estas especificaciones constituye una vista particular de la BD. En esta etapa se identificarán los objetos o eventos del mundo real que almacenará la BD, sus propiedades y las relaciones que mantienen entre ellos. Se identificarán las condiciones de integridad de la información que darán lugar a restricciones de manipulación. Se identificarán las autorizaciones de acceso a la información por parte de los distintos grupos de usuarios. También puede ser interesante en esta etapa tener una estimación del volumen de datos a almacenar. Por último, se identificarán las operaciones a realizar sobre la información. Esta información es relevante en el modelo relacional únicamente para el diseño del modelo físico de la BD. Por esta razón, en algunos casos no se requiere. Se describirán la naturaleza de las transacciones, la frecuencia con que se realizan, la información que utilizan y producen, así como el flujo de información entre ellas. Tema 4: Diseño de bases de datos 3
  4. 4. 4.1.2.2 Diseño del esquema conceptual En esta etapa se combinan los requisitos de los distintos grupos de usuarios del sistema para contribuir a una descripción única y coherente de toda la información a almacenar en la BD. El esquema conceptual se desarrolla en un modelo semántico y define las entidades en la BD, las relaciones entre ellas, las restricciones de integridad de la información, los grupos de usuarios y las autorizaciones de acceso de cada uno de ellos. Este proceso se conoce a veces como integración de vistas, y en el se produce una descripción global de la BD eliminando la redundancia e inconsistencia entre las especificaciones de distintos grupos de usuarios. El modelador debe reconocer entre las diferentes vistas los sinónimos y homónimos y aquellos tipos de datos que pertenecen a las mismas categorías. En esta etapa se construye un modelo de datos que describe cada uno de los objetos y sus relaciones. Se identifican los atributos que forman las claves de acceso a los objetos, se decide la representación de las interrelaciones y se identifican las propiedades opcionales y fijas, para lo cual se utiliza un modelo semántico de datos, comúnmente el modelo Entidad/Relación, que será el que utilicemos nosotros en esta presentación. 4.1.2.3 Diseño Lógico Durante esta etapa, el modelo conceptual se transforma en el modelo empleado por el SGBD donde se implementará el sistema. El modelo que más se utiliza hoy por hoy es el modelo relacional, aunque se utilizan todavía el modelo en red y el jerárquico. Para BD relacionales, en esta etapa se construyen las tablas a partir de los elementos del esquema conceptual, incluyendo las relaciones entre entidades y las reglas de integridad. En esta etapa se crean los usuarios y se administran las autorizaciones para acceder a la información. El modelo E/R desarrollado en el paso anterior puede transformarse directamente en tablas, siguiendo una serie de reglas de transformación. La mayoría de modelos ofrece estas reglas para una transformación semiautomática del esquema conceptual de relaciones de la BD. 4.1.2.4 Normalización de los esquemas relacionales En muchos casos, las tablas resultantes del proceso anterior se someten a un proceso posterior de normalización que elimina redundancias de la información no eliminadas y que repercuten en dificultades en el procesamiento de la información. 4.1.2.5 Diseño físico En función de las operaciones a realizar sobre la BD, se definen los mecanismos de almacenamiento y organización de la información, incluyendo la creación de índices o la agrupación en ‘clusters’ de los datos. En algunos casos puede ser necesario desnormalizar la información (añadiendo redundancia) para conseguir el rendimiento deseado de la aplicación. Tema 4: Diseño de bases de datos 4
  5. 5. 4.1.2.6 Implementación Es la transformación del modelo de datos y los diseños realizados en una base de datos en funcionamiento, que opere en un determinado equipo y bajo el control de un SGBD. 4.1.2.7 Test La etapa de test tiene el propósito de descubrir errores aparecidos en las etapas anteriores y que provocan un comportamiento del sistema diferente al previsto. Es también objetivo de la etapa de test el comprobar junto a los usuarios que el sistema satisface los objetivos establecidos durante la etapa de especificación. 4.1.2.8 Mantenimiento La fase de mantenimiento incluye la corrección de errores que pudieran aparecer durante la etapa de operación del sistema. La implementación también comprende las modificaciones que el usuario pudiera solicitar a partir de la experiencia de operación del sistema o de nuevas necesidades, la mejora de la eficacia del sistema y la mejora de los interfaces de usuario. Tema 4: Diseño de bases de datos 5
  6. 6. 4.2 Diseño Conceptual. El Modelo Entidad-Relación (E/R) En este apartado estudiaremos el modelo E/R, uno de los modelos de datos conceptuales más extendidos en las metodologías de diseño de bases de datos y en las herramientas CASE. El modelo E/R fue propuesto por Peter P. Chen en 1976. Según Chen, ‘el modelo E/R puede ser usado como una base para una vista unificada de los datos’, adoptando ‘el enfoque más natural del mundo real que consiste en entidades y relaciones’. Posteriormente, otros autores han investigado y escrito sobre el modelo, proponiendo importantes aportaciones, por lo que realmente no se puede considerar que exista un único modelo E/R, sino más bien lo que podríamos llamar una familia de modelos. El modelo E/R está centrado en dos conceptos fundamentales: el de entidad y el de relación que explicaremos más adelante en está sección de forma detallada. Desde que fue propuesto, este modelo ha tenido una gran difusión y ha despertado un enorme interés en la comunidad informática dedicada a las bases de datos. 4.2.1 Conceptos fundamentales En el modelo E/R se pueden distinguir como elementos fundamentales las entidades, los atributos, y las relaciones, además del conjunto de valores (análogo al concepto de dominio). 4.2.1.1 Entidad Se puede definir entidad como aquel objeto (real o abstracto) acerca del cual queremos almacenar información en la base de datos. Denominaremos a la estructura genérica en su sentido abstracto tipo de entidad, mientras que entidad será cada una de las ocurrencias o instancias de este tipo de entidad. La representación gráfica de un tipo de entidad es un rectángulo etiquetado con el nombre del tipo de entidad: LIBRO AUTOR Tres reglas generales que debe cumplir cualquier entidad son (Tardieu): • Tiene que tener existencia propia • Cada ocurrencia de un tipo debe poder distinguirse de las demás • Todas las ocurrencias de un tipo de entidad deben tener los mismos tipos de características (atributos). Existen dos clases de entidades: regulares, que tienen existencia por ellas mismas, y débiles, cuya existencia depende de otro tipo de entidad (p. ej., FAMILIAR depende de que exista EMPLEADO, y la eliminación de EMPLEADO obliga a la eliminación de FAMILIAR). Tema 4: Diseño de bases de datos 6
  7. 7. Los tipos de entidad débil se representan con dos rectángulos concéntricos con su nombre en el interior: LIBRO 4.2.1.2 Relación Se entiende por relación a aquella asociación o correspondencia existente entre entidades. Llamaremos tipo de relación a la estructura genérica del conjunto de relaciones existentes entre dos o más tipos de entidad. El tipo de relación se representa mediante un rombo etiquetado con el nombre de la relación, unido mediante arcos a los tipos de entidad que asocia. P. ej.: LIBRO escribe AUTOR Entre dos tipos de entidades puede existir más de un tipo de relación. Una relación se define por su nombre y por su grado. El nombre es el identificador que se le da a la propia relación, y el grado equivale al número de tipos de entidad a los que asocia o relaciona. Así por ejemplo, en el caso anterior, ‘escribe’ es una relación de grado 2. También pueden existir relaciones de grado 1 (o reflexivas), de grado 3, 4, … En general, las relaciones de grado superior a 2 se suelen reducir a relaciones de grado 2, si la semántica de la relación lo permite, puesto que se facilita tanto la comprensión del diagrama como la posterior conversión a otros modelos. Otro elemento que caracteriza a las relaciones es el tipo de correspondencia, que es el número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una ocurrencia del tipo de relación que se está tratando. Gráficamente, esto se representa con alguna de estas etiquetas textuales: 1:1, 1:N, N:M. El papel o rol es la función que cada tipo de entidad realiza en el tipo de relación. Se representa con su nombre sobre el arco que une el tipo de entidad con el tipo de relación. P. ej.: N:M es_escrito_por escribe LIBRO escribe AUTOR 4.2.1.3 Atributo Cada una de las propiedades o características que tiene un tipo de entidad o un tipo de relación se denomina ATRIBUTO. La representación gráfica de un atributo consiste en una elipse con el nombre del atributo en su interior. Tema 4: Diseño de bases de datos 7
  8. 8. Entre todos los atributos de un tipo de entidad debemos elegir uno o varios que actúen como claves primarias. Estos atributos se representarán de la misma forma, pero con el nombre del atributo subrayado. Veamos un ejemplo: N:M es_escrito_por escribe LIBRO escribe AUTOR ISBN Título Fecha Nombre F_nac 4.2.2 Control de redundancia de los diagramas E/R Una vez construido un esquema E/R, hay que analizar si se presentan redundancias, ya que pueden acarrear problemas a la hora de instrumentar la base de datos. Además de la existencia de atributos redundantes, como los que se derivan de otros mediante algún cálculo, hay que estudiar detenidamente los ciclos en el diagrama E/R, ya que pueden indicar la existencia de relaciones redundantes. Un ciclo en un diagrama E/R es un grupo de tipos de entidad unidos en forma circular o cíclica a través de ciertas relaciones. P. ej.: N:M N:M escribe AUTOR publica N:1 LIBRO edita EDITORIAL Es evidente que en este ejemplo podríamos eliminar la relación publica, puesto que si conocemos los libros que un autor ha escrito, y sabemos las editoriales que editan dichos libros, somos capaces de extrapolar las editoriales en las que un determinado autor publica sus libros. Por consiguiente, podemos eliminar la relación publica de nuestro diagrama por ser redundante. Este caso no es general, es decir, es posible que existan ciclos en los que no aparezcan redundancias. Los casos más típicos son los que resultan de dividir relaciones ternarias en sus correspondientes binarias. Tema 4: Diseño de bases de datos 8
  9. 9. 4.2.3 Modelo E/R extendido Una vez visto el modelo básico de Chen, hay que profundizar un poco más en otros aspectos que aportan aún más significado y relevancia a esta herramienta, tan fundamental en la fase de diseño conceptual. Ya hemos señalado que varios autores han considerado diversas extensiones al modelo E/R definido por Chen, dando lugar a lo que algunos han llamado modelo E/R extendido (EE/R). Trataremos de mostrar las extensiones al modelo más interesantes por su funcionalidad y uso. 4.2.3.1 Cardinalidad de un tipo de entidad Se define como el número máximo y mínimo de ocurrencias de un tipo de entidad que pueden estar relacionadas con una ocurrencia del otro u otros tipos de entidad que participan en la relación. Su representación gráfica es una etiqueta del tipo (0,1), (1,1), (0,n), o (1,n), según corresponda. El significado de cada una es: • (0,1). Para una ocurrencia determinada de los otros tipos de entidades que participan en la relación, el valor mínimo de ocurrencias de la entidad que se trata es 0, y el número máximo es 1. • (1,1). Para una ocurrencia determinada de los otros tipos de entidades que participan en la relación, debe existir una y sólo una ocurrencia de la entidad que se trata. • (0,n). Para una ocurrencia determinada de los otros tipos de entidades que participan en la relación, el valor mínimo de ocurrencias de la entidad que se trata es 0, y el número máximo es n. • (1,n). Para una ocurrencia determinada de los otros tipos de entidades que participan en la relación, debe existir como mínimo una ocurrencia de la entidad que se trata, si bien no hay límite en el número de veces que dicha ocurrencia puede aparecer en la relación. Ejemplo: 1:N (1,1) (1,n) DEPTO. pertenece EMPLDO. 4.2.3.2 Relaciones exclusivas Decimos que dos o más tipos de relación son exclusivos cuando cada ocurrencia de un tipo de entidad sólo puede pertenecer a un tipo de relación. Un ejemplo, con su correspondiente forma de representación, es el siguiente: Tema 4: Diseño de bases de datos 9
  10. 10. publica REVISTA ARTICULO aparece RECOPILACION 4.2.3.3 Generalización y Herencia La descomposición de tipos de entidad en varios subtipos es una necesidad muy habitual en el modelado de bases de datos. En el mundo real se pueden identificar varias jerarquías de entidades. La relación que se establece entre un supertipo y sus subtipos corresponde a la noción de ‘es_un’ o ‘es_un_tipo_de’. Este tipo de relación especial se representa a través de un triángulo invertido con la base paralela al rectángulo que representa al supertipo, y conectado a los subtipos. Esta relación tiene la característica de que toda ocurrencia de un subtipo es una ocurrencia del supertipo, aunque no sucede lo contrario, con lo que las cardinalidades serán siempre (1,1) en el supertipo, y (0,1) o (1,1) en el subtipo. El atributo del supertipo que actúa como discriminante se liga al triángulo a través de una elipse. Por ejemplo: EMPLEADO (1,1) tipo es-un (0,1) (0,1) DOCENTE NO DOCENTE Una característica importante en estas relaciones es la herencia, puesto que cualquier atributo del supertipo pasa a ser un atributo de los subtipos. Adicionalmente, existen dos tipos de elementos para la representación que se utilizan para indicar: • Arco. Indica la exclusividad de los subtipos, es decir, que una entidad del supertipo sólo puede ser de uno sólo de los subtipos. • Elipse vacía. Indica la obligatoriedad del supertipo de pertenecer a alguno de los subtipos. Tema 4: Diseño de bases de datos 10
  11. 11. Un ejemplo completo de estos diagramas es: EMPLEADO (1,1) tipo es-un (0,1) (0,1) DOCENTE NO DOCENTE En este caso, se indica que un empleado debe ser de tipo docente o no docente, y además no puede pertenecer a los dos subtipos a la vez. 4.2.3.4 Relaciones Ternarias (de grado 3) Como ya se ha mencionado con anterioridad, lo habitual es encontrar relaciones binarias en los diagramas E/R. Sin embargo, esto no significa que no puedan existir relaciones de orden superior, aunque siempre es conveniente tratar de reducirlas (en la medida en que la semántica de la relación lo permita) a relaciones binarias. Vamos a analizar cómo se representan las relaciones ternarias, y cómo se deben interpretar las cardinalidades de estos tipos de relaciones. Supongamos la relación ternaria mostrada en la figura inferior. En esta relación de ejemplo aparecen las entidades Profesor, Asignatura y Alumno. La relación se llama curso, y representa las ternas que se pueden dar durante un curso académico, relacionando los profesores que imparten ciertas asignaturas, con los alumnos matriculados en dichas asignaturas, y por ende, los profesores que tienen asignados ciertos alumnos. PROFESOR (0,1) ASIGNATURA (0,n) curso (0,n) ALUMNO Tema 4: Diseño de bases de datos 11
  12. 12. Es evidente que esta relación se podría descomponer en tres relaciones binarias, de modo que los profesores estuviesen relacionados con los alumnos a los que les imparten clase, los alumnos estuviesen relacionados con las asignaturas en las que están matriculados, y las asignaturas estuviesen relacionadas con los profesores que las imparten. La información que se podría extraer de ambos diagramas E/R sería la misma, sólo que quizás se encontraría de forma más compacta en la representación tabular correspondiente al diagrama con la relación ternaria. No obstante, es mucho más fácil de interpretar el diagrama E/R con relaciones binarias. Volviendo al diagrama con la relación ternaria, hay que indicar que todos los elementos que pueden aparecer en torno a la relación tienen el mismo significado que en las relaciones binarias, excepto la cardinalidad de las relaciones. Como podrá observarse fácilmente, la cardinalidad de una relación binaria hace referencia al número de apariciones que puedo tener (máximo y mínimo) de una entidad respecto a la aparición de un elemento de la otra entidad que participa en la relación. Si se pretende extender este significado al caso de relaciones de orden n, habrá que especificar la cardinalidad máxima y mínima de elementos de una entidad respecto a los n-1 elementos de las n-1 entidades restantes. Es decir, hay que fijar la aparición de elementos de n-1 entidades para encontrar la cardinalidad máxima y mínima de los elementos de la entidad restante. Por tanto, en nuestro ejemplo, la cardinalidad (0,n) correspondiente a la entidad alumno indica que para una pareja fija de profesor/asignatura puedo tener en la relación un mínimo de 0 alumnos y un máximo sin determinar. Tema 4: Diseño de bases de datos 12
  13. 13. 4.3 Diseño Lógico. Normalización. En el diseño lógico se debe coordinar exigencias casi siempre encontradas, como son eliminar redundancias, conseguir la máxima simplicidad, y evitar cargas suplementarias de programación, obteniendo una estructura lógica adecuada que venga a establecer el debido equilibrio entre las exigencias de los usuarios y la eficiencia. Pero básicamente, el proceso de diseño lógico debe utilizar como entrada un modelo de datos conceptual, el cual se deberá convertir al modelo de la base de datos para el que se está diseñando, esto es, el diseño lógico consiste en una transformación de modelos. Adicionalmente, será necesario comprobar que el modelo lógico resultante garantiza las propiedades de eliminación de redundancias, fácil accesibilidad a los datos, etc. Para ello, en el caso de bases de datos relacionales, recurriremos a la teoría de la normalización, que nos permitirá obtener las mejores relaciones posibles para un esquema lógico. 4.3.1 Transformación de diagramas E/R en relaciones El paso de un esquema en el modelo E/R al relacional está basado en los tres principios siguientes: • Todo tipo de entidad se convierte en una relación. • Todo tipo de relación N:M se transforma en una relación. • Todo tipo de relación 1:N se traduce en el fenómeno de propagación de clave o se crea una nueva relación. En el proceso de transformación de esquemas se pierde semántica, pero esto no va a afectar para nada la integridad de la base de datos, ya que se definirán, por ejemplo, restricciones de integridad referencial para asegurar la conservación de la misma. 4.3.1.1 Transformación de entidades Cada tipo de entidad se debe convertir a una relación, es decir, será necesario crear una tabla para cada entidad que aparezca en el diagrama E/R. Esto, sin embargo, tiene alguna restricción para el caso particular en que las relaciones entre entidades sea del tipo 1:1. 4.3.1.2 Transformación de atributos de entidades Cada atributo de una entidad se debe transformar en una columna en la relación a la que ha dado lugar la entidad. Puesto que hay diferentes tipos de atributos, hay que indicar cómo se deben definir cada uno de ellos: • El o los atributos principales de una entidad (es decir, los que actúan como identificador único para los elementos de la relación, subrayados en el esquema) pasan a ser la clave primaria de la relación. Se debe especificar que no son nulos. Tema 4: Diseño de bases de datos 13
  14. 14. • El resto de atributos pasan a ser columnas de la tabla, pudiendo tomar valores nulos, a no ser que se indique lo contrario. 4.3.1.3 Transformación de relaciones Dependiendo del tipo de relación (cardinalidad) de que se trate, existen diversas formas de transformarlas: • Relaciones N:M. Se transforman en una relación que tendrá como clave primaria la concatenación de los atributos principales de cada una de las entidades que relacionan. Estos atributos deben ser clave ajena respecto a cada una de las tablas donde ese atributo es clave primaria. Habrá que considerar lo que ocurre en los casos en los que se borre o modifique la clave primaria referenciada. Será necesario crear las restricciones de cardinalidad adecuadas a través de la sentencia CHECK de SQL. • Relaciones 1:N. Existen dos soluciones para transformarlas. Habrá que considerar en ambos casos las referencias ajenas, y las actuaciones en caso de borrado y modificación. a) Propagar el atributo principal de la entidad que tiene cardinalidad máxima 1 a la que tiene N, y hacer desaparecer la relación como tal. b) Transformarla en una relación como si fuese una de tipo N:M. Esta acción sólo es recomendable en los casos en que: 1) cuando es posible que aparezcan muchos nulos porque existen pocos elementos relacionados, 2) cuando se prevé que dicha relación pasará en un futuro a ser de tipo N:M, y 3) cuando la relación tiene atributos propios. • Relaciones 1:1. Puesto que se trata de una particularización de cualquiera de los dos casos anteriores, se puede del mismo modo aplicar cualquiera de las dos reglas definidas. No obstante, es recomendable seguir las siguientes reglas: 1) si la relacione es (0,1)(0,1), es mejor crear una relación para evitar el tener muchos nulos como propagación de alguna de las claves a la otra relación (si se prevé que puede haber muchos nulos); 2) si la relación es (0,1)(1,1), es mejor propagar la clave de la entidad (1,1) a la (0,1); 3) si la relación es (1,1)(1,1) la propagación es indiferente, y se hará atendiendo a los criterios de frecuencia de acceso (consulta, modificación, inserción, etc.) a cada una de las tablas en cuestión. 4.3.1.4 Transformación de atributos de relaciones Si la relación se transforma en una tabla, todos sus atributos pasan a ser columnas de la tabla. En el caso en que alguno de los atributos de la relación sea principal, deberá ser incluido como parte de la clave primaria en dicha tabla. 4.3.1.5 Transformación de relaciones exclusivas Para soportar relaciones exclusivas debemos definir las restricciones pertinentes en cada caso. Por ejemplo, en el caso en que exista una exclusividad en la edición de un libro Tema 4: Diseño de bases de datos 14
  15. 15. por parte de una editorial o de una universidad, estas dos relaciones se resuelven mediante el mecanismo de propagación de la clave, llevando las claves primarias de editorial y universidad a libro. Se utilizará entonces la cláusula CHECK de SQL para introducir las restricciones pertinentes. Ejemplo: CRATE TABLE LIBRO ( Cod_libro char(10), Titulo, char(100), … Cod_editorial char(20), Cod_univers char(20), PRIMARY KEY(Cod_libro), FOREIGN KEY (Cod_editorial) REFERENCES Editorial ON UPDATE CASCADE, FOREIGN KEY (Cod_univers) REFERENCES Univers ON UPDATE CASCADE, CHECK ( (Cod_editorial IS NULL AND Cod_univers IS NOT NULL) OR (Cod_univers IS NULL AND Cod_editorial IS NOT NULL) ); 4.3.1.6 Transformación de tipos y subtipos Los tipos y subtipos no son objetos que se puedan representar en el modelo relacional estándar. Existen, pues, varias posibilidades para su transformación: • Englobar todos los atributos de una entidad y sus subtipos en una sola relación, añadiendo el atributo que permite distinguir los subtipos. También habrá que especificar las restricciones semánticas adecuadas. • Crear una relación para el supertipo, y tantas relaciones como subtipos existan. Esta es la mejor opción desde el punto de vista semántico, pero es menos eficiente que la opción anterior. • Crear sólo relaciones para los subtipos, añadiendo en cada una de ellas los atributos pertenecientes al supertipo. 4.3.2 Normalización. Formas Normales Lo que nos ocupa aquí es el esquema conceptual. El diseño de bases de datos es en realidad el diseño de esquemas. Las relaciones base de una BD relacional siempre están normalizadas, en el sentido de que los dominios simples subyacentes contienen sólo valores atómicos. Este tema lleva la idea de normalización mucho más lejos. El punto fundamental es que una relación dada, aun cuando pudiera estar normalizada, podría poseer ciertas propiedades indeseables. La teoría de la normalización nos permite reconocer esos casos y nos muestran cómo podemos convertir esas relaciones a una forma más deseable. La teoría de la normalización tiene como fundamento el concepto de formas normales. Se dice que una relación está en una determinada forma normal si satisface un cierto conjunto de restricciones. Se ha definido un gran número de formas normales (FN). En principio, Codd definió la 1FN, 2FN y 3FN, con la idea de que era más deseable que una relación estuviese en Tema 4: Diseño de bases de datos 15
  16. 16. 2FN que en 1FN, y a su vez, era mejor que estuviese en 3FN que en 2FN. Se introdujo también la idea de un procedimiento, el procedimiento de normalización, con el cual una cierta relación en una determinada FN puede convertirse en un conjunto de relaciones más deseables (o sea, en una FN superior). Además, este procedimiento es reversible, lo que garantiza que no se pierde información en cada paso del proceso. Con posterioridad, se definieron la forma normal de BOYCE/CODD (FNBC) y las 4FN y 5FN. El siguiente gráfico muestra como las relaciones se agrupan en función de su estado de normalización: Universo de las relaciones Relaciones 1FN Relaciones 2FN Relaciones 3FN Relaciones FNBC Relaciones 4FN Relaciones PJ/NF (5FN) 4.3.3 Dependencias funcionales El concepto de dependencia funcional se define del siguiente modo: Dada una relación R, el atributo Y de R depende funcionalmente del atributo X de R (R.X R.Y) si y sólo si un valor de Y en R está asociado a cada valor X en R (en cualquier momento dado). Obviamente, si X es una clave candidata de la relación (o la clave primaria), todos los atributos deben depender funcionalmente de ella. Otra manera más clara de expresar el significado de una dependencia funcional es: Dada una relación R, el atributo Y de R depende funcionalmente del atributo X de R si y sólo si siempre que dos tuplas de R concuerden en su valor de X, deben por fuerza concordar en su valor de Y. Definimos también el concepto de dependencia funcional completa: Se dice que el atributo Y de la relación R es por completo dependiente funcionalmente del atributo X de R si depende funcionalmente de X y no depende funcionalmente de ningún subconjunto propio de X. Tema 4: Diseño de bases de datos 16
  17. 17. Para representar las dependencias funcionales utilizaremos los diagramas de dependencias funcionales. Un ejemplo de este tipo de diagramas es: DNI X# DNI DNI CANTIDAD Y# DNI La dependencia funcional es un concepto semántico. Como consecuencia, se puede decir que estas dependencias son un tipo especial de reglas de integridad. Estas dependencias representan a su vez interrelaciones de muchos a uno. 4.3.4 Primera, segunda y tercera formas normales Por simplicidad, se definen estas tres formas normales para el caso en el que las relaciones sólo tienen una clave candidata (y por tanto, solo tienen clave primaria). Para el caso en que no se cumpla esto, se recurre directamente a la FNBC, que se explica con posterioridad. Definiciones: 1. Una relación está en 1FN si y sólo si todos los dominios simples subyacentes contienen sólo valores atómicos. 2. Una relación está en 2FN si y sólo si está en 1FN y todos los atributos no clave dependen por completo de la clave primaria. 3. Una relación está en 3FN si y sólo si está en 2FN y todos los atributos no clave dependen de manera no transitiva de la clave primaria. O dicho de otro modo, una relación está en 3FN si y sólo si los atributos no clave son: • mutuamente independientes, y • dependientes por completo de la clave primaria donde no clave significa que no participa en la clave primaria, y mutuamente independientes significa que cualquiera de los atributos no depende funcionalmente de cualquier combinación de los otros. Veamos ahora un ejemplo de cómo convertir relaciones entre distintas formas normales. X# SITUACION CANTIDAD Y# CIUDAD Tema 4: Diseño de bases de datos 17
  18. 18. En esta relación, X# e Y# son la clave primaria de la relación, y cantidad, ciudad y situación son los atributos de la relación que dependen funcionalmente de la clave primaria (o de sus componentes) tal y como se indica en la figura. Esta relación está en 1FN por definición, es decir, todos los atributos de la relación tienen valores atómicos (no hay tablas dentro de tablas). El problema de esta relación es que no tiene buen comportamiento respecto a las acciones de actualización (INSERT, DELETE y UPDATE), puesto que las redundancias existentes hacen que las variaciones que se deseen para un cierto numero de tuplas dejen la relación con un contenido incongruente. Por ejemplo, para modificar la situación en una tupla, habrá que modificarla en todas las tuplas donde aparezca dicha situación, puesto que de otro modo la dependencia ciudad situación dejará de cumplirse. En general, el borrado puede eliminar información sobre ciertas dependencias, la inserción puede generar discordancias, y la modificación puede provocar el mismo efecto que una inserción incorrecta. Es obvio que esta relación no está en 2FN puesto que no todos los atributos no clave dependen por completo de la clave primaria. De hecho, Situación y Ciudad dependen de un componente de la clave primaria. Por tanto, para pasar a 2FN habrá que descomponer la relación en otras relaciones más simples (y este será el procedimiento genérico que seguiremos para pasar de unas FN a otras superiores: descomponer las tablas, o lo que es lo mismo, realizar operaciones de proyección). En este caso, la siguiente descomposición nos permite obtener relaciones en 2FN: X# X# SITUACION CANTIDAD Y# CIUDAD La segunda de las relaciones separadas contiene relaciones transitivas, y por tanto, tampoco está en 3FN. Para obtener relaciones en 3FN hay que de nuevo dividir la relación en las siguientes relaciones: X# CIUDAD CIUDAD SITUACION y con esta separación ya se obtienen, definitivamente, las relaciones en 3FN. Como detalle, hay que destacar que la última descomposición se podría haber realizado de dos formas distintas: • X# CIUDAD, CIUDAD SITUACION, o • X# CIUDAD, X# SITUACION Es evidente que en la segunda descomposición se pierde información sobre la dependencia CIUDAD SITUACION. Por tanto, ésta sería una ‘mala’ Tema 4: Diseño de bases de datos 18
  19. 19. descomposición. Habrá que obrar, por tanto, con cautela antes de decidir que tipo de descomposición se realiza en las relaciones con transitividad. 4.3.5 Forma normal de Boyce/Codd El problema de la 3FN es que no maneja relaciones que: • Tiene varias claves candidatas, • Esas claves candidatas son compuestas, y • Las claves candidatas se traslapan (o sea, tienen por lo menos un atributo en común). Por ello, se define la FNBC para el caso en el que existan más de una clave candidata, y que se cumplan dichas condiciones. Hay que introducir, por comodidad, el concepto de determinante, que se define como el atributo del cual depende funcionalmente algún otro atributo. Así pues, se define la FNBC como: Una relación está en FNBC si y sólo si todo determinante es una clave candidata. Se debe advertir que en el caso en el que no se den las condiciones anteriores, o no exista más de una clave candidata (sólo la clave primaria) la FNBC es completamente equivalente a la 3FN. Dicho de otro modo, la definición implica que los únicos determinantes son las claves candidatas, o sea, las flechas del diagrama de dependencias funcionales sólo salen de claves candidatas. Por ejemplo, la siguiente X# J# relación está en FNCB, donde se puede ver que la existencia de varias claves Y# K# candidatas no es necesaria- mente mala. Un problema serio, que no contempla la 3FN sería el siguiente diagrama DF: X# Z# Y# En este caso, la relación no está en FNBC, y sería necesario descomponerla en dos relaciones ((X#, Z#), (Z#, Y#)), aunque las relaciones resultantes no podrían ser independientes entre sí. Sin embargo, en el caso en que se diese simultáneamente cualquiera de estas dos posibles dependencias funcionales en una relación: Tema 4: Diseño de bases de datos 19
  20. 20. X# Y# Z# X# Y# Z# estaríamos ante una relación en FNBC. 4.3.6 Cuarta forma normal Existen relaciones en las que no existen dependencias entre los atributos, sin embargo la actualización de sus campos no es tarea trivial, puesto que la representación semántica de la relación así lo requiere. Por ejemplo, en una tabla en la que se haga constar los profesores que imparten ciertas asignaturas y que utilizan una serie de textos como ayuda a la enseñanza, es evidente que no habrá dependencia entre cada uno de los atributos; sin embargo, en el caso en que se desee introducir un profesor nuevo en la tabla, habrá que crear una fila nueva por cada asignatura que vaya a impartir, y a su vez una fila por cada texto que se utiliza de forma común por todos los profesores de esa asignatura. Estamos por tanto ante una situación de patrones repetitivos en los que no existen dependencias funcionales individuales, pero que obligan a un tratamiento poco óptimos en las operaciones de actualización de la relación. Para analizar este tipo de casos no podemos utilizar las dependencias funcionales que hemos estado manejando hasta ahora. Introducimos un nuevo concepto: dependencia multivaluada, que son una generalización de las dependencias funcionales. Por ejemplo, en la relación de nuestro ejemplo tenemos dos dependencias multivaluadas (ASIGNATURA ⇒ PROFESOR, y ASIGNATURA ⇒ TEXTOS), puesto que una asignatura puede estar impartida por varios profesores, y una asignatura puede utilizar varios textos como apoyo a la enseñanza. Podemos dar una definición un poco más formal de dependencia multivaluada (DMV): Dada una relación R con los atributos A, B y C, la DMV R.A ⇒ R.B se cumple en R si y sólo si el conjunto de valores de B correspondiente a un par dado (valor de A, valor de C) en R depende sólo del valor de A y es independiente del valor de C. Como siempre, A, B y C pueden ser compuestos. Es evidente que una DMV sólo puede existir en una relación que tenga por lo menos tres atributos. Se puede demostrar que en una relacion R(A,B,C), la DMV R.A⇒R.B se cumple si y sólo si se cumple también la DMV R.A⇒R.C. Por tanto, se suele emplear la notación R.A ⇒ R.B | R.C que indica esta situación. Es ahora fácil ver que el problema mencionado con anterioridad tiene que ver con la presencia de DMV en la relación que no son a la vez DF. Tema 4: Diseño de bases de datos 20
  21. 21. Para resolver el problema planteado es necesario descomponer las relaciones que presentan DMV en otras relaciones más pequeñas, aplicando el teorema siguiente: • La relación R, cuyos atributos son A, B y C, se puede descomponer sin pérdidas en sus dos proyecciones R1(A, B) y R2(A, C) si y sólo si se cumplen en R las dependencias multivaluadas A ⇒ B | C. Y ahora ya podemos definir la 4FN: Una relación R está en 4FN si y sólo si, siempre que existe una DMV en R, digamos A ⇒ B, todos los atributos de R dependen tambien funcionalmente de A En otras palabras, las únicas dependencias funcionales o multivaluadas en R son de la forma X K (o sea, una dependencia funcional con respecto a una clave candidata K de algún otro atributo X). O lo que es equivalente, R está en 4FN si está en FNBC y todas las dependencias multivaluadas de R son de hecho dependencias funcionales. 4.3.7 Quinta forma normal Hasta ahora hemos supuesto que la única manera de normalizar consistía en la sustitución (sin pérdidas) de una relación por dos de sus proyecciones, lo que nos ha llevado con éxito hasta 4FN. Sin embargo, existen relaciones imposibles de descomponer sin pérdidas en dos proyecciones, pero que sí pueden descomponerse un tres o más proyecciones sin pérdidas. Para tratar este tipo de relaciones usaremos el término ‘n-descomponibles’ (para n>2), lo que significa que la relación puede descomponerse sin pérdidas en n relaciones, pero no en m (m<n). Vamos a introducir el concepto de dependencia de reunión (DR) para indicar un cierto tipo de restricción sobre las relaciones: La relación R satisface la dependencia de reunión (DR) *(X, Y, …, Z) si y sólo si R es igual a la reunión de sus proyecciones según X, Y, …, Z, donde X, Y, …, Z son subconjuntos del conjunto de atributos de R. Esto no es siempre cierto. Veámoslo con un ejemplo: Sea la relación, XYZ(X#, Y#, Z#), y sus proyecciones XY(X#, Y#), YZ(Y#, Z#), ZX(Z#, X#). La relación XYZ contiene las tuplas siguientes: X1, Y1, Z2 X1, Y2, Z1 X2, Y1, Z1 X1, Y1, Z1 Por tanto, las proyecciones tendrán las tuplas XY YZ ZX X1,Y1 Y1,Z2 Z2,X1 X1,Y2 Y2,Z1 Z1,X1 X2,Y1 Y1,Z1 Z1,X2 Tema 4: Diseño de bases de datos 21
  22. 22. Ahora realizamos la reunión de XY e YZ según Y#, con lo que obtenemos: X1, Y1, Z2 X1, Y1, Z1 X1, Y2, Z1 X2, Y1, Z2 X2, Y1, Z1 y esta relación la reunimos con ZX según (X#, Y#), con lo que obtenemos la relación original. De alguna manera, el hecho de que la reunión de las relaciones en que hemos descompuesto la relación original nos devuelva de nuevo esta relación, significa que la existencia de las tuplas (a1,b1,c2), (a1,b2,c1) y (a2,b1,c1) obliga a la existencia de (a1,b1,c1), tal y como hemos podido comprobar, puesto que la reunión hará que aparezca indefectiblemente esta última tupla. Se puede decir que esta obligación es lo que hemos llamado dependencia de reunión. Sin embargo, si eliminamos la última tupla de la relación XYZ, es decir, no obligamos a que aparezca (a1,b1,c1) por el hecho de que aparezcan las otras tres, dicha dependencia de reunión desaparece, puesto que la reunión sí que hará aparecer esta última tupla al final, sin que aparezca en la relación original. En este ejemplo, la relación XYZ satisface la DR *(XY, YZ, ZX). El teorema de Fagin dice que: R(A, B, C) satisface la DR *(AB, AC) si y sólo si satisface la pareja de dependencias multivaluadas A ⇒ B | C. En vista de que una DR es una generalización de una DMV, y que no todas las relaciones que satisfacen una DR también satisfacen una DMV, además del hecho de que las DR pueden presentar problemas de actualización en las relaciones, hemos de definir una nueva forma normal para evitar estos problemas: Una relación está en 5FN, también llamada forma normal de proyección/reunión (PJ/NF), si y sólo si toda dependencia de reunión en R es una consecuencia de las claves candidatas de R. Tema 4: Diseño de bases de datos 22
  23. 23. 4.4 Diseño Físico El rendimiento de un SGBD es la última medida en el diseño de una base de datos. Un DBA puede mejorar el rendimiento ajustando algunos parámetros del SGBD, e identificando cuellos de botella y problemas de hardware. Sin embargo, el primer paso que hay que dar para obtener un buen rendimiento de la base de datos es hacer una buena toma de decisiones en cuanto al diseño físico de la misma. 4.4.1 Introducción al diseño físico Como cualquier otro aspecto de diseño de una base de datos, el diseño físico debe ser definido por la naturaleza de los datos y su intención de uso. En particular, es necesario conocer la carga que el sistema debe soportar; esta carga consiste en una serie de consultas y actualizaciones de datos de nuestra base de datos. Además, los usuarios suelen tener ciertos requisitos sobre la rapidez que deben tener los procesos de consulta y actualización. La descripción de la carga y los requisitos de los usuarios sobre el rendimiento de las consultas son la base para la toma de decisiones de un buen diseño físico. La descripción de la carga del sistema incluye los siguientes elementos: • Una lista de consultas y sus frecuencias, como una fracción de todas las consultas y actualizaciones. • Una lista de actualizaciones y sus frecuencias. • Objetivos de rendimiento para cada tipo de consulta y actualización. Para cada consulta, debemos identificar: • Las relaciones a las que accede. • Los atributos de la cláusula SELECT. • Los atributos en las condiciones (WHERE), y el grado de selectividad que pueden aportar (mucha restricción, poca, etc.). De igual forma, para cada actualización debemos tomar la siguiente información: • Los atributos en las condiciones (WHERE) y el grado de selectividad que pueden aportar. • El tipo de actualización (insert, delete, update). • En caso de UPDATE, los campos que se modifican. Conviene tener en cuenta que las actualizaciones utilizan un parámetro para seleccionar las tuplas que se deben actualizar. El uso de índices para estos campos puede resultar interesante. Sin embargo, las actualizaciones conllevan una sobrecarga de actualización Tema 4: Diseño de bases de datos 23
  24. 24. de índices, con lo que actualizar campos sobre los que hay definidos índices puede hacer más lento el proceso de actualización. Las decisiones que hay que tomar durante el diseño físico de una base de datos son las siguientes: • Qué índices crear o Qué relaciones y campos de las relaciones se indexarán o Tipo de índice a utilizar • Cuándo realizar cambios en el esquema conceptual para mejorar el rendimiento: o Normalización alternativa de esquemas, cuando se pueda llegar, por ejemplo, a una descomposición FNBC o 3FN por caminos distintos. o Desnormalización o Particionado o Vistas 4.4.2 Criterios para la selección de índices A continuación se proporcionan una serie de criterios que ayudarán a decidir que índices se deben crear y cómo se deben crear. 4.4.2.1 Cuando indexar No hay que construir un índice a menos que alguna consulta se vaya a beneficiar de dicho índice. Cuando sea posible, seleccionar un índice que pueda mejorar la velocidad de más de una consulta. 4.4.2.2 Elección de la clave de búsqueda Los atributos que aparecen en la cláusula WHERE son los candidatos a recibir índices • Los atributos que se usan con criterio de búsqueda exacta pueden ser indexados con índices de tipo hash. • Los atributos que se usan con criterio de búsqueda en un rango pueden ser indexados utilizando Arboles B. 4.4.2.3 Clave de búsqueda de múltiples atributos Se deben considerar índices compuestos (de más de un atributo) cuando la cláusula WHERE incluye condiciones sobre más de un atributo de una relación. Cuando se creen índices de este tipo, si existen condiciones de búsqueda en rangos, hay que tener cuidado con el orden de los atributos definido en el índice. 4.4.2.4 Contemplar el coste del mantenimiento de índices Después de obtener un listado de los índices que sería conveniente crear, hay que considerar el impacto que provocarán en las sentencias de actualización: Tema 4: Diseño de bases de datos 24
  25. 25. • Si el mantenimiento del índice ralentiza operaciones de actualización muy frecuentes, habrá que considerar la eliminación del índice. • Considerar que un índice puede acelerar el proceso de actualización, cuando el índice se define sobre los campos que se utilizan como criterio de selección de aquellas tuplas que se van a actualizar. En resumen, el diseño físico de la base de datos contempla, básicamente, la creación adecuada de índices sobre las estructuras que definen la base de datos. Hemos proporcionado unos criterios de decisión sobre la creación de índices, y una metodología a seguir para obtener un conjunto de índices deseable para el sistema. Pero al mismo tiempo, hay que tener en cuenta que la creación de índices no siempre va a ser beneficiosa para mejorar el rendimiento de nuestro sistema, y es por ello que seguir las directrices de criterios de selección de índices de la forma más ajustada posible nos aportará mayores beneficios y nos evitará errores en la parte del diseño físico. Tema 4: Diseño de bases de datos 25

×