BASE DE DATOS 1

1. INTRODUCCIN 1.1. Concepto y origen de las BD y de los SGBD 1.2. Evolucin de los SGBD Los aos sesenta y setenta: sistemas centralizados Los aos ochenta: SGBD relacionales Los aos noventa: distribucin, C/S y 4GL Tendencias actuales 1.3. Objetivos y servicios de los SGBD Consultas no predefinidas y complejas Flexibilidad e independencia Problemas de la redundancia Integridad de los datos Concurrencia de usuarios Seguridad Otros objetivos 1.4. Arquitectura de los SGBD Esquemas y niveles Independencia de los datos Flujo de datos y de control 1.5. Lenguajes y usuarios DDL DML Usuarios informticos muy expertos Usuarios finales no informticos ocasionales Usuarios finales no informticos dedicados 1.7. Administracin de BD Funciones del ABD 2. MODELOS DE BASE DE DATOS 2.1. Modelo Plano o tabla (flat) 2.2. Modelo relacional, 2.3. Modelo jerrquico, 2.4. Modelo en red 2.5. Modelo relacional con objetos 2.6. Modelo Dimensional
Equipo Tlatempa Galeana Renato Levi Valentn, Trabajo realizado ( 1.1, 1.3, 1.7). Brenda Guadalupe Cuevas Bernabe, Trabajo realizado (2.4, 2.6 ) Giovanny Vasquez Sanchez, Trabajo realizado (1.2,1.5) Claudia Garcia Ponce, Trabajo realizado (2.1,2.3)

1.1 Concepto y origen de las BD y de los SGBD Conceptos. Base de datos (BD). Una base de datos es un conjunto estructurado de datos que representa entidades y sus interrelaciones. La representacin ser nica e integrada,a pesar de que debe permitir utilizaciones varias y simultneas. Sistema de gestin de bases de datos (SGBD). Un sistema de gestin de bases de datos es una herramienta de software (conjunto de programas) que permite la creacin y manipulacin de bases de datos. Orgenes. Las aplicaciones informticas de los aos sesenta acostumbraban a darse totalmente por lotes (batch) y estaban pensadas para una tarea muy especfica relacionada con muy pocas entidades tipo. Cada aplicacin (una o varias cadenas de programas) utilizaba ficheros de movimientos para actualizar (creando una copia nueva) y/o para consultar uno o dos ficheros maestros o, excepcionalmente, ms de dos. Cada programa trataba como mximo un fichero maestro, que sola estar sobre cinta magntica y, en consecuencia, se trabajaba con acceso secuencial. A medida que se fueron introduciendo las lneas de comunicacin, los terminales y los discos, se fueron escribiendo programas que permitan a varios usuarios consultar los mismos ficheros on-line y de forma simultnea. Ms adelante fue surgiendo la necesidad de hacer las actualizaciones tambin on-line. A medida que se integraban las aplicaciones, se tuvieron que interrelacionar sus ficheros y fue necesario eliminar la redundancia. El nuevo conjunto de ficheros se deba disear de modo que estuviesen interrelacionados; al mismo tiempo, las informaciones redundantes (como por ejemplo, el nombre y la direccin de los clientes o el nombre y el precio de los productos), que figuraban en los ficheros de ms de una de las aplicaciones, deban estar ahora en un solo lugar. Estos conjuntos de ficheros interrelacionados, con estructuras complejas y compartidos por varios procesos de forma simultnea (unos on-line y otros por lotes), recibieron al principio el nombre de Data Banks, y despus, a inicios de los aos setenta, el de Data Bases. Aqu los denominamos bases de datos (BD). El software de gestin de ficheros era demasiado elemental para dar satisfaccin a todas estas necesidades. Por ejemplo, el tratamiento de las interrelaciones no estaba previsto, no era posible que varios usuarios actualizaran datos simultneamente, etc. La utilizacin de estos conjuntos de ficheros por parte de los programas de aplicacin era excesivamente compleja, de modo que, especialmente durante la segunda mitad de los aos setenta, fue saliendo al mercado software ms sofisticado: los Data Base Management Systems, que aqu denominamos sistemas de gestin de BD (SGBD).

1.2. Evolucin de los SGBD

Para entender mejor qu son los SGBD, haremos un repaso de su evolucin desde los aos sesenta hasta nuestros das. Los aos sesenta y setenta: sistemas centralizados Los primeros SGBD en los aos sesenta todava no se les denominaba asestaban orientados a facilitar la utilizacin de grandes conjuntos de datos en los que las interrelaciones eran complejas. El arquetipo de aplicacin era el Bill of materials o Parts explosion, tpica en las industrias del automvil, en la construccin de naves espaciales y en campos similares. Estos sistemas trabajaban exclusivamente por lotes (batch). Al aparecer los terminales de teclado, conectados al ordenador central mediante una lnea telefnica, se empiezan a construir grandes aplicaciones on-line transaccionales (OLTP). Los SGBD estaban ntimamente ligados al software de comunicaciones y de gestin de transacciones. Puesto que los programas estaban relacionados con el nivel fsico, se deban modificar continuamente cuando se hacan cambios en el diseo y la organizacin de la BD. La preocupacin bsica era maximizar el rendimiento: el tiempo de respuesta y las transacciones por segundo. Los aos ochenta: SGBD relacionales Los ordenadores minis, en primer lugar, y despus los ordenadores micros, extendieron la informtica a prcticamente todas las empresas e instituciones. Esto exiga que el desarrollo de aplicaciones fuese ms sencillo. Los SGBD de los aos setenta eran demasiado complejos e inflexibles, y slo los poda utilizar un personal muy cualificado. La aparicin de los SGBD relacionales* supone un avance importante para facilitar la programacin de aplicaciones con BD y para conseguir que los programas sean independientes de los aspectos fsicos de la BD. Los aos noventa: distribucin, C/S y 4GL Al acabar la dcada de los ochenta, los SGBD relacionales ya se utilizaban prcticamente 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 prerrelacionales. 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 ordenadores departamentales y personales, y han ido haciendo aplicaciones con BD. El resultado ha sido que en el seno de la empresa hay numerosas BD y varios SGBD de diferentes tipos o proveedores. Este fenmeno de multiplicacin de las BD y de los SGBD se ha visto incrementado por la fiebre de las fusiones de empresas. La necesidad de tener una visin global de la empresa y de interrelacionar diferentes aplicaciones que utilizan BD diferentes, junto con la facilidad que dan las redes para la intercomunicacin entre ordenadores, ha conducido a los SGBD actuales, que permiten que un programa pueda trabajar con diferentes BD como si se tratase de una sola. Es lo que se conoce

