Modelo relacional

Modelo relacional 3.1 Introducción En el capítulo anterior se mencionaron 3 tipos de modelado: conceptual, lógico y físico. El modelo e-r se considera un modelo conceptual ya que permite a un nivel alto el ver con claridad la información utilizada en algun problema o negocio. En este capítulo nos concentraremos en desarrollar un buen modelo "lógico" que se conoce como "esquema de la base de datos" (database schema) a partir del cual se podrá realizar el modelado físico en el DBMS, es importante mencionar que es un paso necesario, no se puede partir de un modelo conceptual para realizar un físico. 3.2 Por qué "modelo relacional" ? Puede resultar confuso el concepto de modelo entidad-relación vs modelo relacional, quizás porque ambos comparten casi las mismas palabras. Como se mencionó en la sección anterior, el objetivo del modelo relacional es crear un "esquema" (schema), lo cual como se mencionará posteriormente consiste de un conjunto de "tablas" que representan "relaciones", relaciones entre los datos. Estas tablas, pueden ser construídas de diversas maneras: Creando un conjunto de tablas iniciales y aplicar operaciones de normalización hasta conseguir el esquema más óptimo. Las técnicas de nomalización se explican más adelante en este capítulo. Convertir el diagrama e-r a tablas y posteriormente aplicar también operaciones de normalización hasta conseguir el esquema óptimo. La primer técnica fue de las primeras en existir y, como es de suponerse, la segunda al ser más reciente es mucho más conveniente en varios aspectos: El partir de un diagrama visual es muy útil para apreciar los detalles, de ahí que se llame modelo conceptual. El crear las tablas iniciales es mucho más simple a través de las reglas de conversión. Se podría pensar que es lo mismo porque finalmente hay que "normalizar" las tablas de todas formas, pero la ventaja de partir del modelo e-r es que la "normalización" es mínima por lo general. Lo anterior tiene otra ventaja, aún cuando se normalice de manera deficiente, se garantiza un esquema aceptable, en la primer técnica no es así. 3.3 Conceptos básicos 3.3.1 Tablas El modelo relacional proporciona un manera simple de representar los datos: una tabla bidimensional llamada relación. título año duración tipo Star Wars 1977 124 color Mighty Ducks 1991 104 color Wayne's World 1992 95 color Relación Películas La relación Películas tiene la intención de manejar la información de las instancias en la entidad Películas, cada renglón corresponde a una entidad película y cada columna corresponde a uno de los atributos de la entidad. Sin embargo las relaciones pueden representar más que entidades, como se explicará más adelante. 3.3.2 Atributos Los atributos son las columnas de un relación y describen características particulares de ella. 3.3.3 Esquemas Es el nombre que se le da a una relación y el conjunto de atributos en ella. Películas (título, año, duración, tipo) En un modelo relación, un diseño consiste de uno o más esquemas, a este conjunto se le conoce como "esquema relacional de base de datos" (relational database schema) o simplemente "esquema de base de datos" (database schema) 3.3.4 Tuplas Cada uno de los renglones en una relación conteniendo valores para cada uno de los atributos. (Star Wars, 1977, 124, color) 3.3.5 Dominios Se debe considerar que cada atributo (columna) debe ser atómico, es decir, que no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de datos. 3.3.6 Representaciones equivalentes de una relación Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es irrelevante. Así mismo el orden de los atributos tampoco es relevante año título tipo duración 1991 Mighty Ducks color 104 1992 Wayne's World color 95 1977 Star Wars color 124 Otra representación de la relación Películas 3.4 Conversión del modelo e-r a un esquema de base de datos (Conversión a tablas) 3.4.1 Introducción El modelo es una representación visual que gráficamente nos da una perspectiva de como se encuentran los datos involucrados en un proyecto u organización. Pero el modelo no nos presenta propiamente una instancia de los datos, un ejemplo que muestre con claridad algunas datos de muestra y como se relacionan en realidad. Por eso es conveniente crear un "esquema", el cual consiste de tablas las cuales en sus renglones (tuplas) contienen instancias de los datos. 3.4.2 Conversión a tablas desde un modelo con relaciones (1-1,1-m,m-m) Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema. modelo e-r conversión a tablas una tabla por cada conjunto de entidades nombre de tabla = nombre de conjunto de entidades una tabla por cada conjunto de relaciones m-m nombre de tabla = nombre de conjunto de relaciones definición de columnas para cada tabla conjuntos fuertes de entidades columnas = nombre de atributos conjuntos débiles de entidades columnas = llave_primaria (dominante) U atributos(subordinado) conjunto de relaciones R (m-m) entre A, B columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R) conjunto de relaciones R (1-1) entre A y B columnas (A) = atribs(A) U llave primaria(B) U atributos(R) conjunto de relaciones R (1-m) entre A y B columnas (B) = atribs(B) U llave primaria(A) U atributos(R) Ejemplo: Para el ejemplo de la figura tendríamos el esquema: escuela id url nombre departamento clave url nombre id_escuela curso clave seccion nombre clave_depto profesor id nombre extension estudiante id nombre carrera profesor_curso id_prof clave_curso seccion_curso estudiante_curso id_estud clave_curso seccion_curso 3.4.3 Conversión a tablas desde un modelo con generalización modelo e-r de generalización a tablas dos posibilidades: crear una tabla para el conjunto de entidades A de mayor nivel columnas (A) = atributos(A) para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columns (B) = atributos (B) U llave_primaria (A) si A es un conjunto de entidades de mayor nivel para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columnas (B) = atributos (B) U atributos (A) Es importante mencionar que a pesar de que existen 2 métodos para convertir una generalización a tablas, no hay una regla exacta de cual usar en determinado caso. A continuación se mencionan algunos consejos útiles para la determinación de cual método emplear: Si la entidad de nivel superior está relacionada con otra(s) entidades puede sugerirse emplear el método (1) ya que de esa manera la tabla (A) será la única involucrada en la relación, de otra forma se tendrían tres tablas (B1,B2 y B3) formando parte de la relación Es importante tomar en cuenta la pertenencia de instancias, si se considera que hablamos de una generalización disjunta, donde no se puede pertenecer a varias entidades de nivel inferior, quizás sea recomendable el método (1), en otro caso se podría pensar en el método (2). También es importante analizar ambos casos con respecto a las "consultas" que se deseen realizar ya que esto también determina en muchos casos el método a emplear. 3.4.4 Descubrimiento de llaves en las relaciones Las llaves resultantes en las relaciones de un esquema se pueden inferir de la siguiente manera: 1) Cada tabla que provenga de una entidad contiene por si misma una llave 2) Para las tablas resultado de una relación se toman las llaves primarias de ambas entidades y éstas conforman la nueva llave primaria, excepto en un caso como el que sigue: Podemos observar que existe una relación m-m entre "actor" y "serie", demostrando que un actor puede actuar en muchas series y que muchas series tendrán a los mismos actores. La tabla que se crearía sería: actor_serie id_actor id_serie id_personaje Joaquín Pardavé Génesis Abel hermano bueno Evita Muñoz (Chachita) Qué bonita familia Dulce abuelita Joaquín Pardavé Génesis Caín hermano malo Evita Muñoz (Chachita) Hermelinda linda Bruja Hermelinda si se considera "id_actor, id_serie" como la llave primaria caemos en un problema porque esa combinación no identifica de manera única a la tupla, como es el caso de "Joaquín Pardavé, Génesis" ya que en la primer tupla tenemos que determina a "Abel hermano bueno" y en la tercera a "Caín hermano malo". La relación es correcta ya que un actor puede representar a varios personajes en la misma obra, pero entonces la llave "id_actor, id_serie" no es la correcta y en este caso lo más recomendable sería emplear los tres atributos de la relación "id_actor, id_serie, id_personaje" 3.5 Normalización Una vez creadas las tablas hay que verificarlas y revisar si aún se puede reducir u optimizar de alguna manera. Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relación son llamados anomalías. Los principales tipos son: Redundancia: la información se repite innecesariamente en muchas tuplas. En la relación siguiente, length y filmType. Anomalías de actualización: cuando al cambiar la información en una tupla se descuida el actualizarla en otra. Si en la relación encontramos que el length de StarWars es 125 podríamos cambiarlo únicamente para la primer tupla y olvidar actualizar las demás. Anomalías de eliminación: si un conjunto de valores llegan a estar vacíos y se llega a perder información relacionada como un efecto de la eliminación. Si eliminamos al actor Emilio Estevez, perdemos también la tupla de la película MightyDucks.