Sistemas de gestión de bases de datos

Transcripción

1 Sistemas de gestión de bases de datos TEMA 1 EVOLUCIÓN DE LAS BASES DE DATOS Tema 1 Evolución de las bases de datos 1. Evolución de los modelos de bases de datos 2. Arquitectura funcional de un SGBD 1. EVOLUCIÓN DE LOS MODELOS DE BASES DE DATOS Le evolución que han seguido los modelos de bases de datos, y que se ajusta perfectamente a la figura del margen, es la siguiente: Los ficheros clásicos Un fichero es un contenedor que almacena datos estructurados siguiendo unas reglas sencillas: el fichero almacena los datos que corresponden a todas las instancias de una determinada entidad, además es una colección de registros, siendo cada registro una colección de campos. Estos ficheros clásicos no proporcionan ningún software especializado de acceso, sino que toda esta programación necesaria para manipular los datos que residen en un fichero tiene que estar contenida en cada uno de los programas que acceden a él. Este requisito introduce complejidad al sistema por tener que conocer con exactitud la implementación física concreta de cada fichero para poder ser entendido y utilizado. Evolución de los modelos de bases de datos El modelo jerárquico Siguiendo con los modelos prerrelacionales, cuando la complejidad de los datos iba creciendo, se requería nuevo software que los ficheros clásicos no soportaban. Aparecieron productos como el IDS construido para General Electric o el más moderno IMS de IBM (1966) que se considera el primer SGBD contruido para la aeronáutica. El contenedor que almacena los datos se llama base de datos que contiene los datos de todas las instancias de un conjunto de entidades relacionadas. Estas entidades se estructuran entre sí de manera jerárquica o en árbol, siendo la base de datos total una colección de árboles, uno por cada instancia de la entidad principal; cada instancia de árbol contiene una instancia de entidad principal y todas las instancias de entidades dependientes relacionadas con la principal, y cada nodo del árbol es una colección de campos, uno por cada atributo de la entidad que este nodo almacena. Aparece la figura del administrador de bases de datos, para gestionar la implementación física de las bases de datos jerárquicas y decidir entre diferentes opciones cuando esto es posible. Este modelo supuso un avance, dado que lo soportaba un verdadero SGBD, porque hay una separación de niveles (nivel exterior jerárquico para programadores y nivel interior, el de la implementación para el administrador). Los modelos en red Aún así, el modelo anterior no modeliza todas las posibilidades, en especial cuando existe una relación entre entidades de muchos a muchos (muy frecuente)

2 2 Sistemas de gestión de bases de datos solo podía representarse introduciendo redundancia de datos. El modelo de tados BOM (bill of materials pues relacionaba materiales y estructuras ya fabricadas) si cumplía este requisito de relación. El modelo en red o modelo CODASYL, determina el set como pieza fundamental para construir un diseño de bases de datos. El set está constituido por dos entidades, el propietario y el miembro, ligadas por una relación de uno a muchos. El set permite al usuario desplazarse de una instancia de propietario a todas las instancias de sus miembros, así como de una instancia de miembro a la instancia de su propietario. La entidad propietario de un set puede ser propietaria de otros sets y/o miembro de otros sets, y la entidad miembro puede ser propietaria de otros sets y/o miembro de otros sets. Así tenemos una verdadera red de entidades. El modelo relacional En el modelo relacional los elementos estructurales son las relaciones, las tuplas y los atributos, popularizados enseguida como tablas, filas y campos. Sobre dichos elementos se definen un conjunto de operaciones (álgebra relacional) y se define un lenguaje declarativo (SQL) para su manipulación. Características como la clave primaria, la clave foránea y el hecho de que el orden de las tuplas dentro de una relación y el orden de los atributos son irrelevantes, caracterizan también a este modelo. Así que los elementos son identificados por apuntares simbólicos (nombres y variables) sin ningún apuntador físico u orden establecido. El uso coloquial mediante tablas, filas y campos preveía que los SGBD se encontrarían también al alcance de usuarios no informáticos, que podrían acceder más fácilmente a los datos almacenados. Aun así, tardaron 10 años en aparecer los primeros SGBD comerciales (1981) de la mano de Oracle y, posteriormente de IBM. Modelos semánticos Los modelos semánticos incorporan el concepto de dominio, bueno de hecho, el modelo relacional también lo hace, pero soporta un número reducido de ellos (enteros, decimales, caracteres, boléanos ); en el modelo semántico se potencia más y se definen las operaciones posibles con cada uno de ellos (así un campo número de teléfono no se permitirá que se use como operación matemática a pesar de ser un entero como puede ser el campo dinero pero que sí tiene sentido que se pueda operar con este último). Ofrece también conceptos de instanciaciónclasificación, de generalización-especialización, de agregación-descomposición, etc. Bases de datos orientadas a objetos El concepto objeto es la asunción de la representación de la complejidad en el largo comino de modelizar la realidad de los datos. Así y al igual que en lenguaje orientado a objetos, aparecen los conceptos de objeto y clase de objeto y existen varias posibilidades de interrelacionar clases de objetos, como la herencia. Eso sí, existió una dicotomía al principio de la década de los 90. La discusión se centraba en si dotar a los lenguajes relacionales existentes de soporte a objetos o, por el contrario, iniciar unos nuevos sistemas de bases de datos orientadas a objetos partiendo de los lenguajes orientado a objetos y olvidando todo el trabajo realizado hasta ahora. Siguiendo esta última tendencia aparecerían las bases de datos orientadas a objetos denominadas puras, pero la tendencia actual es el de dotar a los sistemas actuales de soporte a objetos, dado que durante muchos años han demostrado su buen hacer y porque desde luego, es más rentable para las empresas de software que cuentan mucho en la industria informática: es lo que ha dado en llamarse modelo relacional extendido.

3 Sistemas de gestión de bases de datos 3 2. ARQUITECTURA FUNCIONAL DE UN SGBD El procesamiento de una sentencia SQL es la siguiente: Arquitectura funcional de un SGBD Seguridad: se verifica en primer lugar que el usuario que ha pedido la ejecución de una sentencia, esté autorizado para realizar dicho tipo de sentencia. Procesamiento de vistas: las referencias a vistas son sustituidas por las referencias equivalentes a tablas, con lo que la sentencia queda más homogénea. Integridad: Claves primarias y foráneas, así como las restricciones que pudiera haber solo columnas y tablas son estudiadas para la sentencia a realizar, en busca de que no rompa la integridad de datos del sistema. Optimización: Como las operaciones a ejecutar una vez descompuestas pueden realizarse en distinto orden, el proceso de optimización se encarga de escoger, en cada una de las transformaciones, la mejor combinación posible de operaciones procedimentales. Control de concurrencia: Hay que evitar que la operación que se va a realizar no entre en conflicto con otra operación que también se esté ejecutando. Recuperación: Hay que tomar nota antes de cualquier lectura o escritura de un dato, ya que en fallos posteriores del sistema, tendremos un diario de operaciones y con éste, la posibilidad de recuperarlas. Memoria intermedia: En ella se guardan los datos a los cuales se ha accedido recientemente, pues la probabilidad de volver a acceder inmediatamente es alta y se ahorrar así muchas operaciones físicas de entrada y salida, ya que el gestor de memoria intermedia va físicamente a los datos sólo cuando es necesario.