como base de datos distribuida. Esta distribucin ideal se consigue cuando las diferentes BD son soportadas por una misma marca de SGBD, es decir, cuando hay homogeneidad.

Adems de esta distribucin impuesta, al querer tratar de forma integrada distintas BD preexistentes, tambin se puede hacer una distribucin deseada, diseando una BD distribuida fsicamente, y con ciertas partes replicadas en diferentes sistemas. Las razones bsicas por las que interesa esta distribucin son las siguientes: 1) Disponibilidad. La disponibilidad de un sistema con una BD distribuida puede ser ms alta, porque si queda fuera de servicio uno de los sistemas, los dems seguirn funcionando. Si los datos residentes en el sistema no disponible estn replicados en otro sistema, continuarn estando disponibles. En caso contrario, slo estarn disponibles los datos de los dems sistemas.

2) Coste. Una BD distribuida puede reducir el coste. En el caso de un sistema centralizado, todos los equipos usuarios, que pueden estar distribuidos por distintas y lejanas reas geogrficas, estn conectados al sistema central por medio de lneas de comunicacin. La tecnologa 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, actan de forma que uno tiene el papel de cliente o peticionario de un servicio, y el otro el de servidor o proveedor del servicio. 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 tambin de servidor de un servicio que le pida otro proceso C (o incluso el B, que en esta peticin sera el cliente). Incluso el cliente y el servidor pueden residir en un mismo sistema.

Tendencias actuales Hoy da, los SGBD relacionales estn en plena transformacin para adaptarse a tres tecnologas de xito reciente, fuertemente relacionadas: la multimedia, la de orientacin a objetos (OO) e Internet y la web. Los tipos de datos que se pueden definir en los SGBD relacionales de los aos ochenta y noventa son muy limitados. La incorporacin de tecnologas multimedia imagen y sonido en los SI hace necesario que los SGBD relacionales acepten atributos de estos tipos. Sin embargo, algunas aplicaciones no tienen suficiente con la incorporacin de tipos especializados en multimedia. Necesitan tipos complejos que el desarrollador pueda definir a medida de la aplicacin. En definitiva, se necesitan tipos abstractos de datos: TAD. Los SGBD ms recientes ya incorporaban esta posibilidad, y abren un amplio mercado de TAD predefinidos o libreras de clases. Esto nos lleva a la orientacin a objetos (OO). El xito de la OO al final de los aos ochenta, en el desarrollo de software bsico, en las aplicaciones de ingeniera industrial y en la construccin de interfaces grficas con los usuarios, ha hecho que durante la dcada de los

noventa se extendiese en prcticamente todos los campos de la informtica. En los SI se inicia tambin la adopcin, tmida de momento, de la OO. La utilizacin de lenguajes como C++ o Java requiere que los SGBD relacionales se adapten a ellos con interfaces adecuadas. Durante estos ltimos aos se ha empezado a extender un tipo de aplicacin de las BD denominado Data Warehouse, o almacn de datos, que tambin produce algunos cambios en los SGBD relacionales del mercado. A lo largo de los aos que han trabajado con BD de distintas aplicaciones, las empresas han ido acumulando gran cantidad de datos de todo tipo. Si estos datos se analizan convenientemente pueden dar informacin valiosa*.

1.3 Objetivos y servicios de los SGBD

Los SGBD que actualmente estn en el mercado pretenden satisfacer un conjunto de objetivos directamente deducibles de lo que hemos explicado hasta ahora. Los usuarios podrn hacer consultas de cualquier tipo y complejidad directamente al SGBD. El SGBD tendr que responder inmediatamente sin que estas consultas estn preestablecidas; es decir, sin que se tenga que escribir, compilar y ejecutar un programa especfico para cada consulta. Flexibilidad e independencia La complejidad de las BD y la necesidad de irlas adaptando a la evolucin del SI hacen que un objetivo bsico de los SGBD sea dar flexibilidad a los cambios. Interesa obtener la mxima independencia posible entre los datos y los procesos usuarios para que se pueda llevar a cabo todo tipo de cambios tecnolgicos y variaciones en la descripcin de la BD, sin que se deban modificar los programas de aplicacin 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 informticos que escriben programas que las llevan incorporadas, deben poder desconocer las caractersticas fsicas de la BD con que trabajan. No necesitan saber nada sobre el soporte fsico, ni estar al corriente de qu SO se utiliza, qu ndices hay, la compresin o no compresin de datos, etc. De este modo, se pueden hacer cambios de tecnologa y cambios fsicos para mejorar el rendimiento sin afectar a nadie. Este tipo de independencia recibe el nombre de independencia fsica de los datos. Problemas de la redundancia En el mundo de los ficheros tradicionales, cada aplicacin utilizaba su fichero. Sin embargo, puesto que se daba mucha coincidencia de datos entre aplicaciones, se produca tambin mucha redundancia entre los ficheros. Ya hemos dicho que uno de los objetivos de los SGBD es facilitar la eliminacin de la redundancia. As pues, el verdadero problema es el grave riesgo de inconsistencia o incoherencia de los datos; es decir, la prdida de integridad que las actualizaciones pueden provocar cuando existe redundancia.

