BBDD1_2023-1-97.pdf

1983/2023 - 40 AÑOS DE DEMOCRACIA BASE DE DATOS I Profesor: Jorge Insfran Año: 2023 1 1983/2023 - 40 AÑOS DE DEMOCRACIA UNIDAD 01 INTRODUCCIÓN A LAS BASES DE DATOS CONCEPTO Y ORIGEN DE LAS BASES DE DATOS Y DE LOS SGBD Las aplicaciones informáticas de los años sesenta se realizaban totalmente por lotes (batch) y estaban pensadas para una tarea muy específica relacionada con muy pocas entidades tipo. Aplicaciones informáticas de los años sesenta La emisión de facturas, el control de Cada aplicación (una o varias cadenas de programas) utilizaba archivos de pedidos pendientes de atender, el movimientos para actualizar (creando una copia nueva) y/o para mantenimiento del archivo de consultar uno o dos archivos maestros o, excepcionalmente, más de dos. productos o la nómina del personal Cada programa trataba como máximo un archivo maestro, que solía estar eran algunas de las aplicaciones sobre cinta magnética y, en consecuencia, se trabajaba con acceso informáticas habituales secuencial. Cada vez que se le quería añadir una aplicación que requería el uso de algunos de los datos que ya existían y de otros nuevos, se diseñaba un archivo nuevo con todos los datos necesarios (algo que provocaba redundancia) para evitar que los programas tuviesen que leer muchos archivos. A medida que se fueron introduciendo las líneas de comunicación, los terminales y los discos, se fueron escribiendo programas que permitían a varios usuarios consultar los mismos archivos on-line y de forma simultánea. Más adelante fue surgiendo la necesidad de hacer las actualizaciones también on-line. Integración de aplicaciones Por ejemplo, se integra la aplicación de facturas, la de pedidos pendientes y la gestión del archivo de productos. A medida que se integraban las aplicaciones, se tuvieron que interrelacionar sus archivos y fue necesario eliminar la redundancia. El nuevo conjunto de archivos se debía diseñar de modo que estuviesen interrelacionados; al mismo tiempo, las informaciones redundantes (como, por ejemplo, el nombre y la dirección de los clientes o el nombre y el precio de los productos), que figuraban en los archivos de más de una de las aplicaciones, debían estar ahora en un solo lugar. El acceso on-line y la utilización eficiente de las interrelaciones exigían estructuras físicas que diesen un acceso rápido, como por ejemplo los índices, las multilistas, las técnicas de hashing, etc. Estos conjuntos de archivos interrelacionados, con estructuras complejas y compartidos por varios procesos de forma simultánea (unos on-line y otros por lotes), recibieron al principio el nombre de Data Banks, y después, a inicios de los años setenta, el de Data Bases. Aquí los denominamos bases de datos (BD). El software de gestión de archivos era demasiado elemental para dar satisfacción a todas estas necesidades. Por ejemplo, el tratamiento de las interrelaciones no estaba previsto, no era posible que varios usuarios actualizaran datos simultáneamente, etc. La utilización de estos conjuntos de archivos por parte de los programas de aplicación era excesivamente compleja, de modo que, especialmente durante la segunda mitad de los años setenta, fue saliendo al mercado software más sofisticado: los Data Base Management Systems, que aquí denominamos sistemas de gestión de Bases de Datos (SGBD). Base de Datos I – Unidad 01 – 2023 2 1983/2023 - 40 AÑOS DE DEMOCRACIA Con todo lo que hemos dicho hasta ahora, podríamos definir el término Bases de Datos; una base de datos de un Sistema de Información es la representación integrada de los conjuntos de entidades instancia correspondientes a las diferentes entidades tipo del Sistema de Información y de sus interrelaciones. Esta representación informática (o conjunto estructurado de datos) debe poder ser utilizada de forma compartida por muchos usuarios de distintos tipos. En otras palabras, una base de datos es un conjunto estructurado de datos que representa entidades y sus interrelaciones. La representación será única e integrada, a pesar de que debe permitir utilizaciones varias y simultáneas. LOS ARCHIVOS TRADICIONALES Y LAS BASES DE DATOS Aunque de forma muy simplificada, podríamos enumerar las principales diferencias entre los archivos tradicionales y las Bases de Datos tal y como se indica a continuación: 1) Entidades tipos: Archivos: tienen registros de una sola entidad tipo. BD: tienen datos de varias entidades tipo. 2) Interrelaciones: Archivos: el sistema no interrelaciona archivos. BD: el sistema tiene previstas herramientas para interrelacionar entidades. 3) Redundancia: Archivos: se crean archivos a la medida de cada aplicación, con todos los datos necesarios, aunque algunos sean redundantes respecto de otros archivos. BD: todas las aplicaciones trabajan con la misma Base de Datos y la integración de los datos es básica, de modo que se evita la redundancia. 4) Usuarios Archivos: sirven para un solo usuario o una sola aplicación. Dan una sola visión del mundo real. BD: es compartida por muchos usuarios de distintos tipos. Ofrece varias visiones del mundo real. EVOLUCIÓN DE LOS SGBD Para entender mejor qué son los SGBD, haremos un repaso de su evolución desde los años sesenta hasta nuestros días. LOS AÑOS SESENTA Y SETENTA: SISTEMAS CENTRALIZADOS Los SGBD de los años sesenta y setenta (IMS de IBM, IDS de Bull, DMS de UNIVAC, etc.) eran sistemas totalmente centralizados, como corresponde a los sistemas operativos de aquellos años, y al hardware para el que estaban hechos: una gran computadora para toda la empresa y una red de terminales sin inteligencia ni memoria. Los primeros SGBD en los años sesenta todavía no se les denominaba así- estaban orientados a facilitar la utilización de grandes conjuntos de datos en los que las interrelaciones eran complejas. El arquetipo de aplicación era el Bill of materials o Parts explosion, típica en las industrias del automóvil, en la construcción de naves espaciales y en campos similares. Estos sistemas trabajaban exclusivamente por lotes (batch). Base de Datos I – Unidad 01 – 2023 3 1983/2023 - 40 AÑOS DE DEMOCRACIA Al aparecer los terminales de teclado, conectados a la computadora central mediante una línea telefónica, se empiezan a construir grandes aplicaciones on-line transaccionales (OLTP). Los SGBD estaban íntimamente ligados al software de comunicaciones y de gestión de transacciones. Aunque para escribir los programas de aplicación se utilizaban lenguajes de alto nivel como Cobol o PL/I, se disponía también de instrucciones y de subrutinas especializadas para tratar las Bases de Datos que requerían que el programador conociese muchos detalles del diseño físico, y que hacían que la programación fuese muy compleja. El Data Base / Data Comunications IBM denominaba Data Base/ Data Comunications (DB/DC) al software de comunicaciones y de gestión de transacciones y de datos. Las aplicaciones típicas eran la reserva/compra de billetes a las compañías aéreas y de ferrocarriles y, un poco más tarde, las cuentas de clientes en el mundo bancario. Puesto que los programas estaban relacionados con el nivel físico, se debían modificar continuamente cuando se hacían cambios en el diseño y la organización de la Base de Datos. La preocupación básica era maximizar el rendimiento: el tiempo de respuesta y las transacciones por segundo LOS AÑOS OCHENTA: SGBD RELACIONALES Las computadoras minis, en primer lugar, y después las computadoras micros, extendieron la informática a prácticamente todas las empresas e instituciones. Esto exigía que el desarrollo de aplicaciones fuese más sencillo. Los SGBD de los años setenta eran demasiado complejos e inflexibles, y sólo los podía utilizar un personal muy cualificado. La aparición de los SGBD relacionales1 supone un avance importante para facilitar la programación de aplicaciones con Bases de Datos y para conseguir que los programas sean independientes de los aspectos físicos de la Base de Datos. Todos estos factores hacen que se extienda el uso de los SGBD. La estandarización, en el año 1986, del lenguaje SQL produjo una auténtica explosión de los SGBD relacionales. LAS COMPUTADORAS PERSONALES Durante los años ochenta aparecen y se extienden muy rápidamente las computadoras personales. También surge software para estos equipos monousuario (por ejemplo, dBase y sus derivados, Access), con los cuales es muy fácil crear y utilizar conjuntos de datos, y que se denominan personal data bases. Noten que el hecho de denominar SGBD estos primeros sistemas para PC es un poco forzado, ya que no aceptaban estructuras complejas ni interrelaciones, ni podían ser utilizados en una red que sirviese simultáneamente a muchos usuarios de diferentes tipos. Sin embargo, algunos, con el tiempo, se han ido convirtiendo en auténticos SGBD. LOS AÑOS NOVENTA: DISTRIBUCIÓN, C/S Y 4GL Al acabar la década de los ochenta, los SGBD relacionales ya se utilizaban prácticamente en todas las empresas. A pesar de todo, hasta la mitad de los noventa, cuando se ha necesitado un rendimiento elevado se han seguido utilizando los SGBD pre relacionales. 1 Oracle aparece en el año 1980 Base de Datos I – Unidad 01 – 2023 4 1983/2023 - 40 AÑOS DE DEMOCRACIA A finales de los ochenta y principios de los noventa, las empresas se han encontrado con el hecho de que sus departamentos han ido comprando computadoras departamentales y personales, y han ido haciendo aplicaciones con Bases de Datos. El resultado ha sido que en el seno de la empresa hay numerosas Bases de Datos y varios SGBD de diferentes tipos o proveedores. Este fenómeno de multiplicación de las Bases de Datos y de los SGBD se ha visto incrementado por la fiebre de las fusiones de empresas. La necesidad de tener una visión global de la empresa y de interrelacionar diferentes aplicaciones que utilizan Bases de Datos diferentes, junto con la facilidad que dan las redes para la intercomunicación entre computadoras, ha conducido a los SGBD actuales, que permiten que un programa pueda trabajar con diferentes Bases de Datos como si se tratase de una sola. Es lo que se conoce como base de datos distribuida. Esta distribución ideal se consigue cuando las diferentes Bases de Datos son soportadas por una misma marca de SGBD, es decir, cuando hay homogeneidad. Sin embargo, esto no es tan sencillo si los SGBD son heterogéneos. En la actualidad, gracias principalmente a la estandarización del lenguaje SQL, los SGBD de marcas diferentes pueden darse servicio unos a otros y colaborar para dar servicio a un programa de aplicación. No obstante, en general, en los casos de heterogeneidad no se llega a poder dar en el programa que los utiliza la apariencia de que se trata de una única Base de Datos. Base de Datos I – Unidad 01 – 2023 5 1983/2023 - 40 AÑOS DE DEMOCRACIA Además de esta distribución “impuesta”, al querer tratar de forma integrada distintas Bases de Datos preexistentes, también se puede hacer una distribución “deseada”, diseñando una Base de Datos distribuida físicamente, y con ciertas partes replicadas en diferentes sistemas. Las razones básicas por las que interesa esta distribución son las siguientes: BD centralizada 1) Disponibilidad. La disponibilidad de un sistema con una Base de Datos distribuida puede ser más alta, porque si queda fuera de servicio uno de los sistemas, los demás seguirán funcionando. Si los datos residentes en el sistema no disponible están replicados en otro sistema, continuarán estando disponibles. En caso contrario, sólo estarán disponibles los datos de los demás sistemas. 2) Costo. Una Base de Datos distribuida puede reducir el costo. En el caso de un sistema centralizado, todos los equipos usuarios, que pueden estar distribuidos por distintas y lejanas áreas geográficas, están conectados al sistema central por medio de líneas de comunicación. El costo total de las comunicaciones se puede reducir haciendo que un usuario tenga más cerca los datos que utiliza con mayor frecuencia; por ejemplo, en una computadora de su propia oficina o, incluso, en su computadora personal. BD BD Distribuída BD=∑BDi BD1 BD3 BD4 BD2 La tecnología que se utiliza habitualmente para distribuir datos es la que se conoce como entorno (o arquitectura) cliente/servidor (C/S). Todos los SGBD relacionales del mercado han sido adaptados a este entorno. La idea del C/S es sencilla. Dos procesos diferentes, que se ejecutan en un mismo sistema o en sistemas separados, actúan de forma que uno tiene el papel de cliente o peticionario de un servicio, y el otro el de servidor o proveedor del servicio. Base de Datos I – Unidad 01 – 2023 6 1983/2023 - 40 AÑOS DE DEMOCRACIA Por ejemplo, un programa de aplicación que un usuario ejecuta en su PC (que está conectado a una red) pide ciertos datos de una Base de Datos que reside en un equipo UNIX donde, a su vez, se ejecuta el SGBD relacional que la gestiona. El programa de aplicación es el cliente y el SGBD es el servidor. Petición Cliente Programa usuario Servidor SGBD Otros servicios Noten que el servicio que da un servidor de un sistema C/S no tiene por qué estar relacionado con las Bases de Datos; puede ser un servicio de impresión, de envío de un fax, etc., pero aquí nos interesan los servidores que son SGBD. Un proceso cliente puede pedir servicios a varios servidores. Un servidor puede recibir peticiones de muchos clientes. En general, un proceso A que hace de cliente, pidiendo un servicio a otro proceso B puede hacer también de servidor de un servicio que le pida otro proceso C (o incluso el B, que en esta petición sería el cliente). Incluso el cliente y el servidor pueden residir en un mismo sistema. La facilidad para disponer de distribución de datos no es la única razón, ni siquiera la básica, del gran éxito de los entornos C/S en los años noventa. Tal vez el motivo fundamental ha sido la flexibilidad para construir y hacer crecer la configuración informática global de la empresa, así como de hacer modificaciones en ella, mediante hardware y software muy estándar y barato. C/S, SQL y 4GL...... son siglas de moda desde el principio de los años noventa en el mundo de los sistemas de información. El éxito de las Bases de Datos, incluso en sistemas personales, ha llevado a la aparición de los Fourth Generation Languages (4GL), lenguajes muy fáciles y potentes, especializados en el desarrollo de aplicaciones fundamentadas en Bases de Datos. Proporcionan muchas facilidades en el momento de definir, generalmente de forma visual, diálogos para introducir, modificar y consultar datos en entornos C/S. TENDENCIAS ACTUALES Hoy día, los SGBD relacionales están en plena transformación para adaptarse a tres tecnologías de éxito reciente, fuertemente relacionadas: la multimedia, la de orientación a objetos (OO) e Internet y la web. Los tipos de datos que se pueden definir en los SGBD relacionales de los años ochenta y noventa son muy limitados. La incorporación de tecnologías multimedia –imagen y sonido– en los Sistemas de Información hace necesario que los SGBD relacionales acepten atributos de estos tipos. Sin embargo, algunas aplicaciones no tienen suficiente con la incorporación de tipos especializados en multimedia. Necesitan tipos complejos que el desarrollador pueda definir a medida de la aplicación. En definitiva, se necesitan tipos abstractos de datos: TAD. Los SGBD más recientes ya incorporaban esta posibilidad, y abren un amplio mercado de TAD predefinidos o librerías de clases. Base de Datos I – Unidad 01 – 2023 Nos puede interesar,...... por ejemplo, tener en la entidad alumno un atributo foto tal que su valor sea una tira de bits muy larga, resultado de la digitalización de la fotografía del alumno. 7 1983/2023 - 40 AÑOS DE DEMOCRACIA Esto nos lleva a la orientación a objetos (OO). El éxito de la OO al final de los años ochenta, en el desarrollo de software básico, en las aplicaciones de ingeniería industrial y en la construcción de interfaces gráficas con los usuarios, ha hecho que durante la década de los noventa se extendiese en prácticamente todos los campos de la informática. En los Sistemas de Información se inicia también la adopción, tímida de momento, de la OO. La utilización de lenguajes como C++, C# o Java requiere que los SGBD relacionales se adapten a ellos con interfaces adecuadas. La rápida adopción de la web a los Sistemas de Información hace que los SGBD incorporen recursos para ser servidores de páginas web, como por ejemplo la inclusión de SQL en scripts HTML, SQL incorporado en Java, etc. Noten que en el mundo de la web son habituales los datos multimedia y la OO. Durante estos últimos años se ha empezado a extender un tipo de aplicación de las Bases de Datos denominado Data Warehouse, o almacén de datos, que también produce algunos cambios en los SGBD relacionales del mercado. A lo largo de los años que han trabajado con Bases de Datos de distintas aplicaciones, las empresas han ido acumulando gran cantidad de datos de todo tipo. Si estos datos se analizan convenientemente pueden dar información valiosa 2. Por lo tanto, se trata de mantener una gran Base de Datos con información proveniente de toda clase de aplicaciones de la empresa (e, incluso, de fuera). Los datos de este gran almacén, el Data Warehouse, se obtienen por una replicación más o menos elaborada de las que hay en las Bases de Datos que se utilizan en el trabajo cotidiano de la empresa. Estos almacenes de datos se utilizan exclusivamente para hacer consultas, de forma especial para que lleven a cabo estudios 3 los analistas financieros, los analistas de mercado, etc. Actualmente, los SGBD se adaptan a este tipo de aplicación, incorporando, por ejemplo, herramientas como las siguientes: a) La creación y el mantenimiento de réplicas, con una cierta elaboración de los datos. b) La consolidación de datos de orígenes diferentes. c) La creación de estructuras físicas que soporten eficientemente el análisis multidimensional. OBJETIVOS Y SERVICIOS DE LOS SGBD Los SGBD que actualmente están en el mercado pretenden satisfacer un conjunto de objetivos directamente deducibles de lo que hemos explicado hasta ahora. CONSULTAS NO PREDEFINIDAS Y COMPLEJAS El objetivo fundamental de los SGBD es permitir que se hagan consultas no predefinidas (ad hoc) y complejas. Consultas que afectan a más de una entidad tipo 2 3 Se quiere conocer el número de alumnos de más de veinticinco años y con nota media superior a siete que están matriculados actualmente en la asignatura Bases de datos I. De cada alumno matriculado en menos de tres asignaturas, se quiere obtener el nombre, el número de matrícula, el nombre de las asignaturas y el nombre de profesores de estas asignaturas. Por ejemplo, la evolución del mercado en relación con la política de precios Con frecuencia se trata de estadísticas multidimensionales Base de Datos I – Unidad 01 – 2023 8 1983/2023 - 40 AÑOS DE DEMOCRACIA Los usuarios podrán hacer consultas de cualquier tipo y complejidad directamente al SGBD. El SGBD tendrá que responder inmediatamente sin que estas consultas estén preestablecidas; es decir, sin que se tenga que escribir, compilar y ejecutar un programa específico para cada consulta. Archivos tradicionales En los archivos tradicionales, cada vez que se quería hacer una consulta se tenía que escribir un programa a medida. El usuario debe formular la consulta con un lenguaje sencillo (que se quede, obviamente, en el nivel lógico), que el sistema debe interpretar directamente. Sin embargo, esto no significa que no se puedan escribir programas con consultas incorporadas (por ejemplo, para procesos repetitivos). La solución estándar para alcanzar este doble objetivo (consultas no predefinidas y complejas) es el lenguaje SQL, que veremos más adelante. FLEXIBILIDAD E INDEPENDENCIA La complejidad de las Bases de Datos y la necesidad de irlas adaptando a la evolución del Sistema de Información hacen que un objetivo básico de los SGBD sea dar flexibilidad a los cambios. Interesa obtener la máxima independencia posible entre los datos y los procesos usuarios para que se pueda llevar a cabo todo tipo de cambios tecnológicos y variaciones en la descripción de la Base de Datos, sin que se deban modificar los programas de aplicación ya escritos ni cambiar la forma de escribir las consultas (o actualizaciones) directas. Para conseguir esta independencia, tanto los usuarios que hacen consultas (o actualizaciones) directas como los profesionales informáticos que escriben programas que las llevan incorporadas, deben poder desconocer las características físicas de la Base de Datos con que trabajan. No necesitan saber nada sobre el soporte físico, ni estar al corriente de qué SO se utiliza, qué índices hay, la compresión o no compresión de datos, etc. De este modo, se pueden hacer cambios de tecnología y cambios físicos para mejorar el rendimiento sin afectar a nadie. Este tipo de independencia recibe el nombre de independencia física de los datos. En el mundo de los archivos ya había independencia física en un cierto grado, pero en el mundo de las Bases de Datos acostumbra a ser mucho mayor. Sin embargo, con la independencia física no tenemos suficiente. También queremos que los usuarios (los programadores de aplicaciones o los usuarios directos) no tengan que hacer cambios cuando se modifica la descripción lógica o el esquema de la Base de Datos (por ejemplo, cuando se añaden/suprimen entidades o interrelaciones, atributos, etc.) Base de Datos I – Unidad 01 – 2023 Independencia lógica de los datos Por ejemplo, el hecho de suprimir el atributo fecha de nacimiento de la entidad alumno y añadir otra entidad aula no debería afectar a ninguno de los programas existentes que no utilicen el atributo fecha de nacimiento. 9 1983/2023 - 40 AÑOS DE DEMOCRACIA Y todavía más: queremos que diferentes procesos usuarios puedan tener diferentes visiones lógicas de una misma Base de Datos, y que estas visiones se puedan mantener lo más independientes posibles de la Base de Datos, y entre ellas mismas. Este tipo de independencia se denomina independencia lógica de los datos, y da flexibilidad y elasticidad a los cambios lógicos. EJEMPLOS DE INDEPENDENCIA LÓGICA 1) El personal administrativo de secretaría podría tener una visión de la entidad alumno sin que fuese necesario que existiese el atributo nota. Sin embargo, los usuarios profesores (o los programas dirigidos a ellos) podrían tener una visión en la que existiese el atributo nota, pero no el atributo fecha de pago. 2) Decidimos ampliar la longitud del atributo nombre y lo aumentamos de treinta a cincuenta caracteres, pero no sería necesario modificar los programas que ya tenemos escritos si no nos importa que los valores obtenidos tengan sólo los primeros treinta caracteres del nombre. Independencia lógica Los sistemas de gestión de archivos tradicionales no dan ninguna independencia lógica. Los SGBD sí que la dan; uno de sus objetivos es conseguir la máxima posible, pero dan menos de lo que sería deseable. PROBLEMAS DE LA REDUNDANCIA En el mundo de los archivos tradicionales, cada aplicación utilizaba su archivo. Sin embargo, puesto que se daba mucha coincidencia de datos entre aplicaciones, se producía también mucha redundancia entre los archivos. Ya hemos dicho que uno de los objetivos de los SGBD es facilitar la eliminación de la redundancia. Seguramente piensan que el problema de la redundancia es el espacio perdido. Antiguamente, cuando el precio del byte de disco era muy elevado, esto era un problema grave, pero actualmente prácticamente nunca lo es. ¿Qué problema hay, entonces? Simplemente, lo que todos hemos sufrido más de una vez; si tenemos algo anotado en dos lugares diferentes no pasará demasiado tiempo hasta que las dos anotaciones dejen de ser coherentes, porque habremos modificado la anotación en uno de los lugares y nos habremos olvidado de hacerlo en el otro. Así pues, el verdadero problema es el grave riesgo de inconsistencia o incoherencia de los datos; es decir, la pérdida de integridad que las actualizaciones pueden provocar cuando existe redundancia. Por lo tanto, convendría evitar la redundancia. En principio, nos conviene hacer que un dato sólo figure una vez en la Base de Datos. Sin embargo, esto no siempre será cierto. Por ejemplo, para representar una interrelación entre dos entidades, se suele repetir un mismo atributo en las dos, para que una haga referencia a la otra. Otro ejemplo podría ser el disponer de réplicas de los datos por razones de fiabilidad, disponibilidad o costes de comunicaciones. El SGBD debe permitir que el diseñador defina datos redundantes, pero entonces tendría que ser el mismo SGBD el que hiciese automáticamente la actualización de los datos en todos los lugares donde estuviesen repetidos. Base de Datos I – Unidad 01 – 2023 10 1983/2023 - 40 AÑOS DE DEMOCRACIA La duplicación de datos es el tipo de redundancia más habitual, pero también tenemos redundancia cuando guardamos en la Base de Datos, datos derivados (o calculados) a partir de otros datos de la misma Base de Datos. De este modo podemos responder rápidamente a consultas globales, ya que nos ahorramos la lectura de gran cantidad de registros. En los casos de datos derivados, para que el resultado del cálculo se mantenga consistente con los datos elementales, es necesario rehacer el cálculo cada vez que éstos se modifican. El usuario (ya sea programador o no) puede olvidarse de hacer el nuevo cálculo; por ello convendrá que el mismo SGBD lo haga automáticamente. Datos derivados Es frecuente tener datos numéricos acumulados o agregados: el importe total de todas las matrículas hechas hasta hoy, el número medio de alumnos por asignatura, el saldo de la caja de la oficina, etc. INTEGRIDAD DE LOS DATOS Nos interesará que los SGBD aseguren el mantenimiento de la calidad de los datos en cualquier circunstancia. Acabamos de ver que la redundancia puede provocar pérdida de integridad de los datos, pero no es la única causa posible. Se podría perder la corrección o la consistencia de los datos por muchas otras razones: errores de programas, errores de operación humana, avería de disco, transacciones incompletas por corte de alimentación eléctrica, etc. En el subapartado anterior hemos visto que podremos decir al SGBD que nos lleve el control de las actualizaciones en el caso de las redundancias, para garantizar la integridad. Del mismo modo, podremos darle otras reglas de integridad –o restricciones– para que asegure que los programas las cumplen cuando efectúan las actualizaciones. Cuando el SGBD detecte que un programa quiere hacer una operación que va contra las reglas establecidas al definir la Base de Datos, no se lo deberá permitir, y le tendrá que devolver un estado de error. Al diseñar una Base de Datos para un Sistema de Información concreto y escribir su esquema, no sólo definiremos los datos, sino también las reglas de integridad que queremos que el SGBD haga cumplir. Aparte de las reglas de integridad que el diseñador de la Base de Datos puede definir y que el SGBD entenderá y hará cumplir, el mismo SGBD tiene reglas de integridad inherentes al modelo de datos que utiliza y que siempre se cumplirán. Son las denominadas reglas de integridad del modelo. Las reglas definibles por parte del usuario son las reglas de integridad del usuario. El concepto de integridad de los datos va más allá de prevenir que los programas usuarios almacenen datos incorrectos. En casos de errores o desastres, también podríamos perder la integridad de los datos. El SGBD nos debe dar las herramientas para reconstruir o restaurar los datos estropeados. Los procesos de restauración (restore o recovery) de los que todo SGBD dispone pueden reconstruir la Base de Datos y darle el estado consistente y correcto anterior al incidente. Esto se acostumbra a hacer gracias a la obtención de copias periódicas de los datos (se denominan copias de seguridad o back-up) y mediante el mantenimiento continuo de un diario (log) donde el SGBD va anotando todas las escrituras que se hacen en la Base de Datos. Base de Datos I – Unidad 01 – 2023 11 1983/2023 - 40 AÑOS DE DEMOCRACIA CONCURRENCIA DE USUARIOS Un objetivo fundamental de los SGBD es permitir que varios usuarios puedan acceder concurrentemente a la misma Base de Datos. Cuando los accesos concurrentes son todos de lectura (es decir, cuando la Base de Datos sólo se consulta), el problema que se produce es simplemente de rendimiento, causado por las limitaciones de los soportes de que se dispone: pocos mecanismos de acceso independientes, movimiento del brazo y del giro del disco demasiado lentos, buffers locales demasiado pequeños, etc. Cuando un usuario o más de uno están actualizando los datos, se pueden producir problemas de interferencia que tengan como consecuencia la obtención de datos erróneos y la pérdida de integridad de la Base de Datos. Para tratar los accesos concurrentes, los SGBD utilizan el concepto de transacción de Base de Datos, concepto de especial utilidad para todo aquello que hace referencia a la integridad de los datos, como veremos a continuación. Denominamos transacción de Base de Datos o, simplemente transacción, un conjunto de operaciones simples que se ejecutan como una unidad. Los SGBD deben conseguir que el conjunto de operaciones de una transacción nunca se ejecute parcialmente. O se ejecutan todas, o no se ejecuta ninguna. EJEMPLOS DE TRANSACCIONES 1) Imaginemos un programa pensado para llevar a cabo la operación de transferencia de dinero de una cuenta X a otra Y. Supongamos que la transferencia efectúa dos operaciones: en primer lugar, el cargo a X y después, el abono a Y. Este programa se debe ejecutar de forma que se hagan las dos operaciones o ninguna, ya que si por cualquier razón (por ejemplo, por interrupción del flujo eléctrico) el programa ejecutase sólo el cargo de dinero a X sin abonarlos a Y, la Base de Datos quedaría en un estado incorrecto. Queremos que la ejecución de este programa sea tratada por el SGBD como una transacción de Base de Datos. 2) Otro ejemplo de programa que querríamos que tuviera un comportamiento de transacción podría ser el que aumentara el 30% de la nota de todos los alumnos. Si sólo aumentara la nota a unos cuantos alumnos, la Base de Datos quedaría incorrecta. Para indicar al SGBD que damos por acabada la ejecución de la transacción, el programa utilizará la operación de COMMIT. Si el programa no puede acabar normalmente (es decir, si el conjunto de operaciones se ha hecho sólo de forma parcial), el SGBD tendrá que deshacer todo lo que la transacción ya haya hecho. Esta operación se denomina ROLLBACK. Acabamos de observar la utilidad del concepto de transacción para el mantenimiento de la integridad de los datos en caso de interrupción de un conjunto de operaciones lógicamente unitario. Sin embargo, entre transacciones que se ejecutan concurrentemente se pueden producir problemas de interferencia que hagan obtener resultados erróneos o que comporten la pérdida de la integridad de los datos. Base de Datos I – Unidad 01 – 2023 12 1983/2023 - 40 AÑOS DE DEMOCRACIA CONSECUENCIAS DE LA INTERFERENCIA ENTRE TRANSACCIONES 1) Imaginemos que una transacción que transfiere dinero de X a Y se ejecuta concurrentemente con una transacción que observa el saldo de las cuentas Y y X, en este orden, y nos muestra su suma. Si la ejecución de forma concurrente de las dos transacciones casualmente es tal que la transferencia se ejecuta entre la ejecución de las dos lecturas de la transacción de suma, puede producir resultados incorrectos. Además, si los decide escribir en la Base de Datos, ésta quedará inconsistente (como vemos en la figura). 2) Si simultáneamente con el generoso programa que aumenta la nota de los alumnos en un 30%, se ejecuta un programa que determina la nota media de todos los alumnos de una determinada asignatura, se podrá encontrar a alumnos ya gratificados y a otros no gratificados, algo que producirá resultados erróneos. Transferencia de $1.500 de la cuenta X a la cuenta Y de forma concurrente con la consulta de suma de saldos de X e Y X 5.000 Y 8.000 Transacción de transferencia Suma de Saldos 13.000 Transacción de consulta Lee Y (que es 8.000) Resta 1.500 a X (queda 3.500) Lee X (que es 3.500) y lo suma con Y (da 11.500 en lugar de 13.000) Suma 1.500 a Y (queda 9.500) Estos son sólo dos ejemplos de las diferentes consecuencias negativas que puede tener la interferencia entre transacciones en la integridad de la Base de Datos y en la corrección del resultado de las consultas. Nos interesará que el SGBD ejecute las transacciones de forma que no se interfieran; es decir, que queden aisladas unas de otras. Para conseguir que las transacciones se ejecuten como si estuviesen aisladas, los SGBD utilizan distintas técnicas. La más conocida es el bloqueo (lock). El bloqueo de unos datos en beneficio de una transacción consiste en poner limitaciones a los accesos que las demás transacciones podrán hacer a estos datos. Cuando se provocan bloqueos, se producen esperas, retenciones y, en consecuencia, el sistema es más lento. Los SGBD se esfuerzan en minimizar estos efectos negativos. SEGURIDAD El término seguridad se ha utilizado en diferentes sentidos a lo largo de la historia de la informática. Actualmente, en el campo de los SGBD, el término seguridad se suele utilizar para hacer referencia a los temas relativos a la confidencialidad, las autorizaciones, los derechos de acceso, etc. Estas cuestiones siempre han sido importantes en los Sistema de Información militares, las agencias de información y en ámbitos similares, pero durante los años noventa han ido adquiriendo importancia en cualquier Sistema de Información donde se almacenen datos sobre personas. Base de Datos I – Unidad 01 – 2023 13 1983/2023 - 40 AÑOS DE DEMOCRACIA Recuerden que en el Estado argentino tenemos una ley 4, que exige la protección de la confidencialidad de estos datos. Los SGBD permiten definir autorizaciones o derechos de acceso a diferentes niveles: al nivel global de toda la Base de Datos, al nivel entidad y al nivel atributo. Estos mecanismos de seguridad requieren que el usuario se pueda identificar. Se acostumbra a utilizar códigos de usuarios (y grupos de usuarios) acompañados de contraseñas (passwords), pero también se utilizan tarjetas magnéticas o de presencia, identificación por reconocimiento de la voz, y otros medios biométricos. Nos puede interesar almacenar la información con una codificación secreta; es decir, con técnicas de encriptación (como mínimo se deberían encriptar las contraseñas). Muchos de los SGBD actuales tienen prevista la encriptación. Prácticamente todos los SGBD del mercado dan una gran variedad de herramientas para la vigilancia y la administración de la seguridad. Los hay que, incluso, tienen opciones (con precio separado) para los Sistemas de Información con unas exigencias altísimas, como por ejemplo los militares. OTROS OBJETIVOS Acabamos de ver los objetivos fundamentales de los SGBD actuales. Sin embargo, a medida que los SGBD evolucionan, se imponen nuevos objetivos adaptados a las nuevas necesidades y tecnologías. Como ya hemos visto, en estos momentos podríamos citar como objetivos nuevos o recientes los siguientes: 1) 2) 3) 4) Servir eficientemente los Data Warehouse. Adaptarse al desarrollo orientado a objetos. Incorporar el tiempo como un elemento de caracterización de la información. Adaptarse al mundo de Internet ARQUITECTURA DE LOS SGBD ESQUEMAS Y NIVELES Para trabajar con nuestras Bases de Datos, los SGBD necesitan conocer su estructura (qué entidades tipo habrá, qué atributos tendrán, etc.). Los SGBD necesitan que les demos una descripción o definición de la Base de Datos. Esta descripción recibe el nombre de esquema de la Base de Datos, y los SGBD la tendrán continuamente a su alcance. El esquema de la Base de Datos es un elemento fundamental de la arquitectura de un SGBD que permite independizar el SGBD de la Base de Datos; de este modo, se puede cambiar el diseño de la Base de Datos (su esquema) sin tener que hacer ningún cambio en el SGBD. Anteriormente, ya hemos hablado de la distinción entre dos niveles de representación informática: el nivel lógico y el físico. 4 Ley 25.326 PROTECCION DE LOS DATOS PERSONALES. Promulgada el 30 de octubre de 2000 Base de Datos I – Unidad 01 – 2023 14 1983/2023 - 40 AÑOS DE DEMOCRACIA El nivel lógico nos oculta los detalles de cómo se almacenan los datos, cómo se mantienen y cómo se accede físicamente a ellos. En este nivel sólo se habla de entidades, atributos y reglas de integridad. Por cuestiones de rendimiento, nos podrá interesar describir elementos de nivel físico como, por ejemplo, qué índices tendremos y qué características presentarán, cómo y dónde (en qué espacio físico) queremos que se agrupen físicamente los registros, de qué tamaño deben ser las páginas, etc. En el periodo 1975-1982, ANSI intentaba establecer las bases para crear estándares en el campo de las Bases de Datos. El comité conocido como ANSI/SPARC recomendó que la arquitectura de los SGBD previese tres niveles de descripción de la Base de Datos, no sólo dos 5. De acuerdo con la arquitectura ANSI/SPARC, debía haber tres niveles de esquemas (tres niveles de abstracción). La idea básica de ANSI/SPARC consistía en descomponer el nivel lógico en dos: el nivel externo y el nivel conceptual. Denominábamos nivel interno lo que aquí hemos denominado nivel físico. De este modo, de acuerdo con ANSI/SPARC, habría los tres niveles de esquemas que mencionamos a continuación: a) En el nivel externo se sitúan las diferentes visiones lógicas que los procesos usuarios (programas de aplicación y usuarios directos) tendrán de las partes de la Base de Datos que utilizarán. Estas visiones se denominan esquemas externos. b) En el nivel conceptual hay una sola descripción lógica básica, única y global, que denominamos esquema conceptual, y que sirve de referencia para el resto de los esquemas. c) En el nivel físico hay una sola descripción física, que denominamos esquema interno. 5 Nota Es preciso ir con cuidado para no confundir los niveles que se describen aquí con los descritos en el caso de los archivos, aunque reciban el mismo nombre. En el caso de las Bases de Datos, el esquema interno corresponde a la parte física, y el externo a la lógica; en el caso de los archivos, sucede lo contrario De hecho, en el año 1971, el comité CODASYL ya había propuesto los tres niveles de esquemas Base de Datos I – Unidad 01 – 2023 15 1983/2023 - 40 AÑOS DE DEMOCRACIA Usuarios Nivel Lógico EE1 EEn EE2 Esquemas externos EC Esquema conceptual EI Esquema interno Nivel Físico Base de Datos BD En el esquema conceptual se describirán las entidades tipo, sus atributos, las interrelaciones y las restricciones o reglas de integridad. El esquema conceptual corresponde a las necesidades del conjunto de la empresa o del Sistema de Información, por lo que se escribirá de forma centralizada durante el denominado diseño lógico de la Base de Datos. Sin embargo, cada aplicación podrá tener su visión particular, y seguramente parcial, del esquema conceptual. Los usuarios (programas o usuarios directos) verán la Base de Datos mediante esquemas externos apropiados a sus necesidades. Estos esquemas se pueden considerar redefiniciones del esquema conceptual, con las partes y los términos que convengan para las necesidades de las aplicaciones (o grupos de aplicaciones). Algunos sistemas los denominan subesquemas. Al definir un esquema externo, se citarán sólo aquellos atributos y aquellas entidades que interesen; los podremos redenominar, podremos definir datos derivados o redefinir una entidad para que las aplicaciones que utilizan este esquema externo crean que son dos, definir combinaciones de entidades para que parezcan una sola, etc. EJEMPLO DE ESQUEMA EXTERNO Imaginemos una Base de Datos que en el esquema conceptual tiene definida, entre muchas otras, una entidad alumno con los siguientes atributos: numatri, nombre, apellido, numDNI, direccion, fechanac, telefono. Sin embargo, nos puede interesar que unos determinados programas o usuarios vean la Base de Datos formada de acuerdo con un esquema externo que tenga definidas dos entidades, denominadas estudiante y persona. Base de Datos I – Unidad 01 – 2023 16 1983/2023 - 40 AÑOS DE DEMOCRACIA a) La entidad estudiante podría tener definido el atributo numero-matricula (definido como derivable directamente de numatri), el atributo nombre-pila (de nombre), el atributo apellido y el atributo DNI (de numDNI). b) La entidad persona podría tener el atributo DNI (obtenido de numDNI), el atributo nombre (formado por la concatenación de nombre y apellido), el atributo direccion y el atributo edad (que deriva dinámicamente de fechanac). El esquema interno o físico contendrá la descripción de la organización física de la Base de Datos: caminos de acceso (índices, hashing, apuntadores, etc.), codificación de los datos, gestión del espacio, tamaño de la página, etc. El esquema de nivel interno responde a las cuestiones de rendimiento (espacio y tiempo) planteadas al hacer el diseño físico de la Base de Datos y al ajustarlo 6 posteriormente a las necesidades cambiantes. De acuerdo con la arquitectura ANSI/SPARC, para crear una Base de Datos hace falta definir previamente su esquema conceptual, definir como mínimo un esquema externo y, de forma eventual, definir su esquema interno. Si este último esquema no se define, el mismo SGBD tendrá que decidir los detalles de la organización física. El SGBD se encargará de hacer las correspondencias (mappings) entre los tres niveles de esquemas. ESQUEMAS Y NIVELES EN LOS SGBD RELACIONALES En los SGBD relacionales (es decir, en el mundo de SQL) se utiliza una terminología ligeramente diferente. No se separan de forma clara tres niveles de descripción. Se habla de un solo esquema –schema–, pero en su interior se incluyen descripciones de los tres niveles. En el schema se describen los elementos de aquello que en la arquitectura ANSI/SPARC se denomina esquema conceptual (entidades tipo, atributos y restricciones) y las vistas –view–, que corresponden aproximadamente a los esquemas externos. El modelo relacional en que está inspirado SQL se limita al mundo lógico. Por ello, el estándar ANSI-ISO de SQL no habla en absoluto del mundo físico o interno; lo deja en manos de los SGBD relacionales del mercado. Sin embargo, estos SGBD proporcionan la posibilidad de incluir dentro del schema descripciones de estructuras y características físicas (índice, tablespace, clúster, espacios para colisiones, etc.) INDEPENDENCIA DE LOS DATOS En este subapartado veremos cómo la arquitectura de tres niveles que acabamos de presentar nos proporciona los dos tipos de independencia de los datos: la física y la lógica. Hay independencia física cuando los cambios en la organización física de la Base de Datos no afectan al mundo exterior (es decir, los programas usuarios o los usuarios directos). De acuerdo con la arquitectura ANSI/SPARC, habrá independencia física cuando los cambios en el esquema interno no afecten al esquema conceptual ni a los esquemas externos. 6 En inglés, el ajuste se conoce con el nombre de tuning. Base de Datos I – Unidad 01 – 2023 17 1983/2023 - 40 AÑOS DE DEMOCRACIA Es obvio que cuando cambiemos unos datos de un soporte a otro, o los cambiemos de lugar dentro de un soporte, no se verán afectados ni los programas de aplicación ni los usuarios directos, ya que no se modificará el esquema conceptual ni el externo. Sin embargo, tampoco tendrían que verse afectados si cambiásemos, por ejemplo, el método de acceso a unos registros determinados 7, el formato o la codificación, etc. Ninguno de estos casos debería afectar al mundo exterior, sino sólo a la Base de Datos física, el esquema interno, etc. EE1 EE2 No afectados EEn EC Si hay independencia física de los datos, lo único que variará al cambiar el esquema interno son las correspondencias entre el esquema conceptual y el interno. Obviamente, la mayoría de los cambios del esquema interno obligarán a rehacer la Base de Datos real (la física). EI viejo EI Nuevo BD Vieja BD Nueva Hay independencia lógica cuando los usuarios8 no se ven afectados por los cambios en el nivel lógico. Dados los dos niveles lógicos de la arquitectura ANSI/SPARC, diferenciaremos las dos situaciones siguientes: 1) 2) Cambios en el esquema conceptual. Un cambio de este tipo no afectará a los esquemas externos que no hagan referencia a las entidades o a los atributos modificados. Cambios en los esquemas externos. Efectuar cambios en un esquema externo afectará a los usuarios que utilicen los elementos modificados. Sin embargo, no debería afectar a los demás usuarios ni al esquema conceptual, y tampoco, en consecuencia, al esquema interno y a la Base de Datos física. EE1 EEn viejo EE2 EEn nuevo EC No afectado EI BD USUARIOS NO AFECTADOS POR LOS CAMBIOS Noten que no todos los cambios de elementos de un esquema externo afectarán a sus usuarios. Veamos un ejemplo de ello: antes hemos visto que cuando eliminábamos el atributo apellido del esquema conceptual, debíamos modificar el esquema externo donde definíamos nombre, porque allí estaba definido como concatenación de nombre y apellido. 7 8 Por ejemplo, eliminando un índice en árbol-B o sustituyéndolo por un hashing. Programas de aplicación o usuarios directos. Base de Datos I – Unidad 01 – 2023 18 1983/2023 - 40 AÑOS DE DEMOCRACIA Pues bien, un programa que utilizase el atributo nombre no se vería afectado si modificásemos el esquema externo de modo que nombre fuese la concatenación de nombre y una cadena constante (por ejemplo, toda en blanco). Como resultado, habría desaparecido el apellido de nombre, sin que hubiera sido necesario modificar el programa. Los SGBD actuales proporcionan bastante independencia lógica, pero menos de la que haría falta, ya que las exigencias de cambios constantes en el Sistema de Información piden grados muy elevados de flexibilidad. Los sistemas de archivos tradicionales, en cambio, no ofrecen ninguna independencia lógica. FLUJO DE DATOS Y DE CONTROL Para entender el funcionamiento de un SGBD, a continuación, veremos los principales pasos de la ejecución de una consulta sometida al SGBD por un programa de aplicación. Explicaremos las líneas generales del flujo de datos y de control entre el SGBD, los programas de usuario y la Base de Datos. Recuerden que el SGBD, con la ayuda del SO, lee páginas (bloques) de los soportes donde está almacenada la Base de Datos física, y las lleva a un área de buffers o memorias caché en la memoria principal. El SGBD pasa registros desde los buffers hacia el área de trabajo del mismo programa. Supongamos que la consulta pide los datos del alumno que tiene un determinado DNI. Por lo tanto, la respuesta que el programa obtendrá será un solo registro y lo recibirá dentro de un área de trabajo propia 9. Ejecución de una consulta Programa usuario En la figura vemos representada la Base de Datos, los tres niveles de esquemas, el área de los buffers, el SGBD y el programa de aplicación que le hace la consulta. 7 Área donde se debe poner el resultado 6 Registro 1 Buffers SGBD 4 2 Externo Conceptual 3 Interno Esquemas 5 Página BD El proceso que se sigue es el siguiente: a) 9 Empieza con una llamada ① del programa al SGBD, en la que se le envía la operación de consulta. El SGBD debe verificar que la sintaxis de la operación recibida sea correcta, que el usuario del programa esté autorizado Por ejemplo, una variable con estructura de tupla. Base de Datos I – Unidad 01 – 2023 19 1983/2023 - 40 AÑOS DE DEMOCRACIA b) c) d) e) f) a hacerla, etc. Para poder llevar a cabo todo esto, el SGBD se basa ②en el esquema externo con el que trabaja el programa y en el esquema conceptual. Si la consulta es válida, el SGBD determina, consultando el esquema interno ③, qué mecanismo debe seguir para responderla. Ya sabemos que el programa usuario no dice nada respecto a cómo se debe hacer físicamente la consulta. Es el SGBD el que lo debe determinar. Casi siempre hay varias formas y diferentes caminos para responder a una consulta 10. Supongamos que ha elegido aplicar un hashing al valor del DNI, que es el parámetro de la consulta, y el resultado es la dirección de la página donde se encuentra (entre muchos otros) el registro del alumno buscado. Cuando ya se sabe cuál es la página, el SGBD comprobará ④ si por suerte esta página ya se encuentra en aquel momento en el área de los buffers (tal vez como resultado de una consulta anterior de este usuario o de otro). Si no está, el SGBD, con la ayuda del SO, la busca en disco y la carga en los buffers ⑤. Si ya está, se ahorra el acceso a disco. Ahora, la página deseada ya está en la memoria principal. El SGBD extrae, de entre los distintos registros que la página puede contener, el registro buscado, e interpreta la codificación y el resultado según lo que diga el esquema interno. El SGBD aplica a los datos las eventuales Diferencias entre SGBD transformaciones lógicas que implica el esquema externo (tal vez cortando la dirección por la derecha) Aunque entre diferentes SGBD puede haber y las lleva al área de trabajo del programa ⑥. enormes diferencias de funcionamiento, suelen A continuación, el SGBD retorna el control al seguir el esquema general que acabamos de programa ⑦ y da por terminada la ejecución de la explicar. consulta. MODELOS DE BASES DE DATOS Una Base de Datos es una representación de la realidad (de la parte de la realidad que nos interesa en nuestro Sistema de Información). Dicho de otro modo, una Base de Datos se puede considerar un modelo de la realidad. El componente fundamental utilizado para modelar en un SGBD relacional son las tablas (denominadas relaciones en el mundo teórico). Sin embargo, en otros tipos de SGBD se utilizan otros componentes. El conjunto de componentes o herramientas conceptuales que un SGBD proporciona para modelar recibe el nombre de modelo de Base de Datos. Los cuatro modelos de Base de Datos más utilizados en los Sistema de Información son el modelo relacional, el modelo jerárquico, el modelo en red y el modelo relacional con objetos. Todo modelo de Base de Datos nos proporciona tres tipos de herramientas: a) 10 Las tablas o relaciones se estudiarán en la unidad didáctica “El modelo relacional y el álgebra relacional” de este curso. ¡Cuidado con las confusiones! Popularmente, en especial en el campo de la informática personal, se denomina Bases de Datos a lo que aquí denominamos SGBD. Tampoco se debe confundir la Base de Datos considerada como modelo de la realidad con lo que aquí denominamos modelo de Base de Datos. El modelo de Base de Datos es el conjunto de herramientas conceptuales (piezas) que se utilizan para construir el modelo de la realidad. Estructuras de datos con las que se puede construir la Base de Datos: tablas, árboles, etc. Por ejemplo, siempre tiene la posibilidad de hacer una búsqueda secuencial. Base de Datos I – Unidad 01 – 2023 20 1983/2023 - 40 AÑOS DE DEMOCRACIA b) c) Diferentes tipos de restricciones (o reglas) de integridad que el SGBD tendrá que hacer cumplir a los datos: dominios, claves, etc. Una serie de operaciones para trabajar con los datos. Un ejemplo de ello, en el modelo relacional, es la operación SELECT, que sirve para seleccionar (o leer) las filas que cumplen alguna condición. Un ejemplo de operación típica del modelo jerárquico y del modelo en red podría ser la que nos dice si un determinado registro tiene “hijos” o no. EVOLUCIÓN DE LOS MODELOS DE BASE DE DATOS El modelo relacional se estudia con detalle en la unidad “El modelo relacional y el álgebra relacional” de esta materia. De los cuatro modelos de Base de Datos que hemos citado, el que apareció primero, a principios de los años sesenta, fue el modelo jerárquico. Sus estructuras son registros interrelacionados en forma de árboles. El SGBD clásico de este modelo es el IMS/DL1 de IBM. A principios de los setenta surgieron SGBD basados en un modelo en red. Como en el modelo jerárquico, hay registros e interrelaciones, pero un registro ya no está limitado a ser “hijo” de un solo registro tipo. El comité CODASYL- DBTG propuso un estándar basado en este modelo, que fue adoptado por muchos constructores de SGBD 11. Sin embargo, encontró la oposición de IBM, la empresa entonces dominante. La propuesta de CODASYL-DBTG ya definía tres niveles de esquemas. Durante los años ochenta apareció una gran cantidad de SGBD basados en el modelo relacional propuesto en 1969 por E.F. Codd, de IBM, y prácticamente todos utilizaban como lenguaje nativo el SQL 12. El modelo relacional se basa en el concepto matemático de relación, que aquí podemos considerar de momento equivalente al término tabla (formada por filas y columnas). La mayor parte de los Sistema de Información que actualmente están en funcionamiento utilizan SGBD relacionales, pero algunos siguen utilizando los jerárquicos o en red (especialmente en Sistema de Información antiguos muy grandes). Registros tipo A Así como en los modelos pre-relacionales (jerárquico y en red), las estructuras de datos constan de dos elementos básicos (los registros y las interrelaciones), en el modelo relacional constan de un solo elemento: la tabla, formada por filas y columnas. Las interrelaciones se deben modelizar utilizando las tablas. Otra diferencia importante entre los modelos prerelacionales y el modelo relacional es que el modelo relacional se limita al nivel lógico (no hace absolutamente ninguna consideración sobre las representaciones físicas). Es decir, nos da una independencia física de datos total. Esto es así si hablamos del modelo teórico, pero los SGBD del mercado nos proporcionan una independencia limitada. Jerárquico Registros tipo B Registros tipo A Registros tipo C Red Registros tipo B Tabla A Tabla B Tabla C Relacional Estos últimos años se está extendiendo el modelo de Base de Datos relacional con objetos. Se trata de ampliar el modelo relacional, añadiéndole la posibilidad de que los tipos de 11 12 Por ejemplo, IDS de Bull, DMS de Univac y DBMS de Digital. Por ejemplo, Oracle, DB2 de IBM, Informix, Ingres, Allbase de HP y SQL-Server de Sybase. Base de Datos I – Unidad 01 – 2023 21 1983/2023 - 40 AÑOS DE DEMOCRACIA datos sean tipos abstractos de datos, TAD. Esto acerca los sistemas relacionales al paradigma de la OO. Los primeros SGBD relacionales que dieron esta posibilidad fueron Oracle (versión 8), Informix (versión 9) e IBM/DB2/UDB (versión 5). Hablamos de modelos de Base de Datos, pero de hecho se acostumbran a denominar modelos de datos, ya que permiten modelarlos. Sin embargo, hay modelos de datos que no son utilizados por los SGBD del mercado: sólo se usan durante el proceso de análisis y diseño, pero no en las realizaciones. Los más conocidos de estos tipos de modelos son los modelos La evolución de los modelos... semánticos y los funcionales. Éstos nos proporcionan herramientas muy potentes para describir las estructuras de la... a lo largo de los años los ha ido alejando información del mundo real, la semántica y las interrelaciones, del mundo físico y los ha acercado al mundo pero normalmente no disponen de operaciones para tratarlas. Se lógico; es decir, se han alejado de las limitan a ser herramientas de descripción lógica. Son muy máquinas y se han acercado a las personas. utilizados en la etapa del diseño de Base de Datos y en herramientas CASE. El más extendido de estos modelos es el conocido como modelo ER (entity-relationship), que estudiaremos más adelante. Actualmente, la práctica más extendida en el mundo profesional de los desarrolladores de Sistema de Información es la utilización del modelo ER durante el análisis y las primeras etapas del diseño de los datos, y la utilización del modelo relacional para acabar el diseño y construir la Base de Datos con un SGBD. En esta asignatura hablamos sólo de Base de Datos con modelos de datos estructurados, que son los que normalmente se utilizan en los Sistema de Información empresariales. Sin embargo, hay SGBD especializados en tipos de aplicaciones concretas que no siguen ninguno de estos modelos. Por ejemplo, los SGBD documentales o los de Base de Datos geográficas. LENGUAJES Y USUARIOS Para comunicarse con el SGBD, el usuario, ya sea un programa de aplicación o un usuario directo, se vale de un lenguaje. Hay muchos lenguajes diferentes, según el tipo de usuarios para los que están pensados y el tipo de cosas que los usuarios deben poder expresar con ellos: a) b) c) 13 Habrá usuarios informáticos muy expertos que querrán escribir procesos complejos y que necesitarán lenguajes complejos. Sin embargo, habrá usuarios finales no informáticos, ocasionales (esporádicos), que sólo harán consultas. Estos usuarios necesitarán un lenguaje muy sencillo, aunque dé un rendimiento bajo en tiempo de respuesta. También podrá haber usuarios finales no informáticos, dedicados o especializados. Son usuarios cotidianos o, incluso, dedicados exclusivamente a trabajar con la Base de Datos 13. Estos usuarios necesitarán lenguajes muy eficientes y compactos, aunque no sea fácil aprenderlos. Tal vez serán lenguajes especializados en tipos concretos de tareas. Por ejemplo, personas dedicadas a introducir datos masivamente. Base de Datos I – Unidad 01 – 2023 ¿Qué debería poder decir el usuario al SGBD? Por un lado, la persona que hace el diseño debe tener la posibilidad de describir al SGBD la Base de Datos que ha diseñado. Por otro lado, debe ser posible pedirle al sistema que rellene y actualice la base de datos con los datos que se le den. Además, y obviamente, el usuario debe disponer de medios para hacerle consultas 22 1983/2023 - 40 AÑOS DE DEMOCRACIA Hay lenguajes especializados en la escritura de esquemas; es decir, en la descripción de la Base de Datos. Se conocen genéricamente como DDL o data definition language. Incluso hay lenguajes específicos para esquemas internos, lenguajes para esquemas conceptuales y lenguajes para esquemas externos. Otros lenguajes están especializados en la utilización de la Base de Datos (consultas y mantenimiento). Se conocen como DML o data management language. Sin embargo, lo más frecuente es que el mismo lenguaje disponga de construcciones para las dos funciones, DDL y DML. El lenguaje SQL, que es el más utilizado en las Bases de Datos relacionales, tiene verbos –instrucciones– de tres tipos diferentes: 1) 2) 3) Verbos del tipo DML; por ejemplo, SELECT para hacer consultas, e INSERT, UPDATE y DELETE para hacer el mantenimiento de los datos. Verbos del tipo DDL; por ejemplo, CREATE TABLE para definir las tablas, sus columnas y las restricciones. Además, SQL tiene verbos de control del entorno, como por ejemplo COMMIT y ROLLBACK para delimitar transacciones. En cuanto a los aspectos DML, podemos diferenciar dos tipos de lenguajes: a) b) El lenguaje SQL se explicará en la unidad didáctica “El lenguaje SQL” de esta materia. Lenguajes muy declarativos (o implícitos), con los que se especifica qué se quiere hacer sin explicar cómo se debe hacer. Lenguajes más explícitos o procedimentales, que nos exigen conocer más cuestiones del funcionamiento del SGBD para detallar paso a paso cómo se deben realizar las operaciones (lo que se denomina navegar por la Base de Datos). Lenguajes declarativos y procedimentales El aprendizaje y la utilización de los lenguajes procedimentales acostumbran a ser más difíciles que los declarativos, y por ello sólo los utilizan usuarios informáticos. Con los procedimentales se pueden escribir procesos más eficientes que con los declarativos. Como es obvio, los aspectos DDL (las descripciones de los datos) son siempre declarativos por su propia naturaleza. Los lenguajes utilizados en los SGBD pre relacionales eran procedimentales. SQL es básicamente declarativo, pero tiene posibilidades procedimentales. Aunque casi todos los SGBD del mercado tienen SQL como lenguaje nativo, ofrecen otras posibilidades, como por ejemplo 4GL y herramientas visuales: Lenguajes 4GL (4th Generation Languages) 14 de muy alto nivel, que suelen combinar elementos procedimentales con elementos declarativos. Pretenden facilitar no sólo el tratamiento de la Base de Datos, sino también la definición de menús, pantallas y diálogos. 14 Empezaron a aparecer al final de los años ochenta. Base de Datos I – Unidad 01 – 2023 23 1983/2023 - 40 AÑOS DE DEMOCRACIA Herramientas o interfaces visuales15 muy fáciles de utilizar, que permiten usar las Bases de Datos siguiendo el estilo de diálogos con ventanas, iconos y ratón, puesto de moda por las aplicaciones Windows. No sólo son útiles a los usuarios no informáticos, sino que facilitan mucho el trabajo a los usuarios informáticos: permiten consultar y actualizar la Base de Datos, así como definirla y actualizar su definición con mucha facilidad y claridad. Tanto los 4GL como las herramientas visuales (con frecuencia unidas en una sola herramienta) traducen lo que hace el usuario a instrucciones SQL por distintas vías: En el caso de los 4GL, la traducción se suele hacer mediante la compilación. En el caso de las herramientas visuales, se efectúa por medio del intérprete de SQL integrado en el SGBD. Si queremos escribir un programa de aplicación que trabaje con Bases de Datos, seguramente querremos utilizar nuestro lenguaje habitual de programación 16. Sin embargo, generalmente estos lenguajes no tienen instrucciones para realizar el acceso a las Bases de Datos. Entonces tenemos las dos opciones siguientes: 1) 2) Las llamadas a funciones: en el mercado hay librerías de funciones especializadas en Bases de Datos (por ejemplo, las librerías ODBC). Sólo es preciso incluir llamadas a las funciones deseadas dentro del programa escrito con el lenguaje habitual. Las funciones serán las que se encargarán de enviar las instrucciones (generalmente en SQL) en tiempo de ejecución al SGBD. El lenguaje hospedado: otra posibilidad consiste en incluir directamente las instrucciones del lenguaje de Bases de Datos en nuestro programa. Sin embargo, esto exige utilizar un precompilador especializado que acepte en nuestro lenguaje de programación habitual las instrucciones del lenguaje de Bases de Datos. Entonces se dice que este lenguaje (casi siempre SQL) es el lenguaje hospedado o incorporado (embedded), y nuestro lenguaje de programación (Pascal, C, Cobol, etc.) es el lenguaje anfitrión (host). ADMINISTRACIÓN DE BASES DE DATOS Hay un tipo de usuario especial: el que realiza tareas de administración y control de la Base de Datos. Una empresa o institución que tenga Sistema de Información construidos en torno a Bases de Datos necesita que alguien lleve a cabo una serie de funciones centralizadas de gestión y administración, para asegurar que la explotación de la Base de Datos es la correcta. Este conjunto de funciones se conoce con el nombre de administración de Bases de Datos (ABD), y los usuarios que hacen este tipo especial de trabajo se denominan administradores de Bases de Datos. Los administradores de Bases de Datos son los responsables del correcto funcionamiento de la Base de Datos y velan por que siempre se mantenga útil. Intervienen en situaciones problemáticas o de emergencia, pero su responsabilidad fundamental es velar por que no se produzcan incidentes. A continuación, damos una lista de tareas típicas del ABD: 1) 15 16 Mantenimiento, administración y control de los esquemas. Comunicación de los cambios a los usuarios. Han proliferado en los años noventa. Pascal, C, Cobol, PL/I, Basic, MUMPS, Fortran, Java, etc. Base de Datos I – Unidad 01 – 2023 24 1983/2023 - 40 AÑOS DE DEMOCRACIA 2) 3) 4) 5) 6) 7) 8) Asegurar la máxima disponibilidad de los datos; por ejemplo, haciendo copias (back-ups), administrando diarios (journals o logs), reconstruyendo la Base de Datos, etc. Resolución de emergencias. Vigilancia de la integridad y de la calidad de los datos. Diseño físico, estrategia de caminos de acceso y reestructuraciones. Control del rendimiento y decisiones relativas a las modificaciones en los esquemas y/o en los parámetros del SGBD y del SO, para mejorarlo. Normativa y asesoramiento a los programadores y a los usuarios finales sobre la utilización de la Base de Datos. Control y administración de la seguridad: autorizaciones, restricciones, etc. LA TAREA DEL ABD NO ES SENCILLA. Los SGBD del mercado procuran reducir al mínimo el volumen de estas tareas, pero en sistemas muy grandes y críticos se llega a tener grupos de ABD de más de diez personas. Buena parte del software que acompaña el SGBD está orientado a facilitar la gran diversidad de tareas controladas por el ABD: monitores del rendimiento, monitores de la seguridad, verificadores de la consistencia entre índices y datos, reorganizadores, gestores de las copias de seguridad, etc. La mayoría de estas herramientas tienen interfaces visuales para facilitar la tarea del ABD. Base de Datos I – Unidad 01 – 2023 25 1983/2023 - 40 AÑOS DE DEMOCRACIA RESUMEN En esta unidad hemos hecho una introducción a los conceptos fundamentales del mundo de las Bases de Datos y de los SGBD. Hemos explicado la evolución de los SGBD, que ha conducido de una estructura centralizada y poco flexible a una distribuida y flexible, y de una utilización procedimental que requería muchos conocimientos a un uso declarativo y sencillo. Hemos revisado los objetivos de los SGBD actuales y algunos de los servicios que nos dan para conseguirlos. Es especialmente importante el concepto de transacción y la forma en que se utiliza para velar por la integridad de los datos. La arquitectura de tres niveles aporta una gran flexibilidad a los cambios, tanto a los físicos como a los lógicos. Hemos visto cómo un SGBD puede funcionar utilizando los tres esquemas propios de esta arquitectura. Hemos explicado que los componentes de un modelo de Bases de Datos son las estructuras, las restricciones y las operaciones. Los diferentes modelos de Bases de Datos se diferencian básicamente por sus estructuras. Hemos hablado de los modelos más conocidos, especialmente del modelo relacional, que está basado en tablas y que estudiaremos más adelante. El modelo relacional se estudiará en la unidad “El modelo relacional y el álgebra relacional” de este curso. Cada tipo de usuario del SGBD puede utilizar un lenguaje apropiado para su trabajo. Unos usuarios con una tarea importante y difícil son los administradores de las Bases de Datos. Base de Datos I – Unidad 01 – 2023 26 1983/2023 - 40 AÑOS DE DEMOCRACIA UNIDAD 02 MODELO ENTIDAD RELACIÓN El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real consistente en objetos básicos llamados entidades y de relaciones entre estos objetos. Se desarrolló para facilitar el diseño de bases de datos permitiendo la especificación de un esquema de la empresa que representa la estructura lógica completa de una base de datos. El modelo de datos E-R es uno de los diferentes modelos de datos semánticos; el aspecto semántico del modelo yace en la representación del significado de los datos. El modelo E-R es extremadamente útil para hacer corresponder los significados e interacciones de las empresas del mundo real con un esquema conceptual. El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real consistente en objetos básicos llamados entidades y de relaciones entre estos objetos. Se desarrolló para facilitar el diseño de bases de datos permitiendo la especificación de un esquema de la empresa que representa la estructura lógica completa de una base de datos. El modelo de datos E-R es uno de los diferentes modelos de datos semánticos; el aspecto semántico del modelo yace en la representación del significado de los datos. El modelo E-R es extremadamente útil para hacer corresponder los significados e interacciones de las empresas del mundo real con un esquema conceptual. OBJETOS BÁSICOS DEL MODELO E-R Los conceptos básicos previstos por el modelo ER son entidades, relaciones y atributos. ENTIDADES Y CONJUNTO DE ENTIDADES Una entidad es un objeto que existe y puede distinguirse de otros objetos. La entidad puede ser concreta, por ejemplo: una persona o un libro; o abstracta, por ejemplo, un día festivo o un concepto. Un conjunto de entidades es un grupo de entidades del mismo tipo. El conjunto de todas las personas que tienen una cuenta en el banco, por ejemplo, puede definirse como el conjunto de entidades clientes. Una entidad está representada por un conjunto de atributos. Los posibles atributos del conjunto de entidades clientes son nombre, documento, calle y ciudad. Para cada atributo existe un rango de valores permitidos, llamado dominio del atributo. El dominio del atributo nombre podría ser el conjunto de todos los nombres de personas de cierta longitud. RELACIONES Y CONJUNTO DE RELACIONES Una relación es una asociación entre varias entidades. Por ejemplo, es posible definir una relación que asocia al cliente Gutiérrez con la cuenta 401. Base de Datos I – Unidad 02 – 2023 27 1983/2023 - 40 AÑOS DE DEMOCRACIA Un conjunto de relaciones es un grupo de relaciones del mismo tipo. Se definirá el conjunto de relaciones clientecuenta para denotar la asociación entre los clientes y las cuentas bancarias que tienen. La relación clientecuenta es un ejemplo de una relación binaria, es decir, una que implica a dos conjuntos de entidades. Existen conjuntos de relaciones que incluyen a n-conjuntos de entidades, relaciones n-arias, por ejemplo, la relación ternaria cliecuentasuc que especifica que el cliente Gutiérrez tienen la cuenta 401 en la sucursal Córdoba. Las relaciones recursivas (Reflexivas) son relaciones binarias que conectan una entidad consigo misma. Una relación también puede tener atributos descriptivos o rótulos. Por ejemplo, fecha podría ser un atributo del conjunto de relaciones clientecuenta. Esto especifica la última fecha en que el cliente tuvo acceso a su cuenta. CARDINALIDADES DE MAPEO Un esquema ER empresarial puede definir ciertas limitantes con las que deben cumplir los datos contenidos en la base de datos. Una limitante importante es la de las cardinalidades de mapeo que expresan el número de entidades con las que puede asociarse otra entidad mediante una relación. Las cardinalidades de mapeo son más útiles al describir conjuntos binarios de relaciones, aunque también son aplicables a conjuntos n-arios de relaciones. Para un conjunto binario de relaciones R entre los conjuntos de entidades A y B, la cardinalidad de mapeo puede ser: Una a una: una entidad de A está asociada únicamente con una entidad de B y una entidad de B está asociada solo con una entidad de A. Una a muchas: una entidad en A está asociada con varias entidades de B, pero una entidad de B puede asociarse únicamente con una entidad de A. Base de Datos I – Unidad 02 – 2023 28 1983/2023 - 40 AÑOS DE DEMOCRACIA Muchas a una: una entidad de A está asociada únicamente con una entidad en B, pero una entidad de B está relacionada con varias entidades de A. Muchas a muchas: una entidad en A está asociada con varias entidades de B y una entidad en B está vinculada con varias entidades de A. Para ilustrar lo anterior, considérese el conjunto de relaciones clientecuenta. Si en un banco dado una cuenta puede pertenecer únicamente a un cliente y un cliente puede tener varias cuentas, entonces el conjunto de relaciones clientecuenta es una a muchas, de cliente a cuenta. Si una cuenta puede pertenecer a varios clientes, entonces el conjunto de relaciones clientecuenta es una a muchas, de cuenta a cliente, entonces en definitiva el conjunto de relaciones clientecuenta es muchas a muchas. Las dependencias de existencia constituyen otra clase importante de limitantes. Si la existencia de la entidad x depende de la existencia de la entidad y, entonces se dice que x es dependiente por existencia de y. Base de Datos I – Unidad 02 – 2023 29 1983/2023 - 40 AÑOS DE DEMOCRACIA Funcionalmente esto quiere decir que, si se elimina y, también se eliminará x. Se dice que la entidad y en una entidad dominante y que x es una entidad subordinada. Por ejemplo, supongamos que tenemos los conjuntos de entidades cuenta y transacción. Se forma la relación cuentatransac entre estos dos conjuntos es decir que para una cuenta determinada pueden existir varias transacciones. Esta relación es una a muchas de cuenta a transacción. Cada entidad transacción debe estar relacionada con una entidad cuenta. Si se elimina una entidad cuenta, entonces deben eliminarse también todas las entidades transacción vinculada con esa cuenta. Por lo contrario, pueden eliminarse entidades transacción de la base de datos sin afectar ninguna cuenta. Por lo tanto, el conjunto de entidades cuenta es dominante y transacción es subordinada en la relación cuentatransac. CLAVES PRIMARIAS Una tarea muy importante dentro de la modelación de bases de datos consiste en especificar cómo se van a distinguir las entidades y las relaciones. Conceptualmente, las entidades individuales y las relaciones son distintas entre sí, pero desde el punto de vista de una base de datos la diferencia entre ellas debe expresarse en términos de sus atributos. Para hacer estas distinciones, se asigna una clave primaria a cada conjunto de entidades, ésta es un conjunto de uno o más atributos que, juntos, permiten identificar en forma única a una entidad dentro del conjunto de entidades. Por ejemplo: el atributo documento del conjunto entidades cliente es suficiente para distinguir a una entidad cliente de otra, por lo tanto, puede ser la clave primara de ese conjunto de entidades. Es posible que un conjunto de entidades no tenga suficientes atributos para formas una clave primaria. Por ejemplo: el conjunto entidades transacción tiene tres atributos: numtransac, fecha e importe. Aunque cada entidad transacción es distinta, dos transacciones hechas en cuentas diferentes pueden tener el mismo número de transacción, entonces el conjunto entidades transacción no tienen una clave primaria. Una entidad de un conjunto de este tipo se denomina entidad débil y una entidad que puede tener una clave primaria recibe el nombre de entidad fuerte. El concepto de entidades fuertes y débiles está relacionado con el de “dependencia por existencia”. Un conjunto de entidades débiles no tiene una clave primaria sin embargo es preciso tener una forma de distinguir entre todas las entidades del conjunto, aquella que depende de una entidad fuerte de otro conjunto relacionado. El discriminador de un conjunto de entidades débiles es un conjunto de atributos que permite hacer esta distinción. Por lo tanto, para nuestro ejemplo el discriminador es numtransac ya que para cada cuenta estos números identifican en forma única cada una de las transacciones. La clave primaria de un conjunto de entidades débiles está formada por la clave primaria de la entidad fuerte de la que depende su existencia y su discriminador. En el caso del conjunto de entidades transacción, su clave primaria es (numcuenta, numtransac), donde numcuenta identifica a la entidad dominante de una transacción y numtransac distingue a las entidades transacción dentro de la misma cuenta. Los conjuntos de relaciones también tienen claves primarias. Sus claves primarias se forman tomando todos los atributos que constituyen las claves primarias de los conjuntos de entidades que definen el conjunto de relaciones. Por ejemplo: documento es la clave primaria de cliente y numcuenta es la clave primaria de cuenta. Por lo tanto, la clave primaria del conjunto de relaciones clientecuenta es (documento, numcuenta). Base de Datos I – Unidad 02 – 2023 30 1983/2023 - 40 AÑOS DE DEMOCRACIA METODOLOGÍA ESTRUCTURADA Dentro de la metodología estructurada, el Modelo Entidad Relación se encuadra en el Esquema de Datos, y el Esquema de Datos es parte del Modelo de Comportamiento, que a su vez es parte del Modelo Esencial, como podemos ver en el siguiente cuadro. Modelo del Sistema Modelo de Implementación Modelo Esencial Modelo Ambiental Modelo de Comportamiento Modelo de Implementación del Usuario Modelo de Implementación del Software Lista de Eventos Esquema de Transformaciones Especificación de Requerimientos No Funcionales Lista de Estímulos y Respuestas Esquema de Datos Especificación Tecnología de Implementación Esquema de Arquitectura Diagrama de Contexto Modelo de Procesadores Esquema Físico de Datos Propósito Prototipo de Interfaces del Sistema Modelo de Arquitectura Modelo de Componentes Especificación de Componentes ESQUEMA DE DATOS OBJETIVO: Descripción de los datos que el sistema debe conocer (recordar) para poder responder a los estímulos. Es una visión pasiva del sistema y necesita mostrar: Las relaciones entre los datos, que no pueden mostrarse en los almacenamientos del DFD, pues generan requerimientos falsos. Las especificaciones de procesos del DFD muestran todas las relaciones entre los objetos, mediante los accesos esenciales; esos accesos pueden eliminarse de la especificación, ya que serán expresados en este esquema. Detalle de los datos: Identificadores y atributos descriptivos. Base de Datos I – Unidad 02 – 2023 31 1983/2023 - 40 AÑOS DE DEMOCRACIA HERRAMIENTAS: Las herramientas usadas son: Diagrama de Entidad Relación (conocido como DER), con extensiones de súper/subtipo y tipos de objetos asociativos. A lo largo del texto hablaremos indistintamente de objetos y tipos de objetos, que serán equivalentes a las entidades del DER; de la misma manera, asumiremos que atributo y elemento de dato tienen el mismo significado. Diccionario de datos, con la siguiente composición: DD = {Objeto} + {Objeto_Asociativo} + {Objeto_Débil} + {Super_Tipo} + {Relación} + ({Estructura_de_Datos}) + {Atributo} TÉCNICAS: CONSTRUCCIÓN DEL ESQUEMA DE DATOS Esta técnica es el resultado de aplicar criterios vertidos por variados autores. Los resultados que se obtienen son mucho más "naturales" que los obtenidos con otras técnicas. El aspecto datos es más estable que el aspecto funcional, en la mayoría de los sistemas; también es mucho más difícil pensar el esquema de datos. La mayor dificultad se presenta en establecer la estructura de los objetos, y las relaciones entre los mismos; muchas veces decimos que es posible afirmar que un DER está mal, pero no puede asegurarse que un DER esté completamente bien. 1) Identificar Objetos: Un objeto es la representación de una cosa de existencia real o artificial, que interesa al sistema. Puede ser algo tangible, un rol desempeñado por una persona u organización, un incidente o una interacción. Es importante destacar que no siempre habrá una correspondencia uno a uno entre los objetos del Esquema de Datos y los objetos del mundo real (a los que hemos anteriormente llamado “cosas”). Muchos objetos reales son complejos -es decir, poseen una estructura- y están formados por otros objetos. Pensemos, por ejemplo, en un auto con sus diferentes partes. Si nos interesa registrar información de las distintas componentes del automóvil, no quedará otra alternativa que representarlos como distintos objetos en el DER. 2) Individualizar identificadores únicos de objetos: Un identificador es un atributo que confirma la existencia de un objeto dado, y la identidad de las distintas instancias del mismo. Si no puede encontrarse un identificador, o el objeto posee una sola instancia, este elemento NO ES UN OBJETO. Un objeto será débil si no es identificable por sus propios atributos y que para poder serlo requiere de uno o más atributos externos. 3) Identificar relaciones entre objetos: Una relación es una asociación esencial de la memoria para permitir los accesos esenciales y mejorar la descripción de los objetos. Generalmente las relaciones se implementan a través de atributos referenciales (Si, por ejemplo, fuésemos a implementar este esquema en una base de datos relacional, las relaciones se implementarían a través de claves foráneas). Ya que aquí estamos en la esencia, NO DEBEN utilizarse tales atributos para representar asociaciones entre objetos (por ejemplo, no debería incluirse el atributo Código de Cliente en el objeto Factura - siempre y cuando exista el objeto Cliente-). Las asociaciones se representan únicamente a través de relaciones. Base de Datos I – Unidad 02 – 2023 32 1983/2023 - 40 AÑOS DE DEMOCRACIA 4) Clasificar relaciones: Según los conceptos de: a. Grado: es la cantidad de objetos que intervienen en la relación (unaria, binaria, etc.); b. Conectividad: mapa de la asociación entre objetos (1:1, 1:N, M:N). c. Condicionalidad: indica si la participación de cada uno de los objetos en la relación es obligatoria u opcional, es decir, si existen o no instancias de los objetos intervinientes en la relación. 5) Identificar atributos (elementos de datos que el sistema maneja). 6) Asignar atributos a objetos y relaciones, materializando así la relación intra-objeto, según ese atributo describa una característica del objeto, y/o dependa funcional y no transitivamente del identificador del objeto/relación. 7) Identificar objetos asociativos. Un objeto asociativo es un elemento que se comporta como relación y como objeto al mismo tiempo. Para que exista una instancia del mismo, deben existir instancias de todos los objetos que relaciona. 8) Identificar súper/sub-tipos, agrupando objetos que posean atributos comunes y alguna condición de diferenciación. 9) Dibujar el DER, según la notación de la herramienta. 10) Eliminar elementos redundantes o fuera del alcance del sistema. 11) Generar una entrada en el Diccionario de Datos por cada elemento del DER. 12) Validar aplicando: a. Normalización, con las observaciones indicadas más adelante. b. Técnica de preguntas y respuestas. 13) Revisar el esquema con el resto del modelo. Base de Datos I – Unidad 02 – 2023 33 1983/2023 - 40 AÑOS DE DEMOCRACIA DIAGRAMA DE ENTIDAD RELACIÓN (DER) INTRODUCCIÓN Un sistema puede ser descripto de distintas formas. El sistema no cambia; lo que estamos haciendo es verlo desde distintos puntos de vista, priorizando un aspecto diferente del sistema cada vez. Mediante el DER priorizamos el aspecto datos. En el DFD hay caminos; éstos muestran el fluir de los datos, es el sistema en funcionamiento. Podemos ver que es lo que está pasando. En el DER también hay caminos, pero éstos representan las relaciones entre los distintos tipos de información que maneja el sistema; aquí no fluyen datos como en un DFD. El DER representa los datos almacenados en un sistema presentado como una red de almacenamientos conectados por relaciones; es una vista estática, se ve al sistema como una entidad pasiva. El DER de un sistema es más resistente al cambio que un DFD. Por ejemplo, en una organización, las políticas de crédito a un cliente pueden cambiar (funciones), pero la entidad Cliente sigue existiendo como tal. El DER depende del ambiente, y, por lo tanto, es menos factible que cambie. CONVENCIONES TIPO DE OBJETO (ENTIDAD): Rectángulo Es representado mediante un rectángulo con nombre. Agrupa bajo un mismo nombre un conjunto de cosas del mismo tipo pertenecientes al mundo real. Este objeto juega un rol significativo en el sistema a ser descripto, por ejemplo, Clientes, Artículos, etc. RELACIÓN: X Rombo Es representada mediante un rombo con nombre. Es el resultado de algún proceso del mundo real que vincula tipos de objetos que participan en ese proceso. Una relación es una abstracción porque ésta no describe el proceso, únicamente describe la forma en que las entidades se combinan. Sólo se define una relación entre dos o más tipos de objetos si dicha relación está basada en políticas, reglas o leyes que interesen al sistema que se modela. Base de Datos I – Unidad 02 – 2023 34 1983/2023 - 40 AÑOS DE DEMOCRACIA Las relaciones son típicamente multidireccionales, es decir, X está relacionado con Y y viceversa. Se dice que X está relacionado con Y cuando desde una ocurrencia (instancia) de X puedo obtener la/s ocurrencia/s de Y que le corresponden. El orden de la relación es M:N. Por ejemplo, si X es Departamento, Y es Empleado, y sabemos que un empleado trabaja en un solo departamento, y que en un departamento trabajan muchos empleados, el orden de la relación R (Trabaja) es 1:N. TIPO DE OBJETO ASOCIATIVO: Rectángulo unido a un Rombo Es representado mediante un rectángulo unido a un rombo. Surge cuando una relación contiene además información (Agregación / Asociación). Este tipo de objeto es una relación que además posee atributos propios. Este tipo de objeto sólo existe mientras existan los objetos que relaciona. OBJETOS O ENTIDADES DÉBILES: Rectángulo con línea doble Es representado mediante un rectángulo con línea doble. La línea de relación hacia el objeto fuerte también se dibuja doble. Un objeto que posee identificadores internos que determinan unívocamente a cada una de sus instancias es un OBJETO FUERTE. Un objeto que deriva su existencia a partir del conjunto de atributos identificadores de otro u otros objetos es un OBJETO DÉBIL. Dichos atributos también se conocen como atributos externos. SUPERTIPO Y SUBTIPOS Base de Datos I – Unidad 02 – 2023 35 1983/2023 - 40 AÑOS DE DEMOCRACIA El Supertipo es representado como un rectángulo vinculado a sus subtipos por medio de un triángulo. Es el resultado de tratar una clase de objetos similares como un nuevo tipo de objeto (Generalización / Clasificación). (Ej.: Vehículo es un supertipo compuesto de Auto y Camión). El Subtipo es una entidad. Es el resultado de tratar un subconjunto de algún tipo de objeto como un nuevo tipo de objeto (Diferenciación funcional). Consideraciones Prácticas: Para determinar si el modelo es completo, una buena forma de hacerlo es escribir todas las preguntas a las que debe responder el sistema y verificar si las relaciones del modelo permiten obtener las respuestas. Así como un DFD es erróneo cuando no produce una salida a partir de una entrada, un DER es erróneo si no puede responder a una pregunta de interés del sistema. Hay que tener mucho cuidado con el nivel de detalle bajo el cual se agrupan los datos. No debe ser ni muy detallado ni muy general. Lo importante es representar las interconexiones entre las lógicas principales dentro del área de interés del sistema. De ser muy detallado, nos damos cuenta cuando dos tipos de objetos están descriptos por los mismos atributos y tienen las mismas relaciones (Ej.: Vendedores_Internos y Vendedores_Externos que son tratados de la misma forma). De ser muy general nos damos cuenta cuando debemos identificar bajo qué condiciones son válidos determinados subconjuntos de atributos de un tipo de objeto. (Ej.: tener definido como entidad Cajas_de_Ahorro que incluye como subtipos Caja_Ahorro_Común y Caja_Ahorro_Especial, y cada una de éstas debe tener atributos específicos distintos). Reglas de Conexión: Un tipo de objeto puede o no estar conectado y si lo está, puede ser a una o más relaciones. Una relación debe conectarse a uno o más Objetos. Un objeto no puede estar conectado directamente a otro. Una relación no puede estar conectada directamente a otra. Reglas de Consistencia Interna: No puede haber tipos de objetos con el mismo nombre. Se debe tener un identificador único para cada tipo de objeto, relación, instancia de objeto e instancia de relación. No incluir relaciones irrelevantes para el sistema. Eliminar relaciones que no puedan existir en el mundo real. Eliminar relaciones que son redundantes. Un DER es consistente si puede proveer todos los datos requeridos en la aplicación de la técnica pregunta-respuesta. Reglas de Claridad Semántica: No incluir atributos irrelevantes para el sistema. Todos los atributos de una entidad que son relevantes para el sistema deben ser incluidos. Base de Datos I – Unidad 02 – 2023 36 1983/2023 - 40 AÑOS DE DEMOCRACIA Si un objeto sólo tiene su identificación como atributo, quizás sea conveniente eliminarlo e incluir la información en otra Entidad. Agrupar en súper / subtipos los objetos que dependen de relaciones idénticas. Base de Datos I – Unidad 02 – 2023 37 1983/2023 - 40 AÑOS DE DEMOCRACIA MISCELÁNEAS Es necesario incluir en el DD la información de todos los elementos del DER del sistema. A continuación, detallamos las convenciones a utilizar (que es un grupo de los tantos posibles). Agregaremos un “@” a los atributos que sirvan como identificación al tipo de objeto (Clave), y “ref” a dichos atributos cuando figuran en una relación. TIPO_DE_OBJETO = Significado + @Identificador + {Atributos} TIPO_DE_OBJETO_ASOCIATIVO = Significado + @Identificador-Ref-N + @Identificador-Ref-M + {Atributos} SUPERTIPO = Significado + Atributos_Comunes + {Subtipos} SUBTIPO = * Idem Tipo de Objeto * RELACIÓN = Significado + [@Identificador-Ref-1 + @Identificador-Ref-1 * Caso 1:1 * | @Identificador-Ref-1 + @Identificador-Ref-N * Caso 1:N * | @Identificador-Ref-M + @Identificador-Ref-N * Caso M:N *] CONVENCIONES Notación para describir la composición de los elementos del DD: =... está compuesto por... +... y... [|] o exclusivo. {} repetición (en la llave izquierda desde; en la derecha, hasta). () opcional. ** comentario. NORMALIZACIÓN EN LA CONSTRUCCIÓN DEL ESQUEMA DE DATOS. Para detectar objetos y para eliminar redundancias, podemos valernos de alguna de las técnicas de normalización. El problema consiste en que la mayoría de dichas técnicas tienen como objetivo construir un esquema procesable, introduciendo factores tecnológicos que, a este nivel, están prohibidos. Uno de estos factores es el generado por la primera forma normal, que impide la existencia de grupos repetitivos. Para poder solucionar estos problemas, se sugiere lo siguiente: Utilizar una técnica de normalización que permita trabajar con relaciones anidadas (o sea, elementos repetitivos). Utilizar una técnica de normalización tradicional y luego volver a desnormalizar las relaciones anidadas. Base de Datos I – Unidad 02 – 2023 38 1983/2023 - 40 AÑOS DE DEMOCRACIA En ambos casos se deberá testear con el usuario si los nuevos objetos o relaciones son válidos para el dominio de información del sistema. Además, se aplique o no una técnica de normalización, el concepto de dependencia funcional es muy útil para la construcción del Esquema. EJEMPLO Ilustración 1 Diagrama Entidad Relación Tabla 1 Ejemplo de Diccionario de Datos Empleado = @Legajo + Nombre + Sueldo Habitación = @Identificador + Número + Ubicación + Capacidad + Categoría Hotel = @Nombre + @Ciudad Obra_Social = @Nombre + ImporteDesde + ImporteHasta Pasajero = @ID + TipoDoc + NroDoc + Nombre + NroTarjetaCredito Reserva = @FechaDesde + FechaHasta + NroPersonas + @Pasajero_ref_Nc + @Habitación_ref_M Base de Datos I – Unidad 02 – 2023 39 1983/2023 - 40 AÑOS DE DEMOCRACIA ANEXO A: TÉCNICA DE PREGUNTAS Y RESPUESTAS La técnica de preguntas y respuestas consiste en verificar si las respuestas a una lista de preguntas propuestas por el usuario se encuentran contempladas en el esquema de datos construido. EJEMPLO: La editorial ABC trabaja con varios y diferentes autores quienes escriben los libros que serán publicados. Algunos autores escriben solo un libro, mientras los otros han escrito varios. La editorial también trabaja con varias imprentas. Distintas ediciones de un libro pueden ser realizadas por distintas imprentas. Se desea guardar la fecha de cada edición y la cantidad de ejemplares editados en la misma. Un editor de esta compañía trabaja con varios autores a la vez, editando y produciendo los libros; es el trabajo del editor preparar la última copia revisada pasada a máquina y lista para ser impresa. DICCIONARIO DE DATOS AUTOR = @id_autor + nombre + dirección + tel. +... EDICION = LIBRO-ref-N + IMPRENTA-ref-M + fecha edición + cant.ejemplares EDITOR = @id_editor+ nombre + … IMPRENTA = @id_imprenta + dirección + tel +... LIBRO = @ISBN + título + género Ahora se aplica la técnica de preguntas y respuestas. El usuario desea saber: 1) Qué libros editó cada editor en un determinado momento. 2) a. Que libros escribió cierto autor, b. en un determinado periodo 3) a. Cuál es el autor de un determinado libro, Base de Datos I – Unidad 02 – 2023 40 1983/2023 - 40 AÑOS DE DEMOCRACIA b. Dónde y cuándo nació dicho autor. 4) En qué imprenta se imprimió cierto libro. 5) a. Cuántos ejemplares de un cierto libro se imprimieron en una imprenta. b. en una cierta fecha o período. 6) Con qué editor trabaja cada autor en este momento. 7) a. Con qué editor trabajó cierto autor en una determinada fecha. b. Cuántas veces trabajó con dicho autor y por cuánto tiempo. 8) Con qué imprentas se relaciona un editor, por los libros con los que está trabajando. 9) Cuál es el género en el que se especializa ahora cada editor. En la forma en que está construido el esquema de datos, hay preguntas que no se pueden responder, por ejemplo: - - Para contestar la pregunta 2b, debería agregarse en el diccionario de datos de LIBRO, la fecha en la cual el mismo se realizó. Para contestar la pregunta 3b, debería agregarse en el diccionario de datos de AUTOR, lugar y fecha de nacimiento. Para contestar las preguntas 6, 7a, 7b, y 8, debería agregarse en un objeto asociativo entre EDITOR y AUTOR que contenga el identificador de cada uno de ellos más un conjunto repetitivo que incluye la fecha de comienzo del trabajo más la duración. Para contestar la pregunta 9, debería agregarse en el diccionario de datos de EDITOR, el o los géneros en que se especializa. Luego de estas modificaciones se obtendría: DICCIONARIO DE DATOS AUTOR = @id_autor + nombre + dirección + tel. + fecha_nac +lugar_nac EDICION = LIBRO-ref-N + IMPRENTA-ref-M + fecha edición +cant.ejemplares EDITOR = @id_editor+ nombre + {género} IMPRENTA = @id_imprenta + dirección + tel +... Base de Datos I – Unidad 02 – 2023 41 1983/2023 - 40 AÑOS DE DEMOCRACIA LIBRO = @ISBN + título + género + fecha_escritura REGISTRO = AUTOR-ref-M + EDITOR-ref-1 + fecha_comienzo_trabajo + duración Base de Datos I – Unidad 02 – 2023 42 1983/2023 - 40 AÑOS DE DEMOCRACIA ANEXO B: CICLO DE VIDA CENTRADO EN LOS DATOS 17 Planificación de Bases de Datos Definición del Sistema Recopilación y análisis de requerimientos Diseño de BBDD Diseño Conceptual de Bases de Datos Selección de SGBD Diseño Lógico de Bases de Datos Diseño de Aplicación Diseño Físico de Base de Datos Prototipado Implementación Conversión de Datos y Carga Testing Mantinimiento Operacional 17 Database Systems - A Practical Approach to Design, Implementation, and Management – Chapter 10 Base de Datos I – Unidad 02 – 2023 43 1983/2023 - 40 AÑOS DE DEMOCRACIA UNIDAD 03 EL MODELO RELACIONAL INTRODUCCIÓN Esta unidad didáctica está dedicada al estudio del modelo de datos relacional. El concepto de modelo de datos se ha presentado en otra unidad didáctica. En ésta se profundiza en un modelo de datos concreto: el modelo relacional, que actualmente tiene una gran relevancia. Sus conceptos fundamentales están bien asentados y, además, los sistemas de gestión de bases de datos relacionales son los más extendidos en su utilización práctica. Por estos motivos pensamos que es importante conocerlo. El estudio del modelo relacional sirve, además, de base para los contenidos de otra unidad, dedicada al lenguaje SQL. Este lenguaje permite definir y manipular bases de datos relacionales. Los fundamentos del modelo relacional resultan imprescindibles para conseguir un buen dominio del SQL. OBJETIVOS En los materiales didácticos de esta unidad encontraremos las herramientas indispensables para alcanzar los siguientes objetivos: 1. 2. 3. Conocer los fundamentos del modelo de datos relacional. Saber distinguir las características que debe tener un sistema de gestión de bases de datos relacional para que sea coherente con los fundamentos del modelo relacional. Comprender las ventajas del modelo relacional que derivan del alto grado de independencia de los datos que proporciona, y de la simplicidad y la uniformidad del modelo. INTRODUCCIÓN AL MODELO RELACIONAL El modelo relacional es un modelo de datos y, como tal, tiene en cuenta los tres aspectos siguientes de los datos: La estructura, que debe permitir representar la información que nos interesa del mundo real. La manipulación, a la que da apoyo mediante las operaciones de actualización y consulta de los datos. La integridad, que es facilitada mediante el establecimiento de reglas de integridad; es decir, condiciones que los datos deben cumplir. Un sistema de gestión de bases de datos relacional (SGBDR) da apoyo a la definición de datos mediante la estructura de los datos del modelo relacional, así como a la manipulación de estos datos con las operaciones del modelo; además, asegura que se satisfacen las reglas de integridad que el modelo relacional establece. Los principios del modelo de datos relacional fueron establecidos por E.F. Codd en los años 1969 y 1970. De todos modos, hasta la década de los ochenta no se empezaron a comercializar los primeros SGBD relacionales con Base de Datos I – Unidad 03 – 2023 44 1983/2023 - 40 AÑOS DE DEMOCRACIA rendimientos aceptables. Cabe señalar que los SGBD relacionales que se comercializan actualmente todavía no soportan todo lo que establece la teoría relacional hasta el último detalle. El principal objetivo del modelo de datos relacional es facilitar que la base de datos sea percibida o vista por el usuario como una estructura lógica que consiste en un conjunto de relaciones y no como una estructura física de implementación. Esto ayuda a conseguir un alto grado de independencia de los datos. Un objetivo adicional del modelo es conseguir que esta estructura lógica con la que se percibe la base de datos sea simple y uniforme. Con el fin de proporcionar simplicidad y uniformidad, toda la información se representa de una única manera: mediante valores explícitos que contienen las relaciones (no se utilizan conceptos como por ejemplo apuntadores entre las relaciones). Con el mismo propósito, todos los valores de datos se consideran atómicos; es decir, no es posible descomponerlos. Hay que precisar que un SGBD relacional, en el nivel físico, puede emplear cualquier estructura de datos para implementar la estructura lógica formada por las relaciones. En particular, a nivel físico, el sistema puede utilizar apuntadores, índices, etc. Sin embargo, esta implementación física queda oculta al usuario. En los siguientes apartados estudiaremos la estructura de los datos, las operaciones y las reglas de integridad del modelo relacional. Hay dos formas posibles de

BBDD1_2023-1-97.pdf

Document Details

Related

Full Transcript

Upgrade to continue