4 4 Sistemas de gestión de bases de datos TEMA 2 DISEÑO CONCEPTUAL Y LÓGICO DE BASES DE DATOS 1. DISEÑO DE BASES DE DATOS Las etapas del diseño de bases de datos son: 1. Captura y abstracción de los requerimientos de los usuarios: Mediante entrevistas con todos los miembros de la empresa hay que conseguir una instantánea o fotografía de la misma, para concretas las especificaciones y requerimientos. 2. Esquema conceptual: Con la ayuda de un modelo semántico conveniente elaboramos un esquema conceptual, nosotros elegiremos el modelo UML, pero hay que reconocer que este esquema puede variar con el estado de la tecnología. Ya existen actualmente modelos más potentes, pero como después tenemos que elaborar un modelo lógico partiendo de este conceptual y actualmente los modelos lógicos van muy por detrás de los primeros, no es conveniente realizar el modelo conceptual más potente y detallado que podamos y luego esperar que los modelos lógicos y físicos implementen lo que puedan. EN el futuro a medida que las implementaciones de SGBD sean más finas o completas, quizás tendremos que cambiar nuestra elección de UML por otros modelos semánticos más elaborados. 3. Transformación a modelo lógico: Transformamos el modelo conceptual obtenido en el apartado anterior en UML por el modelo lógico que en nuestro caso consistirá en sentencias estándar AQL. 4. Aplicar la teoría de la normalización: Si procede, normalizaremos (lo veremos en el siguiente capítulo) y en nuestro, por el tipo de modelo elegido, sí procede. 5. Acomodación al SGBD del que disponemos: Construiremos el modelo físico adaptándolo al SGBD del que disponemos. 6. Cuantificación de volúmenes de datos y frecuencias de procesos: Aquí finaliza la parte pesada y esencial del diseño de bases de datos, pero queda el afinamiento, un ajuste que no es en absoluto poco importante. Tenemos que detectar si hay grandes volúmenes de datos a los que aplicar entonces técnicas de fragmentación; también debemos detectar posibles procesos críticos. 7. Desnormalización, tiempo de respuesta, integridad, seguridad, concurrencia, recuperaciones: Todos estos conceptos debemos tratarlos a fondo. Los dos primeros están muy relacionados, pero además debemos dar integridad a la base de datos (buenas restricciones), seguridad, concurrencia (adecuado nivel de aislamiento), etc. 8. Ajuste de las estructuras físicas de almacenamiento y parámetros del sistema: Cada SGBD tiene unos ajustes internos y admite diferentes formas de almacenamiento de estructuras físicas, por lo que debemos introducir los parámetros más adecuados a cada caso; y esto solo se puede realizar con una lectura atenta de los manuales del administrador de base de datos, con mucha experiencia y con pruebas repetidas y experimentación. 9. Control de rendimientos: Ya hay muchas herramientas visuales que monitorizan y nos dan todo tipo de histogramas del rendimiento de la base de datos. 10. Informe final del diseñador: Hay que escribir un informe contando todo lo que se ha hecho: esquemas conceptual y lógico y físico, redundancias deseadas, agrupaciones, etc. Tema 2 Diseño conceptual y lógico de bases de datos 1. Diseño de bases de datos 2. Normalización en bases de datos relacionales Hay que tener en cuenta que estas 10 etapas no son lineales; por frecuentes cambios es fácil tener que volver por ejemplo de la etapa 3 a la 1 para aplicar ciertos cambios, es la retroacción y es una característica muy importante en el comportamiento de los diseñadores. Sobre los modelos lógico y físico hay que decir que los modelos de bases de datos, en abstracto, definirán lo que hemos llamado modelo lógico, representado

5 Sistemas de gestión de bases de datos 5 generalmente por un estándar. Estos modelos más representativos del mercado son 3: Implementaciones del modelo relacional clásico: que suponen el 80% de cuota del mercado actual. Implementaciones de las bases de datos puras orientadas a objetos, que representan una cuota del 3 al 5% y parece que no aumenta. Implementaciones de las bases de datos relacional con objetos: actualmente un 10 a 15% de cuota pero en constante aumento, como Oracle 8, Informix 9, etc. Esto implica que en el futuro podemos decantarnos por escoger como modelo lógico el relacional con objetos y, en consecuencia, como modelo físico el correspondiente a sus implementaciones físicas (Oracle, Informix ). Por último, decir que las alternativas de diseño que hemos elegido, puesto que algunas decisiones debemos tomar, son las siguientes: Hemos elegido como modelo conceptual el UML, y como modelo lógico el relacional clásico, y por tanto como modelos físico el estándar SQL:1999. No es lo mismo diseñar un sistema de información nuevo partiendo desde cero, que diseñar un sistema para una empresa que resulta de la absorción o fusión de varias. 2. NORMALIZACIÓN EN BASES DE DATOS RELACIONALES Tabla Suministros Antes de conocer los 6 grados y formas de normalización, debemos conocer el concepto de dependencia funcional que si no es bien entendido, provoca anomalías de diseño. Básicamente una dependencia funcional en una tupla de una base de datos es cuando uno o más campos de la base de datos, determinan unívocamente otro u otros campos de la tupla, provocándose en este caso redundancias. Así en la tabla/tupla lateral denominada Suministros, encontramos las siguientes dependencias funcionales: {CodigoProv, CodigoArticulo} {Cantidad} {CodigoProv, CodigoArticulo} {CiudadProv} {CodigoProv} {CiudadProv} Estas relaciones de dependencias, también podemos anotarlas así: Las dos primeras relaciones de dependencia se explican porque las claves que la provocan son las claves primarias de la tabla, por ello es lógico que así sean, pero no así la última; es obvio que siempre que aparezca 1 en el código de la provincia, ésta va a ser Jerez. Ojo, que hemos llegado a este análisis al ver los descriptores de la tupla (los nombres de los campos) y analizando los datos que lo contienen, hay que tener cuidado para no tomar tampoco decisiones a la ligera. Como decíamos, la última dependencia nos provoca anomalías de diseño: Anomalías de modificación: Cada vez que un proveedor cambie de provincia (por ejemplo el de Jerez cambia a Ceuta) debo en la tabla hacer tantas modificaciones como veces aparezca, en este caso 2, y tener cuidado de no dejarme ninguna, pues dejaría la tabla inconsistente. Anomalías de borrado: Si un proveedor que sólo suministra un producto deja de hacerlo y lo borramos de la tupla, se perderán sus datos (código de proveedor y ciudad), con lo que perdemos datos elementales sin querer. Anomalías de inserción: No podemos almacenar los datos básicos de un proveedor como el código de provincia y su ciudad si no sabemos los artículos que suministra, son datos independientes que como se hayan juntos en la misma tupla, debemos respetar.