Por lo tanto, convendra evitar la redundancia. En principio, nos conviene hacer que un dato slo figure una vez en la BD. Sin embargo, esto no siempre ser cierto. Por ejemplo, para representar una interrelacin entre dos entidades, se suele repetir un mismo atributo en las dos, para que una haga referencia a la otra. El SGBD debe permitir que el diseador defina datos redundantes, pero entonces tendra que ser el mismo SGBD el que hiciese automticamente la actualizacin de los datos en todos los lugares donde estuviesen repetidos. 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 prdida de integridad de los datos, pero no es la nica causa posible. Se podra perder la correccin o la consistencia de los datos por muchas otras razones: errores de programas, errores de operacin humana, avera de disco, transacciones incompletas por corte de alimentacin elctrica, etc. Cuando el SGBD detecte que un programa quiere hacer una operacin que va contra las reglas establecidas al definir la BD, no se lo deber permitir, y le tendr que devolver un estado de error. Al disear una BD para un SI concreto y escribir su esquema, no slo definiremos los datos, sino tambin las reglas de integridad que queremos que el SGBD haga cumplir. Concurrencia de usuarios Un objetivo fundamental de los SGBD es permitir que varios usuarios puedan acceder concurrentemente a la misma BD. Para tratar los accesos concurrentes, los SGBD utilizan el concepto de transaccin de BD, concepto de especial utilidad para todo aquello que hace referencia a la integridad de los datos, como veremos a continuacin. Denominamos transaccin de BD o, simplemente, transaccin un conjunto de operaciones simples que se ejecutan como una unidad. Los SGBD deben conseguir que el conjunto de operaciones de una transaccin nunca se ejecute parcialmente. O se ejecutan todas, o no se ejecuta ninguna. Seguridad Actualmente, en el campo de los SGBD, el trmino 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 SI militares, las agencias de informacin y en mbitos similares, pero durante los aos noventa han ido adquiriendo importancia en cualquier SI donde se almacenen datos sobre personas. Recordad que en el Estado espaol tenemos una ley*, que exige la proteccin de la confidencialidad de estos datos. Los SGBD permiten definir autorizaciones o derechos de acceso a diferentes niveles: al nivel global de toda la BD, al nivel entidad y al nivel atributo. 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 las nuevas tecnologas. Como ya hemos visto, en estos momentos podramos citar como objetivos nuevos o recientes los siguientes: 1) Servir eficientemente los Data Warehouse. 2) Adaptarse al desarrollo orientado a objetos. 3) Incorporar el tiempo como un elemento de caracterizacin de la informacin. 4) Adaptarse al mundo de Internet.

1.4. Arquitectura de los SGBD Esquemas y niveles

Para trabajar con nuestras BD, los SGBD necesitan conocer su estructura (qu entidades tipo habr, qu atributos tendrn, etc.). Los SGBD necesitan que les demos una descripcin o definicin de la BD. Esta descripcin recibe el nombre de esquema de la BD, y los SGBD la tendrn continuamente a su alcance. El esquema de la BD es un elemento fundamental de la arquitectura de un SGBD que permite independizar el SGBD de la BD; de este modo, se puede cambiar el diseo de la BD (su esquema) sin tener que hacer ningn cambio en el SGBD. Anteriormente, ya hemos hablado de la distincin entre dos niveles de representacin informtica: el nivel lgico y el fsico. En el periodo 1975-1982, ANSI intentaba establecer las bases para crear estndares en el campo de las BD. El comit conocido como ANSI/SPARC recomend que la arquitectura de los SGBD previese tres niveles de descripcin de la BD, no slo dos. De acuerdo con la arquitectura ANSI/SPARC, deba haber tres niveles de esquemas (tres niveles de abstraccin). La idea bsica de ANSI/SPARC consista en descomponer el nivel lgico en dos: el nivel externo y el nivel conceptual. Denominbamos nivel interno lo que aqu hemos denominado nivel fsico. De este modo, de acuerdo con ANSI/SPARC, habra los tres niveles de esquemas que mencionamos a continuacin: a) En el nivel externo se sitan las diferentes visiones lgicas que los procesos usuarios (programas de aplicacin y usuarios directos) tendrn de las partes de la BD que utilizarn. Estas visiones se denominan esquemas externos. b) En el nivel conceptual hay una sola descripcin lgica bsica, nica y global, que denominamos esquema conceptual, y que sirve de referencia para el resto de los esquemas. c) En el nivel fsico hay una sola descripcin fsica, que denominamos esquema interno.

