Módulo II Modelo Relacional
Anuncio
Base de Datos – 311 Módulo II Modelo Relacional El modelo relacional es actualmente el principal modelo para la aplicación del procesamiento de datos, debido a su simplicidad, en comparación a los otros dos modelos estudiados anteriormente: el jerárquico y el de redes. En este módulo se estudian tres tipos de lenguaje formales de consulta para el modelo relacional, el primero es el álgebra relacional, el cual forma la base del lenguaje de consulta SQL1 y los otros dos lenguajes son : el cálculo relacional de tuplas y el cálculo relacional de dominio, que son lenguajes declarativos de consultas basados en la lógica matemática. Otra aspecto que se ilustra en este módulo es la técnica de normalización, que según lo propuesto por Codd (1972) en este proceso el esquema de relación se somete a una serie de pruebas para certificar si pertenece o no a una cierta forma normal, es decir, los atributos se van agrupando en relaciones según su afinidad, con la finalidad de poseer ciertas características deseables. Por último se expone lo referente a la Seguridad e Integridad de los datos, con el propósito de garantizar la coherencia de los datos, comprobando que sólo los usuarios autorizados puedan efectuar las operaciones correctas sobre la base de datos. Objetivo del Modulo II: Resolver problemas de manera analítica y lógica, de Álgebra Relacional y/o Calculo Relacional, de Normalización y de seguridad y/o integridad en sistemas de bases de datos . El módulo II está constituido por tres unidades, especificadas de la siguiente manera: Unidad 4: Álgebra Relacional y Cálculo Relacional Unidad 5: Normalización en bases de datos relacional Unidad 6: Seguridad e Integridad UNIDAD 4: Álgebra Relacional y Cálculo Relacional El objetivo de esta unidad consiste en adquirir los conocimientos necesarios relacionados a la manipulación del modelo relacional, es decir, lo que se denomina Álgebra Relacional y Cálculo Relacional, comenzando por explicar las operaciones básicas del modelo relacional: Seleccionar, Proyectar y Renombrar, seguidamente las operaciones de la teoría matemática de conjuntos: Unión, intersección, la diferencia y el producto cartesiano, además se definirán algunas operaciones adicionales de álgebra relacional. Por otra parte se presentan los conceptos básicos del cálculo relacional, analizando la sintaxis de las consultas, empleando variables de tuplas y de dominio. 1 SQL (Structured Query Languaje, Lenguaje estructurado de consulta). SQL se a establecido como el lenguaje estándar de bases de datos relacionales. Base de Datos – 311 Objetivo de la Unidad 4: Aplicar operaciones de Álgebra Relacional o Cálculo Relacional sobre la base de una situación dada. Contenido de la Unidad 4: Se contempla el estudio de los siguientes puntos: Introducción. Semántica. Operaciones básicas del álgebra relacional. Operaciones relacionales adicionales. Ejemplos de consultas en álgebra relacional Cálculo Relacional orientado a tuplas Cálculo relacional orientado a dominio Recomendaciones para el estudio del contenido de la unidad 4 1.- En esta sección se presentará inicialmente un lenguaje procedimental (el álgebra relacional) y luego un leguaje no procedimental (el cálculo relacional). Es por ello que a continuación se muestra la tabla 4.1 que lo situará en el contenido de este tema, bien sea en la lectura y en el capítulo 7 del libro-texto de la asignatura. Base de Datos – 311 Tabla 4.1 TEMA Álgebra Relacional Cálculo Relacional 2.- MATERIAL DE REFERENCIA CÁPI- SECTULO CIÓN TÍTULO PÁGINAS Introducción del álgebra relacional Lectura Nº 4.1 y Libro-texto: “Fundamentos de Sistemas de Bases de Datos” 7 7.4. Operaciones básicas de álgebra relacional 200-213 7.5. Operaciones relacionales adicionales 213-218 7.6. Ejemplos de consultas en álgebra relacional 218-220 9.3. El cálculo relacional orientado a tuplas 282-291 9.4. El cálculo relacional orientado a dominios 291-293 Proceda con el estudio del contenido de la lectura 4.1 y del capítulo 7, una vez comprendido los conceptos relacionados con el álgebra relacional y el cálculo relacional, usted estará en capacidad de responder las siguientes preguntas: 9 ¿Cómo define el álgebra relacional? 9 ¿Cómo define el cálculo relacional? 9 ¿En qué sentido difiere el cálculo relacional del álgebra relacional y en que sentido es similar? 3.- Si usted respondió las preguntas anteriores, continúe con este punto donde se le presenta un cuestionario que le servirá de ayuda para ejercitarse en el conocimiento de algunos conceptos que aplicará posteriormente en la resolución de problemas del álgebra o cálculo relacional sobre la base de una situación dada. 9 ¿Cuáles son las operaciones del álgebra relacional y el propósito de cada una de ellas? 9 ¿Por qué se dice que el álgebra relacional es un lenguaje procedimental? 9 ¿Por qué se dice que el cálculo relacional es un lenguaje no procedimental? 9 ¿Qué diferencia hay entre el cálculo relacional de tuplas y el cálculo relacional de dominios? Base de Datos – 311 9 ¿Cómo define los siguientes términos con respecto al cálculo de tuplas: La variable de tupla, la relación de rango, átomo, fórmula, expresión? 9 ¿Cómo define los siguientes términos con respecto al cálculo de dominio: Variable de dominio, relación de rango, átomo, fórmula, expresión? 9 ¿Cómo expresaría lo que quiere decir con expresión segura en el cálculo relacional? 3.- Se sugiere elaborar un mapa conceptual que lo ayudará a organizar los puntos estudiados y obtener así una mejor comprensión de ellos, además se recomienda estudiar los ejemplos y realizar los ejercicios de autoevaluación, a objeto de resolver los ejercicios o actividades propuestas que se presentan en este material instruccional. 4.- Una vez aclarado el contenido de este tema, estudie el siguiente ejemplo, donde se ejecutan operaciones de la teoría de conjuntos del algebra relacional. Ejemplo 4.1 Suponga que se tienen las dos relaciones que representan todos los vendedores que están subordinados a otros vendedores (VENDEDORSUBORDINADO) y todos los vendedores que son jefes de otros vendedores (VENDEDOR-JEFE). Obviamente existe redundancia de datos, como se muestra a continuación: VENDEDOR-SUBORDINADO CÓDIGOVENDEDOR NOMBVENDEDOR CÓDIGO-JEFE OFICINA COMISIÓN % 10 14 23 37 39 44 35 12 Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Búster Sánchez 27 44 35 12 44 27 27 27 Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos Aires 10 11 9 13 10 12 11 10 VENDEDOR-JEFE CÓDIGOVENDEDOR NOMBVENDEDOR CÓDIGO-JEFE OFICINA COMISIÓN % 17 44 35 12 Terry Cardon Albert Ige Brigit Bovary Búster Sánchez 12 27 27 27 Chicago Tokyo Brussels Buenos Aires 15 12 11 10 Base de Datos – 311 Si se desea obtener una relación que contenga todos los vendedores , se debe realizar la operación UNION. El resultado de esta operación, es una relación que incluye todas las tuplas que están en VENDEDORSUBORDINADO o en VENDEDOR-JEFE o en ambas, es decir: VENDEDOR ← VENDEDOR-SUBORDINADO ∪ VENDEDOR-JEFE VENDEDOR CÓDIGOVENDEDOR NOMBVENDEDOR CÓDIGO-JEFE OFICINA COMISIÓN % 10 14 23 37 39 17 44 35 12 Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Terry Cardon Albert Ige Brigit Bovary Búster Sánchez 27 44 35 12 44 12 27 27 27 Chicago Tokyo Brussels Buenos Aires Tokyo Chicago Tokyo Brussels Buenos Aires 10 11 9 13 10 15 12 11 10 En la relación resultante se observa que existen tres tuplas del atributo CÓDIGO-VENDEDOR las cuales son: 44, 35, 12 que se encuentran en ambas relaciones anteriores, pero cada una de estas tuplas aparecerá sólo una vez en la relación resultante VENDEDOR. 5.- Examine el siguiente ejemplo, en el cual se presenta la aplicación de la operación Proyectar Ejemplo 4.2 Si queremos hacer una lista con la cédula, apellido, nombre y la especialidad de todos los médicos de una clínica, podemos usar la siguiente operación PROYECTAR: π (MÉDICO) CÉDULA, APELLIDO, NOMBRE, ESPECIALIDAD y la relación resultante quedará de la siguiente manera: Cédula 8.678.908 7.845.908 7.456.789 6.345.890 2.456.789 Apellido Smith Nombre Jhon Wong Zelaya Narayan Jabbar Franklin Alicia Jennifer James Especialidad Oftalmólogo Cirujano Cardiólogo Ginecólogo Internista Base de Datos – 311 6.- Lea los ejemplos que se presentan en la sección 9.3 y 9.4 con respectos al cálculo relacional orientado a tuplas y a dominio. 7.- A continuación se le proporciona algunos aspectos que debe resaltar después que ha adquirido los conocimientos relacionados a este tema: Recordatorio • • • 8.- El álgebra relacional consta de un conjunto de operaciones para manipular relaciones tomando como entrada una o dos de ellas y produce como resultado una nueva relación. El cálculo relacional de dominio utiliza variables que toman sus valores del dominio de un atributo, en vez de tomarlos de una tupla completa, sin embargo ambos cálculos; dominio y tuplas se hayan estrechamente relacionados. El cálculo relacional usa un enfoque completamente diferente al álgebra relacional. No obstante, los dos lenguajes son lógicamente equivalentes. Esto significa que cualquier consulta que pueda resolverse en un lenguaje puede resolverse en el otro. Será más breve en el cálculo relacional, debido a que el lenguaje en si mismo tiene menos construcciones. Para obtener más información sobre los temas de álgebra y cálculo relacional, puede hacer búsqueda en Internet, a través de las siguiente dirección electrónica: Consulta en la web http://www.programacion.com/bbdd/tutorial/modrel/4/: Contiene las operaciones relacionados a las operaciones del álgebra relacional. http://www.programacion.com/bbdd/tutorial/modrel/5/: Contiene información referente al calculo relacional 9.- Si desea profundizar en los aspectos involucrados en esta unidad 4, se sugiere que consulte los siguientes textos que se encuentran en la biblioteca de la UNA: Consulta de libros Base de Datos – 311 • • Introducción a los Sistemas de bases de datos (1998), Quinta edición, C. J. Date. Fundamentos y modelos de Base de datos (1999), Adoración de Miguel y Mario Piattini. 10.- Proceda a realizar el Ejercicio de Autoevaluación presentado a continuación y así podrá evidenciar que ha entendido el material estudiado, luego compruebe sus respuestas con la dada en la “Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir, estudie nuevamente el tópico en el cual desacertó. Ejercicio de Autoevaluación Una empresa internacional que vende productos alimenticios tiene un sistema de base de datos llamada VENTAS, cuyo fin es controlar las ventas realizadas por cada vendedor y saber en que lugar se encuentran localizados. A continuación se presenta un esquema de esta base de datos: VENDEDOR CÓDIGOVENDEDOR 10 14 23 37 39 44 35 12 NOMBVENDEDOR Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Búster Sánchez CÓDIGO-JEFE OFICINA COMISIÓN % 27 44 35 12 44 27 27 27 Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos aires 10 11 9 13 10 12 11 10 Se quiere que aplique operaciones en álgebra relacional y realice los siguientes procedimientos: a) Seleccionar las tuplas de VENDEDOR que trabajan en la oficina de Tokio. b) Seleccionar las tuplas de VENDEDOR que tiene una comisión menor que 14 c) Seleccionar las tuplas de todos los vendedores que trabajan en la oficina Buenos Aires y que tienen un jefe con CÓDIGO mayor a 20. d) Preparar una lista con el nombre, oficina y comisión de todos los empleados. Base de Datos – 311 11.- Proceda a realizar el ejercicio propuesto que se da a continuación: Ejercicio o Actividad Propuesta Una empresa transportista encargada de enviar encomiendas a diferentes regiones de Venezuela requiere implantar un sistema de base de datos con la finalidad de registrar los envíos de paquetes que se han realizado a un determinado cliente. Usando el siguiente esquema relacional: CLIENTE (CODIGO-CLIENTE, NOV-CLIENTE, SALDO) EMBARQUE (NUM-EMBARQUE, CODIGO-CLIENTE, PESO, NUMCAMIÓN, DESTINO) Se quiere aplicar operaciones de álgebra relacional. Responda las siguientes consultas: a) ¿Cuál es el nombre del cliente 433? b) ¿Cuál es la ciudad destino del transporte Nº 3244? c) ¿Qué camión ha transportado paquetes con un peso mayor a 100 toneladas? d) ¿Cuáles son los nombres de los clientes que han enviado paquetes a la ciudad de BARQUISIMETO? e) ¿A qué destinos han enviado paquetes los clientes con un saldo igual Bs. 5.000.000,00? Una vez desarrollado el Ejercicio de Autoeveluación, podrá comparar su repuesta con la dada a continuación: Respuesta al Ejercicio de Autoevaluación a) σ OFICINA = TOKIO CÓDIGOVENDEDOR 14 39 44 (VENDEDOR) NOMBVENDEDOR Masaji Matsu Goro Azuma Albert Ige CÓDIGO-JEFE OFICINA COMISIÓN % 44 44 27 Tokyo Tokyo Tokyo 11 10 12 Base de Datos – 311 b) σ COMISIÓN% < 14 CÓDIGOVENDEDOR 10 23 39 12 C) d) (VENDEDOR) NOMBVENDEDOR Rodney Jones Francois Moire Goro Azuma Búster Sánchez CÓDIGO-JEFE OFICINA COMISIÓN % 27 35 44 27 Chicago Brussels Tokyo Buenos Aires 10 9 10 10 σ OFICINA = Buenos Aire y ID-JEFE > 20 (VENDEDOR) CÓDIGOVENDEDOR NOMBVENDEDOR CÓDIGO-JEFE OFICINA COMISIÓN % 12 Búster Sánchez 27 Buenos Aires 10 π NOM-VENEDEDOR, OFICINA, COMISIÓN % NOMBVENDEDOR Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Búster Sánchez (VENDEDOR) OFICINA COMISIÓN % Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos Aires 10 11 9 13 10 12 11 10 Base de Datos – 311 UNIDAD 5: Normalización en base de datos relacionales El objetivo del diseño de una base de datos relacional es la concepción de un conjunto de esquemas relacionales que permita almacenar la información sin redundancia innecesaria, por lo tanto con la propuesta original de Boyce-Codd (1972), un esquema de relación se somete a una serie de pruebas para "certificar” si pertenece o no a una cierta forma normal y así alcanzar las propiedades deseables de 1) minimizar la redundancia 2) minimizar las anomalías de inserción, eliminación y actualización en una base de datos2. En un principio, Boyce-Codd propuso tres formas normales, a las cuales llamó primera, segunda y tercera formas normales (1FN, 2FN, 3FN). Posteriormente, planteó una definición más estricta de 3FN, a la que se conoce como forma normal de Boyce-Codd (FNBC). Todas estas formas normales se basan en las dependencias funcionales entre los atributos de una relación. Más adelante se propusieron una cuarta forma normal (4FN) y una quinta (5FN), con fundamento en los conceptos de dependencias multivaluadas y dependencias de reunión, respectivamente. En esta unidad se presenta lo referente a la dependencia funcional y luego se expone la primera, segunda y tercera forma normal. Por último se enfoca lo relacionado a una cuarta y una quinta forma normal (4FN y 5FN). Objetivo de la Unidad 5: Aplicar las técnica de Normalización en el diseño de una base de datos relacional Contenido de la Unidad 5: El contenido contempla el estudio de los siguientes puntos: Dependencias funcionales. Formas normales basadas en claves primarias. Definiciones generales de la segunda y tercera forma normal Forma normal de Boyce Codd. Algoritmos para el diseño de esquemas de base de datos relacionales Dependencia multivaluadas y cuarta forma normal Dependencia de reunión y quinta forma normal Dependencia de inclusión Otras dependencias y formas normales Recomendaciones para el estudio del contenido de la unidad 5 2 Este punto de anomalías de actualización se pueden estudiar en el capítulo 14 sección 14.1.2. del libro texto UNA: Fundamento de sistemas de Bases de datos. Base de Datos – 311 1.- Esta sección comienza con un análisis de algunos criterios para distinguir si los esquemas de relación poseen ciertas características deseables, de manera que ayude a los usuarios a comprender con claridad el significado de los datos en el diseño de la base de datos. Luego se definen y se analizan las propiedades de la dependencia funcional, que es la primera herramienta para medir formalmente la idoneidad de las agrupaciones de atributos en los esquemas de relaciones. Seguidamente se expondrá el uso de las dependencias funcionales para agrupar atributos en esquema de relación para que estén en una forma normal, conduciendo de esta manera a estudiar el proceso de normalización, presentando para este proceso las tres primeras formas normales y la forma normal de BoyceCodd. Posteriormente se explican varios algoritmos de normalización basados sólo en dependencias funcionales, de igual manera, se estudiarán las dependencias multivaluadas empleadas para definir la cuarta forma normal y las dependencias de reunión que dan lugar a la definición de la quinta forma normal. 2.- La siguiente tabla lo guiará en la lectura que debe realizar para la comprensión del tema tratados en esta unidad, donde hace referencia a los capítulos, secciones, títulos y páginas correspondiente al libro-texto de la asignatura. Base de Datos – 311 TEMA MATERIAL DE REFERENCIA Libro-Texto: “Fundamentos de Normalización en base de Sistemas de Bases de Datos” datos relacional CÁPITULO SECCIÓN 14 14.2. Dependencias funcionales 14.3. Formas normales basadas en claves primarias 14.4. TÍTULO PÁGINAS 449-455 Definiciones generales de la segunda y tercera formas normales 455-464 462-465 14.5. Forma normal de Boyce_Codd 465-467 15.1. Algoritmos para el diseño de esquemas de bases de datos relacionales 474-484 15.2. Dependencias multivaluadas y cuarta forma normal 485-489 15.3. Dependencia de reunión y quinta forma normal 490-491 15.4. Dependencia inclusión de 491-492 Otras dependencias y formas normales 492-493 15 15.5. 3.- Con el objeto de tener una visión conceptual de lo que significa Normalización y poder definirlo con sus propias palabras, estudie la sección 14.3.1 donde se expone una introducción a la normalización. 4.- Es importante entender la incidencia de los procesos de normalización en las bases de datos relacional, para ello responda las siguientes preguntas: 9 ¿Por qué la teoría de normalización es un método que se aplica en el diseño de una base de datos relacional? 9 ¿Cuál es el objetivo y las ventajas de usar el proceso de normalización en una base de datos relacional? 9 ¿En que consiste el proceso de normalización? Base de Datos – 311 Confronte sus respuestas con sus compañeros de estudio y en caso de dudas consulte al asesor de su Centro local. 5.- Estudie los capítulos Nº 14 y 15 del libro-texto de la asignatura y luego lo invitamos a responder las preguntas que se le presentan a continuación: 9 De las preguntas de repaso, que se encuentran al final de los capítulos Nº 14 y 15 del libro-texto de la asignatura, responda las siguientes: 14.6 al 14.16 del capítulo 14 15.8 a la 15.14 del capítulo 15 9 Explique qué establece la regla de la primera, segunda, tercera y cuarta forma normal? 9 ¿Explique con un ejemplo sencillo como se lleva una relación a la primera, segunda tercera y cuarta forma normal? 6.- De los ejercicios que se encuentran al final de los capítulos Nº 14 y 15, resuelva los siguientes: 14.17 y 14.31 al 14.33 del capítulo 14 15.15, 15.17 al 15.21 del capítulo 15 7.- Se recomienda usar un mapa conceptual como estrategia de aprendizaje, para una mejor comprensión y asimilación de los conceptos, a fin de aplicarlos en la resolución de los procesos de normalización. 8.- Para avanzar un poco más a continuación le presentamos algunos puntos que le servirán de ayuda para ampliar lo estudiado hasta hora. La teoría de la Normalización • La teoría de normalización consiste en realizar un conjunto de restricciones para evitar: La redundancia de los datos: repetición de datos en un sistema. La anomalías de actualización 3, las cuales son: o Anomalías de inserción: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos. o Anomalías de eliminación: pérdidas no intencionadas de datos debido a que se han borrado otros datos. 3 Un ejemplo de cada anomalía de actualización se presenta en el capítulo 14 del libro-texto: Fundamento de sistemas de Bases de datos. Base de Datos – 311 o Anomalías de modificación: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales. • La teoría de normalización tiene como fundamento el concepto de formas normales y estas son definidas como las técnicas empleadas para prevenir las anomalías en las relaciones (tablas). Dependiendo de su estructura, una relación (tabla) puede estar en primera forma normal, segunda forma normal o en cualquier otra, pero siempre cumpliendo ciertas condiciones preestablecidas. Por ejemplo decimos que una relación está en segunda forma normal (2FN) si y solo si está en primera forma normal (1FN) y estará en tercera forma normal si y solo si está en 2FN. Relación entre las formas normales: 9.- A continuación se presentan algunos ejemplos para ilustrar las formas normales, cuando se aplica operaciones de Normalización: Ejemplo 5.1 Primera forma normal (1FN): Se dice que una relación se encuentra en primera forma normal (1FN) si y solo si cada uno de los dominios de un atributo contiene solo valores atómicos es decir, los elementos del dominio solo son unidades simples e indivisibles. Por ejemplo consideremos el siguiente esquema de relación CURSO: CÓDIGO-PARTICIPANTE NOMBRE-PARTICIPANTE NOMBRE-CURSO 1 Marcos Inglés 2 Lucas Contabilidad, Informática 3 Marta Inglés, Contabilidad Se puede observar que el registro código 1 si cumple la primera forma normal, cada atributo del registro contiene un único dato, pero no ocurre así con la tupla Base de Datos – 311 2 y 3 ya que el atributo NOMBRE-CURSO contiene más de un dato cada uno. La solución en este caso es crear dos tablas del siguiente modo: Tabla A CÓDIGO-PARTICIPANTE NOMBRE-PARTICIPANTE 1 Marcos 2 Lucas 3 Marta Tabla B CÓDIGO-PARTICIPANTE NOMBRE-CURSO 1 Inglés 2 Contabilidad 2 Informática 3 Inglés 3 Informática Como se puede comprobar ahora todos los registros de ambas tablas contienen valores únicos en sus atributos, por lo tanto ambas tablas cumplen la Primera Forma Normal (1FN). Una vez normalizada la tabla en 1FN, podemos pasar a la segunda forma normal. Ejemplo 5.2 Segunda forma normal (2FN) Una relación R se encuentra en Segunda Forma Normal, cuando cumple con las reglas de la primera forma normal y todos sus atributos que no son claves dependen por completo de la clave definida. Antes de proceder a realizar el proceso de normalización a una relación (tabla) lo primero que se debe definir es la clave, esta clave deberá contener un valor único para cada registro (no podrán existir dos valores iguales en toda la tabla) y podrá estar formado por un único atributo o por un grupo de atributos. Si todos los atributos de la entidad dependen directamente de la clave se dice que la relación está en 2FN. Supongamos que construimos una tabla con los años que cada empleado ha estado trabajando en cada departamento de una empresa: Base de Datos – 311 CÓDIGO-EMPLEADO CÓDIGO-DPTO. NOMBRE DEPARTAMENTO AÑOS 1 6 Juan Contabilidad 6 2 3 Pedro Sistemas 3 3 2 Sonia Venta 1 4 3 Verónica Sistemas 10 2 6 Pedro Contabilidad 5 Tomando como punto de partida que la clave de esta tabla está formada por los atributos CÓDIGO-EMPLEADO y CÓDIGO-DPTO y podemos observar que la tabla se encuentra en primera forma normal, por tanto vamos a estudiar la 2FN: El atributo NOMBRE no depende funcionalmente de toda la clave, sólo depende del CÓDIGO-EMPLEADO. El atributo DEPARTAMENTO no depende funcionalmente de toda la clave, sólo del CÓDIGO-DPTO. El atributo AÑOS (representa el número de años que cada empleado ha trabajado en cada departamento) depende funcionalmente de la clave CÓDIGO-EMPLEADO y del CÓDIGO-DPTO Por tanto, al no depender de la clave todos los atributos, la tabla no está en segunda forma normal, la solución es la siguiente: Tabla B Tabla A CÓDIGO-DPTO DEPARTAMENTO CÓDIGO-EMPLEADO NOMBRE 1 Juan 2 Pedro 3 Sonia 4 Verónica 2 Ventas 3 Sistemas 6 Contabilidad Tabla C CÓDIGO-EMPLEADO CÓDIGO-DPTO AÑOS 1 6 6 2 3 3 3 2 1 4 3 10 2 6 5 Base de Datos – 311 Podemos observar que ahora si se encuentran las tres tabla en segunda forma normal, considerando que la tabla A tiene como clave el campo CÓDIGOEMPLEADO, la tabla B CÓDIGO-DPTO y la tabla C una clave compuesta por los atributos CÓDIGO-EMPLEADO y CÓDIGO-DPTO. Ejemplo 5.3 Tercera Forma Normal (3FN) Se dice que una tabla está en tercera forma normal si y solo si está en 2FN y los atributos de la tabla dependen únicamente de la clave, dicho en otras palabras los atributos de las tablas no dependen unos de otros. Tomando como referencia el primer ejemplo, supongamos que cada alumno sólo puede realizar un único curso a la vez y que deseamos guardar en que aula se imparte el curso, se puede plantear la siguiente estructura: CÓDIGO-ESTUDIANTE NOMBRE-ESTUDIANTE NOMBRE-CURSO AULA 1 Marcos Informática Aula A 2 Lucas Inglés Aula B 3 Marta Contabilidad Aula C Estudiemos la dependencia de cada campo con respecto a la clave CÓDIGOESTUDIANTE: NOMBRE-ESTUDIANTE depende directamente del CÓDIGO-ESTUDIANTE. NOMBRE-CURSO depende de igual modo del CÓDIGO-ESTUDIANTE. El AULA, aunque en parte también depende del CÓDIGO-ALUMNO, está mas ligado al NOMBRE-CURSO que el estudiante está realizando. Por esta última razón se dice que la tabla no está en 3FN. La solución sería la siguiente: Tabla A CÓDIGO-ESTUDIANTE NOMBRE-ESTUDIANTE NOMBRE-CURSO 1 Marcos Informática 2 Lucas Inglés 3 Marta Contabilidad Base de Datos – 311 Tabla B NOMBRE-CURSO AULA Informática Aula A Inglés Aula B Contabilidad Aula C Una vez conseguida la Segunda Forma Normal (2FN), se puede estudiar la cuarta forma normal (4FN). Ejemplo 5.4 Cuarta forma normal (4FN) Una tabla está en 4FN si y sólo si para cualquier combinación clave - atributo no existen valores duplicados. Veamos con un ejemplo: Geometría FIGURA COLOR TAMAÑO Cuadrado Rojo Grande Cuadrado Azul Grande Cuadrado Azul Mediano Círculo Blanco Mediano Círculo Azul Pequeño Círculo Azul Mediano Comparemos ahora la clave FIGURA con el atributo TAMAÑO, podemos observar que Cuadrado y Grande están repetidos; igual pasa con Círculo y Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una tabla en 4NF. La solución en este caso sería la siguiente: Base de Datos – 311 Color Tamaño FIGURA COLOR Cuadrado Grande Cuadrado Rojo Cuadrado Mediano Cuadrado Azul FIGURA TAMAÑO Círculo Mediano Círculo Blanco Círculo Pequeño Círculo Azul Ahora si tenemos nuestra base de datos en 4FN. 8.- Si desea profundizar en los aspectos involucrados en esta unidad 5, se sugiere que consulte los siguientes textos que se encuentran en la biblioteca de la UNA: Consulta de libros • • 9.- Fundamentos de bases de datos (1998). Tercera edición, de Henry F. Korth, S. Sudarshan y Abraham Silberschatz.. Introducción a los Sistemas de bases de datos (1998), Quinta edición, C. J. Date. Una vez culminado el estudio de la unidad 5, proceda a realizar el siguiente ejercicio, luego compruebe sus respuestas con la dada en la “Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir, estudie nuevamente el tópico en el cual desacertó. Ejercicio de autoevaluación Suponga que se tiene la siguiente relación para una base de datos, la cual corresponde al registro de vuelo de una agencia de viaje: VUELO NÚMEROV CÓDIGOA CÓD-AVIÓN NOMBREA UBICACIÓNA Donde: NÚMEROV = número de vuelo CÓDIGOA = Código del aeropuerto CÓD-AVIÓN = Código del Avión NOMBREA = Nombre del aeropuerto UBICACIÓNA = Ubicación del aeropuerto CLASEA SIGLAA HORAP HORALL Base de Datos – 311 CLASEA = Clase de Avión SIGLAA = Sigla del avión HORAP = Hora de partida HORALL = Hora de llegada Aplique la técnica de normalización y lleve la siguiente relación a la segunda forma normal (2FN): Muestre los esquemas de las relaciones resultantes. Especifique los atributos claves de cada relación 10.- Resuelva la actividad propuesta que se presenta a continuación: Ejercicio o actividad propuesta Considere la relación para libros publicados: LIBRO (Título-libro, NombreAutor, Tipo-libro, ListaPrecios, Afil-autor, Editor) Afil-autor se refiere a la afiliación del autor, suponga que se dan las siguientes dependencias: Título-libro → Editor, Tipo-libro Tipo-libro → ListaPrecio NombreAutor → Afil-autor a) Aplique la normalización hasta que ya no puedan descomponerse las relaciones, Explique las razones para cada descomposición. Respuesta al Ejercicio de autoevaluación VUELO NÚMEROV CÓDIGOA CÓDAVIÓN HORAP HORALL 144444244444443 CLAVE AEROPUERTO CÓDIGOA NOMBREA UBICACIÓNA 14243 CLAVE AVIÓN CÓD-AVIÓN 14243 CLAVE CLASEA SIGLAA Base de Datos – 311 2006 UNIDAD 6: Seguridad e Integridad Los datos que se encuentran en una base de datos deben ser protegidos contra usuarios no autorizados o autorizados, por lo que se debe garantizar que estos usuarios tengan permiso al acceso de cierta o toda información, asegurando que el manejo de esta información se haga en forma correcta. En esta unidad se presentarán varias estrategias que se pueden utilizar para proteger la base de datos de alteraciones intencionada o daños accidentales, es decir lo concerniente a la Seguridad y Autorización4 de los datos en una base de datos. Objetivo de la Unidad 6: Resolver en situaciones dadas, problemas de Seguridad y/o Integridad en bases de datos relacional. Contenido de la Unidad 6: El contenido de la unidad contempla el estudio de los siguientes puntos: Introducción a los problemas de seguridad en las bases de datos. Control de acceso discrecional basado en concesión o revocación de privilegios. Control de acceso obligatorio para seguridad multinivel. Introducción a la seguridad en las bases de datos estadísticas. Seguridad y Autorización. Recomendación para el estudio del contenido de la unidad 6 1.- En esta sección se comenzará por dar una introducción a los problemas de seguridad, luego se estudiarán mecanismos utilizados para conceder y revocar privilegios en los sistemas de base de datos relacionales y en SQL, seguidamente se expondrán los mecanismos para imponer múltiples niveles de seguridad (Control de acceso obligatorio), de igual manera se estudia el problema de controlar el acceso a las bases de datos estadísticas. Por último se examinará el modo en que se pueden utilizar mal los datos, hacerlos inconsistentes de manera intencionada, así como una explicación de los mecanismos y limitaciones para la definición de autorizaciones que proporciona el lenguaje SQL. 2.- A continuación se presenta la tabla 6.1, en ella puede ubicar en el material de referencia, los tópicos referentes a la unidad 6. 4 El termino Autorización se refiere a Integridad. 21 Base de Datos – 311 TEMA 2006 MATERIAL DE REFERENCIA Seguridad y Libro-Texto: “Fundamentos Autorización en de Sistemas de Bases de base de datos Datos” CÁPI- SECTULO CIÓN 22 22.1. 22.2. TÍTULO PÁGINAS Introducción a los problemas de Seguridad en las bases de datos 679-682 Control de acceso discrecional basado en concesión/revocación de privilegio 22.3. Control de acceso obligatorio para seguridad multinivel 22.4. Introducción a la seguridad en base de datos estadísticas 682-687 687-689 Lectura 6.1 Seguridad Autorización Lectura 6.2 Autorización en SQL 690-691 y 3.- Para comenzar con el estudio de esta unidad lea el capítulo 22 del Librotexto: “Fundamentos de Sistemas de Bases de datos” correspondiente a “Seguridad y autorización en bases de datos” y luego responda las preguntas de repaso que se encuentran al final de este capitulo 22. 4.- Organice los puntos estudiados mediante el uso de un mapa conceptual 5. Efectúe una revisión del ejemplo presentado en el libro-texto de la asignatura para luego realizar el ejercicio o actividad propuesta. 6.- A continuación se presentan algunos aspectos que lo ayudarán a ampliar los conocimientos adquiridos hasta ahora. Seguridad e integridad (autorización) en los sistemas de bases de datos Aspectos que debe reflexionar con respecto a lo estudiado en esta unidad: • El termino seguridad de los datos se asocia frecuentemente con integridad, pero ambos conceptos son diferentes. La Seguridad se refiere a la protección de los datos almacenados en la base de datos, frente accesos no autorizados y alteraciones o destrucción malintencionada, mientras que la Integridad se refiere a la validez de 22 Base de Datos – 311 • • 2006 esos datos, es decir proporcionar un medio que asegure que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la perdida de la consistencia de los datos, protegiéndolo contra los daños accidentales. En la Seguridad e Integridad (autorización) el sistema de base de datos necesita estar al tanto de ciertas restricciones que deben ser especificadas (generalmente por el Administrador de bases de datos) en un lenguaje adecuado. Por otro lado el sistema de gestión de bases de datos (SGBD) debe detectar las operaciones del usuarios para asegurar que se cumplan estas restricciones. Características que apoyan la seguridad en los Sistemas de Bases de Datos: Los tópicos que se incluyen a continuación tienen que ver con la exactitud, consistencia y confiabilidad de la información y con la privacidad y confidencialidad de los datos. Claves Primarias Esta definición determina que para un valor llave primaria solo existirá una tupla o registro en la tabla. Esta situación garantiza que no se tenga información repetida o discordante para un valor de clave y puede ser usada como control, para evitar la inclusión de información inconsistente o repetida en las tablas. Dominio de los atributos El dominio de un atributo define los valores posibles que puede tomar este atributo. Además de los dominios "naturales", usados como tipos de datos, el administrador del sistema puede generar sus propios dominios definiendo el conjunto de valores permitidos. Esta característica, usada en forma correcta, se convierte en mecanismo de control, restricción y validación de los datos a ingresar . Hay que resaltar que estas restricciones siempre serán evaluadas en forma automática por el SGBD. Reglas de integridad Cada base de datos funciona en forma diferente y tiene reglas asociadas a su actividad que pueden ser definidas como restricciones en la Base de Datos. Esto implicaría que cualquier operación que se realice debe respetar estas limitantes. Por ejemplo, condicionar que solo se otorgan descuentos en ventas superiores a Bs. 400.000.000,00. Estas son condiciones que la administración coloca a la operación y como principio en el desarrollo de una aplicación, deben ser respetadas por esta. Vistas Sirve como mecanismo para compartir la información almacenada, permitiendo presentar a diferentes usuarios parte del universo, según se considere necesario. Según las políticas de seguridad, es usual que gran parte de los usuarios nunca tengan acceso directamente a las tablas completas, sino que lo hagan a través de las vistas, las cuales, por ser un objeto, son sujetas de otras medidas de seguridad. Perfiles de usuario y Acceso a la Base de Datos Asignación de nombres de usuarios, con su respectiva clave de acceso (password) y perfiles asociados. Pueden también ser creados roles que serán concedidos a los usuarios según sus funciones. 23 Base de Datos – 311 2006 Auditoría En situaciones en que los datos sean críticos, se debe contar con el riesgo de violación de la seguridad por una persona no autorizada, además de errores involuntarios que igual pueden causar inconsistencias o falta de veracidad de la información. Para estos casos es interesante mantener un archivo de auditoría (log), donde son registradas todas las operaciones realizadas por los usuarios de las bases de datos. En caso de sospecha de falla en la seguridad, este archivo puede ser consultado para conocer los daños causados e identificar a los responsables de las operaciones irregulares. Criptografía de Datos Como recurso de seguridad, se puede mezclar o codificar los datos de modo que, al momento de ser almacenados en disco duro o trasmitidos por alguna línea de comunicación, no sean más que bits ininteligibles para aquellos que los accedan por un medio no oficial. La criptografía es de gran importancia en las bases de datos pues la información esta almacenada por largos periodos de tiempo en medios de fácil acceso, como discos duros. Disparadores o Triggers Siendo un Triggers o disparador una rutina asociada con una tabla o vista que automáticamente realiza una acción cuando una fila en la tabla o la vista se inserta (INSERT), se actualiza (UPDATE), o borra (DELETE), permiten vigilar y registrar acciones especificas según las condiciones propias de las reglas establecidas; permitiendo crear log de auditoria a la medida. Como se puede apreciar, los Sistemas de Bases de Datos ofrecen a los desarrolladores, administradores y usuarios, una gama muy completa de herramientas que permiten garantizar la integridad, consistencia, confidencialidad y en general, la seguridad de la información almacenada y con un elemento muy importante a favor: Las líneas de código que se requieren por parte del diseñador de la base de datos son muy pocas, en ocasiones solo basta con una sencilla sentencia para obligar al SGBD controlar y mantener las restricciones necesarias. 7.- Una vez comprendido el contenido del capítulo 24 y el de las lectura 6.1 y 6.2, te invitamos a leer los siguientes ejemplos que muestra la manera de especificar autorizaciones utilizando vistas Ejemplo 6.1 6.1.1 En una relación PROYECTOS se quiere restringir a un usuario en particular, López Javier, a tener una autorización de acceso solamente de lectura, a los atributos NUMPROY y LOCALIDAD, entonces se puede definir una contraseña para el acceso solo en lectura para una relación que la llamaremos NUMPROY_LOC : GRANT READ ACCESS ON NUMPROY-LOC TO LÓPEZ JAVIER 24 Base de Datos – 311 2006 Donde la forma general para la autorización en lenguaje SQL se especifica de la siguiente manera: GRANT < lista de privilegios > ON < nombre de relación o de vista > TO < lista de usuario > La lista de privilegios permite otorgar varios privilegios (de lectura, de eliminación o de actualización) en una sola instrucción. 6.1.2 Consideremos la relación base PERSONAL que tiene el esquema PERSONAL (CÉDULA, NOMBRE, DIRECCIÓN, HSALARIO, NUMDEPT). De este esquema se quiere limitar el acceso del usuario U1 únicamente puede tener acceso a los empleados del departamento 35 de la tabla PERSONAL. Esta vista se podría expresar como: CREATE VIEW DEP_35 AS SELECT CÉDULA, NOMBRE, DIRECCIÓN, HSALARIO, NUMDEPT FROM PERSONAL WHERE NUMDEPT = 35 8.- Si desea profundizar en los aspectos involucrados en esta unidad 5, se sugiere que consulte el siguiente texto que se encuentran en la biblioteca de la UNA: Consulta de libros Si desea profundizar sobre este tema se sugiere que consulte el texto Introducción a los Sistemas de Bases de Datos (1998), Quinta edición del autor C. J. Date. 9.- Una vez culminado el estudio de la unidad 6, proceda a realizar el siguiente ejercicio, luego compruebe sus respuestas con la dada en la “Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir, estudie nuevamente el tópico en el cual desacertó. Ejercicio de autoevaluación Una institución gubernamental requiere de un sistema de base de datos, que presente en forma oportuna y veraz información relacionada a una población, por ejemplo: datos estadísticos basados en grupos de edad, niveles de ingreso, tamaño de la familia, nivel de educación y otros criterios. Al realizar las pruebas para la puesta en marcha de este sistema de base de datos se detectó el siguiente problema: cualquier actuario gubernamental o usuario de empresas de investigación de mercados, pueden tener acceso a información confidencial detallada sobre individuos 25 Base de Datos – 311 2006 como por ejemplo el ingreso de una persona específica, la dirección exacta de su domicilio, etc. Con base al problema planteado usted deberá responder la siguiente pregunta ¿qué tipo de problema se presenta en la situación planteada y como lo resolvería?. 10.- Resuelva la siguiente actividad propuesta: Ejercicio o actividad propuesta Una empresa desea procesar la nomina del personal para fin de mes, pero ésta presenta inconveniente al momento del cuadre de la distribución de asignaciones, cabe destacar que algunas de estas asignaciones están contenidas en varios archivos de la base de datos y en algún momento del proceso no fue actualizado uno de ellos. Con base al problema planteado usted deberá responder la siguiente pregunta: ¿qué tipo de problema cree usted que se presenta en esta base de datos y como lo solucionaría? 11- Una vez desarrollado el Ejercicio de Autoeveluación, podrá comparar su repuesta con la dada a continuación: Respuesta al Ejercicio de autoevaluación En el sistema de base de datos multiusuario de la institución gubernamental se presenta un problema de seguridad; debido a que se debe prohibir el acceso de información confidencial a personas no autorizadas, por lo tanto es necesario la existencia de un control de acceso, con la finalidad de que el sistema de gestión de base de datos (SGBD) chequee cada operación que se realice, con el propósito de validar cualquier restricción de seguridad y suprimir el acceso a datos no permitidos. Por lo general el SGBD cuenta con un subsistema de seguridad y autorización de la base de datos que se encarga de velar por la seguridad de la base de datos y controlar el acceso no autorizado. 26 Base de Datos – 311 2006 Módulo III Diseño de Base de Datos Relacional El propósito del modulo III está orientado a que el estudiante adquiera los conocimientos necesarios en cuanto proceso de diseño conceptual de la base de datos relacional y el proceso de diseño lógico y físico de la base de datos utilizando un SGBDR, con la finalidad de atender las necesidades de información de los usuarios de una organización. Para una base de datos pequeña, donde existe un número reducido de usuarios, el diseño no necesita ser muy complicado, sin embargo, cuando se diseñan bases de datos medianas o grandes, este proceso se vuelve complejo, ya que el sistema debe satisfacer los requerimientos de numerosos usuarios y por consiguiente aplicaciones de una gran cantidad de transacciones. Es por ello que se hace indispensable el seguimiento de varias fases o etapas de diseños que aseguren procedimientos ordenados y metódicos. Podemos identificar cincos fase para el diseño de la base de datos, sin llegar a la implementación, las cuales se especifican a continuación: 1. Obtención y análisis de requisitos 2. Diseño conceptual de la base de datos 3. Elección de un SGBD 4. Transformación al modelo de datos (llamado también diseño lógico de la base de datos) 5. Diseño físico de la base de datos Objetivo del Modulo III: Diseñar en forma analítica y lógica una base de datos relacional. El módulo III está constituido por dos unidades, especificadas de la siguiente manera: Unidad 7: Proceso de Diseño Conceptual de la base de datos relacional. Unidad 8: Proceso de Diseño Lógico y Físico de la Base de Datos Relacional utilizando un SGBDR. UNIDAD 7: Proceso de Diseño Conceptual de la base de datos relacional. En esta unidad 7 al igual que la siguiente unidad, tiene como estrategia de evaluación un trabajo práctico. El estudiante podrá adquirir los conocimientos necesarios que lo conduzca a realizar varias tareas para la elaboración del diseño de la base de datos relacional. En primer lugar se analizará la fase 1, relacionado a la “Obtención y análisis de requisitos”, luego se expondrá la fase 2 donde se describen las actividades que deben desarrollarse para realizar el “diseño conceptual de la base de datos”, posteriormente se explicará la tercera fase “Elección de un Sistema de Gestión de Base de Datos" y por último la fase 4 donde se analizarán los procesos para el diseño lógico de la base de datos. 27 Base de Datos – 311 2006 Objetivo de la Unidad 7: Diseñar conceptualmente una base de datos bajo el modelo de organización relacional Contenido de la Unidad 7: Se contempla el estudio de los siguientes puntos: Obtención y análisis de requisitos. Diseño conceptual de la base de datos Recomendaciones para el estudio del contenido de la unidad 7 1.- A continuación se dará a conocer la tabla 7.1 en la que se puede ubicar en el material de referencia los contenidos de la unidad en el libro-texto: “Fundamentos de Sistema de Bases de Datos”. Tabla 7.1 TEMA CÁPI- SECMATERIAL DE REFERENCIA TULO CIÓN El proceso de Libro-Texto: “Fundamentos de diseño de bases Sistemas de Bases de Datos” de datos relacional 16 TÍTULO PÁGINAS 16.2.1. Fase 1: Obtención y 504-506 análisis de requisitos. 16.2.2. Fase 2: Diseño 506-515 conceptual de la base de datos. 2.- Para organizar los puntos estudiados y obtener una mejor comprensión de ellos se sugiere hacer uso de los mapas mentales, además de efectuar una revisión del ejemplo mostrado en el material instruccional, que le servirá de guía para que pueda desarrollar su trabajo práctico. 3.- Se sugiere seguir el siguiente orden para el estudio de la unidad: Lea la fase de prediseño donde se exponen los requerimientos y necesidades de los usuarios, después la fase del diseño del esquema conceptual, usando el modelo E-R (Entidad-Relación), para describir los datos, tales como las entidades, los vínculos (relaciones) y los atributos, cabe destacar que este modelo es independiente de un SGBD específico. Continuando con el orden para el estudio de la unidad se sugiere leer la explicación que presenta el libro-texto de la asignatura sobre cómo elegir el SGBD. Por último se debe estudiar la fase del diseño lógico, que consiste en transformar el modelo conceptual al modelo de datos empleado por el SGBD (jerárquico, red o relacional). 28 Base de Datos – 311 2006 NOTA: Para el estudio de esta unidad se utilizará en el diseño un SGBD relacional (SGBDR), por ser el modelo más utilizado por las empresas en la actualidad. 5.- Para avanzar un poco más, a continuación le presentamos algunos puntos que le servirán de ayuda para ampliar lo estudiado hasta ahora. El diseño conceptual de una base de datos (modelo de datos de alto Nivel) • Primeramente vamos a establecer cuales son los objetivos del diseño de BD: Satisfacer requisitos de contenido de información de usuarios y aplicaciones. Proporcionar una estructuración de los datos, fácil de entender. Soportar los requisitos de procesamiento y objetivos de rendimiento; como tiempo de respuesta, tiempo de procesamiento, espacio de almacenamiento, etc.. Conseguir un esquema flexible de BD, es decir que sea posible modificarlo (como consecuencia de cambios en los requisitos del sistema) fácilmente una vez implementada la Base de Datos. • El objetivo de cada fase de diseño lo plantean de la siguiente manera los autores Adoración y Piattini (1999): Diseño conceptual: El objetivo es obtener una buena representación de los recursos de información de la empresa u organización, con independencia de usuarios o aplicaciones en particular y fuera de consideración sobre la eficiencia del computador. Diseño lógico: El objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptándolo al modelo de datos que se va a utilizar en el SGBD. En este curso para el diseño de la base de datos, nos referiremos al modelo relacional, pero de forma análoga se podrá adaptar esta etapa de diseño lógico a otro modelo de datos que se ha estudiado en la Unidad 3 del Modulo I. Esta fase se estudiará en la próxima unidad Diseño físico: Esta fase se estudiará en la próxima unidad. • Para el diseño de una base de datos se pueden identificar varios tipos de usuarios. En primer lugar, los usuarios finales, que hacen uso limitado de las capacidades del sistema, normalmente referentes a introducción, manipulación y consulta de los datos. Los usuarios finales pueden ser especializados o con pocos conocimientos, dependiendo de su nivel de interacción con el sistema. En segundo lugar hay que citar a los programadores de base de datos, encargados de escribir 29 Base de Datos – 311 2006 aplicaciones limitadas, mediante el lenguaje de programación, facilitado por el SGBD. Por último, el administrador de base de datos (DBA, Data Base Administrator) cumple las importantes funciones de crear y almacenar las estructuras de la bases de datos, definir las estrategias de respaldo y recuperación, vincularse con los usuarios y responder a los cambios de requerimientos, y definir los controles de autorización y los procedimientos de validación. 5 • Antes de comenzar a diseñar una base de datos, lo primero que se debe hacer es conocer y analizar las expectativas de los usuarios y los usos que se piensa dar a la base de datos con el mayor detalle posible, este proceso es lo que se llama obtención y análisis de requisitos, el cual se presenta en la primera fase del diseño. Es importante cumplir con esta fase inicial porque usualmente se presentan problemas en el momento de la comunicación entre el informático (conocedor de las técnicas de estructuración de los datos pero no poseedor del dominio de la aplicación) y los usuarios; ocurriendo que este último no expresa en forma correcta o precisa la perspectiva que quiere darle a la base de datos, es por esto, que una vez que se han tomado todos los requisitos, se procede a realizar el diseño del esquema conceptual de alto nivel. • En la segunda fase del diseño existen dos actividades paralelas a desarrollar: el diseño del esquema conceptual, que contiene una descripción detallada de los requerimientos de información de los usuarios (obtenido de la fase 1) produciendo un esquema conceptual independiente del SGBD y el diseño de transacción y aplicación, donde muchas transacciones se ejecutarán una vez que se implante la base de datos, pero parte importante del diseño es especificar las características funcionales de estas transacciones en esta etapa temprana del proceso del diseño, garantizando que el esquema de la base de datos incluirá toda la información requerida por dichas transacciones. • Para crear el esquema conceptual en una base establecer estrategias5, existen varias de ellas, seguirán un enfoque incremental; es decir, construcciones de esquemas derivadas de los modifican, refinan o desarrollan sobre ella. • Como punto de partida para la fase 2 en el diseño del esquema conceptual lo primero que hay que hacer es identificar los componentes básicos del esquema: los tipos de entidades, los tipos de relaciones y sus atributos, como se presenta en el ejemplo proporcionado en la unidad 2 del modulo I. También se especifican los atributos claves, las restricciones de cardinalidad, y las entidades débiles. En paralelo se de datos se deben donde la mayoría parten de ciertas requisitos y luego Las “estrategias para el diseño de esquemas” se encuentran en el capítulo 16 del libro-texto de la asignatura 30 Base de Datos – 311 2006 efectúa dentro de la fase 2 un diseño de transacciones6 , antes de explicar un poco lo que trata esta actividad, primero vamos a explicar que es transacción: Una transacción es un conjunto de acciones llevadas a cabo por un usuario o un programa de aplicación, que acceden o cambian el contenido de la base de datos. El propósito del diseño de transacciones en el nivel conceptual es conocer de las aplicaciones conocidas (o transacciones) que se ejecutarán en la base de datos una vez que se implemente. Una parte importante del diseño de bases de datos es especificar las características funcionales de estas transacciones en una etapa temprana del proceso de diseño. Esto garantiza que el esquema de la base de datos incluirá toda la información requerida por dicha transacción. Al comienzo del proceso del diseño, normalmente solo se conocen algunas transacciones que son posiblemente las más importantes de la base de datos; luego en la implementación se presentarán y se implantarán nuevas transacciones. El diseño de las transacciones se suelen identificar mediante la utilización de la información dada en las especificaciones de requisitos de usuario y a través del estudio las entradas y salidas de datos y su comportamiento funcional. El objetivo del diseño de las transacciones es definir y documentar las características de alto nivel de las transacciones que requiere el sistema. Esta tarea se debe llevar a cabo al principio del proceso de diseño para garantizar que el esquema lógico es capaz de soportar todas las transacciones necesarias. Las características que se deben recoger de cada transacción son las siguientes: Datos que utiliza la transacción. Características funcionales de la transacción. Salida de la transacción. Importancia para los usuarios. Frecuencia de utilización. Hay tres tipos de transacciones: En las transacciones de recuperación se accede a los datos para visualizarlos en la pantalla a modo de informe. En las transacciones de actualización se insertan, borran o actualizan datos de la base de datos. En las transacciones mixtas se mezclan operaciones de recuperación de datos y de actualización. 6.- Basándose en lo estudiado hasta ahora, usted estará en capacidad de responder las siguientes argumentos y preguntas. Estas le servirán de ayuda para ejercitarse en el conocimiento de algunos conceptos que aplicará posteriormente en la resolución de problemas para el diseño de una base de datos. 9 Explique la importancia de la “obtención y análisis de requisitos”. 6 En el capítulo 16 del libro-texto: “Fundamento de Sistemas de Bases de Datos” se enfatiza sobre este punto. 31 Base de Datos – 311 2006 9 Defina los requisitos de los diferentes niveles de usuarios en términos de datos necesarios, tipos de consultas y las transacciones que se van a procesar, considerando una aplicación actual de una sistema de base de datos de interés. 9 Explique las características que debe poseer un modelo de datos para el diseño de esquema conceptual. 9 Compare y contraste los dos principales enfoques del diseño de esquemas conceptuales. 9 Analice las estrategias para diseñar un solo esquema conceptual a partir de sus requisitos. 9 ¿Cuáles son las dificultades que se presentan durante cada paso en el enfoque de integración de vistas para el diseño de esquema conceptual. 9 ¿Cómo funcionaría una herramienta de integración de vistas?. Diseñe una arquitectura modular simple para una herramienta de este tipo. 7.- Una vez aclarado lo que es el diseño conceptual, repase el ejercicio de autoevaluación que se presento en la unidad 2, sobre el diseño del diagrama Entidad-Relación para una base de datos universitaria. 8.- Si desea obtener más información sobre el diseño conceptual, puede hacer búsqueda en Internet, a través de la siguiente dirección electrónica: • • 9.- Consulta en la web http://www3.uji.es/~mmarques/f47/apun/node79.html, Encontrará aspectos relacionado una metodología para el diseño conceptual de bases de datos que se basa en el modelo entidadrelación. http://www3.uji.es/~mmarques/f47/apun/node87.html Se presenta una descripción de los pasos para llevar a cabo el diseño lógico. http://www.tramullas.com/documatica/2-7.html Da una descripción sobre la creación de una base de datos: enfoque E/R y transformación relacional. Si desea profundizar sobre el contenido de la unidad 7, se recomienda que consulte los siguientes libros que se encuentran en la biblioteca de la UNA: 32 Base de Datos – 311 2006 Ampliación de conocimientos Miguel Castaño y Mario G. Piaittin (1993). Concepción y diseño de bases de datos del modelo E/R al modelo relacional. Editorial Addison-Wesley Fundamentos y modelos de Bases de Datos (1999) , Adoración de Miguel y Mario Piattini. 2ª edición, editorial alfaomega, Mexico. 10.- En este momento a finalizado el estudio de la unidad 7 y si considera estar claro con todo los puntos estudiados hasta ahora, proceda a realizar el ejercicio propuesto Ejercicio o actividad propuesta Para aplicar los conocimientos adquiridos y alcanzar una mejor visión sobre el diseño conceptual de una base de datos relacional, el estudiante debe formular problemas de situaciones reales, para luego documentar y elaborar los requerimientos de información y los esquemas en la forma más detallada y completa que sea posible. 33 Base de Datos – 311 2006 UNIDAD 8: Proceso de Diseño Lógico y Físico de la base de datos relacional utilizando un SGBD En esta unidad trataremos tres fases, que contiene el Diseño Lógico y físico de la base datos utilizando un Sistema de Gestión de Bases de Datos Relacional (SGBDR). El propósito de estas fases es describir cómo se va a implementar físicamente el esquema conceptual en el modelo relacional, esto consiste en: a) Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas. b) Determinar las estructuras de almacenamiento y los métodos de acceso que se van a utilizar para conseguir unas condiciones de servicios óptimas c) Analizar las transacciones d) Diseñar el modelo de seguridad del sistema. Objetivo de la Unidad 8: Diseñar el modelo lógico y físico de una base de datos utilizando un Sistema de gestión de Base de datos relacional (SGBDR). Contenido de la Unidad 8: Se contempla el estudio de los siguientes puntos: Elección de un SGBD. Transformación al modelo de datos (diseño lógico de la base de datos). Diseño Físico de la base de datos. Factores que influyen en el diseño físico de la base de datos. Decisiones de diseño físico de una base de datos. Recomendaciones para el estudio del contenido de la unidad 8 1.- A continuación se dará a conocer la tabla 8.1, en ella se puede ubicar en el libro-texto de la asignatura los puntos tratados en la unidad 8, así mismo la tabla hace referencia al capítulo, sección, título y página(s) correspondiente a este libro-texto. 34 Base de Datos – 311 2006 Tabla 8.1 TEMA CÁPI- SECMATERIAL DE REFERENCIA TULO CIÓN El proceso de Libro-Texto: “Fundamentos de diseño de bases Sistemas de Bases de Datos” de datos relacional TÍTULO PÁGINAS 16.2.3. Fase 3: Elección del 515-517 SGBD. 16.2.4. Fase 4: Transformación al 517-518 modelo de datos (diseño lógico de la base de datos) 16.2.5. Fase 5: Diseño físico de la base de 518-519 datos 16 16.3.1. 16.3.2. Factores que influyen en el diseño 519-521 físico de la base de datos Decisiones de diseño físico de una 521-523 base de datos 2.- Una vez que usted haya estudiado los tópicos correspondientes a esta unidad se recomienda responder las siguientes preguntas que le servirán de ayuda para resolver el diseño físico de una base de dato, sobre la base de una situación o problema dado. 9 ¿Cuál es el objetivo del diseño físico de una base de datos? 9 Explique cada uno de los pasos que usted considera deba seguir para realizar el diseño físico de una base de datos. Discuta su respuesta con sus compañeros de estudio y en caso de cualquier duda consulte al asesor del Centro Local. 9 Explique que factores influyen sobre la elección de un SGBD para el sistema de información de una organización. 9 De las preguntas de repaso que se encuentran al final del capítulo Nº 16 del libro-texto de la asignatura, responda las siguientes: 16.15 a la 16.21. 3.- En el estudio de esta unidad, se debe tener en cuenta la elección de las estructuras de almacenamiento de datos, sugiriendo repasar las distintas formas de organización de los archivos, utilizando diferentes técnicas como son: los archivos secuenciales indexados (utilizando la estructura de Árbol-B+) y la multillaves. Estas técnicas fueron estudiadas en la asignatura “Procesamiento de datos”. 35 Base de Datos – 311 2006 4.- En este momento consideramos que ha finalizado el estudio de esta unidad y por ello se sugiere realizar un mapa conceptual que lo ayude a organizar sus ideas. 6.- A continuación le proporcionaremos varios aspectos que debe recordar con respecto a lo estudiado hasta ahora Recordatorio • Para el diseño lógico y físico de la base de datos incluiremos primero la tercera fase donde se debe hacer la elección de un SGBD 7, que dependerá de varios factores como son: técnicos, económicos y de beneficio, de servicio técnico y formación de usuarios, políticas de la organización y de rendimiento, etc., sin embargo, resulta difícil la medida y cuantificación ponderada de los diferentes factores, Asimismo se tiene La fase 4 que consiste en la transformación al modelo de datos (diseño lógico de la base de datos), tomando el esquema de la base de datos de la fase del diseño conceptual. Esta fase produce un diseño que se acerca más a la implementación en un Sistema de Gestión de Base de Datos. En esencia esta fase transforma el modelo Entidad - Relación en tablas que podrán ser implementadas en un sistema manejador de base de datos particular. Una vez que el modelo Entidad - Relación es transformado a tablas, se eliminan ciertas anomalías, debidas principalmente a la redundancia, el proceso a través del cuál se da esto se conoce como NORMALIZACIÓN. Es importante comentar que el proceso de normalización es un “medio y no un fin”. La normalización es una técnica8 que se utiliza para comprobar la validez de los esquemas lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos inconsistentes y redundantes. La transformación al modelo lógico se puede hacer a través de uno de estos modelos: el relacional, el de red, el jerárquico o el modelo orientado a objetos, para nuestro curso se tratará el modelo relacional, por ser el modelo mas utilizado en la actualidad en las empresas. El diseño lógico, es un proceso que tienen un punto de inicio y se va refinando continuamente, es decir, se van probando y validando con los requisitos de los usuarios. Tanto el diseño conceptual como el lógico se deben ver como un proceso de aprendizaje en el que el diseñador va comprendiendo el funcionamiento de la organización y el significado de los datos que maneja. Ambos diseños son etapas clave para conseguir un sistema que funcione correctamente. Si el esquema no es una representación fiel de todos los requisitos del sistema que se vaya a diseñar, será difícil, sino imposible, definir todas las vistas de usuario (esquemas externos), o mantener la integridad de la base de datos. 7 El punto referente a la elección del SGBD se cubre en el libro- texto: Fundamento de Sistemas de Bases de Datos. 8 Esta técnica se presenta en el Modulo II Unidad 5 de este material instruccional de apoyo, dedicado a la Normalización en base de datos relacionales. 36 Base de Datos – 311 2006 También puede ser difícil definir el diseño físico o el mantener unas condiciones de servicios aceptables del sistema que permita representar correctamente en la base de datos los futuros cambios que se realicen sobre los programas de aplicación o sobre los datos. El modelo lógico se obtiene transformando el esquema Entidad-Relación (diseñado en la fase 2) en un esquema relacional y para lograr esta transformación se pueden seguir dos etapa: a) Transformación independiente del sistema, en donde se analiza la transformación independiente del SGBD b) Adaptación de los esquemas a un SGBD específico, donde se ajusta los esquemas obtenidos en la primera etapa para ajustarlos a las características de implementación específica del modelo de datos utilizado en el SGBD seleccionado. • Cada Sistema de Gestión de Base de Datos (SGBD) ofrece varias opciones de organización de archivos y caminos de accesos, entre ellas diversos tipos de indexación, agrupaciones de registros relacionados en bloque de discos, enlaces de registros relacionados mediante apuntadores y varios tipos de técnicas de dispersión. Una vez seleccionado el SGBD, el proceso de diseño físico se reduce a elegir la estructura más apropiada para los archivos de la base de datos entre las opciones que ofrece ese SGBD y las pautas para las decisiones de diseño físico aplicables a diversos tipos de SGBD. • Uno de los objetivos principales del diseño físico es almacenar los datos de modo eficiente. Para medir la eficiencia hay varios factores que se deben tener en cuenta: 9 Productividad de transacciones. Es el número de transacciones que en el sistema de la base de datos se quiere procesar en un intervalo de tiempo. 9 Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transacción. Desde el punto de vista del usuario, este tiempo debería ser el mínimo posible. Un aspecto que influye mucho sobre el tiempo de respuesta y que está bajo el control del SGBD es el tiempo de acceso a la base de datos para obtener los elementos de información a los que hace referencia la transacción. El tiempo de respuesta también depende de factores que no puede controlar el SGBD, como son la carga del sistema, la planificación de tareas del sistema operativo o los retrasos de comunicación. 9 Aprovechamiento de espacio. Es la cantidad de espacio de almacenamiento que ocupan los archivos de las base de datos y su estructura de acceso en disco, tales como índice u otros caminos de acceso. Los factores que se mencionaron anteriormente no se pueden satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta mínimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando más espacio en disco. Por lo tanto, el diseñador deberá ir ajustando estos factores para conseguir un equilibrio razonable. El diseño físico inicial no será el definitivo, sino que habrá que ir revisando e ir ajustándolo como sea 37 Base de Datos – 311 oportuno. Muchos SGBD proporcionan monitorear y afinar el sistema. 2006 herramientas para • Para la fase de diseño físico se debe tener en cuenta lo siguiente: la estimación del número de registros que contienen los archivos y los patrones de actualización, obtención de datos del archivo para todas las transacciones en conjunto y las estimaciones de crecimientos de los archivos, ya sea en el tamaño de los registros debido a la adición de nuevos atributos o en el número de registros. • En el diseño físico no sólo es lograr la estructuración apropiada de los datos en el almacenamiento, sino hacerlo de manera tal que garantice un buen rendimiento. Para un esquema conceptual dado, existe muchas alternativas de diseño físico en un SGBD en particular. No es posible tomar decisiones de diseño ni realizar análisis de rendimiento que tengan sentido antes de conocer las consultas y transacciones que se piensa ejecutar en la base de datos. Se debe analizar estas aplicaciones de consultas y transacciones, las frecuencias esperadas de invocación de estas consultas y transacciones, cualquier restricción de tiempo que haya sobre su ejecución y la frecuencia esperada de las operaciones de actualización9. • La mayoría de los sistemas relacionales representan cada relación base como un archivo físico de base de datos. Las opciones de camino de acceso incluyen la especificación del tipo de archivo para cada relación y los atributos sobre los cuales habrán de definirse índices. Los índice de cada archivo pueden ser primario o de agrupación. Un índice primario es un archivo ordenado cuyos registros son de longitud fija y contienen dos campos10. El primero de estos campos tiene el mismo tipo de datos que le campo clave de ordenación (llamado clave primaria) del archivo de datos. Y el segundo campo es un puntero a un bloque de disco (una dirección de bloque). Hay un entrada de índice (o registro de índice) en el archivo del índice por cada bloque del archivo de datos. Si los registros de un archivo están ordenados físicamente según un campo no clave, que no tiene un valor distinto para cada registro, dicho campo se denomina campo de agrupación. Podemos crear un tipo diferente de índice, llamado índice de agrupación, para acelerar la recuperación de registros que tienen el mismo valor en el campo de agrupación. Esto no es lo mismo que un índice primario, que requiere que el campo de ordenación del archivo de datos tenga un valor distinto para cada registro. Un índice de agrupación es también un archivo ordenado con dos campos: el primero es del mismo tipo que el campo de agrupación del archivo de datos y el segundo es un puntero a un bloque. 9 El lector debe revisar todos estos tipos de factores que influyen en el diseño físico de la base de datos descrito en la sección 16.3.1 del capítulo 16 del material de referencia. 10 Se utilizará los términos campos y atributos indistintamente en este tema. 38 Base de Datos – 311 7.- 2006 Para garantizar el logro del objetivo de la unidad 8 es necesario, además de estudiar el contenido correspondiente a esta unidad que se encuentra en el libro-texto de la asignatura, leer el contenido que se presentan a continuación: Aspectos que debe considerar para el diseño físico de la base de datos • La técnica utilizada para representar y almacenar registros en archivos es llamada Organización de archivos, Existen diferentes técnicas de organización de archivos, se mencionarán dos de ellas que fueron vista en la asignatura “Procesamiento de datos”: 9 Secuencial indexado. Permite combinar los tipos de acceso que manejan un archivo secuencial y un archivo relativo. La estructura de árbol-B+, es una técnica muy utilizada en la implementación de los índice de una base de datos. 9 Multi-llave. Está técnica de organización de archivo son el corazón de las implantaciones de base de datos. Existe numerosas técnicas, que han sido utilizadas para implantar archivos multillaves, donde al archivo se le puede acceder a través de múltiples trayectorias, cada una con una clave diferente. Asimismo, las técnicas para la implantación de archivos multillaves están basadas en la construcción de índices para proporcionar acceso directo. • Mientras que en el diseño lógico se especifica qué información se guarda, en el diseño físico se especifica cómo se guarda. Para ello, el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar. Podemos decir que entre el diseño físico y el diseño lógico hay una realimentación, ya que algunas decisiones que se tomen durante el desarrollo del diseño físico, pueden provocar una reestructuración del esquema lógico. • Los tipos de organizaciones de archivos disponibles varían en cada SGBD. Algunos sistemas proporcionan más estructuras de almacenamiento que otros. Es muy importante que el diseñador del esquema físico sepa qué estructuras de almacenamiento le proporciona el SGBD y cómo las utiliza. • Para realizar un buen diseño físico es necesario conocer las consultas y las transacciones que se van a ejecutar sobre la base de datos. Esto incluye tanto información cualitativa, como cuantitativa. Para cada transacción, hay por ejemplo que especificar: 9 La frecuencia con que se va a ejecutar. 9 Las relaciones y los atributos a los que accede la transacción, y el tipo de acceso: consulta, inserción, modificación o eliminación. Los atributos que se modifican no son buenos candidatos para construir estructuras de acceso. 39 Base de Datos – 311 2006 9 Las frecuencias esperadas de las operaciones de actualización: se debe especificar el mínimo posible de caminos de acceso para los archivos que se actualizan con frecuencia. 9 Las restricciones de unicidad sobre los atributos: Los caminos de acceso deberían especificarse sobre los atributos (o conjunto de atributos) que son claves candidatas, que bien son claves primarias o tienen restricciones de unicidad. • Los índices son estructuras de acceso que se utilizan para acelerar el acceso a los registros en respuesta a ciertas condiciones de búsqueda. Algunos tipos de índices, los denominados caminos de acceso secundario, no afectan la colocación físico de los registros en el disco y lo que hacen es proporcionar caminos de acceso alternativos para encontrar los registros de modo eficiente basándose en los campos de indexación. Hay otros tipos de índices que sólo se pueden construir sobre archivos que tienen una determinada organización. Para seleccionar los índices11, se pueden seguir las siguientes indicaciones: 9 Construir un índice sobre la clave primaria de cada relación base. 9 No crear índices sobre relaciones pequeñas. 9 Añadir un índice sobre los atributos que se utilizan para acceder con mucha frecuencia. 9 Añadir un índice sobre las claves ajenas que se utilicen con frecuencia. 9 Evitar los índices sobre atributos que se modifican a menudo. 9 Evitar los índices sobre atributos poco selectivos (aquellos en los que la consulta selecciona una porción significativa de la relación). 9 Evitar los índices sobre atributos formados por caracteres muy largos. Los índices creados se deben documentar, explicando las razones de su elección. Metodología para el diseño físico de una base de datos relacionales A continuación se describe la metodología que usted puede considerar para el diseño físico para bases de datos relacionales. En esta etapa, se parte del esquema lógico global obtenido durante el diseño lógico. En este capítulo se dan una serie de directrices para escoger las estructuras de almacenamiento de las relaciones base, decidir cuándo crear índices y cuándo desnormalizar el esquema lógico e introducir redundancias. En el diseño físico se especifica cómo se guarda la información donde el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema 11 Se debe revisar los diversos topos de índice o caminos de acceso descritos en la Sección 6.1 del librotexto: “ Fundamentos de Sistemas de Bases de Datos”. 40 Base de Datos – 311 2006 informático sobre el que éste va a trabajar. Como se explicó anteriormente el diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, pueden provocar una reestructuración del esquema lógico. Metodología de diseño físico para base de datos relacionales El objetivo de esta etapa es producir una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos de acceso que se utilizarán para conseguir un acceso eficiente a los datos. El diseño físico podemos dividirlo en cuatro fases, cada una de ellas compuesta por una serie de pasos: 1. Traducir el esquema lógico global para el SGBD específico. • Diseñar las relaciones base para el SGBD específico. • Diseñar las reglas de negocio para el SGBD específico. 2. Diseñar la representación física. • Analizar las transacciones. • Escoger las organizaciones de archivo. • Escoger los índices secundarios. • Considerar la introducción de redundancias controladas. • Estimar la necesidad de espacio en disco. 3. Diseñar los mecanismos de seguridad. • Diseñar las vistas de los usuarios. • Diseñar las reglas de acceso. 4. Monitorear y afinar el sistema. 1.- Traducir el esquema lógico global La primera fase del diseño lógico consiste en traducir el esquema lógico global en un esquema que se pueda implementar en el SGBD escogido. Para ello, es necesario conocer toda la funcionalidad que éste ofrece. Por ejemplo, el diseñador deberá saber: a) Si el sistema soporta la definición de claves primarias, claves ajenas y claves alternativas b) Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir atributos como no nulos) c) Si el sistema soporta la definición de dominios d) Si el sistema soporta la definición de reglas de negocio d) Cómo se crean las relaciones base. Diseñar las relaciones base para el SGBD específico Las relaciones base se definen mediante el lenguaje de definición de datos del SGBD. Para ello, se utiliza la información producida durante el diseño lógico: el esquema lógico global y el diccionario de datos. El esquema lógico consta de un conjunto de relaciones y para cada una de ellas, se tiene: • El nombre de la relación. • La lista de atributos entre paréntesis. • La clave primaria y las claves ajenas, si las tiene. • Las reglas de integridad de las claves ajenas. En el diccionario de datos se describen los atributos y para cada uno de ellos, se tiene: • Su dominio: tipo de datos, longitud y restricciones de dominio. • El valor por defecto, que es opcional. • Si admite nulos. • Si es derivado y, en caso de serlo, cómo se calcula su valor. 41 Base de Datos – 311 2006 A continuación, se muestra un ejemplo de la definición de la relación INMUEBLE con el estándar SQL2. CREATE DOMAIN pnum AS VARCHAR(5); CREATE DOMAIN enum AS VARCHAR(5); CREATE DOMAIN onum AS VARCHAR(3); CREATE DOMAIN inum AS VARCHAR(5); CREATE DOMAIN calle AS VARCHAR(25); CREATE DOMAIN area AS VARCHAR(15); CREATE DOMAIN poblacion AS VARCHAR(15); CREATE DOMAIN tipo AS VARCHAR(1) CHECK(VALUE IN (`A',`C',`D',`P',`V')); CREATE DOMAIN hab AS SMALLINT CHECK(VALUE BETWEEN 1 AND 15); CREATE DOMAIN alquiler AS DECIMAL(6,2) CHECK(VALUE BETWEEN 0 AND 9999); CREATE TABLE inmueble inum INUM NOT NULL, calle CALLE NOT NULL, area AREA, poblacion POBLACION NOT NULL, tipo TIPO NOT NULL DEFAULT `P', hab HAB NOT NULL DEFAULT 4, alquiler ALQUILER NOT NULL DEFAULT 350, pnum PNUM NOT NULL, enum ENUM, onum ONUM NOT NULL, PRIMARY KEY (inum), FOREIGN KEY (pnum) REFERENCES propietario ON DELETE no action ON UPDATE cascade, FOREIGN KEY (enum) REFERENCES plantilla ON DELETE set null ON UPDATE cascade, FOREIGN KEY (onum) REFERENCES oficina ON DELETE no action ON UPDATE cascade Diseñar las reglas de negocio para el SGBD específico Las actualizaciones que se realizan sobre las relaciones de la base de datos deben observar ciertas restricciones que imponen las reglas de negocio de la empresa. Algunos SGBD proporcionan mecanismos que permiten definir estas restricciones y vigilan que no se violen. Por ejemplo, si no se quiere que un empleado tenga más de diez inmuebles asignados, se puede definir una restricción en la sentencia CREATE TABLE de la relación INMUEBLE: CONSTRAINT inmuebles_por_empleado CHECK (NOT EXISTS (SELECT enum FROM inmueble GROUP BY enum HAVING COUNT(*)>10)) Otro modo de definir esta restricción es mediante un disparador ( trigger): 42 Base de Datos – 311 2006 CREATE TRIGGER inmuebles_por_empleado ON inmueble FOR INSERT,UPDATE AS IF ((SELECT COUNT(*) FROM inmueble i WHERE i.inum=INSERTED.inum)>10) BEGIN PRINT "Este empleado ya tiene 10 inmuebles asignados" ROLLBACK TRANSACTION END Hay algunas restricciones que no las pueden manejar los SGBD, como por ejemplo `a las 20:30 del último día laborable de cada año archivar los inmuebles vendidos y borrarlos'. Para estas restricciones habrá que escribir programas de aplicación específicos. Por otro lado, hay SGBD que no permiten la definición de restricciones, por lo que éstas deberán incluirse en los programas de aplicación. Todas las restricciones que se definan deben estar documentadas. Si hay varias opciones posibles para implementarlas, hay que explicar porqué se ha escogido la opción implementada. 2.- Diseñar la representación física Uno de los objetivos principales del diseño físico es almacenar los datos de modo eficiente. Para medir la eficiencia hay varios factores que se deben tener en cuenta: 9 Productividad de transacciones. Es el número de transacciones que se quiere procesar en un intervalo de tiempo. 9 Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transacción. Desde el punto de vista del usuario, este tiempo debería ser el mínimo posible. 9 Espacio en disco. Es la cantidad de espacio en disco que hace falta para los archivos de la base de datos. Normalmente, el diseñador querrá minimizar este espacio. Todos estos factores no se pueden satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta mínimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando más espacio en disco. Por lo tanto, el diseñador deberá ir ajustando estos factores para conseguir un equilibrio razonable. El diseño físico inicial no será el definitivo, sino que habrá que ir revisando para observar sus condiciones de servicios e ir ajustándolo como sea oportuno. Muchos SGBD proporcionan herramientas para monitorear y afinar el sistema. Hay algunas estructuras de almacenamiento que son muy eficientes para cargar grandes cantidades de datos en la base de datos, pero no son eficientes para el resto de operaciones, por lo que se puede escoger dicha estructura de almacenamiento para inicializar la base de datos y cambiarla, a continuación, para su posterior operación. Los tipos de organizaciones de archivos disponibles varían en cada SGBD. Algunos sistemas proporcionan más estructuras de almacenamiento que otros. Es muy importante que el diseñador 43 Base de Datos – 311 2006 del esquema físico sepa qué estructuras de almacenamiento le proporciona el SGBD y cómo las utilizará. Para mejorar las condiciones de servicios, el diseñador del esquema físico debe saber cómo interactúan los dispositivos involucrados y cómo esto afecta a estas condiciones de servicios del sistema: Memoria principal. Los accesos a memoria principal son mucho más rápidos que los accesos a memoria secundaria (decenas o centenas de miles de veces más rápidos). CPU. Controla los recursos del sistema y ejecuta los procesos de usuario. El principal objetivo con este dispositivo es lograr que no haya bloqueos de procesos para conseguirla. Si los procesos de los usuarios hacen muchas demandas de recursos al CPU, ésta situación se convierte en un cuello de botella. Entrada/salida a disco. Los discos tienen una velocidad de entrada/salida. Cuando se requieren datos a una velocidad mayor que ésta, el disco genera una degradación de la respuesta requerida. Los principios básicos que se deberían seguir para repartir los datos en los discos son los siguientes: 9 Los archivos del sistema operativo deben estar separados de los archivos de la base de datos. 9 Los archivos de datos deben estar separados de los archivos de índices. La Red. Se convierte en un cuello de botella cuando tiene mucho tráfico y cuando hay muchas colisiones. Cada uno de estos recursos afecta a los demás, de modo que una mejora en alguno de ellos puede provocar mejoras en otros. Analizar las transacciones Para realizar un buen diseño físico es necesario conocer las consultas y las transacciones que se van a ejecutar sobre la base de datos. Esto incluye tanto información cualitativa, como cuantitativa. Para cada transacción, hay que especificar: 9 La frecuencia con que se va a ejecutar. 9 Las relaciones y los atributos a los que accede la transacción 9 El tipo de acceso: consulta, inserción, modificación o eliminación. Los atributos que se modifican no son buenos candidatos para construir estructuras de acceso. Escoger las organizaciones de archivos El objetivo de este paso es escoger la organización de archivos óptima para cada relación. Por ejemplo, un archivos desordenado es una buena estructura cuando se va a cargar gran cantidad de datos en una relación al inicializarla, cuando la relación tiene pocas tuplas, también cuando en cada acceso se deben obtener todas las tuplas de la relación, o cuando la relación tiene una estructura de acceso adicional, como puede ser un índice. Por otra parte, los archivos dispersos (hashing) son apropiados cuando se accede a las tuplas a través de los valores exactos de alguno de sus campos. Si la condición de búsqueda es distinta de la igualdad (búsqueda por rango, por patrón, etc.), la dispersión no es una buena opción. Hay otras organizaciones, como los árboles B+ y los archivos multillave donde las técnicas para la implantación de estos archivos multillave están basadas en la construcción de índices para proporcionar acceso directo de los datos. 44 Base de Datos – 311 2006 Las organizaciones de archivos elegidas deben documentarse, justificando en cada caso la opción escogida. Escoger los índices secundarios Los índices secundarios permiten especificar caminos de acceso adicionales para las relaciones base. Por ejemplo, la relación INMUEBLE se puede haber almacenado en un archivos disperso a través del atributo inum. Si se accede a menudo a esta relación a través del atributo alquiler, se puede plantear la creación de un índice sobre dicho atributo para favorecer estos accesos. Pero hay que tener en cuenta que estos índices conllevan un costo de mantenimiento que hay que sopesar frente a la ganancia en condiciones de servicios. A la hora de seleccionar los índices, se pueden seguir las siguientes indicaciones: 9 Construir un índice sobre la clave primaria de cada relación base. 9 No crear índices sobre relaciones pequeñas. 9 Añadir un índice sobre los atributos que se utilizan para acceder con mucha frecuencia. 9 Añadir un índice sobre las claves ajenas que se utilicen con frecuencia para hacer joins. 9 Evitar los índices sobre atributos que se modifican a menudo. 9 Evitar los índices sobre atributos poco selectivos (aquellos en los que la consulta selecciona una porción significativa de la relación). 9 Evitar los índices sobre atributos formados por tiras de caracteres largas. Los índices creados se deben documentar, explicando las razones de su elección. Considerar la introducción de redundancias controladas En ocasiones puede ser conveniente relajar las reglas de normalización introduciendo redundancias de forma controlada, con objeto de mejorar las condiciones de servicios del sistema. En la etapa del diseño lógico se recomienda llegar, al menos, hasta la tercera forma normal para obtener un esquema con una estructura consistente y sin redundancias. Pero, a menudo, sucede que las bases de datos así normalizadas no proporcionan la máxima eficiencia, con lo que es necesario volver atrás y desnormalizar algunas relaciones, sacrificando los beneficios de la normalización para mejorar las condiciones de servicios. Es importante hacer notar que la desnormalización sólo debe realizarse cuando se estime que el sistema no puede alcanzar las condiciones de servicios deseadas y desde luego, la necesidad de desnormalizar en ocasiones no implica eliminar la normalización del diseño lógico: la normalización obliga al diseñador a entender completamente cada uno de los atributos que se han de representar en la base de datos. Por lo tanto, hay que tener en cuenta los siguientes factores: 9 La desnormalización hace que la implementación sea más compleja. 9 La desnormalización hace que se sacrifique la flexibilidad. 9 La desnormalización puede hacer que los accesos a datos sean más rápidos, pero ralentiza las actualizaciones. Por regla general, la desnormalización de una relación puede ser una opción viable cuando las condiciones de servicios que se obtienen no son las deseadas y la relación se actualiza con poca frecuencia, pero se consulta muy 45 Base de Datos – 311 2006 a menudo. Las redundancias que se pueden incluir al desnormalizar son de varios tipos: se pueden introducir datos derivados (calculados a partir de otros datos), se pueden duplicar atributos o se pueden hacer joins de relaciones. El incluir un atributo derivado dependerá del costo adicional de almacenarlo y mantenerlo consistente con los datos de los que se deriva, frente al costo de calcularlo cada vez que se necesita. No se pueden establecer una serie de reglas que determinen cuándo desnormalizar relaciones, pero hay algunas situaciones muy comunes en donde puede considerarse esta posibilidad: 9 Combinar relaciones de uno a uno. Cuando hay relaciones (tablas) involucradas en relaciones de uno a uno, se accede a ellas de manera conjunta con frecuencia y casi no se les accede separadamente, se pueden combinar en una sola relación (tabla). 9 Duplicar atributos no clave en relaciones de uno a muchos para reducir los joins. Para evitar operaciones de join, se pueden incluir atributos de la relación (tabla) padre en la relación (tabla) hijo de las relaciones de uno a muchos. 9 Tablas de referencia. Las tablas de referencia ( lookup) son listas de valores, cada uno de los cuales tiene un código. Por ejemplo puede haber una tabla de referencia para los tipos de inmueble, con las descripciones de estos tipos y un código asociado. Este tipo de tablas son un caso de relación de uno a muchos. En la relación INMUEBLE habrá una clave ajena a esta tabla para indicar el tipo de inmueble. De este modo, es muy fácil validar los datos, además de que se ahorra espacio escribiendo sólo el código y no la descripción para cada inmueble, además de ahorrar tiempo cuando se actualizan las descripciones. Si las tablas de referencia se utilizan a menudo en consultas críticas, se puede considerar la introducción de la descripción junto con el código en la relación (tabla) hijo, manteniendo la tabla de referencia para validación de datos. 9 Duplicar claves ajenas en relaciones de uno a muchos para reducir los joins. Para evitar operaciones de join, se pueden incluir claves ajenas de una relación (tabla) en otra relación (tabla) con la que se relaciona (habrá que tener en cuenta ciertas restricciones). 9 Duplicar atributos en relaciones de muchos a muchos para reducir los joins. Durante el diseño lógico se eliminan las relaciones de muchos a muchos introduciendo dos relaciones de uno a muchos. Esto hace que aparezca una nueva relación (tabla) intermedia, de modo que si se quiere obtener la información de la relación de muchos a muchos, se tiene que realizar el join de tres relaciones (tablas). Para evitar algunos de estos joins se pueden incluir algunos de los atributos de las relaciones (tablas) originales en la relación (tabla) intermedia. 9 Introducir grupos repetitivos. Los grupos repetitivos se eliminan en el primer paso de la normalización para conseguir la primera forma normal. Estos grupos se eliminan introduciendo una nueva relación (tabla), generando una relación de uno a muchos. A veces, puede ser conveniente reintroducir los grupos repetitivos para mejorar las condiciones de servicios. 46 Base de Datos – 311 2006 Todas las redundancias que se introduzcan en este paso se deben documentar y razonar. El esquema lógico se debe actualizar para reflejar los cambios introducidos. Estimar la necesidad de espacio en disco En caso de que se tenga que adquirir nuevo equipamiento informático, el diseñador debe estimar el espacio necesario en disco para la base de datos. Esta estimación depende del SGBD que se vaya a utilizar y del hardware. En general, se debe estimar el número de tuplas de cada relación y su tamaño. También se debe estimar el factor de crecimiento de cada relación. 3.- Diseñar los mecanismos de seguridad Los datos constituyen un recurso esencial para la empresa, por lo tanto su seguridad es de vital importancia. Durante el diseño lógico se habrán especificado los requerimientos en cuanto a seguridad que en esta fase se deben implementar. Para llevar a cabo esta implementación, el diseñador debe conocer las posibilidades que ofrece el SGBD que se vaya a utilizar. Diseñar las vistas de los usuarios El objetivo de este paso es diseñar las vistas de los usuarios correspondientes a los esquemas lógicos locales. Las vistas, además de preservar la seguridad, mejoran la independencia de datos, reducen la complejidad y permiten que los usuarios vean los datos en el formato deseado. Diseñar las reglas de acceso El administrador de la base de datos asigna a cada usuario un identificador que tendrá una palabra secreta asociada por motivos de seguridad. Para cada usuario o grupo de usuarios se otorgarán permisos para realizar determinadas acciones sobre determinados objetos de la base de datos. Por ejemplo, los usuarios de un determinado grupo pueden tener permiso para consultar los datos de una relación base concreta y no tener permiso para actualizarlos. 4.- Monitorear y afinar el sistema Una vez implementado el esquema físico de la base de datos, se debe poner en marcha para observar sus condiciones de servicios. Si éstas no son las deseadas, el esquema deberá cambiar para intentar satisfacerlas. Una vez afinado el esquema, no permanecerá estático, ya que tendrá que ir cambiando conforme lo requieran los nuevos requisitos de los usuarios. Los SGBD proporcionan herramientas para monitorear el sistema mientras está en funcionamiento. De todo lo dicho anteriormente podemos resumir que el diseño físico es el proceso de producir una descripción de la implementación de la base de datos en memoria secundaria. Se describe las relaciones base y las estructuras de almacenamiento y métodos de acceso que se utilizarán para acceder a los datos de modo eficiente. El diseño de las relaciones base sólo se puede realizar cuando el diseñador conoce perfectamente toda la funcionalidad que presenta el SGBD que se vaya a utilizar. El primer paso para realizar el diseño físico de la base de datos, consiste en traducir el esquema lógico global de 47 Base de Datos – 311 2006 modo que pueda ser fácilmente implementado por el SGBD específico. Se escogen las organizaciones de archivos más apropiadas para almacenar las relaciones base, y los métodos de acceso, basándose en el análisis de las transacciones que se van a ejecutar sobre la base de datos. Se puede considerar la introducción de redundancias controladas para mejorar las condiciones de servicios. Otra tarea a realizar en este paso es estimar el espacio en disco. De igual manera, la seguridad de la base de datos es fundamental, por lo que el siguiente paso consiste en diseñar las medidas de seguridad necesarias mediante la creación de vistas y el establecimiento de permisos para los usuarios. El último paso del diseño físico consiste en monitorear y afinar el sistema para obtener las mejores condiciones de servicios y satisfacer los cambios que se puedan producir en los requisitos. 8.- Una vez aclarado lo que es el diseño físico, prosiga leyendo el ejemplo que se presenta a continuación que le servirá de soporte para entender la transformación del esquema conceptual al relacional. Este ejemplo fue presentado por el autor Adoración y Piattini (p.268,1999), en su libro “fundamentos y modelos de bases de datos”: Ejemplo 7.1 Se trata de una base de datos relacional que gestiona los préstamos de libros: El paso de un esquema en el modelo E-R al modelo relacional está basado en los tres principios siguientes, Adoración y Piattini (1999): • Todo tipo de entidad se convierte en una relación • Todo tipo de interrelación N:M se transforma en una relación • Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de clave o bien se crea una nueva relación. 48 Base de Datos – 311 2006 Nombre_e EDITORIAL Código Nombre_a LIBRO Escribe Edita 1:N E S T R U C T U R A R E L A C I O N A L AUTOR NM LIBRO (Código, Título, Idioma,....., Editorial) Clave ajena EDITORIAL (Nombre-e, Dirección, Ciudad, País) Clave ajena ESCRIBE (Nombre-a, Código) Clave ajena AUTOR (Nombre-a, Nacionalidad, Institución) En la figura se muestra el modelo Entidad-Relación (esquema conceptual), al cual se le aplica un conjunto de reglas a fin de transformarlo en una estructura relacional. Se puede observar que la tres entidades EDITORIAL, LIBRO y AUTOR se transforma en otras tantas relaciones. La interrelación N:M Escribe da lugar a una nueva relación ESCRIBE cuya clave primaria es la concatenación de los atributos identificadores de las entidades que participan en ella (Nombre_a, de AUTOR y Código de LIBRO), siendo además éstos claves ajenas de ESCRIBE que referencian a las relaciones AUTOR Y LIBRO, respectivamente. La interrelación 1:N Edita se transforma mediante el mecanismo de propagación de clave, por el que se incluye en la relación LIBRO la clave de la relación EDITORIAL (a la que llamamos Editorial); atributo que será clave ajena de la relación LIBRO referenciado a EDITORIAL 12 10.- 12 Si desea mejorar su comprensión sobre los conocimientos de esta unidad se recomienda que consulte los siguientes libros que se encuentran en la biblioteca de la UNA: Las claves ajenas de la tabla que referencia no han de llamarse obligatoriamente igual que las claves primarias de la tabla referenciada. Muchas veces, incluso, es costumbre asignar a la clave ajena el nombre de la tabla referenciada; tal como se ha hecho al propagar la clave de EDITORIAL a la relación LIBRO. 49 Base de Datos – 311 2006 Consulta de libros CC • • • • Gary W. Hansen y James V. Hansen (1997). Diseño y administración de bases de datos. Prentice-Hall David M. Kroenke (1996) Procesamiento de Bases de Datos, fundamentos, diseños e instrumentación. Prentice-Hall . Hawryszkiewycz (1994) análisis y diseño de bases de datos. Limusa Jim Buyens (2001), Aprenda desarrollo de bases de datos. McGrawHill 11.- Para alcanzar una mejor visión sobre el diseño físico de una base de datos relacional, es necesario que el estudiante se documente con ejemplos sencillos presentes en algunos de los libros recomendados anteriormente, con la finalidad de aprender a elegir estructuras de almacenamiento y caminos de acceso específico para que los archivos de la base de datos tenga un buen rendimiento con las diversas aplicaciones de la base de datos. 12.- El estudiante debe investigar sobre como utilizar y cuales son las bondades que se presentan al utilizar un Sistema de Gestión de Base de datos (SGBD), esto lo puede hacer a través de los textos recomendados o por documentos que puede encontrar en Internet. 13.- Consulte al asesor de su centro las dudas e inquietudes, bien sea personalmente o por correo electrónico. 50