6 6 Sistemas de gestión de bases de datos Este problema se debe a que la tupla suministros describe dos hechos elementales del mundo real distintos y además independientes: por un lado los artículos que suministra cada proveedor y, por otro, los datos del proveedor en sí mismos. Esto lo pretende resolver la teoría de la normalización: toda relación tiene que describir un concepto semántico único. Cada forma normal del círculo lateral es más restrictiva que la anterior, es decir la 3FN cumple todas las restricciones de la 2FN más algunas nuevas. Cuando una relación no está ni siquiera en 1FN se dice que está en NF 2 (non first normal form). Grados de las formas normales Primera formal normal (1FN) Todo atributo de la relación es atómico, no descomponible y no es un grupo repetitivo. Así en la relación suministros lateral, los atributos código articulo y cantidad no son atómicos. Para que así lo fueran deberían ser como la imagen que teníamos en la página anterior. Cualquier modelo relacional siempre garantiza que las relaciones estén en 1FN dado que sólo hay una estructura para representar los dados, y cada uno de ellos se representa uniformemente mediante valores atómicos. Por tanto, esta relación lateral estaría en NF 2. Tabla Suministros en NF 2 Segunda forma normal (2FN) La relación se encuentra en 1FN y todo atributo no clave depende funcionalmente en forma completa de la clave primaria (hay una excepción y es que un atributo puede depender funcionalmente de parte de la clave primaria si dicho atributo es parte de una clave alternativa). Es obvio que aquellas relaciones con clave primaria simple siempre estarán en 2FN, sólo se puede violar esta 2FN cuando la clave primaria es compuesta, como en el ejemplo de suministros: La idea es clara, si un subconjunto no clave depende funcionalmente de un subconjunto propio de la clave, es porque representa un hecho de este subconjunto propio y, por lo tanto, la solución está en separarlos en dos relaciones diferentes de la siguiente forma: Tercera forma normal (3FN) Similar a la 2FN pero involucrando atributos no claves, es decir, una relación está en 3FN si se encuentra en 2FN y además ningún atributo no clave depende funcionalmente de ningún otro conjunto de atributos no clave. Por cierto, la excepción aplicada en la 2FN también se aplica a la 3FN. Así en esta relación, encontramos que hay una dependencia funcional entre ciudad y provincia de las que ninguna son clave. De nuevo, la solución es proyectar dos relaciones diferentes: Forma normal de Boyce-Codd (FNBC)

7 Sistemas de gestión de bases de datos 7 Tabla Notas La relación anterior se encuentra en 3FN; a pesar de que parece incumplir la 2FN por la relación de dependencia entre DNIAlumno y CódigoMatricula, pero al ser ésta última parte de una clave alternativa (CodigoAsignatura, CodigoMatricula) se aplica la excepción y lo mismo con la excepción a 3FN por la relación de dependencia entre CodigoMatricula y DNIAlumno pues forma parte de una clave alternativa. No obstante, si analizamos la tabla notas lateral, vemos que puede estar plagada de errores. Hay redundancias (por cada asignatura en que se matricule cada alumno, se repite su código de matricula) y anomalías de modificación (como en el ejemplo al modificar el código de matrícula de un alumno). El origen del problema es histórico, pues cuando Codd enunció la 2FN y 3FN en 1970, no consideró la posibilidad de que en una relación pudiera haber varias claves candidatas que fueran compuestas, ni tampoco que entre estas pudieran haber solapamientos. Pues bien, una relación está en FNBC si está en 1FN y todos los determinantes son clave candidata de la relación. Un determinante son los orígenes de la flecha, y en el ejemplo que nos ocupa, si analizamos todas las relaciones posibles: 4 soluciones para normalizar en FNBC encontramos como determinantes: DNIAlumno, DNIAlumno- CodigoAsignatura, CodigoMatricula, CodigoAsignatura-CodigoMatricula y como claves candidatas tenemos: DNIAlumno-CodigoAsignatura y CodigoAsignatura-CodigoMatricula. Como no se cumple que todos los determinantes son clave candidata debemos solucionar las relaciones DNIAlumnoCodigoMatricula y CodigoMatriculaDNIAlumno. Cualquiera de las 4 soluciones con 2 relaciones cada una de ellas de la figura lateral serían válidas para este ejemplo. Las más lógicas desde el punto de vista del centro académico serían la primera o la segunda, y de entre estas dos, nos quedaríamos con la segunda, pues pueden existir alumnos extranjeros que no dispongan de DNI o, lo que es peor, que se repita con alguno de los que ya tenemos matriculados. Hemos de pensar que toda relación se puede normalizar hasta este nivel, aunque el proceso de normalización no es único, aunque eso sí, la solución siempre es satisfactoria. Como consecuencia del proceso de normalización evitamos redundancias y anomalías ya que separamos hechos semánticamente diferentes. Cuarta forma normal (4FN) Hasta ahora las relaciones que hemos visto eran de hechos monovaluados, la 4FN y la 5FN están relacionadas con hechos multivaluados. En el ejemplo que encontramos en la página siguiente se establece la relación ConoceProgr, cuando un empleado codificado mediante su DNI (clave primaria) conoce determinados lenguajes de programación y determinados idiomas hablados y escritos. Si normalizamos la primera tabla que encontramos en la segunda relación nos podemos llegar a preguntar si existen redundancias, a pesar de que cumplen la FNBC y por supuesto, todas las anteriores. Cualquier inclusión de otro lenguaje de programación nuevo que aprendiera un empleado o lengua hablada, nos haría tener que repetir varias inclusiones en la relación para que quedara completamente registrado. El origen de estas anomalías radica en que esta relación recoge dos hechos multivaluados: por un lado los lenguajes de programación que el usuario conoce, y por otro los idiomas que domina, y como estos dos hechos son independientes entre sí (un lenguaje de programación no determina conocer un idioma y viceversa). Así que una relación se encontrará en

8 8 Sistemas de gestión de bases de datos Relación ConoceProg 4FN si se encuentra en FNBC y además no tiene dependencias multivaluadas independientes. Así, el estado inicial yla solución propuesta son las siguientes: Quinta forma normal (5FN) Hay relaciones en las que a pesar de que presentan redundancias en sus contenidos, no se puede aplicar el proceso de reducción a dos relaciones que hemos visto anteriormente, y esto se debe a que no existen todas las posibles combinaciones. Un ejemplo, para la siguiente tabla: Si descomponemos en cualquiera de las tres posibilidades existentes: (Profesor, Asignatura) (Asignatura, Centro) (Profesor, Asignatura) (Profesor, Centro) (Asignatura, Centro) (Profesor, Centro) Acabamos perdiendo información, en primer lugar no sabemos que profesores están asignados a cada centro; en el segundo caso desconocemos qué asignaturas se imparten en cada centro y en el último no podemos saber qué asignaturas imparte cada profesor. Este problema tiene lugar porque la relación ProfesorAsignaturaCentro aunque representa hechos multivaluados, estos son dependientes entre sí (y no como el caso anterior, dado un programador, los idiomas y lenguajes de programación que conocía quedaban perfectamente determinados por sus posibles combinaciones, ahora no). Ahora bien, podemos encontrar una ley de simetría, que en nuestro caso es la siguiente: Si un profesor imparte una asignatura y La asignatura se imparte en un centro y En este centro trabaja el profesor Entonces El profesor imparte la asignatura en el centro. A esta dependencia se le denomina dependencia de proyeccióncombinación, dado que la relación original se puede reconstruir a partir de la combinación de las nuevas relaciones en las que la relación se ha descompuesto: ProfAsigCentro = (ProfAsig * AsigCentro) * ProfCentro Pero hay que tener mucho cuidado, dado que puede haber dos tipos de estas dependencias:

9 Sistemas de gestión de bases de datos 9 Dependencias de proyección-combinación sin variación: Es el caso que hemos tratado hasta ahora porque cumplía la ley de simetría que habíamos establecido. En estos casos si existe este tipo de dependencia, la relación sólo estará en 5FN si la hemos descompuesto en las relaciones que la componen. Dependencias de proyección-combinación con variación: En este caso no es posible la descomposición porque ya no se puede volver a reconstruir y darnos el mismo resultado. Si por ejemplo, a la relación de profesores de ejemplo le eliminamos el valor <Garcia, Algebra, FIB>, y descomponemos en sus 3 relaciones y volvemos a componerlas, nos aparecerá ese valor que hemos eliminado. Esto sucede así porque la ley de simetría de la que partíamos no se cumple para la relación original, es decir, ya no es cierto que cuando un profesor imparte una asignatura (Algebra) y ésta se imparte en un centro (FIB y FME), y ese profesor pertenece a ese centro (FIB y FME) ese profesor imparta la asignatura en ese centro (sí en el caso de FME pero no para Algebra en FIB). Queda claro entonces que el proceso para determinar cuando un hecho multivaluado está en 4FN o en 5FN no es directo, aunque estas relaciones se pueden considerar como casos patológicos que raramente aparecen en la práctica. Lo que sí queda claro es que una relación solo puede violar las formas normales 4FN ó 5FN si su clave primaria está formada como mínimo por 3 atributos (relación ternaria como mínimo) y que una relación que está en forma 5FN puede presentar repeticiones en su contenido, pero éstas son inevitables y no debemos considerarlas redundantes. En definitiva, la normalización es útil para comprobar aspectos semánticos difíciles, pero pocas veces es necesaria, dado que habitualmente podemos distinguir los hechos independientes. Hay veces que conviene aplicar justo lo contrario, la desnormalización, dado que hay que tener en cuenta que la normalización penaliza la recuperación o consulta de los datos porque exige operaciones de combinación en distintas tuplas para recuperar datos que originalmente estaban juntos en la misma; cuando los atributos de una relación que representan otro concepto semántico no se actualizan frecuentemente, quizás resulte conveniente utilizar la desnormalización. Las bases de datos relacionales con objetos incorporan relaciones que están en NF 2, para la teoría actual, dado que hay que desarrollar otra teoría de la normalización específica para ellas.

10 10 Sistemas de gestión de bases de datos TEMA 3 RECONSIDERECIÓN DE LOS MODELOS CONCEPTUAL Y LÓGICO 1. TRAMPAS DE DISEÑO Cinco trampas de diseño son las que con más facilidad de cometes, con distintos ejemplos vamos a tratar de desenmarañarlas: Abanico Para esta primera trampa de diseño (y para la segunda) tendremos el mismo ejemplo que vemos en la figura lateral: la organización de profesores en una Universidad, en la que existen divisiones, a éstas pertenecen departamentos y a ella profesores, con asociaciones 1 a N como se pueden ver. El diseño correcto es el primero de la imagen de 3, pero la segunda imagen es el error en abanico, que se da cuando tenemos dos asociaciones con cardinalidad 1 a N; puesto que se han seleccionado las asociaciones incorrectas y aunque a priori parece que no perdamos información no es cierto, dado que no sabemos como quedan asociadas. Así para un profesor determinado podemos desconocer a que departamento pertenece, pues una consulta a la base de datos para el profesor 1, nos devolverá los departamentos 1 y 2. Este error se debe a no haber modelado correctamente las asociaciones y habernos alejado de la realidad. Organización correcta Error de abanico Error de corte Tema 3 Reconsideración de los modelos conceptual y lógico 1. Trampas de diseño 2. Consideraciones en el paso a modelo lógico 3. Representación en el modelo lógico de la generalización/especialización 4. Representación de atributos instanciados en diferentes valores 5. Abrazos mortales de definición y de carga 6. Sustituos de la clave primaria 7. Frecuencia de procesos y volúmenes de datos 8. Redundancia de datos: duplicados y derivador 9. Históricos Corte Es una trampa parecida a la anterior pero un poco más sutil. Podemos verla en la tercera figura de la imagen lateral, aunque a priori no hay pérdida de información y podemos realizar todas las consultas pertinentes, puede ocurrir que si un departamento se quedase temporalmente sin profesores, perderíamos la asociación divisiones/departamentos. Es decir, al borrar instancias de la clase central, las asociaciones entre instancias de las clases que hay en los extremos pueden quedar cortadas. Pérdida de afiliación Se podría definir como una equivocación en doble abanico. Una instancia de la clase central puede estar relacionada con todo un abanico de instancias en cada una de las otras dos clases, así sólo podemos decir que una instancia de la clase central puede estar relacionada con algunas de las instancias en abanico, pero no podemos concretar cuales. Lo vemos con el ejemplo de la imagen lateral, Al realizar el diseño de la base de datos entre proveedores, piezas y clientes, no podemos decidir de que proveedor son las piezas que ha comprado determinado cliente, y viceversa. La solución a esta pérdida de afiliación la vemos desarrollada en la misma figura, en la parte inferior, se trata de una asociación ternaria denominada suministros. Aridad de las asociaciones En general, hay que prestar mucha atención a las asociaciones que involucran más de dos clases, y alguna de ellas tiene multiplicidad igual a 1. En tales casos, puede que esta clase realmente esté relacionada sólo con una de las otras clases y no deba participar en la asociación, nos tenemos que fijar muy especialmente en la razón por la cual está el 1. Error pérdida de afiliación Solución: asociación ternaria

11 Sistemas de gestión de bases de datos 11 Error de aridad en las asociaciones Una de las posibles soluciones Así, por ejemplo tenemos un diseño erróneo en el que para empezar no sabemos que nombre darle, eso ya es un mal síntoma. Si estudiamos la relación ternaria nos damos cuenta que no está ni en 2FN y es que el diseño es completamente incorrecto, siendo el adecuado el que vemos justo bajo él; otra solución a otros casos es tratar la clase con aridad 1 como atributo de la asociación y no como una clase que participa en la asociación. Semántica de las clases Es importante modelizar en las asociaciones el significado real de los elementos de nuestro diseño; así hay que prestar especial atención al significado real que tiene lo que se quiere representar y no dejarnos llevar por lo que pueda parecer a primera vista. Por ejemplo en una base de datos con departamentos que tienen sedes distintas, y en las que cada departamento puede tener varias sedes, el tributo superficie no puede situarse en el departamento, sino en cada una de las sedes 2. CONSIDERACIONES EN EL PASO A MODELO LÓGICO Comprobación de instancias Desaparición de tablas correspondientes a clases: Si una clase aparece en nuestro modelo conceptual es porque realmente nos interesa que esté y, por lo tanto, ya esta bien que esté, pero nos tenemos que plantear si tiene suficiente importancia para dar lugar a una tabla de la base de datos, especialmente si no tiene ningún atributo que forme parte de la clave primaria. Un ejemplo: En una empresa con 4 almacenes tenemos una tabla almacenes con su AlmacId y otra tabla Piezas con PiezaId; esto nos sirve para relacionar el stock existente en cada moemnte Stock (almacid, piezaid, stock). Solo es posible suprimir una tabla si no guarda ningún atributo y las posibles comprobaciones de integridad se hacen de alguna otra manera. Las claves foráneas por tanto, son muy importantes para la integridad de nuestra base de datos. Comprobación de instancias: Una vez acabado el diseño debemos cerciorarnos de que funciona como realmente queremos que lo haga y modeliza correctamente la realidad. Así en los ejemplos laterales observamos como las instancias que encontramos en la base de datos no se corresponden al esquema que hemos diseñado. Las instancias, eso sí, pueden ayudarnos a encontrar errores, pero nunca nos han de conducir al diseño, esto lo tiene que hacer la semántica de los datos. Atributos de asociaciones: En general, las asociaciones binarias N:M suelen tener atributos, mientras que las de multiplicidad 1:1 ó 1:N no. Si la asociación es 1:N es posible que el atributo pertenezca a clase del lado N, mientras que si la asociación es 1:1 podría pertenecer a cualquiera de las dos. Restricciones de integridad: Tener datos erróneos puede ser incluso peor que no tenerlos, y las restricciones de integridad ayudan a controlar la existencia de errores. En el diseño, no se tiene que descuidar su importancia, y sobre todo, no las tenemos que olvidar en el momento en que este diseño se implemente sobre un SGBD. Para implementar estas restricciones los sistemas actuales nos ofrecen distintas sentencias restrictivas en la creación de tablas (unique, not null, check); el SQL/PSM permite definir disparadores, procedimientos, funciones y paquetes; SQL Host permite incluir sentencias SQL incluso en Java para hacer llamadas; y SQL/CLI tiene librerías de funciones para lo mismo. Sustitución: Si las restricciones de integridad ralentizan el sistema, a veces se hace necesario liberar al SGBD de este trabajo para poder ofrecer un rendimiento adecuado; en este caso debemos tener algún tipo de control externo o, mejor aún, un control diferido por ejemplo que pueda hacer todas las comprobaciones en horas de menos actividad (noches, fines de semana ).