El esquema conceptual corresponde a las necesidades del conjunto de la empresa o del SI, por lo que se escribir de forma centralizada durante el denominado diseo lgico de la BD. Al definir un esquema externo, se citarn slo 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. El esquema interno o fsico contendr la descripcin de la organizacin fsica de la BD: caminos de acceso (ndices, hashing, apuntadores, etc.), codificacin de los datos, gestin del espacio, tamao de lapgina, etc. De acuerdo con la arquitectura ANSI/SPARC, para crear una BD hace falta definir previamente su esquema conceptual, definir como mnimo 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 organizacin fsica. El SGBD se encargar de hacer las correspondencias (mappings) entre los tres niveles de esquemas. Independencia de los datos En este subapartado veremos cmo la arquitectura de tres niveles que acabamos de presentar nos proporciona los dos tipos de independencia de los datos: la fsica y la lgica. Hay independencia fsica cuando los cambios en la organizacin fsica de la BD no afectan al mundo exterior (es decir, los programas usuarios o los usuarios directos). De acuerdo con la arquitectura ANSI/SPARC, habr independencia fsica cuando los cambios en el esquema interno no afecten al esquema conceptual ni a los esquemas externos.

Si hay independencia fsica de los datos, lo nico que variar al cambiar el esquema interno son las correspondencias entre el esquema conceptual y el interno. Obviamente, la mayora de los cambios del esquema interno obligarn a rehacer la BD real (la fsica). Flujo de datos y de control Para entender el funcionamiento de un SGBD, a continuacin veremos los principales pasos de la ejecucin de una consulta sometida al SGBD por un programa de aplicacin. Explicaremos las lneas generales del flujo de datos y de control entre el SGBD, los programas de usuario y la BD.

El proceso que se sigue es el siguiente: a) Empieza con una llamada (1) del programa al SGBD, en la que se le enva la operacin de consulta. El SGBD debe verificar que la sintaxis de la operacin recibida sea correcta, que el usuario del programa est autorizado a hacerla, etc. Para poder llevar a cabo todo esto, el SGBD se basa (2) en el esquema externo con el que trabaja el programa y en el esquema conceptual. b) Si la consulta es vlida, el SGBD determina, consultando el esquema interno (3), qu mecanismo debe seguir para responderla. Ya sabemos que el programa usuario no dice nada respecto a cmo se debe hacer fsicamente la consulta. Es el SGBD el que lo debe determinar. d) Ahora, la pgina deseada ya est en la memoria principal. El SGBD extrae, de entre los distintos registros que la pgina puede contener, el registro buscado, e interpreta la codificacin y el resultado segn lo que diga el esquema interno. e) El SGBD aplica a los datos las eventuales transformaciones lgicas que implica el esquema externo (tal vez cortando la direccin por la derecha) y las lleva al rea de trabajo del programa (6). f) A continuacin, el SGBD retorna el control al programa (7) y da por terminada la ejecucin de la consulta.

1.5. Lenguajes y usuarios

Para comunicarse con el SGBD, el usuario, ya sea un programa de aplicacin o un usuario directo, se vale de un lenguaje. Hay muchos lenguajes diferentes, segn el tipo de usuarios para los que estn pensados y el tipo de cosas que los usuarios deben poder expresar con ellos: a) Habr usuarios informticos muy expertos que querrn escribir procesos complejos y que necesitarn lenguajes complejos. b) Sin embargo, habr usuarios finales no informticos, ocasionales (espordicos), que slo harn consultas. Estos usuarios necesitarn un lenguaje muy sencillo, aunque d un rendimiento bajo en tiempo de respuesta. c) Tambin podr haber usuarios finales no informticos, dedicados o especializados. Son usuarios cotidianos o, incluso, dedicados exclusivamente a trabajar con la BD*. Estos usuarios necesitarn lenguajes muy eficientes y compactos, aunque no sea fcil aprenderlos. Tal vez sern lenguajes especializados en tipos concretos de tareas. El lenguaje SQL, que es el ms utilizado en las BD relacionales, tiene verbos instrucciones de tres tipos diferentes: 1) Verbos del tipo DML; por ejemplo, SELECT para hacer consultas, e INSERT, UPDATE y DELETE para hacer el mantenimiento de los datos. 2) Verbos del tipo DDL; por ejemplo, CREATE TABLE para definir las tablas, sus columnas y las restricciones. 3) Adems, 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) Lenguajes muy declarativos (o implcitos), con los que se especifica qu se quiere hacer sin explicar cmo se debe hacer. b) Lenguajes ms explcitos o procedimentales, que nos exigen conocer ms cuestiones del funcionamiento del SGBD para detallar paso a paso cmo se deben realizar las operaciones (lo que se denomina navegar por la BD). Los lenguajes utilizados en los SGBD prerrelacionales eran procedimentales. SQL es bsicamente 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: 1) Lenguajes 4GL (4th Generation Languages)* de muy alto nivel, que suelen combinar elementos procedimentales con elementos declarativos. Pretenden facilitar no slo el tratamiento de la BD, sino tambin la definicin de mens, pantallas y dilogos. 2) Herramientas o interfaces visuales** muy fciles de utilizar, que permiten usar las BD siguiendo el estilo de dilogos con ventanas, iconos y ratn, puesto de moda por las aplicaciones Windows. No slo son tiles a los usuarios no informticos, sino que facilitan mucho el trabajo a los usuarios informticos: permiten consultar y actualizar la BD, as como definirla y actualizar su definicin con mucha facilidad y claridad.

Si queremos escribir un programa de aplicacin que trabaje con BD, seguramente querremos utilizar nuestro lenguaje habitual de programacin. Sin embargo, generalmente estos lenguajes no tienen instrucciones para realizar el acceso a las BD. Entonces tenemos las dos opciones siguientes: 1) Las llamadas a funciones: en el mercado hay libreras de funciones especializadas en BD (por ejemplo, las libreras ODBC). Slo es preciso incluir llamadas a las funciones deseadas dentro del programa escrito con el lenguaje habitual. Las funciones sern las que se encargarn de enviar las instrucciones (generalmente en SQL) en tiempo de ejecucin al SGBD. 2) El lenguaje hospedado: otra posibilidad consiste en incluir directamente las instrucciones del lenguaje de BD en nuestro programa. Sin embargo, esto exige utilizar un precompilador especializado que acepte en nuestro lenguaje de programacin habitual las instrucciones del lenguaje de BD. Entonces se dice que este lenguaje (casi siempre SQL) es el lenguaje hospedado o incorporado (embedded), y nuestro lenguaje de programacin (Pascal, C, Cobol, etc.) es el lenguaje anfitrin (host). 1.7 Administracin de BD Los administradores de BD son los responsables del correcto funcionamiento de la BD y velan para que siempre se mantenga til. Intervienen en situaciones problemticas o de emergencia, pero su responsabilidad fundamental es velar para que no se produzcan incidentes. A continuacin damos una lista de tareas tpicas del ABD: 1) Mantenimiento, administracin y control de los esquemas. Comunicacin de los cambios a los usuarios. 2) Asegurar la mxima disponibilidad de los datos; por ejemplo, haciendo copias (back-ups), administrando diarios (journals o logs), reconstruyendo la BD, etc. 3) Resolucin de emergencias. 4) Vigilancia de la integridad y de la calidad de los datos. 5) Diseo fsico, estrategia de caminos de acceso y reestructuraciones. 6) Control del rendimiento y decisiones relativas a las modificaciones en los esquemas y/o en los parmetros del SGBD y del SO, para mejorarlo. 7) Normativa y asesoramiento a los programadores y a los usuarios finales sobre la utilizacin de la BD. 8) Control y administracin de la seguridad: autorizaciones, restricciones, etc. La tarea del ABD no es sencilla. Los SGBD del mercado procuran reducir al mnimo el volumen de estas tareas, pero en sistemas muy grandes y crticos se llega a tener grupos de ABD de ms de diez personas. Buena parte del software que acompaa 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 mayora de estas herramientas tienen interfaces visuales para facilitar la tarea del ABD. Hay un tipo de usuario especial: el que realiza tareas de administracin y control de la BD. Una empresa o institucin que tenga SI construidos en torno a BD necesita que alguien lleve a cabo una serie de funciones centralizadas de gestin y administracin, para asegurar que la explotacin de la BD es la correcta.

2. MODELOS DE BASE DE DATOS

2.1 Modelo plano o tabla Tabla en las bases de datos, se refiere al tipo de modelado de datos, donde se guardan los datos recogidos por un programa. Su estructura general se asemeja a la vista general de un programa de Hoja de clculo. Las tablas se componen de dos estructuras: Registro: es cada una de las filas en que se divide la tabla. Cada registro contiene datos de los mismos tipos que los dems registros. Ejemplo: en una tabla de nombres y direcciones, cada fila contendr un nombre y una direccin. Campo: es cada una de las columnas que forman la tabla. Contienen datos de tipo diferente a los de otros campos. En el ejemplo anterior, un campo contendr un tipo de datos nico, como una direccin, o un nmero de telfono, un nombre, etc. A los campos se les puede asignar, adems, propiedades especiales que afectan a los registros insertados. El campo puede ser definido como ndice o auto incrementable, lo cual permite que los datos de ese campo cambien solos o sea el principal indicar a la hora de ordenar los datos contenidos. Cada tabla creada debe tener un nombre nico en la cada Base de Datos, hacindola accesible mediante su nombre o su seudnimo (Alias) (dependiendo del tipo de base de datos elegida). La estructura de las tablas viene dado por la forma de un archivo plano, los cuales en un inicio se componan de un modo similar. Tablas: Son los objetos principales de bases de datos que se utilizan para guardar datos. Elemento disponible en el lenguaje HTML para la creacin de recuadros rectangulares que pueden o no estar anidados y pueden o no contener celdas (recuadros ms pequeos dentro de una tabla, pero que no se consideran tablas). Las tablas se utilizan para organizar, posicionar o dar mejor formato a los textos y grficos en una pgina web. Pueden crearse grficamente a travs de un programa desarrollador de pginas web o manejando los tags correspondientes del lenguaje. 2.2 Modelo relacional Las bases de datos relacionales son el tipo de bases de datos actualmente ms difundido. Los motivos de este xito son fundamentalmente dos: 1. ofrecen sistemas simples y eficaces para representar y manipular los datos 2. Se basan en un modelo, el relacional, con slidas bases tericas El modelo relacional fue propuesto originariamente por E.F. Codd en un ya famoso artculo de 1970. Gracias a su coherencia y facilidad de uso, el modelo se ha convertido en los aos 80 en el ms usado para la produccin de DBMS. La estructura fundamental del modelo relacional es precisamente esa, "relacin", es decir una tabla bidimensional constituida por lneas (tuple) y columnas (atributos). Las relaciones representan las entidades que se consideran interesantes en la base de datos. Cada instancia de la