12 12 Sistemas de gestión de bases de datos 3. REPRESENTACIÓN DE GENERALIZACIÓN/ESPECIALIZACIÓN Existe una especialización disjunta si ninguna instancia de la superclase (A) está en más de una subclase (B, C ó D); y una especialización completa si toda instancia de la superclase está, al menos, en una de las subclases. Estos dos parámetros son fundamentales a la hora de decidirnos por cualquiera de las 3 alternativas que encontramos. La primera alternativa consiste en una tabla para cada una de las clases, donde la superclase contiene los atributos comunes y las tablas de las subclases los específicos a cada uno. Ésta suele ser normalmente la mejor opción, porque es la más flexible y la que se encuentra más cercana al diseño conceptual. La segunda alternativa nos propone una tabla con todos los atributos de todas las clases; interesa si hay pocos atributos y no vamos a tener muchos valores nulos, es decir, interesa cuando la especialización no es disjunta y es completa. La tercera opción consiste en diferentes tablas para cada subclase que guarden también las columnas correspondientes a los atributos de la superclase. Sólo interesa esta alternativa cuando la especialización es disjunta y completa. Generalización/Especialización 4. REPRESENTACIÓN DE ATRIBUTOS INSTANCIADOS EN DIFERENTES VALORES Es relativamente habitual encontrar atributos instanciados en varios valores al mismo tiempo, pero como sabemos la 1FN obliga a que estos atributos sean atómicos. Si por ejemplo queremos guardar en una base de datos distintas medidas para un aparato distinto aplicado a elementos diferentes, tenemos sólo dos opciones: Guardar cada valor en una columna distinta de la tabla: Medida (clave, valor1, valor2,, valorn), Si escogemos esta opción el número de valores (n) no debería ser muy grande y corremos el riesgo de tener muchos valores vacios. Tener una fila diferente para cada valor: Medida (clave, aparato, valor). Así si el valor no está no es necesario guardar ninguna fila. La clave cambia y es menos natural. Con la primera opción accedemos a los valores de un solo golpe, con esta última sólo accedemos de manera sencilla a algunos valores seleccionados. El tratamiento de los atributos también es importante, porque funciones de agregación como SUM, AVG se aplican al agrupar filas, pero no columnas. 5. ABRAZOS MORTALES DE DEFINICIÓN Y CARGA Tenemos dos tipos de abrazos mortales, al intentar crear tablas (de definición) y al insertar datos (de carga). Los abrazos mortales de definición tienen lugar cuando queremos crear dos tablas con claves foráneas la una a la otra, lógicamente como la primera no está creada, la segunda no puede referenciarla y viceversa. Por ejemplo queremos crear la tabla departamento y la tabla empleados, y uno de los empleados tiene que ser el jefe del departamento; si creamos primero la tabla departamento no podemos referenciar al jefe dentro de los empleados porque no está creada, si creamos primero la de empleados no podemos referenciar a qué departamento pertenecen por la misma razón, la tabla a referenciar todavía no existe. Hay dos soluciones: O bien creamos una tercera tabla independiente, que nos sirva para referenciarlas. Por ejemplo, creamos la tabla departamentos con su DeptId,

13 Sistemas de gestión de bases de datos 13 Solución creando una tercera tabla seguidamente la tabla empleados con clave foránea a esa tabla departamentos y en tercer lugar la tabla Jefe que hace referencia a las dos primeras. Esta otra solución la proponen algunos SGBD en sus manuales, y consiste en crear una de las dos tablas sin clave foránea, luego la segunda, y luego volvemos a la primera y la modificamos incluyendo la clave foránea que habíamos omitido. Desde luego es una solución, pero nos encontraremos al insertar datos posteriormente con el abrazo mortal de carga. El abrazo mortal de carga sucede al intentar cargar datos en el caso de que optemos por la segunda solución anterior; si insertamos primero en una tabla violamos la restricción de integridad, pero lo mismo ocurre si lo hacemos en la segunda, al referenciar un objeto que todavía no existe en la otra tabla. También hay dos soluciones posibles, por un lado desactivar las restricciones de integridad de alguna de las tablas, lo cual engendra un grave peligro pues cualquier proceso de otro usuario puede modificar la base de datos y dejarla inconsistente. Una solución mucho mejor consiste en aplazar o diferir la comprobación de las restricciones hasta el final de la transacción, momento en el cual ya tendremos todas las instancias creadas en las dos tablas y cumpliremos las restricciones de integridad. No obstante es mejor evitar todas estas desactivaciones o aplazamientos en las restricciones diseñando la solución con la tercera tabla, pero si tenemos una base de datos ya creada no quedará más remedio que poner en práctica estas soluciones. 6. SUSTITUTOS DE LA CLAVE PRIMARIA La clave primaria de una tabla siempre es motivo de problemas, hasta claves como el DNI que parecen únicos no lo son o no los posee toda la población, así que en muchas ocasiones tampoco sirven. Para crear claves consistentes y, por supuesto, únicas hay dos sistemas: Clave artificial de sistema: Son claves que se generan automáticamente y evitan que dos objetos en una misma tabla puedan tener la misma clave, lo cual las hace únicas pero ojo, dentro de una única tabla, no dentro de toda la base de datos. Con el tiempo han evolucionado a identificadores de objeto que no se repiten nunca para ningún otro objeto nuevo esté en esta tabla o en otra cualquiera. Clave artificial de usuario: Es el usuario el que define esta nueva clave. Ambos tipos de claves suelen ser contadores que se incrementan y no están concebidos para ser consultados, sino únicamente comparados con el objetivo de determinar la identidad de las instancias; las solemos utilizar cuando no hay una clave única consistente, o cuando la clave primaria requiere demasiados atributos para su creación. 7. FRECUENCIA DE PROCESOS Y VOLÚMENES DE DATOS Frecuencia de procesos Un punto esencial para un buen diseño de base de datos es considerar para qué se utilizarán y de qué forma, así podemos intentar favorecer los procesos que se realicen más frecuentemente. Encontramos dos tipos de procesos críticos: los que se ejecutan con gran frecuencia y los que tienen como requerimientos un tiempo de respuesta máximo determinado (como podría ser un sistema de tiempo real). Las soluciones para reducir el tiempo de respuesta de los procesos pasan por implementar algoritmos de búsqueda determinados que favorezcan ese tipo de búsqueda frecuente, y en

14 14 Sistemas de gestión de bases de datos general, realizar planes de ejecución de consultas para encontrar qué paso consume más tiempo y como lo podemos acortar. Volúmenes de datos Cuando los datos crecen y los volúmenes de las tablas son excesivos podemos fragmentarlas: Fragmentación horizontal: Dividirla por filas, las tablas que se crean tienen el mismo número de columnas pero menos filas. El criterio para esta división pueden ser por rangos de valores, un algoritmo de distribución aleatoria, una división por uso. Por ejemplo, este tipo de fragmentación se utiliza geográficamente cuando una gran empresa tiene distintas sedes y los clientes de cada sede se guardan en la tabla fragmentada de cada sede; así para consultar todos los clientes hay que hacer una join completa de las tablas fragmentadas que se encuentran incluso en países distintos. En cualquier caso lo que interesa habitualmente es que las tablas fragmentadas tengan aproximadamente el mismo número de filas. Fragmentación vertical: Ahora las nuevas tablas que se crean tienen menos columnas pero el mismo número de filas. Eso sí, las columnas que constituyen la clave primaria deben replicarse en todas las tablas. 8. REDUNDANCIA DE DATOS: DUPLICADOS Y DERIVADOS La duplicación de datos utiliza más espacio del necesario para almacenar la información y puede crear problemas de inconsistencias en la BD, al tener datos repetidos que debemos actualizar tantas veces como se encuentren duplicados. No obstante, puede evitar operaciones de combinación al no tener que buscar en distintas tablas datos dispersos (recordemos que la normalización obliga a crear nuevas tablas para evitar precisamente la redundancia de datos) y facilita al usuario la consulta del contenido de la base de datos; dado sus ventajas es un sistema que se utiliza, pero dado sus inconvenientes, de hacerlo, debemos documentarlo siempre para que todos los usuarios estén informados. Los datos derivados son otro tipo de datos que se pueden calcular fuera de tiempo, es decir, si un dato que es muy costoso de calcular y nos va a bloquear el SGBD durante un tiempo, se puede calcular en otros momentos previos y almacenarlos a la espera de la petición del usuario. Eso sí, si el dato cambio muy a menudo y sólo se consulta de vez en cuando, no es candidato a ser almacenado. 9. HISTÓRICOS Si queremos reflejar en la base de datos el paso del tiempo, no basta con guardar un único valor para cada dato, sino que tenemos que almacenar todos los valores que toma a lo largo del tiempo, junto con el tiempo de validez y transacción de cada valor. EN este caso, una modificación no sobrescribe los datos, sino que añade otros nuevos. Físicamente no borramos nada y las tablas crecen en cada operación; incluso el hecho de borrar una información añade datos, ya que realmente no borra, sino que registra el momento en que la información ha dejado de ser válida. Estos históricos ocupan muchísimo espacio en la base de datos y no queda más remedio que prever mecanismos de vaciado periódico, como pasar datos a cinta e incluso a papel. Aparte de problemas de espacio tenemos problemas con las restricciones de integridad. Con el paso del tiempo, el cambio de las leyes o incluso nuestros mismos criterios, algo que antes no era válido ahora sí lo va a ser y viceversa; lo cual cambia las reglas según el momento en que nos encontremos.

15 Sistemas de gestión de bases de datos 15 TEMA 4 EL COMPONENTE DE PROCESAMIENTO DE CONSULTAS Y SQL Tema 4 El componente de procesamiento de consultas y peticiones SQL 1. La seguridad 2. El procesamiento de vistas 3. El procesamiento de consultas 4. El control de concurrencia 1. LA SEGURIDAD El concepto seguridad integra distintos aspectos: Confidencialidad: Solo puede leerse la información por parte de los usuarios autorizados a ellos. Integridad: Debe protegerse la información de modificaciones no autorizadas. Disponibilidad. Las violaciones de las bases de datos consisten en la liberación incorrecta de la información, modificación impropia de los datos o denegación de servicios. A su vez las amenazas se pueden clasificar en: Amenazas no fraudulentas: Son accidentes casuales, como desastres naturales, errores en el hardware o software o errores humanos. Amenazas fraudulentas: Son violaciones intencionadas causadas por usuarios autorizados que abusan de sus privilegios o agentes hostiles. Los mecanismos básicos que vamos a estudiar de seguridad son la identificación y autenticación, el control de acceso, la integridad y consistencia y la auditoría. La identificación implica la mera en que un usuario proporciona su identidad al sistema, mientras que la autenticación es el proceso de asociar a un individuo con su identidad única. Los recursos de identificación suelen ser cosas que una persona conoce (contraseña), cosas que una persona posee (tarjeta o clave) o cosas que caracterizan a una persona (huella dactilar, pupila). Para validar o autenticar a un usuario podemos hacerlo mediante el propio SGBD, mediante el sistema operativo, por un servicio de red o por una capa intermedia. Se denomina control de acceso a la parte del SGBD que tiene la función de asegurar que los accesos al sistema estén de acuerdo con los modelos y las reglas fijados por la política de protección. Este control está formado por dos componentes: las políticas de acceso (principios según los cuales se autoriza, deniega o filtra el acceso a un usuario) y los mecanismos de seguridad (procedimientos para cumplir las políticas anteriores). Las distintas políticas se pueden clasificar en discrecionales o de acceso obligatorio. Se denominan políticas discrecionales a las basadas en el conocimiento de los derechos de cada usuario sobre cada objeto; así en una tabla usuario/objeto podemos definir roles a los que pertenece cada usuario y que le dan derecho o no a leer/escribir/borrar determinados objetos o vistas. Las políticas de acceso obligatorio se basan en la idea de que cada dato tiene un nivel de clasificación determinado y cada usuario un nivel de acreditación, para que un usuario pueda acceder a un dato debe tener un nivel de acreditación igual o superior al nivel de clasificación del dato en cuestión. El control de acceso discrecional en SQL se permite con las cláusulas GRANT<privilegios> TO <autorizados> a las que se añade WHIT GRANT OPTION (que permite pasarle los mismos privilegios a otros usuarios). Para revocar estos permisos usamos REVOKE <privilegios> TO <autorizados> seguido de RESTRICT o CASCADE, si queremos que los usuarios a los que el que vamos a quitar el permiso mantengan los permisos o no. La auditoría se utiliza normalmente para la investigación de una actividad sospechosa o para la monitorización y recogida de actividades específicas de la base de datos. El sistema debe ser capaz de auditar sentencias concretas, objetos