entidad encontrar sitio en una tupla de la relacin, mientras que los atributos de la relacin representarn las propiedades de la entidad. Por ejemplo, si en la base de datos se tienen que representar personas, se podr definir una relacin llamada "Personas", cuyos atributos describen las caractersticas de las personas (Figura 2). Cada tupla de la relacin "Personas" representar una persona concreta.

En realidad, siendo rigurosos, una relacin es slo la definicin de la estructura de la tabla, es decir su nombre y la lista de los atributos que la componen. Cuando se puebla con las tuplas, se habla de "instancia de relacin". Por eso, la anterior Figura 2 representa una instancia de la relacin persona. Una representacin de la definiticn de esa relacin podra ser la siguiente: Personas (nombre, apellido, fecha nacimiento, sexo, estado civil) A continuacin, se indicarn ambas (relacin e instancia de relacin) con el trmino "relacin", a no ser que no quede claro por el contexto a qu acepcin se refiere. Las tuplas en una relacin son un conjunto en el sentido matemtico del trmino, es decir una coleccin no ordenada de elementos diferentes. Para distinguir una tupla de otra, se recurre al concepto de "llave primaria", o sea a un conjunto de atributos que permiten identificar unvocamente una tupla en una relacin. Naturalmente, en una relacin puede haber ms combinaciones de atributos que permitan identificar unvocamente una tupla ("llaves candidatas"), pero entre stas se elegir una sola para utilizar como llave primaria. Los atributos de la llave primaria no pueden asumir el valor nulo (que significa un valor no determinado), en tanto que ya no permitiran identificar una tupla concreta en una relacin. Esta propiedad de las relaciones y de sus llaves primarias est bajo el nombre de integridad de las entidades (entity integrity). A menudo, para obtener una llave primaria "econmica", es decir compuesta de pocos atributos fcilmente manipulables, se introducen uno o ms atributos ficticios, con cdigos identificativos unvocos para cada tupla de la relacin. Cada atributo de una relacin se caracteriza por un nombre y por un dominio. El dominio indica qu valores pueden ser asumidos por una columna de la relacin. A menudo un dominio se define a travs de la declaracin de un tipo para el atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero tambin es posible definir dominios ms complejos y precisos. Por ejemplo, para el atributo "sexo" de nuestra relacin "Personas" podemos definir un dominio por el cual los nicos valores vlidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir un dominio por el que se consideren vlidas slo las fechas de nacimiento despus del uno de enero de 1960, si en nuestra base de datos no est previsto que haya personas con fecha de nacimiento anterior a esa. El DBMS se ocupar de controlar que en los atributos de las relaciones se incluyan slo los valores permitidos por sus dominios. Caracterstica fundamental de los dominios de una base de datos relacional es que sean "atmicos", es decir que los valores contenidos en las columnas no se puedan separar en valores de dominios ms

simples. Ms formalmente se dice que no es posible tener atributos multivalor (multivalued). Por ejemplo, si una caracterstica de las personas en nuestra base de datos fuese la de tener uno o ms hijos, no sera posible escribir la relacin Personas de la siguiente manera: Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos) En efecto, el atributo hijos es un atributo no-atmico, bien porque una persona puede tener ms de un hijo o porque cada hijo tendr diferentes caractersticas que lo describen. Para representar estas entidades en una base de datos relacional hay que definir dos relaciones: Personas (*nmero_persona, nombre, apellido, fecha_nacimiento, sexo, estado_civil) Hijos (*nmero_persona, *nombre_apellido, edad, sexo) En las relaciones precedentes, los asteriscos (*) indican los atributos que componen sus llaves primarias. Ntese la introduccin en la relacin Personas del atributo nmero_persona, a travs del cual se asigna a cada persona un identificativo numrico unvoco que se usa como llave primaria. Estas relaciones contienen slo atributos atmicos. Si una persona tiene ms de un hijo, stos se representarn en tuplas diferentes de la relacin Hijos. Las diferentes caractersticas de los hijos las representan los atributos de la relacin Hijos. La unin entre las dos relaciones est constituida por los atributos nmero_persona que aparecen en ambas relaciones y que permiten que se asigne cada tupla de la relacin hijos a una tupla concreta de la relacin Personas. Ms formalmente se dice que el atributo nmero_persona de la relacin Hijos es una llave externa (foreign key) hacia la relacin Personas. Una llave externa es una combinacin de atributos de una relacin que son, a su vez, una llave primaria para otra relacin. Una caracterstica fundamental de los valores presentes en una llave externa es que, a no ser que no sean null, tienen que corresponder a valores existentes en la llave primaria de la relacin a la que se refieren. En nuestro ejemplo, esto significa que no puede existir en la relacin Hijos una tupla con un valor del atributo nmero_persona sin que tambin en la relacin Personas exista una tupla con el mismo valor para su llave primaria. Esta propiedad va bajo el nombre de integridad referencial (referential integrity) Una de las grandes ventajas del modelo relacional es que define tambin un lgebra, llamada "lgebra relacional". Todas las manipulaciones posibles sobre las relaciones se obtienen gracias a la combinacin de tan slo cinco operadores: RESTRICT, PROJECT, TIMES, UNION y MINUS. Por comodidad, se han definido tambin tres operadores adicionales que de todos modos se pueden obtener aplicando los cinco fundamentales: JOIN, INTERSECT y DIVIDE. Los operadores relacionales reciben como argumento una relacin o un conjunto de relaciones y restituyen una nica relacin como resultado. Veamos brevemente estos ocho operadores: RESTRICT: restituye una relacin que contiene un subconjunto de las tuplas de la relacin a la que se aplica. Los atributos se quedan como estaban. PROJECT: restituye una relacin con un subconjunto de los atributos de la relacin a la que viene aplicado. Las tuplas de la relacin resultado se componen de las tuplas de la relacion original, de manera que siguen siendo un conjunto en sentido matemtico.

TIME: se aplica a dos relaciones y efecta el producto cartesiano de las tuplas. Cada tupla de la primera relacin est concatenada con cada tupla de la segunda. JOIN: se concatenan las tuplas de dos relaciones de acuerdo con el valor de un conjunto de sus atributos. UNION: aplicando este operador a dos relaciones compatibles, se obtiene una que contiene las tuplas de ambas relaciones. Dos relaciones son compatibles si tienen el mismo nmero de atributos y los atributos correspondientes en las dos relaciones tienen el mismo dominio. MINUS: aplicado a dos relaciones compatibles restituye una tercera que contiene las tuplas que se encuentran slo en la primera relacin. INTERSECT: aplicado a dos relaciones compatibles restituye una relacin que contiene las tuplas que existen en ambas. DIVIDE: aplicado a dos relaciones que tengan atributos comunes, restituye una tercera que contiene todas las tuplas de la primera relacin que se puede hacer que correspondan con todos los valores de la segunda relacin.

En las siguientes tablas, a ttulo de ejemplo, se representan los resultados de la aplicacin de algunos operadores relacionales a las relaciones Personas e Hijos. Como nombres para las relaciones resultado se han utilizado las expresiones que las producen. Personas nmero_persona nombre 2 1 3 Mario Giuseppe

apellido fecha_nacimiento sexo stado_civil Rossi Russo 29/03/1965 15/11/1972 M M F Casado Soltero Soltera

Alessandra Mondella 13/06/1970

Hijos nmero_persona nombre_apellido edad sexo 2 2 Maria Rossi Gianni Rossi 3 5 F M

RESTRICT sesso='M' nmero_persona nombre

(Personas) apellido fecha_nacimiento sexo estado_civil

2 1

Mario

Rossi

29/03/1965 15/11/1972

M M

Casado Soltero

Giuseppe Russo

PROJECT sexo M F

sexo

(Personas)

RESTRICT sexo='M' n. nombre apellido nacimiento sexo stado_civil nombre Mario Rossi Mario Rossi apellido 29/03/1965 M Apellido 29/03/1965 M Csado Casado

(Personas) edad sexo F M

Maria Rossi 3 Gianni Rossi 5

Las bases de datos relacionales efectan todas las operaciones en las tablas usando el lgebra relacional, aunque normalmente no le permiten al usuario usarla. El usuario interacciona con la base de datos a travs de una interfaz diferente el lenguaje SQL, un lenguaje declarativo que permite escribir conjuntos de datos. Las instrucciones SQL vienen descompuestas por el DBMS en una serie de operaciones relacionales.

2.3 Modelo jerrquico Una base de datos jerrquica consiste en una coleccin de segmentos (registro) que Se conectan entre s por medio de enlaces. Cada segmento es una coleccin de campos (atributos), que contienen un solo valor cada uno de ellos. Un enlace es una asociacin o unin entre dos segmentos exclusivamente. Las caractersticas principales de implementar este modelo son: Globalizacin de la informacin: permite a los diferentes usuarios considerar la Informacin como un recurso corporativo que carece de dueos especficos. Eliminacin de informacin inconsistente: si existen dos o ms archivos con la misma informacin, los cambios que se hagan a stos debern hacerse a todas las copias del archivo de facturas. Permite compartir informacin Permite mantener la integridad en la informacin: la integridad de la informacin es una de sus cualidades altamente deseable y tiene por objetivo que slo se almacena la informacin correcta. Independencia de datos: el concepto de independencia de datos es quizs el que ms ha ayudado a la rpida proliferacin del desarrollo de Sistemas de Bases de datos. En este tipo de modelos la organizacin se establece en forma de rbol, donde la raz es un nodo ficticio. As tenemos que, una base de datos jerrquica es una coleccin de arboles. El contenido de un registro especfico puede repetirse en varios sitios (en el mismo arbol o en varios rboles). Los Segmentos se clasifican en tres tipos:

1) Padre: ES aquel que tiene descendientes (hijos) todos localizados al mismo nivel. 2) Hijo: ES aquel que depende de un segmento anterior, todos los hijos del mismo padre tendrn que estar localizados en el mismo nivel 3) Segmento Raz: Es el nico segmento que no tiene padre, es el antecesor de todos, y es el segmento de mayor nivel, es decir esta en el nivel superior del arbol. 2.4 Modelo de datos en red El modelo de datos en red general representa las entidades en forma de nodos de un grafo, y las interrelaciones entre estas mediante arcos que unen dichos nodos. En principio esta representacin no impone restriccin alguna acerca del tipo y el nmero de arcos que puede haber, con lo que se pueden modelar estructuras de datos tan complejas como sea necesario. En este modelo las entidades se representan como nodos y sus relaciones son las lneas que los unen. En esta estructura cualquier componente puede relacionarse con cualquier otro. A diferencia del modelo jerrquico, en este modelo, un hijo puede tener varios padres. En este modelo las entidades se representan como nodos y sus relaciones son las lneas que los unen. En esta estructura cualquier componente puede relacionarse con cualquier otro. A diferencia del modelo jerrquico, en este modelo, un hijo puede tener varios padres. Los conceptos bsicos en el modelo en red son: y El tipo de registro, que representa un nodo. y Elemento, que es un campo de datos. y Agregado de datos, que define un conjunto de datos con nombre.