16 16 Sistemas de gestión de bases de datos concretos, sentencias sobre objetos (mezcla de las dos primeras) y a usuarios o grupos determinados. Algunos SGBD incorporan sentencias SQL que permiten generar una auditoría de manera declarativa. De no ser así, deberemos crear disparadores (triggers) para que realicen esta función y vayan llenando las tablas de auditoría conforme se producen acontecimientos registrables. La Ley Orgánica de Protección de Datos de Carácter Personal de 1999 establece 3 niveles de seguridad según el tipo de datos que se contengan: Nivel básico: Requiere medidas de autenticación y control de acceso a estos ficheros personales. Nivel medio: El administrador debe elaborar un catálogo sobre las medidas de seguridad genéricas y se deben implantar mecanismos seguros de autenticación remota. Nivel alto: Es necesario usar métodos criptográficos para evitar que los datos sensibles sean inteligibles, y los datos relativos a ideología, creencias, origen racial, salud, vida sexual, etc, son susceptibles de ser protegidos en este nivel. 2. EL PROCESAMIENTO DE VISTAS Las vistas son relaciones virtuales que sólo están representadas por su nombre y su definición; no existen físicamente en la base de datos sino que se crean en el momento que un usuario la utiliza. Por ejemplo se pueden crear la siguiente vista sobre una tabla departamento y una tabla empleado: CREATE VIEW Vista1 AS SELECT nombre, FechaAlta, salario, categorio FROM empleado WHERE categoría NOT IN ( Presidente, Directivo ) Hay dos estrategias fundamentales para implementar las vistas: reescribir la consulta o materializarse la vista. La más utilizada es la primera la reescritura, según la cual la consulta se repone de manera que haga referencia a las tablas de la base de datos. Con la materialización cuando se hace la consulta se crea una tabla temporal con el contenido físico de la vista. En el primer caso cuando se hacen varias consultas seguidas o una sola pero compleja sobre la vista, la consulta se vuelve muy ineficiente; con la materialización podemos hacer varias consultas sobre una misma tabla seguidas no teniendo así que crearla cada vez, pero su desventaja es que la actualización de la tabla temporal puede ser bastante costosa si cambian muchos datos en las tablas de las que se origina. Otro detalle importante de las vistas es la actualización. Una vista siempre puede consultarse, pero no siempre puede actualizarse, concretamente sólo es posible esta última acción si la vista está construida sobre una única tabla y los atributos de la vista contienen una clave candidata de la original; las vistas definidas sobre más de una tabla no suelen ser actualizables, y las vistas que incluyen cláusulas GROUP BY o funciones no agregadas nunca son actualizables. Para romper esta dificultad en la actualización de vistas, existen los llamados disparadores de sustitución, que se activan en lugar del mandato que ha provocado el disparo y siempre tienen que estar definidos a nivel de fila; estos disparadores permiten efectuar modificaciones sobre vistas que no son actualizables. Una ventaja más de las vistas es utilizarlas como elemento de diseño externo. SI tenemos varias aplicaciones que tienen que acceder a determinados datos de las tablas, en lugar de presentarles directamente las tablas, podemos crearles vistas particulares (si ya incluimos disparadores de sustitución mejor que mejor) y cada aplicación creerá tener una base de datos diseñada a medida.

17 Sistemas de gestión de bases de datos 17 Las tablas derivadas son tablas que tienen existencia física, ocupan por tanto lugar en la base de datos, pero se calculan a partir de las tablas básicas. Por ejemplo, en un supermercado podríamos crear la tabla derivada con las ventas por cada sección, esta tabla se crearía a partir de los códigos de los productos, el precio, las secciones, etc y no sería necesario crearla cada vez que hiciéramos una consulta; se supone que creamos esta tabla derivada porque la utilizamos mucho y no queremos calcularla cada vez que la necesitamos. Ahora bien, debemos decidir cuando se produce la actualización de esta tabla y de que forma: Tiempo de actualización: Puede ser ON COMMIT, es decir cada vez que se confirme una transacción que modifique alguna de las tablas maestras que dan lugar a la tabla derivada, u ON DEMAND, sólo cuando el usuario lo solicite. Forma de actualización: COMPLETE (completa), FAST (rápido, refresco incremental), FORCE (aplica el refresco rápido si es posible, y si no un refresco completo) o NEVER (nunca). Las tablas temporales son aquellas en las que el contenido tiene vigencia dentro de una sesión (o una transacción) y desaparece en el momento en que ésta finaliza. Son muy útiles para almacenar resultados intermedios de una transacción. En definitiva, las ventajas y desventajas de la utilización de vistas son las siguientes: Independencia de datos y de aplicaciones: al utilizar las vistas como interfaz de la aplicación, se llega a la independencia completa respecto a las tablas originales. Simplificación de uso para el usuario: Bien combinadas, las vistas nos permiten realizar consultas complejas de forma sencilla y transparente. Mejora de la seguridad: El usuario desconoce las tablas originales por lo que no puede tan siquiera intentar acceder a ellas. Integridad de los datos: con la cláusula WITH CHECK OPTION el usuario no puede llevar datos fuera de los límites que tiene marcados y los cambios que realice dejarán siempre la vista y, por tanto, las tablas, en estado consistente. Rendimiento: Podemos realizar caminos de acceso rápido a las consultas más frecuentemente realizadas. Como desventajas tenemos: Restricciones de actualización: No todas las vistas son actualizables y a menos que usemos disparadores de sustitución, no podemos hacer un diseño externo solo con vistas. Restricciones de estructura: Algunos SGBD siguiendo normas ISO no permiten construir vistas a partir de cualquier consulta. 3. EL PROCESAMIENTO DE CONSULTAS El procesamiento de consultas está formado por una serie de subprocesos (ver imagen en la página siguiente) de análisis, traducción y optimización que se ejecutarán de manera secuencial. Primero se comprueba la validez léxica (faltas de ortografía), después la validez semántica (si los objetos de los que se habla en la consulta son válidos o no), ya se hace entonces la primera optimización semántica; el resultado se transforma en la expresión relacional correspondiente, llamada plan de ejecución o árbol de consulta lógico. A partir del primer árbol empieza la optimización sintáctica, que consiste en transformar de modo heurístico la expresión relacional original en otra equivalente que sea mucho más eficiente; podemos entonces utilizar optimizadotes físicos basados en costes o heurísticos, y por fin se genera el código para la consulta.

18 18 Sistemas de gestión de bases de datos Por tanto, los pasos a seguir son los siguientes: Procesamiento de consultas Optimización semántica: Se accede al diccionario de datos y se comprueba que todas las columnas y tablas que aparecen en la consulta existen, y que el usuario tiene derecho sobre ellas. Se tienen por tanto en cuenta las leyes de la lógica y las restricciones de integridad propia de las tablas. Así por ejemplo si pedimos una consulta en la que los empleados tienen un salario > 400; y por restricciones de integridad en nuestra tabla todos los empleados tienen un salario por encima de 500, la consulta se convertirá en buscar todos los empleados; o por ejemplo buscar los empleados con sueldo >500 y a la vez sueldo <300 no llegaría a ejecutarse. Optimización sintáctica: Se tiene ahora que traducir la consulta a algún lenguaje interno lo bastante rico para representar cualquier tipo de consulta y lo bastante neutral para no predisponer a ninguna estrategia de implementación. Se transforma la consulta en SQL (no procedimental) a una consulta en álgebra relacional (procedimental). Normalmente el traductor genera un plan lógico correcto pero sin ningún tipo de mejora, normalmente o tenemos una serie de bloques conectados por conectores AND o por la disyuntiva OR. Por tanto interviene un nuevo factor: Planes de consulta lógicos equivalentes y métodos heurísticos: Hay muchas reglas para transformar una consulta relacional en otra equivalente, y en general hay una serie de reglas heurísticos (basado en aquello que suele pasar, aunque a veces, si nos salimos de la normalidad, da resultados impredecibles): o o o Primero hacer las operaciones de selección, pues reducen la cardinalidad del resultado intermedio. Si sobre una relación hay que aplicar más de una selección, se utilizarán propiedades conmutativas para conseguir llevarlas a cabo todas a la vez. Así estas operaciones de selección tienen que estar lo más abajo posible en el árbol del plan de consulta lógico. Después realizar las operaciones de proyección. Utilizar la asociatividad de operaciones binarias (combinación, unión, intersección) para elegir la operación que dé el resultado de cardinalidad más pequeño y realizarlo primero, de manera que la operación siguiente sea menos costosa de realizar. o Si hay una expresión común en distintas partes del árbol, realizar la operación una única vez. Implementación física de los operadores relacionales: Se tiene que transformar un plan lógico de consultas en un plan de consultas físico; y para estimar el coste de los algoritmos, es necesario que el SGBD guarde una información estadística de cada tabla (el número de filas, el número de filas que caben en una página, el número de páginas requeridas para guardar, y la medida en bytes de una fila de la tabla) y de cada atributo (número de valores distintos de cada atributo, valor más pequeño y valor más grande de cada atributo y cardinalidad de la selección del atributo es el número medio de filas que cumplen una condición de igualdad-). A cada operación física se le asigna un coste, y dado el abaratamiento del hardware hoy día, el coste principal será el tiempo. Así tenemos: o o Operaciones de ordenación: Si toda la tabla cabe en la memoria principal, el coste es mínimo, solo es necesario leerla y la ordenación se hace por cualquier método clásico. Cuando la tabla no cabe toda en la memoria principal, se acostumbra a utilizar un algoritmo de ordenación externa utilizando la memoria de forma temporal. Operaciones de selección: Se puede realizar una búsqueda lineal o una búsqueda binaria (se examina primero la posición central de la tabla en ficheros ordenados y a partir de ahí buscamos la posición central de la

19 Sistemas de gestión de bases de datos 19 mitad de la tabla en la que estará el dato, y así sucesivamente). Éste último caso permite aún en el pero de los entornos, una búsqueda 25 veces más rápida que la lineal. Ahora, si el atributo por el que buscamos es una clave candidata, todo será más rápido, o le podemos poner también un índice secundario si no es una clave candidata. o Operaciones de proyección: Involucra dos operaciones eliminar los atributos no deseados y eliminar las filas repetidas que se han generado, en caso de que existan claro. o Operaciones de combinación: Son las que más tiempo consumen durante el procesamiento de consultas y por lo tanto, marcarán la eficiencia global del SGBD. Hay varias opciones: combinación de ciclo anidado (para cada fila de una tabla exterior se obtienen todas las filas de la tabla interior y se comprueba cuáles cumplen la condición; en este caso es mejor que la tabla exterior se haga sobre la tabla más pequeña, da mejor resultado; combinación de ciclo anidado indexado (varía de la anterior en que en la tabla interior se va directamente a la página adecuada mediante un índice de acceso);combinación por ordenación por fusión (si las 2 tablas están ordenadas es la más eficiente, puesto que solo hay que leer de forma secuencial cada una de las tablas y añadir a los resultados aquellos valores que coincidan) y combinación por dispersión (se utiliza una función de asociación hash, para dividir las dilas de las dos tablas en conjuntos que tengan el mismo valor de la función de asociación, con lo que vemos que de la función depende el buen hacer de este método). Optimización física: Se dedica a hacer que los planes de consulta lógicos se lleven a cabo de la mejor manera posible. Existen dos grandes tipos de algoritmos de optimización que se pueden usar: optimización heurística y basada en costes. o o o Optimización física heurística: Se aplican una serie de recetas que normalmente dan buenos resultados y que en la mayoría de ellos permiten conseguir resultados satisfactorios. Su principal defecto es que a veces el plan propuesto difiere bastante del más óptimo. Como sabemos que hay operaciones más costosas y menos costosas, el SGBD tiene un orden de prioridades para la realización de cada una de ellas y, como decimos, en los casos más frecuentes, da buen resultado. Optimización basada en costes: Sólo hay que construir un conjunto con todos los posibles planes de ejecución físicos, calcular el coste de cada uno de ellos y escoger el de menor coste. Como vemos siempre tendremos el plan más óptimo, pero hay un problema: para calcular los costes de los distintos planes, hay que tener suficiente información sobre tablas, atributos, cardinalidades, que varían constantemente en la base de datos, y el tener esta información actualizada es fundamental. El encarrilamiento consiste en aprovechar la salida de una operación como entrada de otra, de forma que nos ahorramos la creación de resultados intermedios en disco (materialización) y se suele utilizar para ahorrar un tiempo precioso de escritura/lectura. También con el actual abaratamiento de las memorias, muchos optimizadores materializan las tablas intermedias directamente en la memoria, con lo que se consigue una eficacia parecida a la del encarrilamiento. 4. EL CONTROL DE CONCURRENCIA datos: Recordemos los problemas de concurrencia que teníamos en una base de Actualización perdida: Cuando una operación posterior cambia un dato que una operación anterior acababa de actualizar, pero ya se ha perdido porque estaban editando al mismo tiempo.

20 20 Sistemas de gestión de bases de datos Lectura no confirmada: Antes de que se confirme un dato, otra transacción ya ha leído esos datos que después han sido cancelados. Lectura no repetible: En la lectura del mismo dato, en dos ocasiones da diferentes resultados. Estos problemas lo solucionábamos con la seriabilidad: las diferentes transacciones se han de poder ejecutar de forma concurrente, pero su efecto final sobre los datos tendrá que ser el mismo que si se ejecutasen en serie. Los métodos que explicamos a continuación son optimistas, es decir, presuponen que hay muchos datos para leer y por tanto es difícil (aunque no imposible) que exista alguna incompatibilidad, en ese caso sólo en el momento de escribir se aseguran de que no hay tal incompatibilidad. Control de concurrencia basado en marcas temporales Consiste en asignar una marca temporal (MT(T)) antes de que se empiece a ejecutar una transacción T. Estas marcas son únicas y se asignan en orden ascendente, de manera que cualquier transacción posterior deberá cumplir que MT(T )>MT(T). Así por ejemplo, si una transacción T1 con M= quiere leer el elemento X pero otra transacción T2 con M=25000 lo ha escrito, debe deshacer su operación de lectura. En general, para que no se produzcan los problemas descritos anteriormente, el planificador podrá tomar cualquier petición de lectura o escritura por parte de una transacción y autorizar la petición, abortarla y recomenzarla con una nueva marca temporal o detenerla y, más tarde, decidir si la aborta o autoriza. Control de concurrencia por validaciones Es una implementación especial del caso anterior, en la que el planificador mantiene información sobre las transacciones. Para cada una guarda un conjunto de transacciones, un conjunto de lectura de transacciones con todos los datos de la BBDD que tendrá que leer y otro conjunto de escritura de transacciones con todos los que tendrá que escribir. Las transacciones tendrán 3 fases: Lectura: Se lee de la base de datos toda la información que falta, se hacen todos los cálculos y se guardan los resultados en la memoria. Validación: El planificador comprueba si puede escribir en la base de datos los resultados que tiene en la memoria sin producir problemas de incompatibilidades; compara los conjuntos de lectura y escritura con los de las transacciones actuales; si no hay problema pasamos a la siguiente fase, sino, reiniciamos la transacción. Escritura: Los resultados que se guardan en memoria se escriben en la base de datos. Control de concurrencia multiversión Las estrategias se basan en detener o deshacer la ejecución de la transacción iniciada que provoca problemas, ahora vamos a mantener varias versiones de los datos; cuando se vaya a escribir, el planificador debe saber cual es la versión adecuada. Existen a su vez dos sistemas: Control por marcas temporales: Este mecanismo es muy eficiente para sistemas con muchas más lecturas que escrituras. Se asignan además de las marcas temporales habituales, a cada elemento una secuencia de versiones formadas por el valor de la versión j del gránulo determinado, la marca temporal de la transacción que haya creado la versión y la mayor de las marcas temporales de todas las transacciones que han leído con éxito la versión j. Dependiendo de si tiene que leerse o escribirse hay un algoritmo: o Si la marca temporal de la transacción T es menor que la marca temporal de la transacción que ha creado esa versión, entonces se deshace la transacción T. o Si la marca de tiempo es igual, entonces se puede escribir el contenido de la versión.