2.5 Modelo relacional de objetos Este modelo intenta fundir la orientacin a objetos con el modelo de base de datos relacional. Como muchos de los lenguajes de programacin actuales, como Java, son orientados a objetos, una estrecha integracin entre los dos podra proporcionar una relativamente sencilla abstraccin a los desarrolladores que programan en lenguajes orientados a objetos y que tambin necesitan programar en SQL. Esta integracin, adems, debera casi eliminar la necesidad de una constante traslacin entre las tablas de la base de datos y las estructuras del lenguaje orientado a objetos, que es una tarea muy ardua. Con una base de datos ms grande, incluso con enlaces entre las tablas, el nmero de problemas se dispara, incluyendo la escalabilidad debida a los mltiples JOINs en el modelo de datos y los enlaces cruzados entre las claves de la tablas. Pero, afortunadamente, ya hay productos disponibles que permiten crear este tipo de puentes entre los modelos relacional y orientado a objetos; es ms, hay varias de estas soluciones que estn siendo desarrolladas para trabajar especficamente con Java.

2.6 Modelo dimensional

Dentro de la disciplina de Modelado de Datos, encontramos el Modelo Dimensional. Sus elementos principales son: 1. Hechos, 2. Dimensiones Los Hechos seran aqullos datos que nos proporcionan una informacin cuantitativa sobre las carctersticas del Negocio que queremos analizar. En nuestro caso, los Hechos sern los datos de la accin (Precio Apertura, Precio Cierre, Mximo Diario, Mnimo Diario, Volumen). Su finalidad es proporcionar informacin necesaria para la gestin, facilitando el conocimiento del Negocio o Proceso a modelar, y fundamentar, entre otras, la toma de decisiones, facilitar los procesos de marketing (ofertas y promociones), fidelizar clientes, valorar el desempeo de los trabajadores, etc. Por otra parte, las Dimensiones buscan determinar un contexto para el anlisis de los Hechos. Se trata de grupos homogneos de elementos, en muchas ocasiones, jerarquizados. Su papel es promocionar la informacin contenida en los Hechos. En nuestro caso, tenemos dos dimensiones: Tiempo y Sociedades. Las Dimensiones pueden estar jerarquizadas o no. En nuestro caso, todos los elementos de la dimensin Tiempo son jerarquizables, y se pueden representar en un esquema en rbol. El primer trmino es Ao, siendo sus descendientes Trimestres, que a su vez tienen como descendientes a los Meses, stos a las Semanas, etc. En este contexto, definimos al Elemento Padre como el elemento superior en la jerarqua dado un elemento (Ao es el Elemento Padre de Trimestres) y como Elemento Hijo a los elementos inferiores en la jerarqua dado un elemento (Meses es el Elemento Hijo de Semanas). Pero los elementos de la dimensin Sociedad no son jerarquizables, ya que su nexo de unin es su condicin de valores includos en el IBEX-35, y todos estaran al mismo nivel. Si en el futuro, decidieramos aumentar el nmero de sociedades a analizar, ms all del IBEX-35, e incluysemos todos los valores sujetos a negociacin en el Mercado de Madrid, o incluso en Mercados internacionales (por ejemplo, el NASDAQ-100, que es un ndice de incluye los 100 principales valores del sector TIC a cotizacin en el Mercado de New York), si ya tendramos elementos-Padre y elementos-Hijo (siendo los elementos-Padre IBEX-35 , NASDAQ-100 , etc. y los elementos-Hijo las sociedades cuyas acciones estn includas en el clculo del ndice Telefonica, Repsol YPF, etc), aunque mantendran su condicin de No-agregables (ya que, a priori, no tiene sentido sumar todos los precios de cierre de valores distintos). La relacin entre los Hechos y las Dimensiones tiene en cuenta la Granularidad. Definimos la Granularidad como el menor grado de detalle de nuestro anlisis. En nuestro caso, sera diasociedad. Otra forma de definirlo es cmo el menor nivel al que existe relacin entre los Dimensiones y el conjunto de Hechos. Por lo tanto, los Hechos son explicables a partir de datos en un entorno da-sociedad. A partir de aqu, podemos realizar Roll Up, que no es ms que ir agregando los valores en funcin de los elementos-Padre, y as sucesivamente hasta llegar al

Elemento superior de la jerarqua. En nuestro caso, si hacemos Roll Up sucesivamente desde el menor grado, tendramos un anlisis semana-sociedad, mes-sociedad, trimestre-sociedad, aosociedad. El proceson inverso, basado en desagregar en funcin de los elementos-Hijo, se conoce como Drill Down, y busca permitir al analista de la informacin, una forma de ver ms detalle los datos. Cuando lo que hacemos es limitar o ampliar los miembros de una Dimensin (pej, queremos ver los datos de los Hechos solo para el primer trimestre de 2010), estamos haciendo un Slice (del ingls, cortar en lonchas), . El proceso de acotar an ms el conjunto de informacin contenida por un Slice se conoce como Dice (del ingls, cortar en dados). Las dos enfoques con los que su utiliza el Modelo Dimensional son: 1. Modelo en Estrella 2. Modelo en Copo-de-Nieve