Bases de Datos

Claudia Jimenez, Marcela Varas y Gustavo Donoso DIICC, Facultad de Ingeniera Universidad de Concepcin

Apuntes en construccin
Apuntes para el ramo Bases de Datos del Departamento de Ingeniera Civil Informtica y Ciencias de la Computacin Facultad de Ingeniera, Universidad de Concepcin, Chile.

1.-Sistemas de Bases de Datos

1.1.-Evolucin: De los Sistemas Orientados a los Procesos a los Sistemas Orientados a los datos

Los sistemas orientados a los datos se caracterizan porque los datos no son de una aplicacin sino de una Organizacin entera que los va a utilizar. Se tiende a integrar las aplicaciones, evitando aplicaciones aisladas. Se diferencian las estructuras lgicas y fsicas, de manera que el usuario final solo se vincule con las estructuras lgicas. La descripcin de la estructura lgica se separa de los lenguajes de programacin. El concepto de relacin cobra importancia, de modo que se requiere de herramientas que permitan definirlas y almacenarlas.

Originalmente las aplicaciones que se desarrollaban para en las organizaciones estaban orientadas a cubrir necesidades muy especficas de procesamiento, por lo cual tanto los lenguajes de programacin como las estructuras de datos se centraban en realizar de manera ms eficiente una tarea especfica. En la Figura 1.1.- se puede ver claramente como la tarea (tratamientos) es un elemento central en el diseo de las estructuras de datos que utiliza, por ejemplo si el tratamiento T5 no existiese, tendra sentido que exista el archivo F5?. Ms an, si profundizamos el anlisis, de la Figura 1.1.- vemos que existen datos (D1, D3, D4 y D6) que residen en distintos archivos siendo conceptualmente nicos- esta situacin resultaba claramente peligrosa por las inconsistencias que acarrea, por ejemplo, si el dato D6 tiene un valor distinto en el archivo F4 al que tiene en el archivo F5. Cul es el correcto?

As, las bases de datos buscan resolver principalmente aquel problema, evitar las inconsistencias que se producan por la utilizacin de los mismos datos lgicos desde distintas plataformas fsicas (archivos) a travs de procesos independientes. El anlisis entonces comienza por formular la lgica de los datos organizacionales como un todo, para despus vincular aquellos con los procesos que los utilizan. Es en este anlisis en que las Bases de Datos como una unidad tanto terica como conceptual y fsica cobran importancia. Y el mecanismo sobre el cual esto se articula es el de disminuir la redundancia a travs del establecimiento de relaciones entre los datos de una organizacin.

1.2.-Concepto de Base de Datos

La idea de base de datos surge como una necesidad de mantener datos relacionados. Veamos un ejemplo. Supongamos 3 archivos: artculos, clientes y pedidos. Un cliente puede tener varios pedidos, pueden existir varios pedidos para un mismo artculo, diferentes pedidos en diferentes fechas, etc. Si los requerimientos son: Los pedidos del cliente XXX, una solucin es generar una lista por cada cliente, generando una relacin entre los archivos clientes y pedidos. Todos los pedidos de un artculo, se tendr una lista por cada artculo, generando una relacin entre pedidos y artculo.

Las relaciones anteriores son complejas, por lo que se hace necesario contar con alguna herramienta que facilite estos requerimientos. Se debe considerar que los requerimientos hacen uso de los mismos datos. Las definiciones de base de datos son numerosas. Todas coinciden en que es un conjunto de datos almacenados en un soporte de acceso directo. Los datos estn interrelacionados y estructurados de acuerdo a un modelo que sea capaz de recoger el mximo contenido semntico. Definicin 1: "Coleccin de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es servir a una o ms aplicaciones de la mejor forma posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean mtodos bien determinados para incluir nuevos datos y para modificar o extraer los datos almacenados". Martin, 1975. Definicin 2: "Coleccin integrada y generalizada de datos, estructurada atendiendo a las relaciones naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad de datos con objeto de poder atender todas las necesidades de los diferentes usuarios". Deen, 1985. Definicin 3: "Coleccin de datos integrados, con redundancia controlada y con una estructura que refleje las interrelaciones y restricciones existentes en el mundo real; los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de stas, y su definicin y descripcin, nicas para cada tipo de datos, han de estar almacenadas junto con los mismos. Los procedimientos de actualizacin y recuperacin, comunes y bien determinados, habrn de ser capaces de conservar la integridad, seguridad y confidencialidad del conjunto de los datos". A.de Miguel, 1993. Definicin 4: "Una base de datos consiste en alguna coleccin de datos persistentes e independientes usados por una organizacin determinada." (Date, 1995)

1.2.1.- Caractersticas del dato:

No efmero, en el sentido que permanece en el tiempo Estructurado, para que facilite el compartirlos por aquellos que lo necesiten Operacional Transaccional (OLTP), manipularlos aplicando operadores para obtener resultados Sentido semntico Integro, en el sentido que refleja una realidad existente

De hecho los datos que contiene una base de datos tiene una caracterstica especial, se les reconoce como datos de operacin. Datos de Operacin: los datos de una Base de Datos se consideran DATOS de OPERACION, distinguindose de los datos de entrada y de salida. Una Base de Datos, es un conjunto de datos de operacin almacenados y utilizados por los sistemas de aplicacin de una organizacin especfica. Cualquier organizacin necesita disponer de una gran cantidad de datos acerca de su funcionamiento. Estos constituyen sus datos de operacin. Los datos de Operacin no incluyen datos de entrada o de salida, colas de espera de trabajo o cualquier otro dato de ndole transitoria. As los datos de entrada, por ejemplo, se refiere a los datos que entran al sistema desde el exterior, tales datos pueden ocasionar un cambio en los datos de operacin, pero no constituyen parte de la Base de Datos. El conjunto de los datos de operacin tiene directa relacin con aquellos elementos de datos que modelan el sentido de la organizacin como un sistema dotado de identidad propia, as, si comparamos el conjunto de los datos de operacin estructurados para organizaciones distintas, la semntica de aquellos necesariamente ser diferente, por mucho que sus sintaxis sean idnticas. Los datos de operacin reflejan contenidos semnticos, tanto as que el diseo lgico de una base de datos tambin se conoce como modelado semntico.

1.2.2.- Anlisis del concepto de base de datos

El concepto de Base de Datos determina algunas caractersticas que le son propias, por ejemplo: El mundo real considera interrelaciones entre datos y restricciones semnticas que deben estar presentes en una base de datos. Una base de datos no solo debe almacenar entidades y atributos (recordar los sistemas tradicionales de archivos), sino que tambin debe almacenar interrelaciones entre datos. Por otro lado, actualmente se le est dando mucha importancia a las restricciones semnticas, de manera que stas se almacenan junto con los datos. La redundancia de datos debe ser controlada, de forma que no existan duplicidades perjudiciales ni innecesarias. Las redundancias fsicas, convenientes muchas veces a fin de responder a objetivos de eficiencia, sean tratadas por el mismo sistema, de modo que no puedan producirse incoherencias. Esto significa que en las bases de datos NO est permitida la redundancia lgica, pero si se admite cierta redundancia fsica por motivos de eficiencia. Las bases de datos pretenden servir a toda la organizacin, es decir a mltiples usuarios y a diferentes aplicaciones (recordar los sistemas tradicionales de archivos). La independencia, tanto lgica como fsica, de los tratamientos sobre los datos y estos mismos, ha tenido una enorme influencia en la arquitectura de los SGBD (recordar los sistemas tradicionales de archivos). La definicin y descripcin del conjunto de datos contenido en la base debe ser nica e integrada con los mismos datos. (recordar los sistemas tradicionales de archivos). En las

bases de datos, la descripcin, y en algunos casos, tambin una definicin y documentacin completas (metadatos) se almacenan junto con los datos, de modo que stos estn documentados, y cualquier cambio que se produzca en la documentacin debe quedar recogido en el sistema. La actualizacin y recuperacin de las bases de datos debe realizarse mediante procesos bien determinados, incluidos en el SGBD; procedimientos que han de estar diseados de modo que se mantenga la integridad, seguridad y confidencialidad de la base.

1.2.3.- Las caractersticas elementales de una Base de Datos

El objetivo de disminuir la redundancia de un conjunto de datos determina dos caractersticas fundamentales que poseer cualquier sistema de Bases de Datos: Integrada: se entiende que una base de datos puede considerarse como una unificacin de varios archivos de datos independientes, donde se elimina parcial o totalmente cualquier redundancia entre los mismos. P.e. una base de datos especfica puede contener registros de EMPLEADO, que incluyen el nombre, direccin, departamento, salario, etc. y, existir registros de INSCRIPCION que representan inscripciones de empleados en cursos de capacitacin. Supongamos que para llevar a cabo el proceso de administracin de los cursos se necesita conocer el departamento de cada estudiante inscrito. Desde luego, no hay necesidad de incluir este dato (redundante) en los registro de INSCRIPCION, siempre se puede obtener recurriendo a los registros de EMPLEADO correspondiente. Compartida: Se entiende que partes individuales de la Base de Datos pueden compartirse entre varios usuarios distintos, en el sentido que cada uno de ellos puede tener acceso a la misma parte de la Base de Datos y utilizarla con propsitos diferentes. Tal comportamiento es en verdad consecuencia del hecho de que la Base de Datos es integrada. En el caso del ejemplo anterior se tiene que los datos de los registros de EMPLEADOS es compartido por usuarios del departamento de personal y capacitacin. Consecuencia del mismo hecho, que la Base de Datos es integrada, se advierte en que cualquier usuario tendr acceso slo a algn subconjunto de la Base completa, adems, los subconjuntos de diferentes usuarios se procesarn de muy diversas maneras. En otras palabras, diferentes usuarios percibirn de modos muy distintos una base de datos.

1.2.4.- La independencia Dato-Proceso

Una de las principales ventajas que provee una base de Datos (ver siguiente punto) es la independencia entre los datos y los tratamientos que se hacen de ellos. A diferencia de los sistemas orientados al procesos, en los cuales los datos eran sumamente dependientes de los programas al extremo que lenguajes como COBOL definan en su cdigo la estructura de los archivos esto lo podemos ver actualmente en C y Pascal. Con ello la estructura de los datos de las tablas que los contienen son altamente dependiente de los procesos que los utilizan, de hecho, para que un proceso pueda utilizar un determinado dato que se encontraba almacenado en un archivo deba hacer la declaracin completa de la estructura de este archivo, esta declaracin era slo modificable en tiempo de edicin quedando fija ya en tiempo de compilacin. Lo anterior era vlido para cualquier acceso a los datos de un conjunto de archivos. Ocurre que histricamente la tasa de variacin de los procesos es mayor que la de los datos que aquellos procesos manejan, ms an cualquier actualizacin de los datos que maneja un proceso determina que ste necesariamente sea actualizado, lo que no siempre ocurre en el sentido contrario. No siempre que un proceso cambia esto determina cambios en los datos que ese proceso utiliza. As, es claro que la situacin de datos dependientes de los procesos era inadecuada, ya que claramente la dependencia es en el sentido contrario. Lo anterior es asimilable a los cambios que sufren las organizaciones, generalmente aquellos son de forma, un banco que cambia su imagen corporativa, que se agregen o eliminen funciones de atencin a pblico o de

produccin, reduccin de personal, etc. Los cambios de fondo no son habituales en las organizaciones, ellos tiene que ver con cambios en la misin de la organizacin, en los objetivos. Si un banco cambia de imagen corporativa logo, forma de atencin, etc.- aquellos son cambios de forma y tienen bsicamente que ver con variaciones en los procesos y eventualmente con algunos datos; ahora si el banco quiere transformarse en una AFP, entonces la situacin es ms compleja y profunda, la misin organizacional cambia, el objetivo cambia y, por lo mismo, el cambio es radical afectando todos los elementos que componen la organizacin, todos aquellos elementos donde se refleja el sentido organizacional, es decir afecta directamente a los datos y sus relaciones cambio que indirectamente afectara a los procesos que manejan estos datos. El concepto de Base de Datos rescata aquella dependencia que tienen los procesos de los datos y la radicaliza priorizando la independencia de estos ltimos, determinando mecanismos de definicin y de descripcin que no requieren de procesos. Con lo anterior se crea un sustrato de datos modelando la organizacin, sobre el cual se establecen los procesos que los utilizan. Donde la definicin y mantencin de este sustrato es tericamente independiente de los procedimientos de la organizacin y los procesos que apoyan su realizacin. Por otra parte esta independencia tambin apunta en el sentido contrario, es decir, si hay claridad en el problema de la influencia de los datos sobre los procesos, es perfectamente definible mecanismos que minimicen este influjo y que posibiliten una, tambin, independencia de los procesos.

1.3.-Ventajas de las bases de datos

Una sistematizacin de las ventajas de las Bases de Datos bosquejadas e los puntos anteriores los podemos resumir en el siguiente cuadro: Cuadro resumen de las ventajas de las bases de datos Referidas a Los datos Ventajas Los resultados Los usuarios Independencia de estos respecto de los tratamientos y viceversa Mejor disponibilidad de los mismos Mayor eficiencia en la recogida, codificacin y entrada Mayor coherencia Mayor valor informativo Mejor y ms normalizada documentacin de la informacin Acceso ms rpido y sencillo de los usuarios finales Ms facilidades para compartir los datos por el conjunto de los usuarios Mayor flexibilidad para atender a demandas cambiantes.

Anlisis cuadro anterior Independencia de los datos respecto a los tratamientos y viceversa: esto supone que un cambio en los tratamientos no imponga un nuevo diseo lgico y/o fsico de la base de

datos. Por otro lado, cambios en la incorporacin, desaparicin de datos, cambios en la estructura fsica o caminos de acceso no deben obligar a alterar los programas. As se evita la reprogramacin de las aplicaciones. Es el punto de partida para la adaptacin de los sistemas de informacin a la evolucin de las organizaciones. Coherencia de los resultados: debido a que la informacin de la base de datos se recoge y se almacena una sola vez, en todos los tratamientos se utilizan los mismos datos, por lo que los resultados de estos son coherentes y comparables. As, se eliminan las divergencias en los resultados. Mejor disponibilidad de los datos para el conjunto de los usuarios: en una base de datos ningn usuario es propietario de los datos, pues stos se comparten entre las aplicaciones, existiendo una mayor disponibilidad y transparencia. Mayor valor informativo: esto se refiere al concepto de sinergia, en donde el valor informativo del conjunto de datos es superior a la suma del valor informativo de los elementos individuales. Mejor y ms normalizada documentacin: la mayora de los SGBD proporcionan herramientas para reflejar el contenido semntico de los datos, es decir, incluyen una descripcin de los datos dentro del sistema. Mayor eficiencia en la captura, validacin e ingreso de datos al sistema: al no existir redundancias, los datos se capturan y validan una sola vez aumentando el rendimiento del proceso previo al almacenamiento Reduccin del espacio de almacenamiento: por un lado, la disminucin de redundancias y las tcnicas de compactacin hacen que disminuya el espacio en disco. Sin embargo, los diccionarios, referencias, punteros, listas invertidas tambin ocupan espacio.

1.4.-Desventajas de las bases de datos

Las desventajas de una base de datos no las podemos dejar de mencionar. El siguiente cuadro resume algunas de aquellas. Cuadro resumen de las desventajas de las bases de datos Relativas a La implantacin Desventajas Los usuarios Costosa en equipos (lgico y fsico) Ausencia de estndares Larga y difcil puesta en marcha Rentabilidad a mediano plazo Personal especializado Desfase entre teora y prctica

Anlisis del cuadro anterior Instalacin costosa: equipos: nuevas instalaciones o ampliaciones, sistemas operativos, compiladores, SGBD comerciales, computadores ms poderosos, etc. Personal especializado: es clave la administracin de la base de datos, se requiere de conocimientos especficos. Desfase entre teora y prctica: muchos ejecutivos asumen que ciertas funcionalidades son ya un hecho, cuando en realidad son estudios tericos.

Existe tambin una resistencia al cambio, sobre todo que este involucra a toda la organizacin. En el xito de esto el papel mediador de los profesionales de informtica es fundamental, sobre todo en organizaciones grandes donde una base de datos se puede ver como la centralizacin del poder en manos de unos pocos, generalmente los encargados de su administracin.

1.5.-Componentes de los Sistemas de bases de datos

Un sistema de bases de datos contempla los siguientes componentes: La base de datos El Sistema de Gestin de Bases de Datos(SGBD, DBMS) o motor, tal como Oracle, Sybase, etc. Programas de aplicacin Un conjunto de usuarios (finales, DBA, programadores de aplicaciones, etc.) Mquinas Programas utilitarios( generadores de informes, de interfaces, herramientas de desarrollo, de administracin, etc.)

En la Figura 1.3.- se puede observar un esquema general del la arquitectura de una base de datos, en la cual se detallan los principales componentes de ella adems de las relaciones entre ellos y la base de datos lgica. Veamos una descripcin simple del aquellos elementos: Una Vista Externa es una visin particular de un usuario o un grupo de usuarios de la Base de Datos. El Esquema Externo representa una forma de definicin o formalizacin de esta vista externa. La Vista Conceptual pretende ser la representacin total y abstracta de los datos que componen la Base; la formalizacin de esta se logra mediante el Esquema Conceptual. Por ltimo, la Vista Interna es de un nivel muy bajo y corresponde al almacenamiento fsico de los datos de la Base, sobre un Esquema Interno que es la formalizacin de esto, e.d. tipos de registros almacenados, ndices, etc. Las correspondencias se pueden definir como una asociacin de distintas representaciones para un mismo dato. Un DSL es un sublenguaje de datos, es una combinacin de dos lenguajes: un lenguaje de definicin de datos (DDL) y un lenguaje de manipulacin de Datos (DML). Este lenguaje representa un nexo entre el Sistema de Base de Datos y algn lenguaje anfitrin (p.e. COBOL, FORTRAN, C, etc.); e.d., el DSL provee herramientas a los lenguajes tradicionales para que se integren al Sistema de Base de Datos. Puede haber distintos tipos de DSL para un mismo sistema. DBMS es la sigla en ingls de Sistema de Administracin de Bases de Datos, que corresponde al Software que maneja todos los accesos a la Base de Datos, e.d. cada solicitud de acceso de un usuario al SABD es interpretada e inspeccionadas las correspondencias, generando, a continuacin, una respuesta coherente a las necesidades de la pregunta. La interfaz con el Usuario es el lmite de acceso que tiene un Usuario comn a la Base, todo lo que est bajo este lmite es transparente (desconocido) para l. Por ltimo, el Administrador de Bases de Datos (DBA) corresponde a la persona o grupo de personas encargada del control general del sistema. Sus responsabilidades o funciones incluyen: Decidir el contenido de la Base de Datos: comprende la identificacin de entidades de inters para la organizacin y los datos a registrar de stas entidades. Luego se define el contenido de la Base de Datos generando un Modelo Conceptual. Decidir la estructura de almacenamiento y la estrategia de acceso: esto es decidir como deben representarse los datos en forma interna y hacer la correspondencia entre estos y el modelo conceptual ya definido. Vincularse con los usuarios: comprende toda una labor de prestacin de servicios que busca garantizar la existencia, en la Base, de los datos necesarios y la formalizacin de los distintos esquemas externos. Definir los controles de autorizacin y procedimientos de validacin: involucra la definicin de restricciones de seguridad y proteccin para la conservacin de la integridad de los Datos. Definir una estrategia de respaldo y recuperacin: esto corresponde a un esquema de seguridad ms amplio que lo anterior y, bsicamente, su objetivo es la operacin exitosa del sistema. Controles de desempeo y responder a los cambios de requerimiento: la idea aqu es lograr un desempeo aceptable, segn expectativas, del Sistema mediante mecanismos de control.

1.6.- El sistema de Gestin de Bases de Datos (SGBD o DBMS)

Un sistema de gestin de bases de datos consiste de una coleccin de datos interrelacionados y un conjunto de programas para acceder a esos datos. La coleccin de datos es la base de datos, y es la que contiene informacin por ejemplo acerca de una empresa determinada. El objetivo principal de un SGBD es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer y almacenar informacin en la base de datos. Toda organizacin puede verse en tres niveles de gestin: operacional, tctico y estratgico. Muchas veces se produce una desconexin de los sistemas que caracterizan a estos niveles, pues constituyen sistemas aislados, sin relacin entre ellos. Esto produce un aumento del costo global de creacin y mantenimiento del sistema de informacin, produce redundancias e incoherencias. Esto impide una gestin racional de los datos. La base de datos es un depsito nico de datos para toda la organizacin, por lo que debe ser capaz de integrar los distintos sistemas y aplicaciones, atendiendo a las necesidades de los usuarios en los tres niveles. El objetivo del SGBD es suministrar la interfaz entre el conjunto de los datos y dichos usuarios. El SGBD tambin debe proporcionar a los otros usuarios (analistas, programadores, administradores) las correspondientes herramientas que les permitan un adecuado desarrollo de sus funciones.

Definicin del SGBD El SGBD es un conjunto coordinado de programas, procedimientos, lenguajes, etc. que suministra, tanto a usuarios no informticos como a los analistas, programadores o al administrador, los medios necesarios para describir, recuperar y manipular los datos almacenados en la base, manteniendo su integridad, confidencialidad y seguridad. Funciones del SGBD De Descripcin o Definicin Debe permitir al administrador de la base especificar los datos que la integran, su estructura y las relaciones que existen entre ellos, las reglas de integridad semntica, los controles a efectuar antes de autorizar el acceso a la base, etc., as como las caractersticas de tipo fsico y las vistas lgicas de los usuarios. Esta funcin la realiza el lenguaje de definicin de datos (LDD), propio del SGBD, y debe ser capaz de definir las estructuras de datos a los tres niveles (nivel externo, nivel lgico global o conceptual y nivel interno). A nivel interno se define: Espacio reservado para la base(volmenes, cilindros y pistas) Longitud de los campos Modo de representacin de los datos (binario, decimal, alfanmerico, etc.) Caminos de acceso como punteros e ndices.

A nivel externo y conceptual, la funcin de descripcin proporciona los instrumentos para la definicin de entidades, su identificacin, atributos, interrelaciones entre ellas, autorizaciones de acceso, restricciones de integridad, etc. El SGBD, adems de describir, debe permitir la correspondencia o mapping entre estos niveles. De Manipulacin Permite a los usuarios de la base (todos) buscar, eliminar o modificar los datos de la base, de acuerdo a las especificaciones y normas de seguridad dadas por el administrador. Esto se realiza mediante el lenguaje de manipulacin de datos (LMD), mediante un conjunto de instrucciones (lenguaje husped) que son admitidas por un lenguaje de programacin (lenguaje anfitrin), o bien, mediante un lenguaje autocontenido, que posee todas las instrucciones necesarias para llevar a cabo estas tareas. De Utilizacin Rene todas las interfaces que necesitan los diferentes tipos de usuarios para comunicarse con la base y proporciona un conjunto de procedimientos para el administrador. Algunas de estas funciones de servicio son:

cambiar capacidades de los archivos obtener estadsticas de utilizacin respaldos cargar y descarga de la base seguridad, etc.

Lenguajes de los SGBD Las distintas funciones que cumple un SGBD, hace necesario contar con diferentes lenguajes y procedimientos que permitan la comunicacin con la base de datos. Por tipo de funcin, tendremos lenguajes de definicin y lenguajes de manipulacin. Por tipo de usuarios tendremos lenguajes para informticos y lenguajes para no informticos o usuarios finales. Estos ltimos, pueden tener aplicaciones formalizables tal como la gestin de personal o no formalizables como cualquier proceso de toma de decisiones. Cuando se trata de procesos formalizables, usualmente los programadores de aplicaciones escriben los procedimientos en programas. Si el proceso no es formalizable, escribir un programa no es aconsejable. Es conveniente que el mismo usuario final resuelva directamente sus requerimientos mediante los instrumentos que el SGBD pone a su alcance. Por otro lado, los usuarios informticos, como el DBA, analistas y programadores requerirn medios poderosos por los cuales podrn definir, extraer y manipular los datos en algn lenguaje de programacin. A este lenguaje se le llama lenguaje anfitrin (por ejemplo, C). Casi la totalidad de los SGBD disponen de lenguajes de 4ta generacin, que se caracterizan por ser poco procedimentales y el acceso a la base de datos se realiza mediante sentencias embebidas en el lenguaje de 4ta generacin y escritas en SQL (SGBD relacionales). Los lenguajes que por si mismos pueden actuar con la base de datos, sin necesidad de apoyarse en otro lenguaje se llaman autocontenidos. Lenguajes de manipulacin de datos Para cumplir los objetivos asignados a la funcin de manipulacin, se ha de contar con lenguajes que den a los usuarios la posibilidad de referirse a determinados conjuntos de datos que cumplan ciertas condiciones (criterio de seleccin). El SQL como lenguaje de manipulacin de datos tiene la propiedad dual, es decir, puede actuar como husped o autocontenido. Los LMD pueden ser procedimentales o no procedimentales, es decir, si necesitamos especificar con detalle el acceso a la base tendremos un lenguaje procedimental. Los lenguajes orientados al usuario final deben ser lo menos procedurales posible. Aqu basta con decir qu se quiere, sin explicar cmo obtenerlo.

Por otro lado, los LMD pueden ser navegacionales, que recuperan o actualizan datos registro a registro. Otros lenguajes actan sobre un conjunto de registros, de forma que una nica sentencia puede dar lugar a la recuperacin o actualizacin del conjunto de registros que cumpla el criterio de seleccin especificado, tal como el SQL.

1.7.- Distintos niveles de abstraccin en una base de datos y arquitectura ANSI/X3/SPARC

Uno de los principales objetivos de las bases de datos es conseguir la independencia entre las estructuras lgica y fsica de los datos, que tiene como consecuencia la independencia entre datos y aplicaciones. As, los cambios en la estructura de los datos tengan una repercusin mnima en los programas de aplicacin y viceversa. Este concepto de independencia implica la separacin entre el almacenamiento y la organizacin lgica de los datos, con lo que se consigue: Los datos se presentarn de formas distintas, segn las necesidades de los usuarios. El almacenamiento de los datos, su estructura lgica y los programas de aplicacin sern independientes unos de otros.

Este objetivo, ha tenido gran influencia en la arquitectura de los SGBD. En los SI existen 2 estructuras: la lgica (vista del usuario) y la fsica (forma en que se encuentran los datos en el almacenamiento). En las bases de datos aparece un nuevo nivel de abstraccin llamado nivel conceptual, estructura lgica global, esquema. Esta estructura intermedia es una representacin global de los datos independiente de equipos y los usuarios (visin de la empresa). Los otros dos niveles corresponden al nivel de mquina o interno y al nivel de usuario o externo.

La estructura lgica de usuario o esquema externo(nivel usuario) es la visin que tiene de la base de datos cada usuario en particular. La estructura lgica global o esquema responde al enfoque del conjunto de la empresa (visin del administrador). La estructura fsica o esquema interno es la forma como se organizan los datos en el medio de almacenamiento fsico.

1.7.1.- Esquema Externo / Nivel Externo

En el debern encontrarse reflejados solo aquellos datos e interrelaciones que necesite un usuario en particular. Tambin deben especificarse las restricciones de uso, como por ejemplo, derecho a borrar o insertar determinados datos. Habr tantos esquemas externos como exijan las diferentes aplicaciones y un mismo esquema externo puede ser utilizado por varias aplicaciones. En algunos SGBD en esta estructura aparecen los caminos de acceso a los datos, lo que no es tan apropiado ya que indicara una dependencia lgica/fsica. Esta situacin depende del modelo de datos en el cual se apoya el SGBD. En particular, en el modelo relacional los caminos de acceso solo se encuentran en el nivel interno, no siendo nunca visibles por el usuario. Este nivel se ocupa de las vistas individuales de los usuarios. Los usuarios pueden ser programadores de aplicaciones o usuarios finales. Estos usuarios disponen de un lenguaje, que para los usuarios finales ser un lenguaje de consulta o algn lenguaje de aplicacin especial, manejado por ejemplo por mens o forms. Los usuarios programadores de aplicaciones tendrn lenguajes de programacin convencionales o algn lenguaje propio de 4ta generacin. El SQL(Structured Query Language) es usado en casi todos los sistemas relacionales actuales. En casi todos los sistemas el SQL puede utilizarse como lenguaje interactivo o de consulta o bien embebido en otros lenguajes, tal como COBOL por ejemplo. Recordar lo visto anteriormente en los lenguajes de un SGBD. Esta distincin entre lenguaje anfitrin y lenguaje embebido es transparente para el usuario. Si ambos lenguajes son difcilmente separables, se dice que son fuertemente acoplados, si por el contrario se pueden separar con facilidad son dbilmente acoplados. Actualmente la mayora de los sistemas son dbilmente acoplados.

1.7.2.- Esquema o Estructura Lgico Global / Nivel conceptual

Tiene por objetivo describir en trminos abstractos pero con absoluta fidelidad una cierta realidad de una organizacin y de su proceso de gestin. Por ser la visin general de los datos, deber incluir la descripcin de todos los datos e interrelaciones entre stos, restricciones de integridad y confidencialidad. Este nivel se define mediante un esquema conceptual. Para escribirlo se utiliza un DDL conceptual. Es importante sealar que para que exista independencia de los datos, las definiciones en DDL conceptual no debern implicar consideraciones de estructura de almacenamiento, deben ser definiciones de contenidos de informacin. Por lo tanto, en el esquema conceptual no debe haber representaciones de campos almacenados, secuencia de registros, indexacin, etc. El paso del mundo real al esquema conceptual corresponde a un proceso de modelizacin. En este punto es donde se utilizan los modelos conceptuales.

1.7.3.- Esquema interno/ Nivel Interno

Este esquema es dependiente del SGBD. Sin embargo, existen elementos comunes que son: Estrategia de almacenamiento: Asignar espacios de almacenamiento para los datos, as como relaciones existentes entre los distintos espacios de almacenamiento. Tambin se especifica la estrategia de emplazamiento de los datos que ha sido utilizada para optimizar tiempo y espacio de memoria secundaria. Tambin debe considerarse como se tratan los desbordes, etc. Camino de acceso: Se incluye la especificacin de claves primarias, secundarias, ndices, claves de ordenacin. Tcnicas de compresin de datos Tcnicas de criptografa Correspondencia conceptual/interna: especifica como se representan los registros y campos conceptuales en el nivel interno. Si se altera la definicin de la estructura de almacenamiento, la correspondencia conceptual/interna deber modificarse tambin para que no vare el esquema conceptual. Es tarea del DBA controlar tales modificaciones. Tcnicas de Tuning y optimizacin Dispositivos de memoria: tamao de la pgina, nro. de pginas asignadas a cada rea de almacenamiento, tamao de los buffers de E/S. Organizaciones fsicas: para mejorar la recuperacin y los tiempos de acceso, el sistema debe dar facilidades al DBA para definir hashing, agrupamientos, etc. Dependiendo del SGBD podr definir punteros entre registros, privilegiando ciertos caminos de acceso. Control de acceso: reglas para proteger la confidencialidad y seguridad de la base de datos.

2.- Modelamiento Conceptual con MER.

2.1.- El Diseo Conceptual en el Proceso de Desarrollo de Software.
Consideremos el Ciclo de Vida Clsico de un producto Software. Dentro del desarrollo, las primeras etapas son las que cobran mayor importancia, ya que en ellas se debe centrar la mayor cantidad de esfuerzo, para asegurar una mayor calidad del producto.

Figura 2.1.- Ciclo de Vida Clsico. Dentro de estas etapas, se encuentra el diseo. El diseo como actividad se puede entender en distintos niveles de abstraccin, separndolo en diseo conceptual, diseo lgico y diseo fsico. El diseo conceptual es de un alto nivel de abstraccin, y puede confundirse su inicio con el trmino de la etapa de anlisis, ya que permite visualizar de mejor manera un problema. Adems este diseo no est necesariamente asociado a priori con una plataforma de implementacin, sino que ms cercano a la realidad, al problema a solucionar. El diseo lgico se acerca ms a la implementacin del producto en una plataforma computacional, integrando consideraciones para la plataforma especfica en cuestin. Finalmente el diseo fsico es una especificacin tal que representa exactamente la implementacin del producto.

2.2.- El Diseo de Bases de Datos.

En el siguiente diagrama se puede apreciar el proceso de diseo de bases de datos. Los requisitos de datos constituyen un componente de los requisitos de un producto y son una entrada al diseo conceptual.

Figura 2.2.- Proceso de Diseo de Bases de Datos

2.2.1.- Diseo Conceptual.

Recibe como entrada la especificacin de requerimientos y su resultado es el esquema conceptual de la base de datos, que es una descripcin de alto nivel de la estructura de la base de datos, independiente del software que se use para manipularla. Modelos Conceptuales: MER, Modelos OO, Formalismo Individual.

2.2.2.- Diseo Lgico.

Recibe como entrada el esquema conceptual y da como resultado un esquema lgico, que es una descripcin de la estructura de la base de datos que puede procesar el software DBMS. Modelos Lgicos: Relacional, de Redes, Jerrquico.

2.2.3.- Diseo Fsico.

Recibe como entrada el esquema lgico y da como resultado un esquema fsico, que es una descripcin de la implementacin de una base de datos en la memoria secundaria, describe las estructuras de almacenamiento y los mtodos usados para tener un acceso efectivo a los datos. Modelos Fsicos: Modelo Unificador, Memoria de Elementos.

2.3.- Modelo de Datos.

Dentro de la problemtica del diseo de bases de datos, los modelos de datos cumplen un importante rol, pues son las herramientas que nos permiten generar los esquemas de bases de datos, los que regirn su estructura. Un modelo de datos define las reglas por las cuales los datos son estructurados. Esta estructuracin, sin embargo, no da una interpretacin completa acerca del significado de los datos y de la forma en que sern usados. Las operaciones permitidas sobre datos deben ser definidas. Muchos modelos conceptuales, como el MER, no incluan operaciones en sus definiciones preliminares, por lo que fueron propuestas en estudios posteriores. Se define el modelo de datos M consistente de dos partes: G: un conjunto de reglas generadoras de esquemas. O: un conjunto de operaciones. El conjunto de reglas G expresa las propiedades estticas de un modelo de datos y corresponden a lo que se denomina generalmente Data Definition Language (DDL). Este define las estructuras permitidas para el modelo de datos M, es decir, generan esquemas. El conjunto G se puede dividir en dos: o o Gs: reglas generadoras de las estructuras permitidas. Gc: reglas generadoras de las restricciones del modelo. As, Gs genera las categoras y estructuras para un modelo, y Gc las restricciones. Utilizando esta ltima notacin, un esquema S consiste de dos partes: una estructura Ss y restricciones Sc, donde Sc es una lista explcita de restricciones que deben ser satisfechas en todo momento. Un modelo de datos tambin puede tener restricciones que son inherentes a l, las que generalmente se incorporan en Ss (la estructura).

Las reglas de generacin G son generadoras de un conjunto de esquemas S, en el que cada uno de ellos define estructuras y restricciones particulares para los datos. Hay muchas bases de datos D en trminos de la ocurrencia del esquema S, pero todos tienen la misma estructura genrica y obedecen a las mismas restricciones definidas en S. En resumen:

Figura 2.3.- Modelo de Datos Las propiedades dinmicas de un modelo de datos son expresadas por un conjunto de operaciones O, las que generalmente son llamadas Data Manipulation Language (DML). Estas propiedades definen las acciones permitidas para una base de datos, tal que transforme la ocurrencia Di en la ocurrencia Dj.

2.4.- El Modelo Entidad Relacin.

A continuacin se definen los elementos del modelo entidad relacin y sus extensiones ms usadas. Adems se incluye su representacin grfica.

2.4.1.- Dominio.
Conjunto de valores de un mismo tipo.

Ejemplo: nombres de personas, rut vlidos, estados civiles.

2.4.2.- Atributo.
Elemento de un Dominio. Aporta mediante su rtulo, la semntica de los valores del Dominio al que est asociado.

Ejemplo: Rut, nombre, departamento, edad, tipo proyecto.

2.4.3.- Atributo Compuesto.

Corresponde a grupos de atributos que tienen afinidad en cuanto a su significado o a su uso .

Ejemplo: Direccin = calle + nmero + ciudad

2.4.4.- Tipo de Entidad.

Los Tipos de Entidad representan clases de objetos de la realidad. Adems se componen de atributos, los cuales representan las caractersticas de un tipo de entidad.

Ejemplo: Persona, Proceso, Factura, Gua de Despacho, Cliente, Producto.

2.4.5.- Identificador de un tipo de entidad.

Un atributo I, posiblemente compuesto, de un tipo de entidad TE, es un Identificador de TE si y slo si satisface las siguientes 2 propiedades independientes del tiempo. a. Unicidad. En cualquier momento dado, no existen dos elementos en TE con el mismo valor de I. b. Minimalidad. Si I es compuesto, no ser posible eliminar ningn atributo componente de I sin destruir la propiedad de unicidad.

Ejemplo: en Chile, para un tipo de entidad Persona, el identificador puede ser Rut.

2.4.6.- Tipo de Interrelacin.

Los Tipos de interrelacin representan agregaciones de dos o ms entidades (interrelaciones binarias o n-arias) no necesariamente diferentes. El Identificador de un Tipo de Interrelacin, se forma a partir de los identificadores de los tipos de entidad que relaciona.

Ejemplo: Tipo de Entidad 1 es Empleado, Tipo de Entidad 2 es Departamento, Tipo de Interrelacin es Trabaja para.

2.5.- Modelo Entidad Relacin: Extensiones

2.5.1.- Cardinalidad de Asignacin.

Caracteriza a los atributos de un tipo de entidad y a los tipos de interrelacin. Las definicin aqu utilizada corresponde a la realizada por Tardieu. Cardinalidad de atributo con respecto a un tipo de entidad. Para los atributos, la cardinalidad mnima indica el nmero mnimo de valores de un atributo asociado con cada caso (ocurrencia) de una entidad o interrelacin. La cardinalidad mxima indica el nmero mximo de valores para un atributo asociado a cada caso de una entidad o interrelacin. Se define la Cardinalidad del Atributo A con respecto al tipo de entidad TE como: Card(A,TE)=( mnimo, mximo), con mnimo, mximo {0,...,n} y mnimo mximo. donde un elemento de A debe participar al menos mnimo veces, y a lo ms mximo veces en cada ocurrencia de TE.

Ejemplo: el atributo telfono del tipo de entidad Persona puede tener cardinalidad (0,3)

2.5.1.1.- Cardinalidad de tipo de entidad con respecto a un tipo de interrelacin. Para los tipos de interrelacin la cardinalidad mxima (mnima) establece el menor (mayor) nmero de correspondencias en cada una de los tipos de entidad involucradas en la interrelacin. Se define la Cardinalidad del Tipo de Entidad TE con respecto al tipo de interrelacin R como: Card(TE,R) = (mnimo, mximo), con mnimo, mximo {0,...,n} y mnimo mximo. donde toda ocurrencia de TE debe participar al menos mnimo veces, y a lo ms mximo veces en R.

Ejemplo: Cada entidad de Provincia participa en la relacin Pertenece exactamente una vez, mientras que cada entidad de Regin participa en la relacin Pertenece a lo menos una vez. Esto es, cada a cada regin pertenecen a lo menos una provincia, mientras que toda provincia debe pertenecer a slo una regin.

2.5.2.- Identificador de un tipo de entidad.

Sea TE un tipo de entidad, sean A1, A2..., An atributos monovalentes obligatorios de TE, sean TE1, TE2..., TEm otros tipos de entidad vinculados a TE por R1, R2..., Rm, tipos de interrelacin (binarias) obligatorias. Considrese un posible identificador I = {a1, a2..., an, TE1, TE2..., TEm}, n = 0, m = 0, n + m = 1. El valor del identificador para un caso particular te del tipo de entidad TE se define como el conjunto de todos los valores de los atributos ai (i = 1,2, ..., n) y todos los casos de los tipos de entidad TEj (j = 1,2, ..., m) vinculadas con te. Cada entidad puede tener mltiples identificadores alternativos. Ejemplo: En una biblioteca, se tiene para cada libro uno o ms ejemplares. Cada libro tiene un cdigo nico, mientras que para diferenciar a un ejemplar de otro, se le agrega un correlativo. Para esta situacin, se puede tener un esquema como el siguiente, donde el tipo de entidad Libro tiene como atributos cdigo, ttulo y ao edicin, mientras que Ejemplar tiene como atributos nmero de ejemplar y ubicacin.

2.5.2.1.- Clasificacin de los tipos de entidad segn sus identificadores. o o Tipo de Entidad Fuerte: Tipo de entidad con identificador interno. Por ejemplo el tipo de entidad Libro. Tipo de Entidad Dbil: Tipo de entidad con identificador externo o mixto. Por ejemplo el tipo de entidad Ejemplar.

2.5.3.- Estructura de Generalizacin.

Un tipo de entidad TE (tipo de entidad genrica) es una generalizacin de un grupo de tipos de entidades STE1 , STE2 , ..., STEn (tipos de entidad subconjunto) si cada entidad de los tipos de entidad STE1 , STE2 , ..., STEn es tambin una entidad del tipo de entidad TE. (Lo opuesto a la generalizacin se denomina especializacin.) Adems cada atributo, interrelacin o generalizacin definida para un tipo de entidad genrica, ser heredado por todas las entidades subconjunto de la generalizacin.

Ejemplo: el Tipo de entidad Persona es una generalizacin de cliente y empleado, en un Banco.

2.5.3.1.-Cobertura. Las jerarquas de generalizacin presentan la propiedad de cobertura. La cobertura puede ser parcial o total y exclusiva o superpuesta. La cobertura parcial o total permite especificar una restriccin entre el tipo de entidad genrica y sus tipos de entidad subconjunto, donde todos los elementos del tipo de entidad genrico deben pertenecer a alguno de sus tipos de entidad subconjunto (si es total), o no (si es parcial). La cobertura exclusiva o superpuesta permite especificar una restriccin entre los tipos de entidad subconjunto, donde los elementos que pertenecen a un tipo de entidad subconjunto pueden pertenecer tambin a otro tipo de entidad subconjunto (si es superpuesto) o no (si es exclusiva).

Ejemplo: Consideremos el caso de un banco cualquiera y una poltica respecto a las personas a considerar, y su calidad de empleados y clientes. Caso cobertura total y exclusiva: Todas las personas son empleados o clientes del banco, pero no ambas cosas simultneamente. En este caso hablamos de cobertura total (todas las personas estn clasificadas como empleados o clientes) y exclusiva (s una persona se clasifica como empleado, no puede clasificarse como cliente y al contrario ocurre lo mismo).

Caso cobertura total y superpuesta: Todas las personas son empleados o clientes del banco, permitindose que un empleado sea a su vez cliente. En este caso hablamos de cobertura total (todas las personas estn clasificadas como empleados o clientes) y superpuesta (no existe restriccin con respecto a la exclusividad).

Caso cobertura parcial y exclusiva: Hay personas, algunas de las cuales son empleados o clientes del banco, pero no ambas cosas simultneamente. En este

caso hablamos de cobertura parcial (no todas las personas estn clasificadas como empleados o clientes) y exclusiva (s una persona se clasifica como empleado, no puede clasificarse como cliente y al contrario ocurre lo mismo).

Caso cobertura parcial y superpuesta: Algunas personas son empleados o clientes del banco, pudiendo ser ambas cosas. En este caso hablamos de cobertura parcial (no todas las personas estn clasificadas como empleados o clientes) y sobrepuesta (si una persona se clasifica como empleado tambin puede clasificarse como cliente).

2.5.4.- Agregacin de Tipos de Entidad.

Un tipo de interrelacin y los tipos de entidad que relaciona, puede ser manejado como un tipo de entidad en un nivel de abstraccin mayor, lo que posibilita que se pueda interrelacionar con otros tipos de entidad. Este mecanismo es conocido como Estructura de Agregacin o Agregacin de Tipos de Entidad, en aquellas extensiones del MER que la incorporan.

Ejemplo: En una organizacin se manejan pedidos, los que incluyen productos solicitados por clientes. Cada pedido debe ser asignado a un empleado.

2.5.5.- Roles de Tipos de Entidad en Tipos de Interrelacin.

Un Rol de un Tipo de Entidad en un Tipo de Interrelacin es la funcin que aquel cumple dentro de sta. La definicin de roles permite atribuirle a un tipo de entidad su semntica dentro de la agregacin, aportndole mayor expresividad al esquema y permitiendo disminuir ambigedades en la definicin de cardinalidades (esto cobra mayor importancia en aquellos tipos de interrelacin que involucran a un mismo tipo de entidad ms de una vez).

Ejemplo:

2.5.6.- Tipos de Interrelaciones Exclusivas con respecto a un Tipo de Entidad.

Sea TE un tipo de entidad y sea un conjunto de tipos de interrelacin RE= {R1,...,Rn} tales que TE Ri, i en {1,...,n}, RE se dice exclusivo con respecto a TE, si cada ocurrencia de TE slo puede estar presente a lo ms en un Ri, i en {1,...,n}. Observacin: En este caso la cardinalidad mnima de TE con respecto a Ri, con i en {1,...,n} debe ser 0.

Ejemplo: Consideremos el caso de una organizacin donde se desarrollan proyectos, los cuales pueden ser asignados a empleados de la organizacin, o a una empresa contratista, pero no a ambos.

2.6.- Restricciones en MER extendido.

Las restricciones estticas especifican los estados posibles de la base de datos modelada en un esquema dado. En un esquema MER la principal restriccin esttica est dada por la estructura (pertenencia de un atributo a un tipo de entidad o interrelacin, tipos de entidad que relaciona un tipo de interrelacin), y tambin se pueden especificar las siguientes. o o o o o o Dominio. Cardinalidad de atributo con respecto a un tipo de entidad. Cardinalidad de un tipo de entidad con respecto a un tipo de interrelacin. Identificadores. Cobertura. Tipos de Interrelacin Exclusivas con respecto a un Tipo de Entidad.

2.7.- Estrategia para modelar con MER.

Se debe hacer uso de los conceptos de abstraccin bsicos: clasificacin, agregacin y generalizacin. Para ello se pueden seguir los procesos siguientes. 1. Identificar Tipos de Entidad y las relaciones que existen entre ellos. 2. Descomponer un tipo de entidad en dos o ms tipos de entidad, relacionados o no, o participando en una estructura de generalizacin. 3. Descomponer un tipo de interrelacin en varias. 4. Identificar atributos para cada elemento. 5. Definir identificadores para los tipos de entidad. 6. Definir restricciones de cardinalidad y cobertura. 7. Verificar que el esquema resultante es correcto con respecto a la especificacin (representa toda la realidad descrita). 8. Verificar que el esquema es correcto con respecto al buen uso del modelo. 9. Analizar modificaciones al esquema.

2.8.- Ejemplo.
Consideremos el caso de un campeonato juvenil (menores de 25 aos) de ftbol. Existen distintos aspectos a considerar para este caso. o o o o o o o Hay equipos de a lo menos 11 jugadores. Cada jugador puede participar en un equipo solamente. En cada partido juegan dos equipos. En cada partido participan 3 colegiados: un arbitro, un arbitro de banda derecha y un arbitro de banda izquierda. Cada jugador tiene asignadas posiciones en las que puede jugar en un partido. Cada jugador de un equipo participa en un partido en una posicin, que debe ser alguna para las cuales est preparado. No necesariamente todas las posiciones deben ser ocupadas en un partido (puede haber ms de once posiciones).

2.8.1.- Esquema MER.

Sea el siguiente esquema MER una posible representacin de la realidad descrita:

Los nombres de los tipos de interrelacin han sido abreviados para mayor legibilidad del esquema. A continuacin se detalla su significado. L: Local V: Visita P: Pertenece

J: Juega O: Ocupa H: habilitado para I: Arbitro Banda Izquierda D: Arbitro Banda Derecha A: Arbitro.

Se definen los atributos de los tipos de entidad a continuacin.

Tipo de Entidad Equipo Jugador

Atributo nombre equipo rut nombre fecha de nacimiento fecha

Dominio Nombres de equipos de ftbol Rut vlidos Nombres de Persona Fechas posteriores a 1971 Fechas del ao 1996 Horas entre las 10:00 y las 21:30 Rut vlidos Nombres de Persona enteros mayores que cero Funciones de Jugadores Jugador Partido

Partido hora rut Colegiado nombre nmero Posicin funcin JuegaPartido (es Agregacin ) Jugador Partido

Las restricciones que no se han definido explcitamente en el esquema ni en la documentacin posterior, se presentan a continuacin: a. Un equipo no puede participar en un mismo partido como visita y local a la vez. b. Un jugador slo puede jugar en un partido ocupando una posicin en la que est habilitado. c. Un jugador slo puede jugar en un partido si su equipo participa en l como local o visita. d. De los jugadores que participan en un partido, a lo menos 11 pertenecen al equipo local y 11 al equipo visitante. e. En un mismo partido, deben estar asignados colegiados distintos para cada rol.

2.9.-Modelos de Datos y Diseo de Bases de Datos

Los niveles de abstraccin de la arquitectura ANSI facilitan el diseo de una base de datos, al proporcionar instrumentos que ayudan a la estructuracin del mundo real hasta llegar a la base de datos fsica. En el estado actual de la tecnologa, donde aun no existe un modelo conceptual (y su lenguaje de descripcin) generalizado e independiente del SGBD, es preferible hacer una distincin entre el esquema conceptual, tal como es concebido en la normativa ANSI (descripcin de la organizacin de acuerdo con un modelo independiente del SGBD) y lo que es el esquema de los actuales SGBD (jerrquica, red, relacional) y su sometimiento a las restricciones que estos impongan.

2.9.1.- Modelos conceptuales. Sus caractersticasEl diseo de bases de datos no es el

nico campo para la aplicacin de los modelos conceptuales. En los aos 80, los llamados sistemas de diccionarios de datos, cuya funcin es definir el contenido de la base de datos y de los programas de aplicacin dentro de los SI, utilizaron extensamente los modelos conceptuales. Principalmente debido a la facilidad de lectura y la expresividad de stos (documentacin de la base de datos).

Una condicin bsica de los modelos conceptuales es que son buenas herramientas para representar la realidad. Expresividad: Hacen uso de la abstraccin de generalizacin, de modo que permiten una representacin directa en el esquema de una gran variedad de restricciones de integridad, es decir, aserciones que permiten la seleccin de casos vlidos del esquema de base de datos. Simplicidad: Debe ser simple, para que un esquema creado con este modelo sea fcil de entender por diseadores y usuarios de la aplicacin de bases de datos. Notar que un modelo muy expresivo tiende a ser complejo. Minimalidad: Si cada concepto presente en el modelo tiene un significado distinto con respecto a todos los dems. Formalidad: Los esquemas creados usando modelos conceptuales representan una especificacin formal. Todos los conceptos del modelo tienen una interpretacin nica, precisa y bien definida.

En el rea de bases de datos existe permanentemente el debate de los modelos de datos. De acuerdo a la arquitectura de las bases de datos (ANSI/SPARC), podemos distinguir 3 tipos de modelos: Modelos externos Modelos conceptuales Modelos internos

Los dos primeros pueden llamarse modelos lgicos y el ltimo un modelo fsico. Algunos autores dividen los modelos lgicos en conceptuales y convencionales. Segn A. de Miguel, los modelos conceptuales son entidad/interrelacin, infolgico, RM/T, etc. y los modelos convencionales son modelos jerrquicos, de red y relacional. Segn Battini, un modelo de datos es una serie de conceptos que puede utilizarse para describir un conjunto de datos y operaciones para manipularlos. Cuando un modelo de datos describe un conjunto de conceptos de una realidad determinada, se llama modelo conceptual de datos. Los conceptos de un modelo de datos se construyen por lo regular usando mecanismos de abstraccin y se describen mediante representaciones lingsticas y grficas; es decir, puede definirse una sintaxis y puede desarrollarse una notacin grfica. Hay dos tipos de modelos de datos: modelos conceptuales, usados en el diseo de bases de datos y modelos lgicos, apoyados por los SGBD, que son paquetes de software que crean, modifican y mantienen bases de datos. Los modelos conceptuales son instrumentos para representar la realidad a un nivel alto de abstraccin. Utilizando los modelos conceptuales, podemos construir una descripcin de la realidad fcil de entender e interpretar. Los modelos lgicos apoyan descripciones de datos procesables por un computador, incluyen el modelo jerrquico, de red y relacional. Segn Knorth, los diversos modelos de datos que se han propuesto se dividen en tres grupos: modelos lgicos basados en entidades u objetos, modelos lgicos basados en registros y modelos fsicos de datos.

Dentro de los primeros tenemos, el modelo entidad-interrelacin, el modelo orientado a objetos, entre otros. El objetivo de stos es proporcionar altos niveles de abstraccin, o lo que significa que se usan en niveles conceptuales. Los modelos lgicos basados en registros se usan para describir los datos en forma lgica y global, siendo de un nivel ms alto que el de implementacin. Aqu tenemos el modelo relacional, modelo de red y el modelo jerrquico. Una idea bsica de estos ltimos modelos se presenta a continuacin. Modelo Jerrquico Por medio de un modelo jerrquico, el esquema de datos puede visualizarse como un grafo arborescente, en que los nodos corresponden a las clases de objetos y los arcos corresponden a asociaciones entre 2 nodos.

Modelo de Red El esquema de datos puede visualizarse como un grafo sin ningn tipo de limitacin, es decir, existen ciclos. Los nodos representan clases de objetos y los arcos relaciones entre 2 nodos.

Modelo Relacional Representa los datos y las relaciones entre los datos mediante una coleccin de tablas.

3.-MODELO RELACIONAL
3.1.-Evolucin del MR
La siguiente tabla hace una sntesis de la evolucin del Modelo Relacional, desde su surgimiento a fines de la dcada del sesenta hasta la actualidad.

Aos
1968-1970 1970... 1973-1978 1979 1981 1982

Sucesos
Surge el Modelo Relacional (Codd). Aparece el concepto de relacin: tabla. Desarrollo tericos: ej: lgebra relacional (Codd, 1972). Prototipos (Ingres, Sistema R, etc.) Oracle SQL Sybase, Informix

1984 1986 1990 1992 1994

SQL/ANS SQL ISO Modelo Relacional versin 2 (RM/V2) Codd. Nulos SQL2 estndar. SQL3 Aun no estandarizado BDOO

3.2.-Objetivos del MR
El trabajo publicado por Codd en ACM (1970) presentaba un nuevo modelo de datos que persegua una serie de objetivos, que se resumen en los siguientes: Independencia fsica. El modo en el que se almacenan los datos no influye en su manipulacin lgica y por tanto, los usuarios que acceden a esos datos no tienen que modificar sus programas por cambios en el almacenamiento fsico. Independencia lgica. El aadir, eliminar o modificar objetos de la base de datos no repercute en los programas y/o usuarios que estn accediendo a subconjuntos parciales de los mismos (vistas). Flexibilidad. En el sentido de poder presentar a cada usuario los datos de la forma en que ste prefiera. Uniformidad. Las estructuras lgicas de los datos presentan un aspecto uniforme, lo que facilita la concepcin y manipulacin de la base de datos por parte de los usuarios. Sencillez. Las caractersticas anteriores, as como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea fcil de comprender y de utilizar por parte del usuario final.

El modelo Relacional se divide en 3 partes: estructura de los datos, integridad de los datos, y manipulacin de los datos.

3.3.-Estructura del Modelo Relacional

La relacin es el elemento bsico del modelo relacional y se representa por una tabla. Informalmente, los trminos y sus equivalentes son:

Relacin Tupla Atributo Nmero de tuplas Nmero de atributos

Tabla Fila Columna Cardinalidad Grado

Dominio Clave primaria

Coleccin de valores, de los cuales uno o mas atributos obtienen sus valores reales Identificador nico para la tabla, es decir, una columna o combinacin de columnas con la propiedad de que nunca existen 2 filas de la tabla con el mismo valor en esa columna o combinacin de columnas

Es importante sealar que la tabla es plana en el sentido de que el cruce de una fila y una columna solo puede dar un valor, es decir, no se admiten atributos multivaluados.

3.3.1.-Dominio y Atributo
Concepto de Dominio Un Dominio D es un conjunto finito de valores homogneos y atmicos V1, V2, ...Vn caracterizados por un nombre. Homogneo significa que los valores son todos del mismo tipo y atmicos significa que son indivisibles, es decir, si se descomponen se perdera la semntica del dominio. Ejemplos: Dominio de Nacionalidades: Chilena, Francesa, Norteamericana, etc. Todo dominio tiene un nombre y un tipo de datos, en el ejemplo anterior, el tipo de datos es un conjunto de caracteres de longitud mxima de 10. Se pueden asociar unidades de medida, como metros, kilos, etc. y otras restricciones. Se considera que los dominios no incluyen nulos, ya que nulo (null) no es un valor. La importancia de los dominios es que restringen las comparaciones, es decir, solo se pueden comparar atributos definidos sobre el mismo dominio. Concepto de Atributo Un atributo A es el papel que tiene un determinado dominio D en una relacin. Se dice que D es el dominio de A y se denota dom(A). Es usual dar el mismo nombre al atributo y al dominio subyacente. En el caso de que sean varios los atributos de una misma tabla, definidos por el mismo dominio, habr que darles nombres distintos, ya que una tabla no puede tener dos atributos con el mismo nombre. Un dominio compuesto es una combinacin de dominios simples que tiene un nombre y sobre l se pueden aplicar ciertas restricciones de integridad. Por ejemplo, un usuario podra manejar adems de los tres dominios Da, Mes, Ao, un dominio compuesto llamado Fecha que sera la combinacin de los tres y al que podramos aplicar restricciones de integridad a fin de que no aparecieran valores no vlidos para la fecha. De la misma forma se puede definir un atributo compuesto Fecha que toma valores del dominio compuesto de igual nombre. Todos los atributos compuestos como los dominios compuestos pueden ser tratados como piezas nicas de informacin, es decir, como valores atmicos.

3.3.2.-Relacin
Matemticamente una relacin definida sobre los n dominios D1, D2,.., Dn no necesariamente distintos, es un subconjunto del producto cartesiano de estos dominios donde cada elemento de la relacin, una tupla, es una serie de n valores ordenados. Esta definicin (Codd) no alude a atributos y adems en las tuplas los valores estn ordenados, de modo que podemos manejar el concepto de relacin un poco mas actualizado diciendo que: Una relacin R sobre un conjunto de dominios D1,D2,...Dn -no necesariamente todos distintos-, se compone de dos partes: una cabecera y un cuerpo (Date). La cabecera est formada por un conjunto de atributos o, en trminos ms precisos, de pares atributo-dominio {(A1:D1), (A2:D2),...., (An:Dn)}, donde cada atributo Aj corresponde a uno y solo uno de los dominios subyacentes Dj (j=1,2,...,n). El cuerpo est formado por un conjunto de tuplas, que vara en el tiempo. Cada tupla est formada por pares atributo-valor {(A1:vi1), (A2:vi2),....,(An:vin)} (i=1,2,...,m), donde m es el numero de tuplas del conjunto. Los valores m y n se llaman cardinalidad y grado respectivamente. La cardinalidad vara con el tiempo, el grado no.Segn A. de Miguel. La relacin R tiene dos conceptos: Intensin o Esquema de relacin, denotado R(A1:D1, A2:D2, ....An:Dn) es un conjunto de n pares atributo-dominio subyacente {(Ai:Di)} donde n es el grado del esquema de relacin. La intensin es la parte definitiva y esttica de la relacin (relativamente) que corresponde a la cabecera cuando la relacin se percibe como una tabla. Extensin o Instancia de relacin, denotada por r(R) es un conjunto de m tuplas {t1,t2,...,tm} donde cada tupla es un conjunto de n pares atributo-valor {(Ai:Vij)}, donde Vij es el valor del dominio Di asociado al atributo Ai en la tupla j. El nmero de tuplas m es la cardinalidad.

Intensin de una relacin: AUTOR(NOMBRE: Nombres, NACIONALIDAD: Nacionalidades, INSTITUCION: Instituciones) Extensin de una relacin:

AUTOR NOMBRE Date, C.J. De Miguel, A. Ceri,S. NACIONALIDAD Norteamericana Espaola Italiana INSTITUCION Relational Ins. FIM Politecnico Milan

No hay dos tuplas iguales El orden de las tuplas no es significativo El orden de las columnas o atributos no es significativo

Cada atributo solo puede tomar un unico valor del dominio, no admitiendo por lo tanto los grupos repetitivos.

Anlisis: Si nos atuvisemos a la definicin matemtica de relacin como "subconjunto del producto cartesiano de n dominios no necesariamente distintos", el orden de los atributos seria significativo, es decir, si cambisemos el orden de los atributos tendramos una relacin distinta. Ante el inconveniente que esto supondra para el usuario y las ventajas de poder alterar el orden de los atributos sin que cambie la relacin, es conveniente definir la relacin de esta otra manera, siendo consistente con la restriccin de que el orden de las tuplas no es significativo. Esta es una de las diferencias entre la relacin matemtica y la relacin del modelo relacional.

3.3.3.-Claves
Una clave candidata de una relacin es un conjunto no vaco de atributos que identifican unvoca y mnimamente cada tupla. Toda relacin siempre tendr una clave candidata. Clave primaria: es aquella clave candidata que el usuario elegir, por consideraciones ajenas al modelo relacional, para identificar las tuplas de la relacin. El modelo relacional no incluye este concepto de elegir una clave como primaria, cuando hay varias candidatas. Clave alternativas: Son aquellas claves candidatas que no han sido escogidas como claves primarias. Clave ajena o fornea: de una relacin R2 es un conjunto no vaco de atributos cuyos valores han de coincidir con los valores de la clave primaria de una relacin R1 (R1 y R2 no son necesariamente distintas). Notar que la clave ajena y la correspondiente clave primaria han de estar definidas sobre los mismos dominios.

3.3.4.-Restricciones
Las restricciones son estructuras no permitidas. Hay dos tipos: inherentes y del usuario. Las inherentes al modelo, tal como no tener tuplas repetidas y las del usuario que validan las instancias de la relaciones. 3.3.4.1.-Restricciones inherentes Adems de las derivadas por el concepto de relacin, existe la llamada regla de integridad de entidad. "Ningn atributo que forme parte de la clave primaria de una relacin puede tomar un valor nulo". Nulo significa desconocido o inexistente. Esta restriccin debera aplicarse a las claves alternativas, pero el modelo no lo exige. Justificaciones Las entidades del mundo real son identificables y distinguibles. Si una entidad es lo bastante importante en el mundo real como para requerir una representacin explcita en la base de datos, tal entidad deber ser susceptible de indentificarla sin ambigedad, pues de lo contrario seria imposible hablar de ella. Por esto, la regla de integridad de las entidades se expresa as: En una base de datos, nunca registraremos informacin acerca de algo que no podamos identificar.

3.3.4.2.-Restricciones de usuario Se pueden definir como un predicado sobre un conjunto de atributos, de tuplas o de dominios, que debe ser verificado para que constituya una ocurrencia valida del esquema. Dentro de estas, destaca la restriccin de integridad referencial:" Si una relacin R2 (relacin que referencia) tiene un descriptor que es la clave primaria de la relacin R1 (relacin referenciada), todo valor de dicho descriptor debe concordar con un valor de la clave primaria de R1 o ser nulo". El descriptor es una clave ajena de la relacin R2. EDITORIAL( NOMBRE_E, DIRECCION, CIUDAD, PAIS ); PK: NOMBRE_E LIBRO( CODIGO,TITULO,IDIOMA,...., NOMBRE_E ); PK:CODIGO FK:NOMBRE_E La clave fornea, NOMBRE_E podra ser null, ya que en un momento determinado podramos no conocer la editorial de un libro. Esta clave que referencia a EDITORIAL debe concordar con la clave primaria de EDITORIAL. AUTOR( NOMBRE, NACIONALIDAD, INSTITUCION, ....); PK:NOMBRE LIBRO( CODIGO, TITULO, IDIOMA, EDITORIAL,...); PK:CODIGO ESCRIBE( NOMBRE, CODIGO ); PK:NOMBRE+CODIGO FK:NOMBRE, CODIGO Las claves forneas NOMBRE y CODIGO no pueden ser nulos, porque ambas son la clave primaria de ESCRIBE. Adems de definir las claves forneas, hay que definir las consecuencias de las operaciones de borrar y modificar tuplas de la relacin referenciada: Operacin restringida (RESTRICT) Borrar o modificar tuplas de una relacin que contiene la clave primaria referenciada slo se permite, si no existen tuplas con dicha clave en la relacin que contiene la clave fornea. Ej: para borrar una editorial, no tendra que haber ningn libro que estuviese publicado por dicha editorial. Operacin con transmisin en cascada (CASCADE) El borrado o modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo el borrado o modificacin en cascada de las tuplas de la relacin que contiene la clave fornea. Ej: Al modificar el nombre de una editorial en EDITORIAL, se tendra que modificar tambin dicho nombre en todos los libros publicados por dicha editorial. Operacin con puesta a nulos (SET NULL) El borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo poner a nulos los valores de las claves forneas de la relacin que referencia. Ej: cuando borramos una editorial, los libros que ha publicado dicha editorial y que se encuentran en LIBRO se les coloque el atributo nombre_e a nulos. Esta opcin solo es posible cuando el atributo que es clave fornea admite el valor nulo. Operacin con puesta a valor por defecto (SET DEFAULT) El borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo poner el valor por defecto a la clave fornea de la

relacin que referencia. Este valor debe ser definido al momento de crear la tabla correspondiente. Operacin que desencadena un procedimiento de usuario El borrado o la modificacin de tuplas de la tabla referenciada pone en marcha un procedimiento definido por el usuario. Nota: cuando las restricciones de integridad referencial afectan a varias tablas, hay que tener en cuenta que la combinacin de opciones puede generar graves problemas de integridad.

3.4.- Dinmica Relacional

La ltima parte del Modelo Relacional es su componente dinmica, que se divide en 2 partes: lgebra relacional y clculo relacional. El lgebra relacional se basa en un conjunto de operadores que operan sobre relaciones. El clculo relacional se basa en predicados que definen un estado objetivo de la base de datos, y tenemos el clculo relacional orientado a la tupla y el clculo relacional orientado al dominio.

3.4.1.- Algebra Relacional

Formada por un conjunto de operadores de alto nivel, que aplicados sobre relaciones, obtienen relaciones. Esta se llama propiedad de cierre. Son 8 operadores, 5 de los cuales son primitivos, en relacin a que son los tradicionales de la teora de conjuntos. 3.4.1.1.- Operadores primitivos Operadores Unarios Sea R(A) una relacin, R(A) = R(A1:D1, A2:D2,...,An:Dn), donde A es el conjunto de atributos definidos sobre el conjunto de dominios D. Sea r(R) definida sobre el esquema R, de grado n y cardinalidad m, constituida por el conjunto de m tuplas.

r(R) = { ti} , i=1, m; donde ti = < vi1, vi2, ... vin > / vij Di

Operador Restriccin ( ) La restriccin, tambin llamada seleccin, de una relacin mediante una expresin lgica (predicado de seleccin) da como resultado una relacin formada por el subconjunto de tuplas que satisfacen dicha expresin. La relacin resultante constituye un subconjunto horizontal de r(R). AUTOR( NOMBRE, NACIONALIDAD, INSTITUCION ) AUTOR NOMBRE NACIONALIDAD INSTITUCION

Date, C.J. De Miguel, A. Ceri,S.

Norteamericana Espaola Italiana

Relational Ins FIM Politecnico Milan

nacionalidad

= "espaola" (AUTOR) NACIONALIDAD Espaola INSTITUCION FIM

NOMBRE De Miguel, A.

Formalmente: Sea un operador de comparacin (>, <, =, , , ) y p un predicado de seleccin formado por una expresin lgica integrada por clusulas de la forma: Ai Aj Ai constante, unidas por los operadores booleanos "AND", "OR", "NOT". El operador de seleccin aplicado a la relacin R con el predicado p, se denota: p(R) y produce una relacin cuyo esquema R ser el mismo y cuya extensin ser:

{ ti r(R) / p(ti) = "cierto"}

El grado de la relacin resultante ser por tanto n, es decir el mismo que el de la relacin R y su cardinalidad m m. Operador Proyeccin ( ) La proyeccin de una relacin sobre un subconjunto de sus atributos es una relacin definida sobre ellos, eliminando las tuplas duplicadas que hubieran podido resultar; es por tanto, un subconjunto vertical de la relacin a la que se aplica el operador.

nacionalidad institucin(AUTOR)

NACIONALIDAD Norteamericana Espaola Italiana

INSTITUCION Relational Ins. FIM Politecnico Milan

Formalmente: Sea X un subconjunto estricto y no vaco de A ( X A y X ), la aplicacin del operador de proyeccin a R en el contexto de X, denotado por: X(R) ser una relacin cuyo esquema es R(X) y cuya extensin es el conjunto de tuplas de la relacin original definidas sobre los atributos X, eliminando las que resulten duplicadas, es decir:

{ ti(X) / X A}.
El grado n y la cardinalidad m de la relacin resultante cumplen con : n < n y m m.

Operadores Binarios Los operadores binarios se aplican a dos relaciones y algunos de ellos (unin, diferencia e interseccin) exigen que las dos relaciones involucradas sean compatibles en sus esquemas. Se dice que dos relaciones R y R con esquemas R(Ai:Di) y R(Ai:Di) y cardinalidades m y m, son compatibles a efectos de dichos operadores cuando ambas estn definidas sobre el mismo conjunto de dominios, cumplindose:

Ai Aj / dom(Ai) = dom(Aj) y Ai Aj / dom(Ai) = dom(Aj)

o sea, R y R sern semnticamente equivalentes, lo que no quiere decir, que los nombres de los atributos sean los mismos (sintcticamente), sino que han de estar definidos sobre los mismos dominios. Unin (U) La unin de dos relaciones compatibles en su esquema es otra relacin definida sobre el mismo esquema de relacin, cuya extensin estar constituida por las tuplas que pertenezcan a R o a R o a ambas (se eliminan las tuplas repetidas puesto que se trata de una relacin).

AUTOR NOMBRE Date C.J. De Miguel Saltor F. Ceri S. NACIONALIDAD Norteamericana Espaola Espaola Italiana INSTITUCION Relational Ins. FIM FI de UPB Polit.Milan

EDITOR NOMBRE Chen P. De Miguel NACIONALIDAD Norteamericana Espaola INSTITUCION ER Ins. FIM

Yao L. Ceri S.

Norteamericana Italiana

U.NY Polit.Milan

AUTOR U EDITOR NOMBRE Date C.J. De Miguel Saltor F. Ceri S. Chen P. Yao L. NACIONALIDAD Norteamericana Espaola Espaola Italiana Norteamericana Norteamericana INSTITUCION Relational Ins. FIM FI de UPB Polit.Milan ER Ins. U.NY

Formalmente: Sean dos relaciones compatibles con esquemas R y R, la unin de ambas, denotada por R U R ser una relacin con esquema R (o R ya que ambos son iguales) y con extensin:

ti / ti r v ti r
Diferencia (-) La diferencia de dos relaciones compatibles en su esquema es otra relacin definida sobre el mismo esquema de relacin, cuya extensin estar constituida por el conjunto de tuplas que pertenezcan a R pero no a R.

AUTOR NOMBRE Date C.J. De Miguel Saltor F. Ceri S. Chen P. Yao L. NACIONALIDAD Norteamericana Espaola Espaola Italiana Norteamericana Norteamericana INSTITUCION Relational Ins. FIM FI de UPB Polit.Milan ER Ins. U.NY

EDITOR NOMBRE Chen P. De Miguel Yao L. Ceri S. NACIONALIDAD Norteamericana Espaola Norteamericana Italiana INSTITUCION ER Ins. FIM U.NY Polit.Milan

AUTOR - EDITOR NOMBRE Date C.J. Saltor F. NACIONALIDAD Norteamericana Espaola INSTITUCION Relatinal Ins. FI de UPB

Formalmente: Sean dos relaciones compatibles con esquemas R y R, la diferencia entre ambas, denotada por: R - R ser una relacin con esquema R (o R ya que son iguales) y con extensin:

ti / ti r ti r
Producto cartesiano generalizado ( ) El producto cartesiano generalizado de dos relaciones de cardinalidades m y m es una relacin cuyo esquema estar definido sobre la unin de los atributos de ambas relaciones y cuya extensin estar constituida por las m m tuplas formadas concatenando cada tupla de la primera relacin con cada una de las tuplas de la segunda.

SOCIOS CODIGO 1 2 NOMBRE Elena Manriquez Manuel Garca DIRECCION Calle 123 Calle 234

LIBROS LIBRO DB Systems Basi di Dati SQL stan. AUTOR Date C.J. Ceri S. Date C.J. EDITORIAL Addison Clup Addison

SOCIOS LIBROS CODIGO 1 1 1 2 2 2 NOMBRE Elena Manriquez Elena Manriquez Elena Manriquez Manuel Garca Manuel Garca Manuel Garca DIREC Calle 123 Calle 123 Calle 123 Calle 234 Calle 234 Calle 234 LIBRO DB Systems Basi di Dati SQL stan. DB Systems Basi di Dati SQL stan. AUTOR Date C.J. Ceri S. Date C.J. Date C.J. Ceri S. Date C.J. EDITORIAL Addison Clup Addison Addison Clup Addison

Formalmente: Sean las relaciones con esquemas R y R, el producto de ambas denotado: R R ser una relacin de grado n + n cuyo esquema estar formado por los n + n atributos A U A. Es decir: (Ai:Di,...,An:Dn, Ai:Di,...,An : Dn) y cuya extensin, de cardinalidad m m ser:

< vi1,...,vin,vj1,...,vjn > / i, j (vi1,...,vin> r <vj1,...,vjn> / r)

Resumen:

3.4.1.2.-Operadores derivados Se caracterizan porque se pueden expresar en funcin de los operadores primitivos. Combinacin o Reunin ( ) La combinacin de dos relaciones respecto de sus columnas k y l, es otra relacin constituida por todos los pares de tuplas ti y tj concatenadas, tales que, en cada par, las columnas k y l de las correspondientes tuplas satisfacen la condicin especificada. Es decir, el k-esimo elemento de la tupla ti de la primera relacin cumple con respecto al l-esimo elemento de la tupla tj de la segunda, la condicin especificada; denotamos por cualquier operador de comparacin. Formalmente: La combinacin de las dos relaciones de esquemas R y R respecto de sus columnas k y l, denotada: R * R es otra relacin de grado n + n, cuyo esquema estar formado por los n + n atributos: A U A. es decir: ( A1:D1,..., An:Dn, A1:D1,...,An:Dn ) y cuya extensin, de cardinalidad m x m, ser:

<vi1...vin,vj1,...,vjn> / i j ( <vi1...vin > r < vj1,...,vjn> r vik vjl = "cierto")

Si la condicin es la de igualdad, se denomina combinacin por igualdad (equi_join). La llamada combinacin natural es una combinacin por igualdad donde se ha eliminado en la relacin resultante uno de los atributos idnticos. Es el caso ms comn para relaciones que tienen

un atributo comn.

AUTOR NOMBRE Date C.J. De Miguel Saltor F. Ceri S. NACIONALIDAD Norteamericana Espaola Espaola Italiana INSTITUCION Relational Ins. FIM FI de UPB Polit.Milan

LIBROS LIBRO DB Systems Basi di Dati SQL stan. Diseo BD AUTOR Date C.J. Ceri S. Date C.J. De Miguel EDITORIAL Addison Clup Addison Rama

AUTOR * LIBROS (autor.nombre = libros.autor) NOMBRE Date C.J. De Miguel Date C.J. Ceri S. NACIONALIDAD Norteamericana Espaola Norteamericana Italiana INSTITUCION Relational Ins. FIM Relational Ins. Polit.Milan LIBRO DB Systems Diseo BD SQL stan Basi di Dati EDITORIAL Addison Rama Addison Clup

La combinacin es un producto cartesiano seguido de restriccin, y la combinacin natural es un producto cartesiano seguido de una restriccin por igualdad y de proyeccin. Interseccin ( )

La interseccin de dos relaciones compatibles en su esquema es otra relacin definida sobre el mismo esquema de relacin, cuya extensin estar constituida por las tuplas que pertenezcan a ambas relaciones.

AUTOR NOMBRE Date C.J. De Miguel Saltor F. Ceri S. NACIONALIDAD Norteamericana Espaola Espaola Italiana INSTITUCION Relational Ins. FIM FI de UPB P.Milan

EDITOR NOMBRE Chen P. De Miguel Yao L. Ceri S. NACIONALIDAD Norteamericana Espaola Norteamericana Italiana INSTITUCION ER Ins. FIM U.NY Polit.Milan

AUTOR EDITOR NOMBRE De Miguel Ceri S. NACIONALIDAD Espaola Italiana INSTITUCION FIM Polit.Milan

Formalmente: Sean dos relaciones compatibles con esquemas R y R, la interseccin de ambas, denotada por: R R ser una relacin con esquema R (o R ya que son iguales) y con extensin:

ti / ti r ti r
La interseccin se puede definir en funcin de la Unin y la Diferencia: R R = (R U R) - ((R -R) U (R - R)).

Divisin (:) La divisin de dos relaciones es otra relacin cuya extensin estar constituida por las tuplas que al completarse con las tuplas de la segunda relacin permiten obtener la primera. Formalmente: Sean dos relaciones con esquemas R y R, la divisin de ambos, denotada R : R ser una relacin de grado n-n cuyo esquema estar formado por los n-n atributos A - A es decir:

(Ai:Di,...,An-n:Dn-n)
y cuya extensin ser:

< vi1,...,vi(n-n) > / < vi(n-n+1),..., vin > r < vi1,...,vi(n-n) , vi(n-n+1),..., vin > r

AUTOR NOMBRE Date C.J. De Miguel Saltor F. Ceri S. Costilla C. Codd E. De Miguel NACIONALIDAD Norteamericana Espaola Espaola Italiana Espaola Norteamericana Espaola EDITORIAL Addison Rama Paraninfo Club Diaz de Santos Prentice Hall Addison

EDITORIAL EDITORIAL Addison Rama

AUTOR : EDITORIAL (saber los autores que han publicado en Addison y Rama)

NOMBRE De Miguel

NACIONALIDAD Espaola

La divisin se puede expresar en funcin de la proyeccin, del producto cartesiano y de la diferencia:

R : R = B(R) - B(R X B(R) - R), siendo B el conjunto de atributos de A menos A.

4.-Metodologa para el Diseo de Bases de Datos

4.1.-Introduccin
La concepcin de una Base de Datos Relacional es una tarea larga y costosa. Existe la necesidad de contar con procedimientos ordenados que faciliten el desarrollo de un producto software, ya que esto tiene una incidencia en cuanto a costos y plazos de entrega, adems de la calidad y mantenimiento del producto. Segn Sommerville (1988) " un buen diseo es la clave de una eficiente ingeniera del software. Un software bien diseado es fcil de aplicar y mantener, adems de ser comprensible y fiable. Los sistemas mal diseados, aunque puedan funcionar, sern costosos de mantener, difciles de probar y poco fiables". Muchas veces, el diseo de una base de datos se limita aplicar la teora de normalizacin, cuando en realidad debe abarcar muchas otras etapas, que van desde la concepcin hasta la instrumentacin. Una metodologa es un conjunto de modelos y herramientas que nos permiten pasar de una etapa a la siguiente en el proceso de diseo de la base de datos. Rolland y Benci (1988). En la determinacin de las fases de la metodologa debemos definir una jerarqua de niveles de abstraccin que resulte apropiada, en el sentido de ser lo suficientemente amplia para que a cada nivel le correspondan decisiones de diseo bien definidas, pero, a la vez, no proponer demasiados niveles, ya que sera muy sensible a la interpretacin del diseador. No existe una metodologa consagrada, sin embargo, ciertas etapas son distinguibles: Diseo Conceptual, cuyo objetivo es obtener una buena representacin de los recursos de informacin de la empresa, con independencia de usuarios o aplicaciones en particular y fuera de consideraciones de eficiencia del computador. Diseo Lgico, cuyo objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptndolo al modelo de datos en el que se apoya el SGBD que se va a utilizar (modelo relacional).

Diseo Fsico, cuyo objetivo es conseguir una instrumentacin lo mas eficiente posible del esquema lgico.

Causas de malos diseos Falta de conocimiento del dominio de la aplicacin, conocimiento que no posee el informtico, pero si el usuario (aunque no sepa estructurarlo ni expresarlo de forma precisa). Falta de experiencia en el modelado

4.2.-Etapa 1:Diseo Conceptual

Bsicamente 2 etapas: Etapa de anlisis de requisitos Etapa de conceptualizacin

El anlisis de requisitos debe responder a la pregunta: que representar? Para ello hay que estudiar las reglas de la empresa (del negocio) a los diferentes niveles de la organizacin, para elaborar una descripcin de la organizacin. Esquema percibido. Puede utilizarse el lenguaje natural. La segunda etapa responde a la pregunta Como representar?. Aqu se utilizan los modelos conceptuales. Nosotros utilizaremos el MER y sus extensiones, que bsicamente define entidades, atributos, interrelaciones y restricciones semnticas. Esquema conceptual. En el paso del esquema percibido al esquema conceptual. No existen reglas claras que permitan decidir que elemento es una entidad o cual otro una interrelacin. Existen 2 enfoques. Enfoque lingstico y categorizacin de objetos. En el enfoque lingstico: un sustantivo (nombre comn) que acta como sujeto o complemento directo en un frase es por lo general un tipo de entidad, aunque podra ser un atributo. Ej: los socios piden prestados libros, existen 2 posibles entidades: SOCIO y LIBRO. los nombres propios indican ocurrencias de un tipo de entidad, Ej: Date,C indica una ocurrencia de AUTOR. un verbo transitivo o una frase verbal es un tipo de interrelacin, Ej: pedir prestado indica una interrelacin entre las entidades LIBRO y SOCIO. una preposicin entre 2 nombres suele ser un tipo de interrelacin o tambin establece la asociacin entre una entidad y sus atributos. Ej: la institucin del autor, podemos pensar en la interrelacin entre AUTOR e INSTITUCION o bien, el atributo institucin de AUTOR.

En el enfoque de categorizacin de objetos (Navathe, 1983): una entidad es un objeto de datos que tiene ms propiedades que su nombre o se utiliza como operando en una sentencia de seleccin, borrado o insercin. Ej: en la biblioteca existen libros que poseen una serie de propiedades, como son el ttulo, idioma, nro. de copias, etc. LIBRO es una entidad, ya que tiene varias propiedades. Ej: cuando un socio

deja serlo, es preciso eliminarlo de la base de datos, SOCIO es una entidad, por ser un operando en una sentencia de borrado. un atributo es un objeto de datos al que se asigna un valor o se utiliza como operando en una operacin aritmtica, boolean, etc. Ej: se puede consultar si el ttulo de un libro es Bases de datos, luego, ttulo es un atributo. una interrelacin es un objeto de datos que hace posible la seleccin de una entidad por medio de una referencia a un atributo de otra entidad. Ej: seleccionar los libros que ha escrito un determinado autor, por lo que escribir es una interrelacin, ya que nos permite seleccionar una entidad (LIBRO) por medio de una referencia a un atributo de otra entidad (Nombre de AUTOR).

Casos especiales: 1.-"ES_UN" nos permite crear jerarquas de entidades, corresponde al concepto de generalizacin de Smith y Smith (1977). Ej: tanto un libro como un artculo son documentos. Ver figura: Los atributos de DOCUMENTO son heredados por ARTICULO y LIBRO. Tambin pueden haber atributos que son exclusivos de las entidades subtipos, por ejemplo, editorial podra ser un atributo de LIBRO pero no de ARTICULO. 2.-TIENE, este verbo, posee muchas interpretaciones. ocurrencia de, ej: un libro tiene varios ejemplares, en el sentido que un ejemplar es una ocurrencia de libro. Cual sera el identificador de la entidad, que es ocurrencia, (EJEMPLAR)???. Se forma con el identificador de la entidad principal (LIBRO) junto a un atributo discriminante de la ocurrencia. Ej: libros con 5 dgitos y 2 dgitos para los ejemplares. interrelacin entre entidades Ej: los libros pueden tener mas de un autor, acta como interrelacin entre AUTOR y LIBRO. -asociacin de las entidades con sus atributos (agregacin) Ej: los libros tienen un ttulo, un ao de publicacin y un idioma, estamos asociando a la entidad LIBRO una serie de atributos. Algunas maas: - si decimos los socios piden prestados libros, estaramos generando un diagrama con entidades LIBRO, SOCIO, EJEMPLAR, e interrelaciones presta (LIBRO, SOCIO) y tiene (LIBRO,EJEMPLAR), lo que es incorrecto. Debera ser, las mismas entidades, e interrelaciones tiene (LIBRO, EJEMPLAR) y presta (EJEMPLAR,SOCIO). - en las jerarquas de supertipo y subtipos, los atributos deben definirse a un nivel adecuado, es decir, si tanto libros como artculos tienen titulo e idioma, estos atributos deben estar en DOCUMENTO.

4.2.1.-Caractersticas del esquema conceptual

La fase de modelacin conceptual cumple los siguientes objetivos: Captar y almacenar el universo del discurso mediante una descripcin rigurosa, representando la informacin que describe a la organizacin y que es necesaria para su funcionamiento. Aislar la representacin de la informacin de los requisitos de la mquina y exigencias de cada usuario en particular. Independizar la definicin de la informacin de los SGBD en concreto.

Los esquemas conceptuales se caracterizan por: Claridad, la significacin es no ambigua. Coherencia, sin contradicciones o confusiones Plenitud, representa lo esencial sin ser exhaustivo. Fidelidad, la representacin del universo del discurso ha de hacerse sin desviaciones ni deformaciones. Simplicidad, mxima sencillez (nro reducido de componentes, conceptos separados, redundancia controlada). Notar que desde un mismo universo del discurso se pueden obtener distintos esquemas conceptuales. El problema de la equivalencia entre DEI es importante. Algunos criterios de equivalencia son: Compatibilidad de dominios de datos, los DEI representan el mismo UD Equivalencia de dependencias de datos, representan las mismas restricciones. Equivalencia de ocurrencias de datos

Existen ciertas restricciones de tipo semnticas que no son posibles de describir a travs de tpicamente el MER extendido. Muchas de estas se escriben en lenguaje natural dentro del mismo DEI.

4.2.2.-Metodologa Ascendentes y Descendentes

Las metodologas descendentes o top-down cuya filosofa es que el esquema conceptual refleje directamente la visin de la empresa que se intenta modelar en la BD. Se parte del estudio del UD para elaborar el esquema conceptual y sobre el se definen posteriormente vistas de usuario como subconjuntos de este esquema conceptual. Las metodologas ascendentes o bottom-up, entiende el esquema conceptual como el resultado de la integracin de las vistas de los distintos usuarios, por lo que empieza construyendo las distintas vistas de usuario y teniendo en cuenta las restricciones entre stas, elabora un esquema conceptual mediante un proceso de integracin de vistas.

Proceso de integracin de vistas Las vistas se dividen en idnticas y no idnticas. Las idnticas contienen los mismos tipos de objetos, puede que con distintos nombres. Las no idnticas, poseen diferentes tipos de objetos (todo o en parte). Dentro de estas ultimas hay que distinguir las que son equivalentes de las que no lo son. La integracin de vistas consiste en partir de dos vistas y obtener una tercera que las englobe, as sucesivamente hasta llegar al esquema global. Al querer integrar vistas surgen algunos problemas: 1.- Conflictos de nombres:

o o

homonimia, a dos objetos se les ha asignado el mismo nombre sinonimia, un mismo objeto con mas de un nombre Ejemplos: conflicto de nombre e entidades, un sistema trata con AUTOR y con cod_autor como atributo identificador y otro, con ESCRITOR e identificador cod_escritor. Solucin: usar una sola con su respectivo identificador. Conflicto de nombre en interrelaciones, una REVISTA publica ARTICULO o bien, en una REVISTA aparece un ARTICULO. Solucin: Cambiar el nombre, adoptar uno solo.

2.- Conflictos entre entidades: o una entidad es un subconjunto de otra. Solucin: introducir un subtipo. Ej: entidades REVISTA y PUBLICACION, esta ultima incluye ademas revistas, recopilaciones y otros tipos, se puede resolver introduciendo la revista como un subtipo de publicacin. Se llama restriccin de seleccin. o una entidad es disjunta con respecto a otra, pero ambas poseen atributos comunes, es decir, son un subtipo de una tercera entidad. Solucin: crear el supertipo. Se llama restriccin de disyuncin. 3.- Conflicto entre tipos de objetos en los que un atributo en una vista es una entidad es otra o viceversa: La solucin es transformar el atributo en entidad o la entidad en atributo segn convenga. Ej: entidad EDITORIAL o atributo de LIBRO?. Si vemos que es importante almacenar informacin de la editorial la consideraremos una entidad, sino ser atributo. 4.- Conflicto de cardinalidades en interrelaciones: Ej: interrelacin escribe entre AUTOR y DOCUMENTO, en un caso 1,n y en otro n,n.

o o o o

se trata de la misma interrelacin, en este caso se deja la menos restrictiva n,n. se trata de dos interrelaciones distintas como escribe de tipo n,n y edita de tipo 1,n (suponiendo que un documento puede ser editado por una persona). En este caso se deben reflejar ambas interrelaciones con distintos nombres. la entidad AUTOR tiene una interrelacin con DOCUMENTO que es escribe, mientras que un subtipo de ella (que es EDITOR) tiene otra interrelacin con DOCUMENTO, que es edita. existen dos subtipos de la entidad AUTOR, que poseen interrelaciones distintas con DOCUMENTO, por ejemplo, el subtipo ESCRITOR y el subtipo EDITOR con las interrelaciones escribe y edita, respectivamente.

5.- Analisis de redundancia de interrelaciones: Una vez integradas las vistas, habr que analizar si se producen redundancias de interrelaciones, lo que grficamente se refleja en ciclos. Vistas en curso anterior.

4.3.-Etapa 2: Diseo Lgico

En esta etapa transformaremos el esquema conceptual obtenido en la fase anterior a un esquema relacional. Este esquema sigue siendo independiente del SGBD que se utilizar en la siguiente etapa. El paso del esquema E/R al relacional se basa en los siguientes principios: Todo tipo de entidad se convierte en una relacin Todo tipo de interrelacin N:M se transforma en una relacin Todo tipo de interrelacin 1:N se traduce en el fenmeno de propagacin de la clave o bien se crea una nueva relacin.

4.3.1.-Reglas de Transformacin
1.-Transformacin de Dominios

CREATE DOMAIN Estados_Civiles AS CHAR(1) CHECK(VALUE in ( S, C, V, D)

2.-Transformacin de entidades

CREATE TABLE... Cada entidad se transforma en una relacin. 3.-Transformacin de atributos de entidades Los AIP , pasan a ser la clave primaria de la relacin PRIMARY KEY. Los AIA, pasan a ser UNIQUE. Ambas son clusulas en el comando CREATE TABLE.

4.-Transformacin de Interrelaciones 4.1.-Interrelaciones N:M Se transforma en una relacin que tendr como clave primaria la concatenacin de los AIP de las entidades que asocia. Cada uno de estos atributos que forman parte de la clave primaria son clave fornea respecto a las tablas en donde son claves primarias. Esto se representa por al clusula FOREING KEY dentro del comando CREATE TABLE de la relacin. 4.2.-Interrelaciones 1:N Propagar el AIP de la entidad que tiene cardinalidad mxima 1 a la que tiene n. Transformarlo en una relacin, como si se tratara de una interrelacin N:M. Esto es ms conveniente cuando: o El nmero de ocurrencias de la entidad que propaga su clave es muy pequeo, evitando los valores nulos. o Cuando se prev que en el futuro dicha interrelacin se convierta en una N:M o Cuando la interrelacin tiene atributos propios Un aspecto importante en estas interrelaciones se relaciona con las cardinalidades mnimas. Si la cardinalidad mnima de la entidad que se propaga es 1, significa que no pueden admitirse valores nulos en la clave fornea (clave propagada). En cambio, si es 0, si se admiten valores nulos. 4.3.-Interrelaciones 1:1 Son casos en donde se puede crear una relacin o bien propagar la clave. Esto ltimo puede ser en ambas direcciones.

Si las entidades que se asocian tienen ambas cardinalidades (0,1):

En el MR: MATRIMONIO(cod_hombre , cod_mujer) HOMBRE(cod_hombre,....) MUJER(cod_mujer,....) As, se evitan los valores nulos que apareceran en caso de propagar la clave de la entidad MUJER a la entidad HOMBRE o viceversa. Recordar que no todos los hombres ni todas las mujeres estn casados.

Una de las entidades tiene cardinalidad (0,1) y la otra (1,1), conviene propagar la clave
de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1).

En MR: EMPLEADO(cod_empleado,...) DEPTO(cod_depto,cod_empleado) clave fornea, NOT NULL

clave en cualquier direccin. Sera conveniente tener en cuenta acceso ms frecuentes y prioritarios de los datos. 5.-Transformacin de atributos de interrelaciones Es conveniente que aquellas interrelaciones que posean atributos propios se transformen en una relacin en donde aquellos atributos pasan a ser columnas de dicha relacin. 6.-Transformacin de restricciones Las restricciones son por ejemplo rango de valores para un determinado dominio. Muchas de las restricciones no se representan en el esquema conceptual por lo que no existen reglas claras para transformarlas. Usualmente las restricciones se consideran en la fase siguiente y se implementan a travs de funcionalidades particulares que ofrecen los SGBD comerciales. Tpicamente esto es a travs de triggers. 7.-Transformacin de dependencias en identificacin y en existencia

En el caso de que ambas entidades tengan cardinalidades (1,1), se puede propagar la

En MR: LIBRO(cod_libro,...)

EJEMPLAR(cod_libro, cod_ejemplar,...) clave fornea, NOT NULL, ON DELETE CASCADE, ON UPDATE CASCADE. Para dependencia en identificacin, la clave primaria de la entidad dbil debe estar formada por la concatenacin de las claves de las dos entidades participantes en la interrelacin.

8.-Transformacin de tipos y subtipos Una sola relacin, correspondiente al supertipo. Es conveniente cuando existan muy pocos atributos diferentes entre los subtipos y las interrelaciones que los asocian con el resto de las entidades del diagrama son las mismas para todos los subtipos. Una relacin para entidad: el supertipo y los subtipos correspondientes. Es conveniente cuando existen muchos atributos diferentes entre los subtipos y adems se quieren mantener los atributos comunes de todos ellos en una relacin (supertipo). Relaciones para los subtipos, que contengan adems los atributos comunes. Es conveniente cuando existen muchos atributos distintos entre los subtipos y los accesos realizados sobre los datos de los distintos subtipos siempre afectan a atributos comunes.

a) DOCUMENTO(cdigo, ttulo, idioma,...,tipo) b) DOCUMENTO(cdigo, ttulo, idioma,...) ARTICULO(cdigo,....) LIBRO(cdigo,...) c) LIBRO(cdigo,ttulo, idioma,...) ARTICULO(cdigo,ttulo, idioma, ....)

4.3.-Etapa 3: Diseo Fsico

Esta etapa depende del SGBD comercial que se utilizar para implementar la base de datos Algunos elementos de diseo fsico son: INDICES Son lgicamente y fsicamente independientes de los datos. Se crean o eliminan sin que produzca efectos en la base de datos. Se mantienen en forma automtica por los SGBD. Se utiliza el comando CREATE UNIQUE INDEX. Se estructuran en rboles B*-tree. SECUENCIAS Son generadores de nmeros secuenciales utilizados como valor nico para un determinado atributo de una relacin. Sin secuencias, el proceso normal de generacin de estos enteros conlleva un bloqueo manual en acceso para actualizacin de la tabla que los contiene. Con este mecanismo, las estructuras se bloquean justo en el momento de la actualizacin. Se utiliza el comando CREATE SEQUENCE... CLUSTER o AGRUPACIONES Es una estructura formada por una o varias tablas. Las filas de stas que comparten el mismo valor de clave se almacenan fsicamente juntas. VISTAS Son visiones lgicas de tablas, que permiten entregar a los usuarios slo la informacin que a stos les interesa. Facilitan el control de la seguridad de la base de datos SINONIMOS Proporcionan un nombre alternativo para referenciar tablas, vistas o secuencias. LINKS Son enlaces definidos desde la base de datos local a una base de datos remota.

5.-TEORIA DE LA NORMALIZACION
Cuando se disea una base de datos mediante el modelo relacional, al igual que ocurre en otros modelos de datos, tenemos distintas alternativas, es decir, podemos obtener diferentes esquemas relacionales y no todos son equivalentes, ya que algunos van a representar la realidad mejor que otros.

Es necesario conocer qu propiedades debe tener un esquema relacional para representar adecuadamente una realidad y cules son los problemas que se pueden derivar de un diseo inadecuado. La teora de la Normalizacin es un mtodo objetivo y riguroso que se aplica en el diseo de bases de datos relacionales. Cuando estudiamos la estructura del modelo relacional, nos dimos cuenta que la base de datos puede representarse por medio de un conjunto de objetos (dominios y relaciones) y de un conjunto de reglas de integridad. El esquema relacional puede obtenerse de dos formas distintas: Directamente a partir de la observacin de nuestro universo del discurso, en donde especificamos conjuntos de atributos, relaciones y restricciones que corresponden a los observados en el mundo real. Realizando el proceso de diseo en dos fases, primero el diseo conceptual (E/R) obteniendo el esquema conceptual y posteriormente transformar ste a un esquema relacional, siguiendo algunas reglas generales, que fueron dadas anteriormente.

Algunos problemas que se pueden presentar son: Incapacidad para almacenar ciertos hechos Redundancias y por tanto, posibilidad de incoherencias Ambigedades Prdida de informacin (aparicin de tuplas espreas) Prdida de dependencias funcionales, es decir, ciertas restricciones de integridad que dan lugar a interdependencias entre los datos. Aparicin en la BD de estados no vlidos, es decir, anomalas de insercin, borrado y modificacin. En conclusin el esquema relacional obtenido debe ser analizado para comprobar que no presenta los problemas anteriores. Analicemos la siguiente relacin: ESCRIBE AUTOR Date, C. Date, C. Date, C. Codd,E. Gardarin Gardarin Valduriez Kim,W. NACIONALIDAD Norteamericana Norteamericana Norteamericana Norteamericana Francesa Francesa Francesa Norteamericana COD_LIBRO 98987 97777 98987 7890 12345 67890 67890 11223 TITULO Database SQL Stan Guide for Relational Basi Dati Comp BD Comp BD BD OO EDITORIAL Addison Addison, W. Addison, W. Addison,W. Paraninfo Eyrolles Eyrolles ACM

199

198

198

199

198

198

198

198

Lochovsky

Canadiense

11223

BD OO

ACM

198

Esta relacin almacena datos de autores y de libros. Algunos problemas son: Redundancia, ya que la nacionalidad del autor se repite por cada ocurrencia del mismo. Lo mismo sucede cuando un libro tiene mas de un autor, se repite la editorial y el ao de publicacin. Anomalas de modificacin, es fcil cambiar el nombre de una editorial en una tupla sin modificar el resto de las que corresponden al mismo libro, lo que da lugar a incoherencias. Anomalas de insercin, ya que si queremos ingresar informacin de algn autor, del que no hubiera ningn libro en la base datos, no sera posible, ya que cod_libro es parte de la clave primaria de la relacin (regla de integridad de la entidad). La insercin de un libro, que tiene dos autores obliga a insertar dos tuplas en la relacin. Anomalas de borrado, ya que si queremos eliminar un cierto libro, deberamos perder los datos de su autor y viceversa.

En los casos anteriores, se deja en manos del usuario manejar la integridad de la base de datos. Lo anterior sucede pues no se cumple un hecho bsico de todo diseo:

"hechos distintos, deben almacenarse en objetos distintos"

Una forma de evitar este tipo de problemas consiste en seguir la metodologa propuesta en el curso, es decir, un riguroso diseo conceptual y un traspaso de ste al modelo relacional. Sin embargo, ante posibles dudas respecto a si un esquema relacional est correcto, aplicaremos a dicho esquema un mtodo formal de anlisis, que permita analizar errores y generar esquemas correctos. Esta es la teora de la normalizacin. En el ejemplo anterior, el conjunto de las siguientes relaciones no presenta estos problemas: LIBRO( cod_libro, titulo, editorial, ao ) AUTOR( nombre, nacionalidad ) ESCRIBE( cod_libro, nombre ) La normalizacin introduce una tcnica formal para disear bases de datos relacionales, y permite mecanizar parte del proceso al disponer de algoritmos de normalizacin. Una observacin importante, es que las anomalas antes descritas se producen en procesos de actualizacin y no en procesos de consulta. La normalizacin penaliza las consultas, al disminuir la eficiencia, ya que la normalizacin aumenta el nro. de relaciones presentes en la base de datos, por lo que una determinada consulta puede llevar consigo el acceso a varias tablas, lo que aumenta el costo de sta.

5.1.-Nocin intuitiva de las formas normales

La normalizacin tiene como objetivo obtener esquemas relacionales que cumplan determinadas condiciones, a travs de las formas normales. Primera Forma Normal (1FN) fue introducida por Codd, en su primer trabajo. Es una restriccin inherente al modelo relacional por lo que su cumplimiento es obligatorio. Consiste en la prohibicin de que en una relacin existan grupos repetitivos, es decir, un atributo no puede tomar ms de un valor del dominio subyacente. Segunda Forma Normal (2FN), fue introducida por Codd. Una relacin est en 2FN, si adems de estar en 1FN, todos los atributos que no forman parte de ninguna clave candidata suministran informacin acerca de la clave completa. Para la relacin PRESTAMO( num_socio, nombre_socio, cod_libro, fec_prest, editorial, pas ) las claves candidatas son: (num_socio, cod_libro) y (nombre_socio, cod_libro) Se puede observar que ciertos atributos que no forman parte de las claves candidatas, tal como editorial, constituye informacin acerca del libro, pero no acerca de la clave completa. Luego, la relacin prstamo no se encuentra en 2FN. La solucin es descomponer esta relacin en las siguientes: PRESTAMO1( num_socio, nombre_socio, cod_libro, fec_prest ) LIBRO( cod_libro, editorial, pas ) En la relacin PRESTAMO1, el nico atributo que no forma parte de las claves candidatas es fec_prest, pero suministra informacin acerca de la clave completa. Por lo que est en 2FN. La relacin LIBRO, la clave es cod_libro, y los dos atributos: editorial y pas suministran informacin de la clave completa. Por lo tanto, est en 2FN. OBS: Una relacin que est formada por un nico atributo esta en 2 FN. Tercera Forma Normal (3FN), propuesta por Codd. Una relacin est en 3FN, si adems de estar en 2FN, los atributos que no forman parte de ninguna clave candidata facilitan informacin slo acerca de la(s) clave(s) y no acerca de otros atributos. En la relacin PRESTAMO1, el atributo fec_prest facilita informacin acerca de las claves, ya que no existen ms atributos. Por lo que est en 3FN. En la relacin LIBRO, el atributo pas entrega informacin acerca de la editorial que publica el libro, por lo que no est en 3FN. La solucin es descomponerla en: LIBRO1( cod_libro, editorial )

EDITORIAL( editorial, pas ), que estn en 3FN, ya que todo atributo no clave facilita informacin acerca de la clave. Forma Normal de Boycce y Codd (FNBC). La relacin PRESTAMO1, que est en 3FN, todava presenta anomalas, ya que num_socio y nombre_socio, se repiten innecesariamente por cada cod_libro. Una relacin est en FNBC si y solo si, el conocimiento de las claves candidatas permite averiguar todas las interrelaciones existentes entre los datos de la relacin, o lo que es igual, las claves candidatas son los nicos descriptores sobre los que se facilita informacin por cualquier otro atributo. En la relacin PRESTAMO1, num_socio es informacin acerca de nombre_socio y viceversa. Ninguno de estos atributos son clave (aunque formen parte de la clave). Para solucionarlo la descomponemos: SOCIO( num_socio, nombre_socio ) PRESTAMO2( num_socio, cod_libro, fec_prest ), que estn en FNBC. Hasta ahora nuestro esquema relacional est compuesto por las siguientes relaciones en FNBC: LIBRO1( cod_libro, editorial ) EDITORIAL( editorial, pas ) SOCIO( num_socio, nombre_socio ) PRESTAMO2( num_socio, cod_libro, fec_prest ) La teora de la normalizacin se basa en restricciones definidas sobre los atributos de una relacin. que son conocidas como dependencias. Existen varios tipos de dependencias: Funcionales, relacionadas con la 2FN y 3FN y FNBC Multivaluadas, relacionadas con la 4FN De proyeccin o combinacin, relacionadas con la 5FN.

5.2.-Dependencias funcionales
Sea el esquema de relacin R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X o que X determina o implica a Y, que se representa por X Y, si solo si, cada valor de X tiene asociado en todo momento un nico valor de Y. ej: cod_libro titulo, el cdigo del libro determina el titulo. El cod_libro es el implicante y titulo es el implicado. Siempre el implicado es un hecho (una informacin) acerca del implicante. OBS1: la afirmacin cod_libro determina titulo NO significa que a partir de cod_libro podamos conocer el titulo. Es decir, para un esquema R, si tenemos la dependencia funcional X Y, dado un valor de X no podemos en general conocer el valor de Y. Solo nos limitaremos a firmar que para

dos tuplas de cualquier extensin de R que tengan el mismo valor de X, el valor de Y tambin ser igual en ambas. OBS2: Las dependencias son predicados o restricciones sobre cualquier extensin vlida del esquema de relacin, por lo que observar una determinada extensin (datos) no puede llevarnos a afirmar la existencia de una dependencia funcional.

5.2.1.-Dependencia funcional completa

Si el descriptor X es compuesto, es decir, X(X1, X2), se dice que Y tiene dependencia funcional completa de X, si depende funcionalmente de X, pero no depende de ningn subconjunto del mismo, esto es: XY X1 | Y X2 | Y. Se representa X Y. X Y si y solo si NO X X / X Y. Ejemplos: La relacin PUBLICA( articulo, revista, numero, pagina ), que representa la pagina inicial en la que comienza un articulo en una revista. Un mismo articulo puede aparecer publicado en distintas revistas y en cada una de ellas, en paginas distintas y una revista publica varios artculos, se tiene: articulo, revista, numero pagina articulo | pagina revista | pagina numero | pagina

5.2.2.-Dependencia funcional trivial

Una dependencia funcional X Y es trivial si Y es un subconjunto de X (Y X). Ejemplos: cod_libro cod_libro articulo, revista revista.

5.2.3.-Dependencia funcional elemental

Solo las dependencias elementales son tiles en la normalizacin.

Una dependencia funcional X Y es elemental si Y es un atributo nico, no incluido en X y no existe X incluido en X tal que X Y, es decir, la dependencia funcional elemental es un dependencia funcional completa no trivial, en la que el implicado es un atributo nico.

5.2.4.- Dependencia funcional transitiva

Sea la relacin R( X,Y,Z ), en la que existen las siguientes dependencias funcionales: X Y, Y Z y Y | X, se dice que Z tiene dependencia transitiva respecto a X, a travs de Y. ej: LIBRO_ED( codlibro, editorial, pas ) La dependencia entre codlibro y pas es transitiva, a travs de editorial. Intuitivamente se interpreta como que PAIS es una informacin del libro, pero indirectamente, ya que es una informacin de EDITORIAL y esta a su vez de LIBRO.

5.3.-Teora formal de la Normalizacin

Dado un conjunto de atributos A y un conjunto de dependencias entre ellos, D, que constituyen un esquema de relacin R(A,D) (esquema origen), se trata de transformar este esquema original en un conjunto de n esquemas de relacin Ri(Ai,Di), i=1,n (esquemas resultantes), que cumplan determinadas caractersticas. Estas son: Conservacin de la informacin Conservacin de las dependencias Normalizacin de las relaciones

5.3.1.-Conservacin de la informacin
Se debe cumplir: Conservacin de los atributos

U Ai = A, i=1, n.
Conservacin del contenido (las tuplas)

Para toda extensin r de R, la combinacin (join) de las relaciones resultantes ha de producir la relacin origen, es decir, * ri = r, i=1,n.
Si el proceso de normalizacin no se lleva a cabo correctamente , pueden aparecen nuevas tuplas que no estaban en la relacin origen. Estas se llaman tuplas espreas, que falsean el contenido de la base de datos.

Ejemplo: Dada la relacin original

LIBRO(COD_LIBRO, EDITORIAL, PAIS) COD_LIBRO 9030 9110 9040 9234 9567 y las relaciones resultantes: EDITORIAL RAMA RAMA PARANINFO ANAYA ADD.WES PAIS ESPAA ESPAA ESPAA ESPAA USA

LIBRO1(COD_LIBRO, PAIS) COD_LIBRO 9030 9040 9110 9234 9567 PAIS ESPAA ESPAA ESPAA ESPAA USA

EDITORIAL(EDITORIAL, PAIS) EDITORIAL RAMA RAMA PARANINFO ANAYA ADD.WES PAIS ESPAA ESPAA ESPAA ESPAA USA

LIBRO1 * EDITORIAL COD_LIBRO 9030 9030 9030 9040 9040 9040 9010 9110 9010 9234 9234 9234 9567 EDITORIAL RAMA PARANINFO ANAYA RAMA PARANINFO ANAYA RAMA PARANINFO ANAYA RAMA PARANINFO ANAYA ADD.WES PAIS ESPAA ESPAA ESPAA ESPAA ESPAA ESPAA ESPAA ESPAA ESPAA ESPAA ESPAA ESPAA USA

En negrita, tuplas espreas.

5.3.3.-Definicin formal de la tres primeras formas normales

Primera Forma Normal: equivalente a la definicin dada antes Segunda Forma Normal: Est en 1FN Cada atributo no principal tiene dependencia funcional completa respecto de cada una de las claves.

ejemplo: La relacin PUBLICA2( articulo, revista, numero, pagina, editorial ) que refleja en qu numero de qu revista se publica un artculo, en qu pagina comienza y cul es la editorial. Tenemos las siguientes dependencias:

articulo, revista, numero pagina revista editorial clave:(articulo, revista, numero) Esta relacin no esta en 2FN, ya que editorial depende de la revista y tiene redundancia, pues se repite la editorial para cada articulo que se publica en una revista. Tercera Forma Normal: Est en 2FN Ningn atributo no principal depende transitivamente de ninguna clave de la relacin

Ejercicio: R( estudiante, nro_matricula,curso,centro, profesor, texto ), con las restricciones: Un estudiante puede estar matriculado en varios cursos Un estudiante tiene un numero de matrcula distinto para cada curso en el que est matriculado Un curso se imparte en un solo centro El nmero de matrcula identifica al centro en el que se imparte el curso y al curso mismo Un curso es impartido por un solo profesor, pero un profesor puede impartir varios cursos Un curso se apoya en distintos textos y un mismo texto puede servir de soporte a varios cursos.

Reducir el esquema anterior a un conjunto equivalente de relaciones en FNBC Las dependencias funcionales se relacionan con el modelado relacional de interrelaciones 1:N y 1:1.

5.4.- Dependencias Multivaluadas y 4FN

Las dependencias multivaluadas son una generalizacin de las dependencias funcionales. En stas un conjunto de valores del implicado, son determinados por un implicante. Esta situacin aparece cuando existen grupos repetitivos. Ej: la siguiente tabla

AUTORES AUTOR Date Ullman MATERIA Lenguaje SQL; Diseo BD Diseo BD; Bases Conc. INSTITUCION Relational Inst.; Codd& Date Cons. Stanford Univ.

La tabla no cumple la 1FN. La normalizacin de esta tabla produce la siguiente:

AUTORES AUTOR Date Date Date Date Ullman Ullman MATERIA Lenguaje SQL Lenguaje SQL Diseo BD Diseo BD Diseo BD Bases Conc. INSTITUCION Relational Inst Codd& Date Cons Codd& Date Cons Relatinal Inst. Stanford Univ. Stanford Univ

Esta tabla normalizada presenta gran cantidad de redundancia. La clave es el conjunto de los 2 atributos. Por lo que est en FNBC. En ella tenemos que un autor multidetermina a materia y un autor multidetermina a institucin. Las dependencias multivaluadas se producen cuando existen interrelaciones N:M independientes entre si. Entre autor y materia hay una interrelacin N:M y tambin entre autor e institucin y materia e institucin son independientes. Definicin Dependencia Multivaluada. Fagin (1977). La dependencia multivaluada se denota X Y, y se lee X multidetermina a Y, y significa que X implica un conjunto de valores de Y con independencia de los dems atributos de la relacin. Las dependencias multivaluadas dependen del contexto, es decir influye el resto de los atributos de la relacin. Si agregamos un atributo a AUTORES, departamento, que nos indica el departamento de una institucin en el que se trabaja en una cierta materia, obteniendo:

AUTOR Date

MATERIA Lenguaje SQL

INSTITUCION Relational Inst.

DEPTO Lenguajes

Date Date Date Ullman Ullman

Lenguaje SQL Diseo BD Diseo BD Diseo BD Bases Conc

Codd& Date Cons. Codd& Date Cons. Relatinal Inst. Stanford Univ. Stanford Univ.

Bases de D Analisis

Bases de D Lenguajes

Inteligencia

Aqu, la dependencia autor materia no se cumple, porque depende del contexto ( de depto). Cuarta Forma Normal (4 FN) Una relacin se encuentra en 4FN, si y solo si, las nicas dependencias multivaluadas no triviales son aquellas en las cuales una clave multidetermina un atributo, es decir, toda dependencia multivaluada viene determinada por una clave candidata. En la tabla AUTORES(autor, materia, institucin), existen las dependencias multivaluadas: autor materia y autor institucin. La relacin no se encuentra en 4FN, ya que estas dependencias estn implicadas por autor, que no es clave candidata. La clave candidata es el conjunto de los tres atributos. Para normalizarla se descompone en 2 proyecciones: AUTORES1(autor, materia) AUTORES2(autor,institucion), que si estn en 4FN. Revisar la 5FN en libros.

5.6.-Organizacin de Relaciones
- estructuracin (consideraciones lgicas) Normalizacin Particionamiento horizontal

- reestructuracin (consideraciones fsicas) Desnormalizacin Particionamiento (horizontal, vertical) Particionamiento Horizontal de relaciones

Esta estructuracin permite eliminar valores nulos, debido en general a no haberse detectado los subtipos de una entidad o haberlas reunido en una sola entidad. DOCUMENTO(cod-doc, titulo, idioma, editorial) Que almacena datos de libros y artculos. El atributo editorial es inaplicable a articulo, podramos descomponer la relacin en: LIBRO(cod-doc, titulo, idioma, editorial) ARTICULO(cod-doc, titulo, idioma) Relacin origen pasa por seleccin a una que tiene todos los atributos que la original, pero contiene valores conocidos junto con otra a travs de seleccin que contiene solo los atributos no nulos, eliminando el atributo de la relacin origen que tenia nulos (proyeccin). La construccin de la relacin original se realiza por medio de la unin relacional, despus de aadir los atributos para que sean compatibles en la unin. Desnormalizacion y Particionamiento Son mtodos o formas de organizar las relaciones, teniendo en cuenta razones de tipo fsico: Tasa de actualizaciones versus consultas Las veces que se accede conjuntamente a los atributos El tamao en bytes de los atributos Tipos de proceso (en linea-batch) Prioridad de los procesos Tamao de las tablas.

6.-PROTECCIN A LOS DATOS

La proteccin de los datos es un aspecto muy vinculado con el concepto mismo de base de datos. La proteccin de los datos debe realizarse contra fallos fsicos, fallos lgicos y fallos humanos. Estas situaciones alteran los datos, con lo que la base de datos ya no puede servir a los fines para los que fue creado. En este contexto aparecen los temas de: recuperacin, concurrencia, seguridad e integridad de la base de datos. Los problemas de recuperacin y concurrencia estn muy relacionados con lo que se conoce como procesamiento de transacciones El SGBD proporciona mecanismos para prevenir fallos (subsistemas de control), para detectarlos una vez que se han producido (subsistema de deteccin) y para corregirlos

6.1.-RECUPERACION
El objetivo del concepto de recuperacin es el de proteger la BD contra fallas lgicas y fsicas que destruyan los datos en todo o en parte. Independiente de la naturaleza de las fallas ests pueden afectar a dos aspectos del almacenamiento de la Base de Datos, como son: Fallas que provocan la prdida de memoria voltil Fallas que provocan la prdida del contenido de memoria secundaria.

Para asegurar que la BD siempre este en un estado consistente, se crean unidades de ejecucin llamadas transacciones, que pueden definirse como una secuencia de operaciones que han de ejecutarse en forma atmica, es decir, se realizan todas las operaciones que comprende la transaccin o no se realiza ninguna. Ej: una transaccin bancaria que saca dinero de una cuenta y lo dispone en otra. Las transacciones o terminan con xito y son grabadas en la base o bien fracasan y debe ser restaurado el estado anterior de la BD. El componente del sistema encargado de lograr la atomicidad se conoce como administrador de transacciones y las operaciones COMMIT (comprometer) y ROLLBACK (retroceder) son la clave de su funcionamiento. La operacin COMMIT seala el trmino exitoso de la transaccin: le dice al administrador de transacciones que se ha finalizado con xito una unidad lgica de trabajo, que la base de datos est o debera estar de nuevo en un estado consistente y que se pueden comprometer, o hacer permanentes todas las modificaciones efectuadas por ese unidad de trabajo. La operacin ROLLBACK, en cambio, seala el trmino no exitoso de la transaccin: le dice al administrador de transacciones que algo sali mal, que la base de datos podra estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lgica de trabajo deben retroceder o anularse. Las caractersticas de una transaccin son: Atomicidad, en el sentido que hemos especificado anteriormente: se ejecutan todas las sentencias o ninguna. Preservacin de la consistencia: la ejecucin de una transaccin deja la BD en un estado consistente. Aislamiento, ya que una transaccin no muestra los cambios que produce hasta que finaliza. Persistencia, ya que una vez que finaliza la transaccin con xito, sus efectos perduran en la BD. Seriabilidad, en el sentido de que el efecto de ejecutar transacciones concurrentemente debe ser el mismo que se producira al ejecutarlas por separado en un orden secuencial segn van entrando en el sistema.

Para conseguir anular y recuperar transacciones, el mtodo mas usado consiste en utilizar un archivo de diario o log en el que va guardando toda la informacin necesaria para deshacer (en caso de fracasar) o rehacer ( en caso de recuperar) las transacciones. Este archivo consta de: identificador de la transaccin

hora de modificacin identificador del registro afectado tipo de accin valor anterior del registro nuevo valor del registro informacin adicional.

Otra alternativa es manejar 2 archivos de log, uno con la imagen anterior a las modificaciones y otro con la imagen posterior a las modificaciones. El archivo log es usualmente una pila que una vez llena va eliminado registros segn van entrando nuevos. Un concepto relacionado con los archivos de log es el CHECKPOINT, que permite manejar en forma eficiente el contenido de los archivos log, ya que permiten no tener que recorrer todo el archivo de log, ante fallas. El establecimiento de puntos de revisin implica: grabar fsicamente el contenido de los buffers de datos a la base de datos fsica grabar fsicamente un registro de punto de revisin especial dentro del archivo de log o bitcora

Los puntos marcados como checkpoint, permiten la recuperacin de la base de datos en caliente, es decir, despus de la cada del sistema se obtiene la direccin del registro de recuperacin ms reciente y se recorre el archivo de log desde el punto marcado como checkpoint.

La transaccin t1 no se ve afectada por la falla del sistema, ni por el proceso de recuperacin, por haberse completado antes del ltimo punto de recuperacin. Las transacciones t2 y t4, a pesar de haber terminado no han sido grabadas en la base de datos, ya que stas seran cometidas en un checkpoint. Las transacciones t3 y t5 debern rehacerse ya que no han concluido. El procedimiento que deber realizar el sistema al reiniciarse consiste en:

1. Comenzar con dos listas de transacciones, la lista ANULAR y la lista REPETIR. Igualar la lista ANULAR a la lista de todas las transacciones incluidas en el registro de punto de revisin. Dejar vaca la lista REPETIR. 2. Examinar la bitcora hacia adelante a partir del registro de punto de revisin. 3. Si se encuentra una entrada de bitcora de "iniciar transaccin" para la transaccin T, aadir T a la lista ANULAR. 4. Si se encuentra una entrada una entrada de bitcora "comprometer" para la transaccin T, pasar esa transaccin de la lista ANULAR a la lista REPETIR. 5. Cuando se llegue al final de la bitcora, las listas ANULAR y REPETIR identificarn, respectivamente, las transacciones de los tipos T3 y T5 y las de los tipos T2 y T4. Posteriormente el sistema revisar la bitcora hacia atrs, anulando todas las transacciones de la lista ANULAR. A continuacin la revisar hacia adelante, realizando de nuevo todas las transacciones en la lista REPETIR. Por ultimo, una vez terminada todas las actividades de recuperacin, el sistema estar listo para aceptar nuevos trabajos. La recuperacin en fro, consiste en disponer de un backup o respaldo de la BD, que permitir junto con los archivos de log, que se han ido produciendo desde el ultimo backup, reconstruir la BD, para dejarla consistente. El error fatal, se produce cuando se pierde el archivo de log. En este caso resulta imposible recuperar la base. La solucin pasa por disponer los archivos de log en respaldos. El DBA debe definir responsabilidades, procedimientos, situaciones y plazos en los que se deben realizar las copias de seguridad y el respaldo del archivo de log, especificando a los operadores los procedimientos de recuperacin ante cadas. El principio bsico en el que se basa la recuperacin es la redundancia.

6.1.1.-Compromiso en dos fases

Este concepto es particularmente importante cuando se tienen mltiples SGBD en el contexto de los sistemas de bases de datos distribuidas. Supongamos una transaccin que actualiza una base de datos Oracle y una base de datos ADABAS. Si la transaccin se completa con xito, todas las modificaciones, tanto de los datos Oracle como de los datos Adabas, debern comprometerse. Si fracasa todas debern anularse. Aqu el COMMIT (o ROLLBACK) afecta a todo el sistema. Estas instrucciones son manejadas por un componente llamado coordinador, y puede realizarse correctamente porque utiliza el protocolo de compromiso en dos fases. 1. El coordinador ordena a los administradores de recursos (Oracle , Adabas) que se preparen para las dos posibilidades con respecto a la transaccin. Esto significa que cada administrador guarda fsicamente (almacena) las entradas de la bitcora que corresponden a los recursos locales empleados por la transaccin. Si la grabacin tiene xito, el manejador de recursos contestar "todo bien" al coordinador. En caso contrario, contestar "no est bien". 2. Cuando el coordinador reciba la respuesta de todos los administradores de recursos, grabar una entrada en su propia bitcora fsica. Si todas las respuestas fueron "todo bien", la decisin ser comprometer. Si cualquiera de las respuestas fue "no est bien", la decisin ser retroceder. En cualquier caso, el coordinador le informar de su decisin a todos los administradores de recursos y cada administrador de recursos deber comprometer o anular la transaccin localmente.

Cada administrador deber hacer lo que el coordinador le ordena en la fase 2. As es el protocolo.

6.2.- Concurrencia
En sistemas multiusuario, es necesario un mecanismo para controlar la concurrencia. Se pueden producir inconsistencias importantes derivadas del acceso concurrente, como por ejemplo, el problema de la operacin perdida. En un sistema de biblioteca, existe un campo que almacena el nro de copias disponibles para prstamo. Este campo debe incrementarse en uno cada vez que se devuelve un ejemplar del libro y disminuirse en uno cada vez que se presta un ejemplar. Si existen varias bibliotecarias, una de ellas inicia la transaccin t1, leyendo la variable nro ejemplares (n), cuyo contenido se guarda en la variable n1. Tiempo despus, otra bibliotecaria podra leer la misma variable incrementndola en una unidad , transaccin t2. Despus, la transaccin t1 aade una unidad a esa variable y la actualiza, el resultado es errneo, ya que la variable N debera haber aumentado en 2 unidades, y solo ha aumentado en una. La transaccin t2 se ha perdido.

6.2.1.- Tcnicas de control de concurrencia

Pesimistas: bloqueo y marcas de tiempo Optimistas

Tcnicas de bloqueo: es una variable asociada a cada elemento de datos que describe el estado de dicho elemento respecto a las posibles operaciones (recuperacin o actualizacin) que se pueden realizar sobre ellos en cada momento. Las transacciones pueden llevar a cabo bloqueos, impidiendo a otros usuarios la recuperacin o actualizacin de los elementos bloqueados, para evitar inconsistencias en el acceso concurrente. Los SGBD tienen bloqueos(por tupla, por tabla) para asegurar la consistencia. Los usuarios tambin pueden bloquear explcitamente los objetos, impidiendo el acceso por parte de otros usuarios. Tipos de bloqueo Exclusivos: cuando una transaccin mantiene un bloqueo de este tipo, ninguna otra transaccin puede acceder a el objeto bloqueado, ni bloquearlo, hasta que sea liberado por la transaccin que lo haba retenido. Se utiliza cuando se quiere actualizar datos. Bloqueo compartido: cuando una transaccin bloquea en este modo, permite que otras transacciones retengan tambin el objeto en bloque compartido, pero no exclusivo. Este tipo se utiliza cuando no se requiere actualizar datos, pero se desea impedir cualquier modificacin mientras los datos son consultados.

El algoritmo que se utiliza se llama bloqueo de dos fases (two phase locking). El problema de las tcnicas de bloqueo es que puede producirse un interbloqueo (deadlock), dos o mas transacciones estn esperando cada una de ellas que la otra libere algn objeto antes de seguir

Se puede solucionar: Prevenir el deadlock: obliga a que las transacciones bloqueen todos los elementos que necesitan por adelantado. EN caso de no poder conseguir todos esos elementos no bloquea ninguno y se queda en espera hasta volver a intentarlo. Detectar el deadlock: Se controla de forma peridica si se ha producido un deadlock. Se construye un grafo en espera, cada nodo es una transaccin en ejecucin y un arco de una transaccin Ti a Tj, en caso que Ti est esperando un elemento que ocupa Tj. Si existe un ciclo en el grafo tenemos un deadlock. La solucin es escoger transacciones vctimas y deshacerlas, hasta que desaparezca el deadlock. Cada SGBD tiene polticas diferentes para escoger vctimas. Este tema influye notoriamente en el rendimiento de los sistemas. Los SGBD pueden bloquear: un campo de un registro (un atributo de una tabla) un registro (una tupla) un archivo (una tabla) la BD total

Esto se llama granularidad del bloqueo. Granularidad muy gruesa implica gestionar menor nro de bloqueos, pero retrasa la ejecucin de muchas transacciones (los objetos no se van liberando). Una granularidad muy fina, permite mayor concurrencia, pero aparecen mas situaciones de deadlock que han de ser resueltas. Tcnicas de marca de tiempo (timestamping) Las marcas de tiempo son identificadores nicos que se asignan a las transacciones, que se consideran como el tiempo de inicio de una transaccin. Con esta tcnica no existen bloqueos. Ordena las transacciones. Se retrasan. Tcnicas optimistas Las transacciones acceden libremente a los elementos, y antes de finalizar se determina si ha habido interferencias. Este tipo de tcnicas considera que las transacciones tienen 3 fases: Lectura: las transacciones realizan operaciones sobre copias privadas de los objetos (accesibles solo por la transaccin) Validacin : en la que se comprueba si el conjunto de objetos modificados por una transaccin se solapa con el conjunto de objetos modificados por alguna otra que haya hecho la validacin durante la fase de lectura de dicha transaccin Grabacin:, en el caso de no detectar interferencias se graban las modificaciones, convirtiendo las versiones privadas de los objetos en versiones actuales.

6.3.- Integridad

La integridad tiene como funcin proteger la BD contra operaciones que introduzcan inconsistencias en los datos. Se habla de integridad en el sentido de correccin, validez o precisin de los datos. El subsistema de integridad de un SGBD debe por tanto detectar y corregir, en la medida de lo posible, las operaciones incorrectas. En la prctica es el punto dbil de los SGBD comerciales, ya que casi toda la verificacin de integridad se realiza mediante cdigo de procedimientos escritos por los usuarios. Habr operaciones cuya falta de correccin no sea detectable, por ejemplo, introducir un fecha de nacimiento 25/12/1945 cuando en realidad era 25/12/1954.

6.3.1.-Operaciones semnticamente inconsistentes

Son las que transgreden las restricciones que ha definido el administrador al disear la base de datos, tales como: Restricciones sobre dominios por ejemplo, el dominio edad est comprendido entre 18 y 65 aos. Restricciones sobre los atributos, por ejemplo, la edad de los empleados ingenieros debe ser mayor de 21 aos.

Estas restricciones pueden ser estticas, como las anteriores o dinmicas por ejemplo, el sueldo de un empleado no puede disminuir. Otra forma de clasificar las restricciones es en: simples: si se aplican a una ocurrencia de un atributo con independencia de los dems, por ejemplo, el sueldo de un empleado tiene que ser mayor que 60000. compuestas: si implican ms de una ocurrencia, como es el caso de las restricciones de comparacin, por ejemplo, el sueldo de un empleado debe ser menor que el de su jefe. O bien , las llamadas de globalidad, por ejemplo, el sueldo medio de los empleados de un determinado depto debe ser menor de 250000.

Los SGBD tienen que ofrecer en su lenguaje de definicin, facilidades que permitan describir las restricciones con una sintaxis adecuada. Por ejemplo, CREATE DOMAIN, CREATE ASSERTION, CREATE INTEGRITY RULE En general, una regla de integridad est compuesta por tres componentes: La restriccin propiamente tal, que establece la condicin que deben cumplir los datos La respuesta a la transgresin, que especifica las acciones a tomar, como rechazar las operaciones, informar al usuario, corregir el error con acciones complementarias, etc. Condicin de disparo, que especifica cundo debe desencadenarse la accin especificada en la restriccin de integridad: antes, despus o durante cierto evento.

Los triggers, son casos especiales de reglas de integridad. Un trigger es un procedimiento que se activa o dispara al ocurrir un evento, que tienen muchas utilidades.

Las reglas de integridad deben almacenarse en el diccionario de datos, como parte integrantes de los datos(control centralizado de la semntica), de modo que no han de incluirse en los programas. Esto trae algunas ventajas: Las reglas de integridad son ms sencillas de entender y de cambiar, facilitando su mantenimiento. Se detectan mejor las inconsistencias Se protege mejor la integridad, ya que ningn usuario podr escribir un programa que las transgreda, llevando a la BD a estados inconsistentes.

El subsistema de integridad del SGBD debe realizar las siguientes funciones: Comprobar la coherencia de las reglas que se definen Controlar las distintas transacciones y detectar las transgresiones de integridad Cuando se produce una transgresin, ejecutar las acciones pertinentes.

6.4.-Seguridad
El objetivo es proteger la BD contra accesos no autorizados. Se llama tambin privacidad. Incluye aspectos de: Aspectos legales, sociales y ticos Polticas de la empresa, niveles de informacin publica y privada Controles de tipo fsico, acceso a las instalaciones Identificacin de usuarios: voz, retina del ojo, etc. Controles de sistema operativo

En relacin al SGBD, debe mantener informacin de los usuarios, su tipo y los accesos y operaciones permitidas a stos. Tipos de usuarios: DBA, estn permitidas todas las operaciones, conceder privilegios y establecer usuarios Usuario con derecho a crear, borrar y modificar objetos y que adems puede conceder privilegios a -otros usuarios sobre los objetos que ha creado. Usuario con derecho a consultar, o actualizar, y sin derecho a crear o borrar objetos.

Privilegios sobre los objetos, aadir nuevos campos, indexar, alterar la estructura de los objetos, etc. Los SGBD tienen opciones que permiten manejar la seguridad, tal como GRANT, REVOKE, etc. Tambin tienen un archivo de auditora en donde se registran las operaciones que realizan los usuarios. Otro mecanismo de seguridad que ofrecen los SGBD en entregar informacin a los usuarios a travs de vistas (CREATE VIEW)

7.- Procesamiento y optimizacion de consultas

Los SGBD procesan , optimizan y ejecutan las consultas de alto nivel, utilizando tcnicas y algoritmos. Cuando se tiene una consulta en SQL, sta debe ser analizada lxica y sintcticamente, luego validada. EL analizador lxico identifica los componentes del lenguaje en el texto de la consulta, el analizador sintctico revisa la sintaxis de la consulta para determinar si est formulada de acuerdo a las reglas sintcticas del lenguaje de consulta. La validacin consiste en comprobar que todos los nombres de los atributos y de relaciones sean vlidos. A continuacin se crea una representacin interna de la consulta, por lo regular en forma de estructura de datos de rbol o grafo. Esto se denomina rbol o grafo de consulta. En seguida, el SGBD debe crear una estrategia de ejecucin para obtener el resultado de la consulta a partir de los archivos internos de la base de datos. Por lo general, una consulta tiene muchas posibles estrategias de ejecucin, y el proceso de elegir la ms adecuada se conoce como optimizacin de consultas. El mdulo optimizador de consultas se encarga de producir un plan de ejecucin y el generador de cdigo genera el cdigo necesario para ejecutarlo. El procesador de base de datos en tiempo de ejecucin se encarga de ejecutar el cdigo de la consulta , sea compilado o interpretado, para producir el resultado de la consulta. El optimizador en realidad no escoge siempre el plan ms optimo, ya que encontrar la estrategia optima pude consumir mucho tiempo. Solo escoge una estrategia razonablemente eficiente. Las consultas relacionales deben ser optimizadas. Las tcnicas para optimizar consultas son dos: Basada en reglas heursticas, que permiten ordenar las operaciones de la consulta en un rbol o grafo. Basada en costos, que estiman el costo sistemticamente, y eligen la de ms bajo costo.

Empleo de la heurstica en la optimizacin de consultas La principal regla heurstica es aplicar las operaciones de restriccin y proyeccin antes de aplicar la reunin u otras operaciones binarias. Esto es porque el tamao del archivo resultante de una operacin binaria es una funcin de los tamaos de los archivos de entrada (en algunos casos funcin multiplicativa). Optimizacin heuristica de rboles de consulta Un rbol de consulta es una estructura de rbol que corresponde a una expresin del lgebra relacional por el hecho de que representa las relaciones de entrada como nodos hoja del rbol y las operaciones del lgebra relacional como nodos internos. Ej: obtener para cada proyecto ubicado en santiago, su numero, el numero del departamento que lo controla, el apellido, la direccin y la fecha de nacimiento del gerente de ese departamento.

 numerop,numd,apellido,direccion,fechan ((( lugarp=santiago(PROJECTO))join

numd=numerod(DEPARTAMENTO))join nssgte=nss(EMPLEADO))

SELECT numerop,numd,apellido,direccion,fechan FROM proyecto,departamento,empleado WHERE numd=numerod AND nssgte=nss AND lugarp="santiago"

Las 3 relaciones PROJECT,DEPARTAMENTO, EMPLEADO se representan con nodos hoja, y las operaciones del algebra relacional con nodos internos. Cunado se ejecuta el rbol de consulta, se jecuta primero el nodo (1), ya que el resultado de (1) debe estar disponible para ejecutar (2). En general, existen muchos rboles de consulta que representan una sola consulta. De modo que el analizador sintctico de consultas, casi siempre genera un rbol de consulta cannico estndar que corresponde a una consulta en SQL, sin efectuar optimizacin. El rbol cannico para el ejemplo es:

El rbol cannico se construye aplicando primero el producto cartesiano de las relaciones especificadas en la clusula FROM., luego las condiciones de seleccin y reunin de la clusula WHERE, seguidas de la proyeccin sobre los atributos de la clusula SELECT. Este rbol es muy ineficiente, debido al producto cartesiano(X). Por ejemplo, si las relaciones PROJECT, DEPARTAMENTO, EMPLEADO tienen 100, 50 y 150 bytes, y contuvieran 100,20 y 5000 tuplas, respectivamente, el resultado del producto cartesiano contendra 10 millones de tuplas con un tamao de registro de 300 bytes. As, el optimizador transformara este rbol de consulta inicial aun rbol de consulta final cuya ejecucin sea eficiente. Al hacer esta conversion, se deben ocupar reglas de transformacin que vayan conservando las equivalencias. Reglas de transformacin para operaciones del lgebra relacional. 1.cascada de restricciones ( ): una condicin de seleccin conjuntiva puede descomponerse en una secuencia de operaciones individuales. c1ANDc2AND...ANDcn(R) c1( c2 (...( cn(R))...)) 2.conmutatividad de : c1( c2(R)) c2( c1(R)) 3.cascada de : En una secuencia de operaciones , podemos ignorar todas menos la ultima.

 lista1 ( lista2(...( listan (R)) ...)) lista1(R) 4:conmutacion de con : si en la condicin de seleccin C intervienen slo los atributos A1,,...An de la lista de proyeccin, se pueden conmuta ambas operaciones. A1,A2,...,An( c(R)) c( A1,A2,...,An(R)) 5.conmutatividad de join (o de X): R join S S join R 6.conmutacion de con join (o X): si todos los atributos de la condicin de seleccin C pertenecen a slo una de las relaciones por reunir, digamos R, las dos operaciones pueden conmutarse. c(R join S) ( c(R)) join S 7.conmutacion de con join (o X): 8.conmutatividad de operaciones de conjuntos 9.asociatividad de join, X, e 10. conmutacion de con operaciones de conjuntos 1. la operacin se conmuta con

Resumen: la principal heurstica de la optimizacin algebraica consiste en aplicar primero las operaciones que reducen el tamao de los resultados intermedios. En esto entra la ejecucin de las operaciones seleccionar tan pronto como sea posible para reducir el numero de tuplas y la ejecucin de las operaciones proyectar tan pronto como sea posible para reducir el numero de atributos. Esto se logra desplazando las operaciones seleccionar y proyectar lo ms abajo que se pueda en el rbol. Adems se deben ejecutar las operaciones seleccionar y reunin ms restrictivas (las que producen relaciones con el menor numero de tuplas o el tamao absoluto ms pequeo) antes que otras operaciones similares.

Bases de Datos Semestre 2000-2 Claudia Jimnez Quintana

Captulo 8: Vistas en el Modelo Relacional 6.1 Definicin de Vistas

Los usuarios que acceden a una base de datos relacional, lo hacen tpicamente a travs de vistas, de modo que diferentes usuarios tienen diferentes vistas.

Una vista es una tabla virtual derivada, con nombre (Date, 1995). El trmino virtual significa que la tabla no existe en s, pero para el usuario parece existir. Por el contrario una tabla base es real, en el sentido que existe almacenada en algn dispositivo fsico de almacenamiento. Las vistas no se sustentan en datos almacenados. Solo se almacena su definicin en el catlogo, en base a otras tablas.

Ejemplo: CREATE VIEW BUENOS_PROV AS SELECT ID_PROV, NOMBRE, CIUDAD FROM PROV WHERE CIUDAD = "CONCEPCION";

As, cuando se ejecuta esta proposicin, se almacena en el catlogo.

Las vistas son dinmicas, de forma que las modificaciones realizadas a PROV, sern visibles instantneamente a travs de la vista BUENOS_PROV y viceversa.

Cualquier tabla derivable, que puede obtenerse mediante una proposicin SELECT, puede definirse como una vista.

6.2 Operaciones DML sobre Vistas

Las operaciones sobre vistas deben convertirse en operaciones equivalentes sobre las tablas base subyacentes.

La forma en que se logra esta correspondencia es mediante el lgebra relacional. Dado que la definicin de vista es una expresin algebraica, con nombre. Este proceso, de sustitucin, funciona debido a la propiedad de cierre del lgebra.

Recuperacin de datos (SELECT): No existe, en teora, problema al consultar datos a travs de una vista. Sin embargo, SQL, tiene el operador GROUP BY (agrupar), siendo el resultado de agrupar una tabla, un conjunto de tablas (no se cumple el principio de cierre). Lo mismo sucede con las funciones de agregados de SQL. Esto significa que si se crea una vista utilizando el operador GROUP BY, ciertas consultas a las vistas fallarn.

Actualizacin de vistas(INSERT, DELETE, UPDATE): No todas las vistas se pueden actualizar. Lo anterior, va a depender del tipo de vista. As, tenemos los siguientes tipos:

Vistas de subconjunto de columnas Vistas de subconjunto de filas Vistas de reunin Vistas de resumen estadstico

Vistas de subconjuntos de columnas Si la vista ha sido creada incluyendo la clave primaria de la relacin subyacente, es actualizable. Por el contrario, si no la incluye, no es actualizable.

Ejemplo:

Tabla PROV ID_PROV S1 S2 S3 S4 S5 NOMBRE LAPIZ LOPEZ TORRE REHIN PELIKAN XEROX SITUACION 20 10 30 20 30 CIUDAD CONCEPCION SANTIAGO SANTIAGO CONCEPCION TEMUCO

VISTA A: CREATE VIEW ID_CIUDAD AS SELECT ID_PROV, CIUDAD FROM PROV;

VISTA B: CREATE VIEW SITUACION_CIUDAD AS SELECT SITUACION, CIUDAD FROM PROV;

ACTUALIZACION EN VISTA A: 1. Se puede insertar un nuevo proveedor en la vista, tal como (S6, OSORNO), insertando el registro (S6, NULL,NULL,OSORNO) en la tabla subyacente PROV.

2. Se puede eliminar un registro existente de la vista, tal como (S1, CONCEPCION), eliminando el registro (S1, LAPIZ LOPEZ, 20, CONCEPCION) de la tabla subyacente PROV. 3. Se puede modificar un registro de la vista, tal como, cambiar la ciudad de un proveedor, modificndose el registro correspondiente de la tabla subyacente PROV.

ACTUALIZACION EN VISTA B: 1. Insertar un nuevo registro en la vista, tal como (40, VALPARAISO), el sistema intentar insertar el registro (NULL, NULL, 40, VALPARAISO) en PROV. Esto no ser posible ya que la clave primaria no puede ser NULL. 2. AL eliminar un registro de la vista, no se sabr cul es el registro que corresponde a la tabla PROV, ya que no se ha especificado el identificador de proveedor (ID_PROV). Este no forma parte de la vista. 3. Sucede lo mismo que en 2, al tratar de modificar un registro de la vista.

Vistas de subconjunto de filas

En estos casos sucede lo mismo que las vistas de subconjunto de columnas, de tal manera que si incluyen la clave primaria, ser posible actualizarlas.

Ejemplo: CREATE VIEW PROV_CONCEPCION AS SELECT ID_PROV, NOMBRE, SITUACION, CIUDAD FROM PROV WHERE CIUDAD= "CONCEPCION";

Esta vista si es actualizable.

Vistas de reunin

S= (S1#, S2, S3, S4) P= (P1#, P2, P3, P4)

S join P (S1#, S2, S3, S4 0 P4, P1#, P2, P3)

CREATE VIEW VISTA (S#, Snombre, Situacion, SCIUDAD, P#, PNombre

Vistas de resumen estadstico

CREATE VIEW PC (P#, CANTTOTAL) AS SELECT P#, SUM(CANT) FROM SP GROUP BY P#;

Esta vista no permite modificaciones ni inserciones en el atributo CANTTOTAL.

Figura 6.1: Clasificacion de vistas

6.3 Ventajas de las vistas

Ofrecen independencia lgica de datos, en casos de reestructuracin de la base de datos. La independencia lgica ha de entenderse como la independencia de los usurios con respecto a la estructura lgica de la base de datos. Permiten a diferentes usuarios ver los mismos datos de distintas maneras y al mismo tiempo Se simplifica la percepcin del usurio, ya que stos solo se concentran en aquellos datos que les son interesantes. Son un mecanismo de seguridad, debido a que habrn datos ocultos (los no visibles a travs de la vista). Dichos datos estan a salvo de accesos.

Bases de Datos Semestre 2000-2 Claudia Jimnez Quintana

Captulo 8: EL NIVEL INTERNO

El nivel interno en un sistema de bases de datos es el que se ocupa de cmo estn almacenados los datos en el disco. Dado que las operaciones de E/S son consumidoras de tiempo, la idea es reducir al mnimo el nmero de accesos a disco. Lo anterior se logra, usando tcnicas para organizar los datos almacenados en el disco. La organizacin de los datos en el disco, se llama estructura de almacenamiento. Existen varias estructuras de almacenamiento, con diferentes niveles de desempeo, unas ms adecuadas que otras, dependiendo del tipo de aplicaciones. Por lo anterior, un SGBD, debe manejar varias de estas estructuras, con el objeto de almacenar diferentes porciones de la base de datos en diferentes formas. Ser deseable que tambin pueda cambiar la estructura de almacenamiento de una porcin determinada cuando varen los requerimientos de desempeo.

El proceso de elegir una estructura de almacenamiento para una base de datos se conoce como diseo fsico.

7.1 Acceso a Bases de Datos

El proceso general de acceso a una base de datos se describe a continuacin.

1.-El DBMS (SGBD) decide cul registro necesita y solicita al manejador de archivos que extraiga dicho registro. 2.-El manejador de archivos decide cul pgina contiene el registro buscado y le solicita al manejador de disco que lea esa pgina. (Recordar que una pgina es la unidad de E/S, es decir, es la cantidad de datos transferidos entre el disco y la memoria principal en un solo acceso al disco). 3.-El manejador de disco determina la localizacin fsica de la pgina en el disco y realiza la operacin de E/S necesaria.

Dicho proceso se muestra en la figura 7.1.

Figura 7.1: Acceso a Bases de datos

7.1.1 Manejador de disco

Es un componente del sistema operativo subyacente. Se encarga de todas las operaciones fsicas de E/S. Cuando el manejador de archivos necesita la lectura de una pgina p, el manejador de disco necesita saber dnde est situada esa pgina en el disco fsico. Por lo tanto, maneja la correspondencia entre pginas p y direcciones fsicas en el disco. El conjunto de pginas del disco se divide en un subconjunto de paginas ocupadas, con interseccin vaca y un conjunto de pginas libres(disponibles). Cada uno de estos conjuntos tiene un identificador, as como tambin cada pgina del disco. Las operaciones que realiza el manejador de disco son las siguientes:

Leer la pgina p del conjunto de pginas c Reemplazar la pgina p dentro del conjunto c. Agregar una nueva pgina p dentro a c (obtener una pgina vaca del conjunto de pginas de espacio libre y devolver el nmero de pgina p). Eliminar de c (volver a p al conjunto de pginas de espacio libre).

La funcin principal del manejador de disco es conocida como administracin de pginas.

7.1.2 Manejador de archivos

Cada conjunto de pginas contendr uno o ms archivos y cada archivo almacenado tiene un identificador, al igual que los registros. Un archivo es conjunto de registros. Las operaciones que realiza el manejador de archivos son las siguientes:

Leer el registro almacenado r del archivo almacenado a Reemplazar r por otro en a Agregar un registro r (devuelve el identificador de registro) Eliminar r de a Crear a Eliminar a

7.1.3 Concepto de Agrupamiento

Consiste en almacenar juntos fsicamente los registros que tienen una relacin lgica entre s. Por ejemplo, si se quiere leer dos registros r1 y r2, almacenados en las pginas p1 y p2 respectivamente, se tiene que: 1.- Si p1 y p2 son la misma pgina, el acceso a r2 no requerir E/S fsica alguna. 2.- Si p1 y p2 son distintas, pero cercanas fisicamente, r2 requerir una operacin de E/S fsica, pero el tiempo ser pequeo, ya que las cabezas de lectura/escritura estarn cerca.

Agrupamiento intraarchivo: Dentro de un archivo. Por ejemplo, la lectura secuencial de todos los proveedores. Cada registro est cerca de otro.

Agrupamiento interarchivos: Varios archivos. Registros alternados, por ejemplo los archivos proveedor y archivos de productos.

Un SGBD debe permitir especificar diferentes clases de agrupamiento para un archivo determinado.

7.1.4 Proceso de carga de la base de datos

1.-Base de datos vaca 2.-Insertar proveedores P1, P2, P3, P4 y P5. Se crea el conjunto de pginas de Proveedores 3.-Insertar Productos pr1, pr2, pr3, pr4, pr5, pr6. Se crea el conjunto de pginas de Productos. 4.-Insertar un nuevo proveedor P6. 5.-Eliminra el Proveedor P2 6.-Insertar un nuevo producto pr7. 7.-Eliminar el Proveedor P4.

0 1 P1 6 pr1 2 P2 3 P3 4 P4 5 P5

7 pr2

8 pr3

9 pr4

10 pr5

11 pr6

12 13 18 19 24 25 26 27 28 29 20 21 22 23 14 15 16 17

Despus de insertar P1, P2, P3, P4, P5, pr1, pr2, pr3, pr4, pr5, pr6.

0 1 P1 6 pr1 2 pr7 3 P3 4 5 P5

7 pr2

8 pr3

9 pr4

10 pr5

11 pr6

12 P6

13

14

15

16

17

18 19 24 25 26 27 28 29 20 21 22 23

Despus de insertar P6, eliminar P2, insertar pr7 y eliminar P4.

Si la carga inicial de la base de datos considera un buen agrupamiento, qu pasa despus de sucesivas inserciones y eliminaciones?

Para garantizar que pginas lgicamente adyacentes lo sean fsicamente se utilizan punteros. As, cada pagina tendr un encabezado, que se utiliza como informacin de control. Este encabezado incluye la direccin fsica en el disco de la pgina que sigue a esa pgina dentro de la secuencia lgica, como se muestra en la figura 7.2.

0X 1 P1 3 6 pr1 7 2 pr7 X 3 P3 5 4 12 5 P5 12

7 pr2 8

8 pr3 9

9 pr4 10

10 pr5 11

11 pr6 2

12 P6 X

13

14

15

16

17

18 19 24 25 26 27 28 29 20 21 22 23

Figura 7.2

La pregunta es entonces, Cmo sabe el manejador de disco dnde estn situados los diversos conjuntos de pginas?, Cmo localiza la primera pgina?

En un lugar fijo del disco (la pista cero del cilindro cero) se almacena una pgina que proporciona dicha informacin(tabla de contenido del disco). Ver figura 7.3.

Figura 7.3: Pgina cero o directorio del disco.

As, la funcin principal del manejador de archivos es la administracin de registros almacenados. Los registros almacenados se sitan en la parte superior de la pgina, como se muestra en la figura 7.4.

Figura 7.4: Carga de registros

El identificador de registro o RID se compone de dos partes: el nmero de pgina p dnde est r y un desplazamiento en bytes con respecto a la base de p, el cual identifica una ranura que a su vez contiene el desplazamiento en bytes de r con respecto al tope de p, como se muestra en la figura 7.5.

Figura 7.5.

7.2 Estructuras de Almacenamiento

Existen tcnicas para mejorar la secuencia fsica. La secuencia fsica es la ruta de acceso aceptable en muchas situaciones, en otras se requiere algo mejor.

Las tcnicas usadas en el ambiente de bases de datos son: indexacin, dispersin, cadenas de punteros y tcnicas de compresin. Estas no son mutuamente excluyentes, de tal forma que es posible para un archivo dado, tener acceso a l por dispersin como indexado por el mismo campo almacenado.

7.2.1 Indexacin
Ejemplo: Consultar la tabla proveedores, "encontrar todos los proveedores de una ciudad x". Esta consulta se ejecuta con frecuencia, por lo que debe tener un buen desempeo. Alternativas:

Examinar el archivo de proveedores completo, buscando todos los registros en los cuales el valor del campo de ciudad sea Londres= x. Buscar en el archivo de ciudades todas las entradas de Londres y para cada una de ellas seguir el puntero al registro correspondiente en el archivo de proveedores, como se muestra en la figura 7.6

Figura 7.6 Si la proporcin de proveedores de Londres es pequea con respecto a los dems, la segunda estrategia es ms eficiente que la primera:

El SGBD est consciente del orden fsico del archivo ciudades (puede interrumpir su bsqueda en ese archivo tan pronto como encuentre una ciudad posterior a Londres en orden alfabtico) Aun cuando tuviera que examinar todo el archivo de ciudades, esta bsqueda requerira menos operaciones de E/S en total, ya que el tamao fsico del archivo de ciudades es inferior al de proveedores (los registros son ms pequeos).

Se dice que el archivo de ciudades es un ndice del archivo de proveedores. El archivo de proveedores est indexado por ciudad.

Un ndice es un archivo almacenado, en donde cada registro se compone de: Dato y un puntero o RID. El dato es un valor de algn campo del archivo indexado y el puntero identifica un registro de ese archivo que tiene ese valor en ese campo. El campo en cuestin del archivo indexado se llama campo indexado. Si el dato corresponde a la clave primaria, el ndice se llama ndice primario, y si es cualquier otro campo se llama ndice secundario.

7.2.1.1 Utilizacin de indices

La ventaja principal de los ndices es que agilizan la obtencin de datos, reduciendo el nmero de operaciones de E/S. La desventaja es que la actualizacin de los archivos se hace ms lenta.

Los ndices se usan de dos maneras:

Acceso secuencial al archivo indexado, es decir en el orden definido por los valores del campo indexado. Acceso directo: a registros individuales con base a un valor dado del campo indexado.

Adicionalmente, los ndices son tiles en consultas de pruebas de existencia, en donde solo se lee el ndice y no se lee el archivo indexado, por ejemplo: hay proveedores en Atenas?.

7.2.1.2 Arboles B
Es una clase de ndice, usada comnmente en base de datos, pues ofrecen un buen desempeo. La mayora de los sistemas relacionales ofrecen esta estructura de almacenamiento, incluso a veces es la nica.

La idea es que se crea un ndice para un ndice. Inicialmente, al crear un ndice ya no se requiere una revisin secuencial del archivo indexado. Sin embargo, sigue siendo necesaria una revisin fsica secuencial del ndice. Si el archivo indexado es de gran tamao, el ndice puede llegar a ser tambin muy grande, y por tanto su revisin secuencial en s puede llegar a requerira bastante tiempo. La solucin es entonces tratar al ndice como un archivo almacenado normal y crear un ndice para l. Esta idea puede llevarse a varios niveles, pero lo usual es tres.

Un rbol B est compuesto de dos partes:

Un conjunto secuencia, que consta de un

ndice de un solo nivel de los datos reales. Un conjunto ndice, que es un ndice con estructura de rbol del conjunto secuencia.

La combinacin del conjunto ndice y el conjunto secuencia se llama rbol B +. Un ejemplo de rbol B se muestra en la figura 7.7

Figura 7.7

Un problema de los rboles en general es que las inserciones y eliminaciones pueden desequilibrar el rbol, es decir, los nodos hojas no estn todos en el mismo nivel. La gran ventaja de los arboles B es que las inserciones y eliminaciones garantizan equilibrio del rbol. De hecho la B es de balanceado.

7.2.2 Dispersin

Es una tcnica para obtener acceso directo rpido a un registro almacenado. La tcnica funciona as:

Cada registro almacenado se coloca en la base de datos en un sitio cuya direccin RID se calcula como una funcin (funcin de dispersin) de algn campo de ese registro (campo de dispersin). La direccin calculada se llama direccin de dispersin.

Para almacenar inicialmente el registro, el SGBD calcula la direccin de dispersin del nuevo registro y ordena al manejador de archivos que lo grabe en esa posicin.

Para localizar despus el registro a partir del valor del campo de dispersin, el SGBD realiza el mismo calculo y ordena al manejador de archivos que lea el registro en la posicin calculada.

Tpicamente se utilizan las funciones divisin/residuo, de modo que la direccin de dispersin es igual al resto de dividir la clave entre 13, por ejemplo. Bases de Datos Semestre 2000-2 Claudia Jimnez Quintana

Captulo 8: EL NIVEL INTERNO

El nivel interno en un sistema de bases de datos es el que se ocupa de cmo estn almacenados los datos en el disco. Dado que las operaciones de E/S son consumidoras de tiempo, la idea es reducir al mnimo el nmero de accesos a disco. Lo anterior se logra, usando tcnicas para organizar los datos almacenados en el disco. La organizacin de los datos en el disco, se llama estructura de almacenamiento. Existen varias estructuras de almacenamiento, con diferentes niveles de desempeo, unas ms adecuadas que otras, dependiendo del tipo de aplicaciones. Por lo anterior, un SGBD, debe manejar varias de estas estructuras, con el objeto de almacenar diferentes porciones de la base de datos en diferentes formas. Ser deseable que tambin pueda cambiar la estructura

de almacenamiento de una porcin determinada cuando varen los requerimientos de desempeo. El proceso de elegir una estructura de almacenamiento para una base de datos se conoce como diseo fsico.

7.1 Acceso a Bases de Datos

El proceso general de acceso a una base de datos se describe a continuacin.

1.-El DBMS (SGBD) decide cul registro necesita y solicita al manejador de archivos que extraiga dicho registro. 2.-El manejador de archivos decide cul pgina contiene el registro buscado y le solicita al manejador de disco que lea esa pgina. (Recordar que una pgina es la unidad de E/S, es decir, es la cantidad de datos transferidos entre el disco y la memoria principal en un solo acceso al disco). 3.-El manejador de disco determina la localizacin fsica de la pgina en el disco y realiza la operacin de E/S necesaria.

Dicho proceso se muestra en la figura 7.1.

Figura 7.1: Acceso a Bases de datos

7.1.1 Manejador de disco

Es un componente del sistema operativo subyacente. Se encarga de todas las operaciones fsicas de E/S. Cuando el manejador de archivos necesita la lectura de una pgina p, el manejador de disco necesita saber dnde est situada esa pgina en el disco fsico. Por lo tanto, maneja la correspondencia entre pginas p y direcciones fsicas en el disco. El conjunto de pginas del disco se divide en un subconjunto de paginas ocupadas, con interseccin vaca y un conjunto de pginas libres(disponibles). Cada uno de estos conjuntos tiene un identificador, as como tambin cada pgina del disco. Las operaciones que realiza el manejador de disco son las siguientes:

Leer la pgina p del conjunto de pginas c Reemplazar la pgina p dentro del conjunto c. Agregar una nueva pgina p dentro a c (obtener una pgina vaca del conjunto de pginas de espacio libre y devolver el nmero de pgina p). Eliminar de c (volver a p al conjunto de pginas de espacio libre).

La funcin principal del manejador de disco es conocida como administracin de pginas.

7.1.2 Manejador de archivos

Cada conjunto de pginas contendr uno o ms archivos y cada archivo almacenado tiene un identificador, al igual que los registros. Un archivo es conjunto de registros.

Las operaciones que realiza el manejador de archivos son las siguientes:

Leer el registro almacenado r del archivo almacenado a Reemplazar r por otro en a Agregar un registro r (devuelve el identificador de registro) Eliminar r de a Crear a Eliminar a

7.1.3 Concepto de Agrupamiento

Consiste en almacenar juntos fsicamente los registros que tienen una relacin lgica entre s. Por ejemplo, si se quiere leer dos registros r1 y r2, almacenados en las pginas p1 y p2 respectivamente, se tiene que: 1.- Si p1 y p2 son la misma pgina, el acceso a r2 no requerir E/S fsica alguna. 2.- Si p1 y p2 son distintas, pero cercanas fisicamente, r2 requerir una operacin de E/S fsica, pero el tiempo ser pequeo, ya que las cabezas de lectura/escritura estarn cerca.

Agrupamiento intraarchivo: Dentro de un archivo. Por ejemplo, la lectura secuencial de todos los proveedores. Cada registro est cerca de otro.

Agrupamiento interarchivos: Varios archivos. Registros alternados, por ejemplo los archivos proveedor y archivos de productos.

Un SGBD debe permitir especificar diferentes clases de agrupamiento para un archivo determinado.

7.1.4 Proceso de carga de la base de datos

1.-Base de datos vaca 2.-Insertar proveedores P1, P2, P3, P4 y P5. Se crea el conjunto de pginas de Proveedores 3.-Insertar Productos pr1, pr2, pr3, pr4, pr5, pr6. Se crea el conjunto de pginas de Productos. 4.-Insertar un nuevo proveedor P6. 5.-Eliminra el Proveedor P2 6.-Insertar un nuevo producto pr7. 7.-Eliminar el Proveedor P4.

0 1 P1 6 pr1 2 P2 3 P3 4 P4 5 P5

7 pr2

8 pr3

9 pr4

10 pr5

11 pr6

12 13 18 19 24 25 26 27 28 29 20 21 22 23 14 15 16 17

Despus de insertar P1, P2, P3, P4, P5, pr1, pr2, pr3, pr4, pr5, pr6.

0 1 P1 6 pr1 2 pr7 3 P3 4 5 P5

7 pr2

8 pr3

9 pr4

10 pr5

11 pr6

12 P6

13

14

15

16

17

18 19 24 25 26 27 28 29 20 21 22 23

Despus de insertar P6, eliminar P2, insertar pr7 y eliminar P4.

Si la carga inicial de la base de datos considera un buen agrupamiento, qu pasa despus de sucesivas inserciones y eliminaciones?

Para garantizar que pginas lgicamente adyacentes lo sean fsicamente se utilizan punteros. As, cada pagina tendr un encabezado, que se utiliza como informacin de control. Este encabezado incluye la direccin fsica en el disco de la pgina que sigue a esa pgina dentro de la secuencia lgica, como se muestra en la figura 7.2.

0X 1 P1 3 6 pr1 7 2 pr7 X 3 P3 5 4 12 5 P5 12

7 pr2 8

8 pr3 9

9 pr4 10

10 pr5 11

11 pr6 2

12 P6 X

13

14

15

16

17

18 19 24 25 26 27 28 29 20 21 22 23

Figura 7.2

La pregunta es entonces, Cmo sabe el manejador de disco dnde estn situados los diversos conjuntos de pginas?, Cmo localiza la primera pgina?

En un lugar fijo del disco (la pista cero del cilindro cero) se almacena una pgina que proporciona dicha informacin(tabla de contenido del disco). Ver figura 7.3.

Figura 7.3: Pgina cero o directorio del disco.

As, la funcin principal del manejador de archivos es la administracin de registros almacenados. Los registros almacenados se sitan en la parte superior de la pgina, como se muestra en la figura 7.4.

Figura 7.4: Carga de registros

El identificador de registro o RID se compone de dos partes: el nmero de pgina p dnde est r y un desplazamiento en bytes con respecto a la base de p, el cual identifica una ranura que a su vez contiene el desplazamiento en bytes de r con respecto al tope de p, como se muestra en la figura 7.5.

Figura 7.5.

7.2 Estructuras de Almacenamiento

Existen tcnicas para mejorar la secuencia fsica. La secuencia fsica es la ruta de acceso aceptable en muchas situaciones, en otras se requiere algo mejor.

Las tcnicas usadas en el ambiente de bases de datos son: indexacin, dispersin, cadenas de punteros y tcnicas de compresin. Estas no son mutuamente excluyentes, de tal forma que es posible para un archivo dado, tener acceso a l por dispersin como indexado por el mismo campo almacenado.

7.2.1 Indexacin
Ejemplo: Consultar la tabla proveedores, "encontrar todos los proveedores de una ciudad x". Esta consulta se ejecuta con frecuencia, por lo que debe tener un buen desempeo. Alternativas:

Examinar el archivo de proveedores completo, buscando todos los registros en los cuales el valor del campo de ciudad sea Londres= x. Buscar en el archivo de ciudades todas las entradas de Londres y para cada una de ellas seguir el puntero al registro correspondiente en el archivo de proveedores, como se muestra en la figura 7.6

Figura 7.6 Si la proporcin de proveedores de Londres es pequea con respecto a los dems, la segunda estrategia es ms eficiente que la primera:

El SGBD est consciente del orden fsico del archivo ciudades (puede interrumpir su bsqueda en ese archivo tan pronto como encuentre una ciudad posterior a Londres en orden alfabtico) Aun cuando tuviera que examinar todo el archivo de ciudades, esta bsqueda requerira menos operaciones de E/S en total, ya que el tamao fsico del archivo de ciudades es inferior al de proveedores (los registros son ms pequeos).

Se dice que el archivo de ciudades es un ndice del archivo de proveedores. El archivo de proveedores est indexado por ciudad.

Un ndice es un archivo almacenado, en donde cada registro se compone de: Dato y un puntero o RID. El dato es un valor de algn campo del archivo indexado y el puntero identifica un registro de ese archivo que tiene ese valor en ese campo. El campo en cuestin del archivo indexado se llama campo indexado. Si el dato corresponde a la clave primaria, el ndice se llama ndice primario, y si es cualquier otro campo se llama ndice secundario.

7.2.1.1 Utilizacin de indices

La ventaja principal de los ndices es que agilizan la obtencin de datos, reduciendo el nmero de operaciones de E/S. La desventaja es que la actualizacin de los archivos se hace ms lenta.

Los ndices se usan de dos maneras:

Acceso secuencial al archivo indexado, es decir en el orden definido por los valores del campo indexado. Acceso directo: a registros individuales con base a un valor dado del campo indexado.

Adicionalmente, los ndices son tiles en consultas de pruebas de existencia, en donde solo se lee el ndice y no se lee el archivo indexado, por ejemplo: hay proveedores en Atenas?.

7.2.1.2 Arboles B

Es una clase de ndice, usada comnmente en base de datos, pues ofrecen un buen desempeo. La mayora de los sistemas relacionales ofrecen esta estructura de almacenamiento, incluso a veces es la nica.

La idea es que se crea un ndice para un ndice. Inicialmente, al crear un ndice ya no se requiere una revisin secuencial del archivo indexado. Sin embargo, sigue siendo necesaria una revisin fsica secuencial del ndice. Si el archivo indexado es de gran tamao, el ndice puede llegar a ser tambin muy grande, y por tanto su revisin secuencial en s puede llegar a requerira bastante tiempo. La solucin es entonces tratar al ndice como un archivo almacenado normal y crear un ndice para l. Esta idea puede llevarse a varios niveles, pero lo usual es tres.

Un rbol B est compuesto de dos partes:

Un conjunto secuencia, que consta de un ndice de un solo nivel de los datos reales. Un conjunto ndice, que es un ndice con estructura de rbol del conjunto secuencia.

La combinacin del conjunto ndice y el conjunto secuencia se llama rbol B +. Un ejemplo de rbol B se muestra en la figura 7.7

Figura 7.7

Un problema de los rboles en general es que las inserciones y eliminaciones pueden desequilibrar el rbol, es decir, los nodos hojas no estn todos en el mismo nivel. La gran ventaja de los arboles B es que las inserciones y eliminaciones garantizan equilibrio del rbol. De hecho la B es de balanceado.

7.2.2 Dispersin
Es una tcnica para obtener acceso directo rpido a un registro almacenado. La tcnica funciona as:

Cada registro almacenado se coloca en la base de datos en un sitio cuya direccin RID se calcula como una funcin (funcin de dispersin) de algn campo de ese registro (campo de dispersin). La direccin calculada se llama direccin de dispersin.

Para almacenar inicialmente el registro, el SGBD calcula la direccin de dispersin del nuevo registro y ordena al manejador de archivos que lo grabe en esa posicin.

Para localizar despus el registro a partir del valor del campo de dispersin, el SGBD realiza el mismo calculo y ordena al manejador de archivos que lea el registro en la posicin calculada.

Tpicamente se utilizan las funciones divisin/residuo, de modo que la direccin de dispersin es igual al resto de dividir la clave entre 13, por ejemplo. ANEXOS

Dominios

En el modelo relacional estndar un dominio es un objeto ms, propio de la estructura del modelo que, como tal, debe tener su definicin concreta en el lenguaje de definicin de datos DDL que se elija. (Muchos SGBDR comerciales no proveen esta definicin).

Por ejemplo: CREATE DOMAIN Estado_Civil AS CHAR(1) CHECK (VALUE IN (S, C, V, D))

Entidades
Cada tipo de entidad se convierte en una relacin. Cada relacin que corresponda a un tipo de entidad llevar su mismo nombre. Para su definicin usamos la sentencia SQL CREATE TABLE.

Atributos
Atributos compuestos y polivalentes. El modelo relacional admite slo atributos simples, monovalentes. Cada atributo compuesto se puede transformar segn las siguientes dos alternativas: a. Eliminar el atributo compuesto considerando todos sus componentes como atributos individuales, o b. eliminar los componentes individuales y considerar el atributo compuesto entero como un slo atributo.

Esquemas relacionales: a. Persona (Rut, Nombre, Calle, Nmero, Ciudad) b. Persona (Rut, Direccin)

Los atributos polivalentes requieren la introduccin de relaciones nuevas; cada atributo polivalente distinto requiere una relacin en la cual pueda estar representado como atributo monovalente. La nueva relacin contiene el atributo polivalente ms el identificador de la entidad original; el identificador de la nueva relacin es el conjunto de todos sus atributos.

Esquema relacional: Persona(Rut, Nombre) Direccin(Rut, Calle, Nmero, Ciudad) con Rut clave fornea que referencia a Persona.

Atributos identificadores. El o los atributos identificadores de cada tipo de entidad pasan a ser la clave de la relacin si es que son los identificadores principales. Se usa la clusula PRIMARY KEY. Respecto a los identificadores alternativos, se utiliza la clusula UNIQUE.

Otros atributos. Los atributos no identificadores pasan a ser columnas de la tabla, las cuales tienen permitido tomar valores nulos, a no ser que se indique lo contrario.

Interrelaciones

Dependiendo del tipo de correspondencia de la interrelacin, variar la manera de realizar la transformacin del esquema.

Interrelaciones N:M Un tipo de interrelacin N:M se transforma en una relacin que tendr como clave primaria la concatenacin de los identificadores de los tipos de entidad que asocia. No hay manera de diferenciar en el esquema relacional cuales relaciones provienen de tipos de entidad y cuales provienen de tipos de interrelacin. Utilizando alguna norma en los nombres se puede superar de algn modo esta prdida de semntica. Cada uno de los atributos que forman la clave primaria de una relacin derivada de un tipo de interrelacin N:M son clave fornea respecto de cada una de las relaciones derivadas de los tipos de entidad que relaciona. Esto se especifica a travs de la clasula FOREIGN KEY dentro de la sentencia de creacin de la tabla.

@cod-autor @cod-libro + ttulo

El esquema relacional resultante: Autor (cod-autor) Libro(cod-libro, ttulo) Escribe(cod-libro, cod-autor ) con cod-libro clave fornea que referencia a Libro y cod-autor clave fornea que referencia a Autor

Interrelaciones 1:N Aqu existen dos casos a considerar. a. La entidad del lado de "muchos" tiene una participacin obligatoria.

@nombre + habitantes @nmero + nombre + habitantes

El esquema relacional resultante: Ciudad( Nombre-Ciudad, Nmero Regin, habitantes) Regin( Nmero-Regin, nombre, habitantes)

b. La entidad del lado de "muchos" tiene una participacin parcial.

@num-pedido + fecha tasa-descuento @nombre + fono

Los pedidos pueden hacerse por medio de vendedores, en cuyo caso se aplica una tasa de descuento, y tambin directamente sin vendedores (sin aplicar una tasa de descuento). De este modo, existe la posibilidad de valores nulos de nombre-vendedor y tasa-descuento en relacin a Pedido si se usa el siguiente esquema:

Pedido( Num-Pedido, fecha, nombre-vendedor, tasa descuento) Vendedor( Nombre, fono)

Si el nmero relativo de esos pedidos es grande, y no se puede admintir valores nulos, una mejor alternativa sera establecer tres relaciones (lo cual es el caso ms general):

Vendedor ( nombre, fono) Pedido (num-pedido, fecha) Pedido-ventas (num-pedido, nombre-vendedor, tasa-descuento)

(num-pedido en Pedido ventas es clave fornea, referenciando a Pedido).

Interrelaciones 1:1 Aqu consideramos dos alternativas, la integracin en una relacin y la definicin de una relacin aparte.

La opcin de integracin en una relacin tiene sentido cuando la participacin de las dos entidades en la relacin es total (cardinalidad mnima 1). Hay dos posibilidades:

a. Las dos entidades tienen las mismas claves primarias. En este caso las dos relaciones correspondientes se integran en una relacin combinando todos los atributos e incluyendo la clave primaria slo una vez.

@num-cliente + nombre-cliente @num-cliente + direccin-envo

El esquema relacional resultante: Envo-Cliente( num-cliente, nombre-cliente, direccin-envo)

b. Las dos entidades tienen claves primaria diferentes. Supongamos que Cliente e Info Envo tienen claves primarias diferentes, numcliente y direccin-envo respectivamente. En este caso tambin se integran en una relacin combinando todos los atributos e incluyendo las claves primarias de ambas. La clave primaria de la relacin ser una de las dos, por ejemplo, la relacin que sigue usa num-cliente como clave primaria: Envo-Cliente (num-cliente, nombre-cliente, direccin-envo)

La opcin de definicin de una relacin aparte se usa cuando una o las dos entidades tienen una participacin parcial (cardinalidad mnima 0). Aqu tambin hay dos posibilidades: a. Una entidad tiene participacin parcial.

@num-cliente + nombre @(tipo-tarjeta + nmero) + crdito

El esquema relacional resultante: Cliente (num-cliente, nombre-cliente) Tarjeta Crdito ( tipo-tarjeta, nmero, crdito) Posee Tarjeta( tipo-tarjeta, nmero, num-cliente)

b. Las dos entidades tiene participacin parcial.

@rut + nombre fecha @rut + nombre

El esquema relacional resultante: Hombre (rut-hombre, nombre) Mujer (rut-mujer, nombre) Matrimonio (rut-hombre, rut-mujer, fecha)

Atributos de Interrelaciones
Si la interrelacin se transforma en una relacin, todos sus atributos pasan a ser columnas de la relacin. En caso de que la relacin se transforme mediante propagacin de clave, sus atributos migran junto con la clave a la relacin que corresponda, aunque puede ser mejor crear una nueva relacin para representar un interrelacin que tiene atributos.

Interrelaciones exclusivas
Para soportar interrelaciones exclusivas se deben definir las restricciones pertinentes en cada caso.

Esquema Relacional:

Libro(Id-Libro, ..., Id-Editorial, Id-Universidad) Universidad (Id-Universidad, ...)

Editorial (Id-Editorial, ...)

En este caso, se propagan las claves de Universidad y Editorial a Libro. Para obligar a que se cumpla la exclusividad hay que introducir las correspondientes restricciones en una clasula CHECK: CHECK (( Id-Editorial IS NULL and Id-Universidad IS NOT NULL) OR (Id-Editorial IS NOT NULL and Id-Universidad IS NULL))

Generalizaciones
Las generalizaciones no son objetos que puedan representarse directamente en el modelo relacional. Ante una entidad y sus subtipos caben varias soluciones de transformacin, con la consiguiente prdida de semntica dependiendo de la estrategia elegida, las cuales son 3: 1. Integrar la jerarqua de generalizacin en una sola entidad uniendo los atributos de las subentidades y aadiendo estos atributos a los de la superentidad. Esto se permite si la distincin entre las subentidades no es significativa desde el punto de vista de una aplicacin. Ms an, se aade un atributo discriminativo para indicar el caso al cual pertenece la entidad en consideracin. Esta alternativa es aplicable a todos los casos, con todas las coberturas, teniendo el problema de tener que manejar en algunos casos demasiados valores nulos y que las operaciones que slo actuaban sobre una subentidad tendrn que buscar ahora los casos correspondientes dentro del conjunto completo de casos.

Estudiante = @ nmero-matrcula + nombre Pregrado = Carrera

Postgrado = Ttulo-tesis

Esquema Relacional resultante: Estudiante ( Nmero-matrcula, nombre, carrera, ttulo-tesis, tipo)

Adems se debe verificar la exclusividad: CHECK ( (tipo = Postgrado AND carrera IS NULL AND titulo-tesis IS NOT NULL) OR (tipo = Pregrdao AND carrera IS NOT NULL AND titulo-tesis IS NULL))

2. Eliminar la superentidad reteniendo las subentidades. Aqu los atributos heredados deben propagarse entre las subentidades. Esta alternativa no es prctica para generalizaciones superpuestas o parciales; slo lo es para jerarquas totales y exclusivas. Adems, si el nmero de atributos de la superentidad (comunes a toda las subentidades) es excesivo, su duplicacin en el esquema de cada subentidad no se justifica.

Empleado = @ rut + nombre Ingeniero = especialidad Gerente = Nmero-supervisados

Esquema Relacional resultante: Ingeniero (rut, nombre, especialidad) Gerente (rut, nombre, Nmero-supervisados)

3. Retener todas las entidades y establecer explcitamente las interrelaciones entre la superentidad y las subentidades. Esta alternativa se puede considerar como la ms general de las tres, ya que siempre es posible. Las desventajas de este enfoque son que el esquema resultante es bastante complejo y hay una redundancia inherente al representar cada eslabn ES-UN en la jerarqua original a travs de una relacin explcita. Las ventajas, por otra parte, son que modela todos los casos, lo que la hace ms flexible ante cambios de requerimientos, y es conveniente si la mayora de las operaciones son estrictamente locales respecto a la superentidad o a una de las subentidades.

Proyecto = @Nmero-proyecto + nombre-proyecto Desarrollo-Sw = Nmero mdulos Subcontrato = contratista-principal

Esquema Relacional resultante: Proyecto (Nmero-proyecto, nombre-proyecto) Desarrollo-Sw (Nmero-proyecto, Nmero Mdulos) Subcontrato(Nmero-proyecto, contratista-principal)

Donde en Desarrollo-Sw y subcontrato las claves primarias son a su ves claves forneas que referencias a proyecto, implementando de ese modo las relaciones ES-UN.

Atributos Derivados
No existe para los atributos derivados una representacin directa y concreta en el modelo relacional y sus SGBD. En este caso, los atributos se tratan de la forma usual, implementando los procedimientos que calculen el valor del atributo derivado cada vez que inserten o borren las ocurrencias de los atributos que intervienen en el clculo de este y aadir las restricciones correspondientes.

Transformacin de dependencias en identificacin y en existencia

En MR: LIBRO(cod_libro,...)

EJEMPLAR(cod_libro, cod_ejemplar,...) clave fornea, NOT NULL, ON DELETE CASCADE, ON UPDATE CASCADE.

Para dependencia en identificacin, la clave primaria de la entidad dbil debe estar formada por la concatenacin de las claves de las dos entidades participantes en la interrelacin. ANEXO 2 Dependencias Funcionales

Dependencia funcional Lo primero consiste en revisar algunas definiciones: Def. 1: Una dependencia funcional es una relacin muchos a uno desde un conjunto de atributos a otro que tiene una relacin.

Def. 2: Sea R una relacin y sean X e Y subconjuntos arbitrarios del conjunto de atributos de R. Cuando se dice que Y es funcionalmente dependiente de X -en smbolos XY- s y slo s cada valor de X en R est asociado con, precisamente, un valor de Y en R. En otras palabras, cuando quiera que dos tuplas de R coinciden sobre un mismo valor de X, ellas tambin coinciden sobre un mismo valor de Y. Las definiciones anteriores explicitan que para una relacin R es posible considerar un amplio conjunto de dependencias funcionales entre los atributos que la componen. Esto es obvio si consideramos para la segunda definicin que X es una clave candidata -ms an si es una clave principal- e Y son todos los atributos de la relacin. Estas dependencias se establecen para todos los posibles valores legales de los atributos considerados. Esto significa que puede darse el caso que todas las tuplas que actualmente existen en la relacin cumplan con una determinada restriccin funcional, pero eso es algo que en la realidad no ocurre y es en este sentido que se habla de los valores legales de los atributos, todos los posibles en la realidad. Dependencias Triviales y No triviales Una forma obvia de reducir el tamao del conjunto de dependencias es eliminar las dependencias triviales. Una dependencia es trivial si es imposible que no pueda ser satisfecha. Esto ocurre, en efecto, si y slo si el conjunto a la derecha es un subconjunto del que est a la izquierda. Las dependencias no triviales son todo aquel conjunto que es distinto de subconjunto de las triviales. Dependencia funcional completa Se dice que el atributo Y de la relacin R es por completo dependiente funcionalmente del atributo X de la relacin R si depende funcionalmente de X y no depende funcionalmente de ningn subconjunto propio de X (es decir, no existe un subconjunto propio Z de los atributos componentes de X tales que Y sea funcionalmente dependiente de Z). Propiedades Sean A,B,C y D son subconjuntos arbitrarios del conjunto de atributos que tiene la relacin R, y escribir AB significa la Unin de A y B. Entonces tenemos: Reglas de inferencia de Armstrong 1. Reflexivilidad: Si B es un subconjunto de A, entonces A B. 2. Aumentacin: Si A B, entonces AC BC. 3. Transitividad: Si A B y B C, entonces A C. 4. Autodeterminacin: A A. 5. Descomposicin: Si A BC, entonces A B y A C. 6. Unin: Si A B y A C, entonces A BC. 7. Composicin: Si A B y C D, entonces AC BD. Teorema de Unificacin General: u:unin y -:diferencia. Si A B y C D, entonces A u ( C - B ) BD

Dependencia Multivaluada

Def.-3: Dada una relacin R con los atributos A, B y C, la dependencia multivaluada (DMV) R.AR.B se cumple en R si y slo si el conjunto de valores de B correspondiente a un par dado (valor de A, valor de C) en R depende slo del valor de A y es independiente del valor de C Dependencias funcionales de las claves Una clave candidata consiste de un conjunto de atributos K (no vaco) de la relacin R que satisface las siguientes propiedades, independientes del tiempo: 1.Unicidad: en cualquier momento dado, no existen dos tuplas en R con el mismo valor de K. 2.Minimalidad: si K es compuesto, no ser posible eliminar ningn componente de K sin destruir la propiedad de unicidad. Ntese que la relacin tiene por lo menos una clave candidata, porque las relaciones no contienen tuplas repetidas. Ahora bien, del conjunto de las claves candidatas de una relacin dada, se elige una y slo una como clave primaria de esa relacin; las dems, si existen se llaman claves alternativas. Revisando las definiciones anteriores y comparndolas con la definicin de dependencia funcional podemos decir que siempre existir una dependencia entre cualquier clave candidata y los atributos que no son o no componen dicha clave, pero que tambin pertenecen a la relacin.

Ejemplos de Dependencias Funcionales Las dependencias funcionales son representaciones semnticas de las relaciones que existen entre los datos en una realidad. Un buen ejemplo de esto es el nombre de una persona; el cual siempre depender del rut de esa persona; ya que aunque existiesen dos personas con el mismo nombre, ellas siempre tendrn distinto rut. Pero, como se seal, las dependencias funcionales reflejan enlaces semnticos permanentes entre datos de un diseo. Y es en este ltimo sentido que podramos pensar que el ejemplo entregado anteriormente puede no ser un ejemplo de una dependencia funcional dentro de un diseo, ya que la existencia o no de alguna de ellas es una decisin del diseador. En relacin a lo anterior, podemos pensar en la situacin de un alumno de sta universidad: podemos considerar que su rut y su nombre dependen funcionalmente de su nmero de matrcula y la dependencia del nombre al rut obviarla. Con la situacin anterior podemos tambin ejemplificar, forzando la situacin, lo que es una dependencia funcional completa: por ejemplo, supongamos para un alumno que el nombre lo hacemos depender del conjunto de atributos compuesto por rut y nmero de matrcula; pero, realmente el nombre de una persona (en este caso alumno) depende slo del rut, un subconjunto de los atributos que componen nuestro conjunto inicial; el ejemplo anterior derivara en una dependencia completa, si slo se hiciera depender el atributo nombre del rut. Grficamente es posible representar una dependencia funcional mediante flechas, esto ya se vio en la definicin en que simblicamente se representa una dependencia de Y con respecto de X mediante la expresin: XY. Por ejemplo para las relaciones de alumno y ramos se tendra los siguientes atributos: Alumno( NoMatrcula, Nombre, Sexo, FechaNac.) Ramos( NoMatrcula,CodRamo,NotaFinal) Con las siguientes dependencias funcionales: Alumno.NoMatrcula Nombre Alumno.NoMatrcula Sexo

Alumno.NoMatrcula FechaNac (NoMatrcula, CodRamo) NotaFinal

Dependencias Funcionales y Formas Normales Procedimiento de normalizacin adicional La teora de la normalizacin busca que las relaciones cumplan con un cierto conjunto de restricciones explcitas, de modo que sea posible asegurar ciertas propiedades deseables en los datos. Las formas normales corresponden a un conjunto discreto de restricciones progresivas que hacen que una relacin tenga un grado de normalizacin en el momento que cumple con algn subconjunto de aquellas. El sentido de progresin que determinan las formas normales es justificado por las caractersticas de las restricciones que ellas imponen, donde, para que una relacin acceda a la posibilidad de cumplir el siguiente conjunto de restricciones debe, previamente satisfacer las anteriores. Esto se puede ver desde el punto que hay ciertas relaciones a las cuales les basta con cumplir un conjunto de restricciones y con ello alcanzar un grado de normalizacin suficiente. Mientras, por otro lado, existen otras relaciones que necesitan cumplir con otro conjunto mayor de restricciones para alcanzar ste estado deseable en sus datos. As las formas normales estn contenidas unas en otras formando un conjunto de reglas que progresivamente va asegurando calidad en las relaciones. Esto se alcanza mediante un procedimiento de normalizacin en el cual una relacin en unacierta forma normal, se puede convertir en una o ms relaciones que estn en una forma ms deseable. As, el procedimiento lo podemos caracterizar como la reduccin sucesiva de un conjunto dado de relaciones a una forma ms deseable. Cabe sealar que el procedimiento es reversible; es decir, siempre es posible tomar la salida del procedimiento (relaciones con un grado de normalizacin) y convertirlas otra vez en la entrada (antes de cumplir con las restricciones). Esto ltimo es importante ya que significa que no se pierde informacin durante el proceso de normalizacin.

Formas Normales Las dependencias funcionales permiten definir de manera ms formal los elementos de normalizacin del modelo relacional. Para ello, y entendiendo que no es simple la comprensin del problema de las formas normales y su relacin con las dependencias funcionales, se establece el siguiente mtodo de desarrollo explicativo: primero, se entregar la definicin que propone C.J.Date en el libro "Introduccin a los Sistemas de Bases de Datos", la cual, probablemente necesitar de algn grado de explicacin; as, en segundo lugar, se entregar una breve explicacin de esa definicin. Primera forma normal Una relacin est en primera forma normal (1NF) si y slo si todos los dominios simples subyacentes contienen slo valores atmicos. Las dependencias no participan directamente en la normalizacin para alcanzar la primera forma normal puesto que sta slo busca eliminar los grupos repetitivos. As, el siguiente es un ejemplo de este nivel de normalizacin sobre el atributo b:

R:

a1

b1,b2,b3

c1

a2

b4,b5

c2

R1:

a1

b1

c1

a1

b2

c1

a1

b3

c1

a2

b4

c2

a2

b5

c2

se puede apreciar que b presenta repeticiones de ocurrencias para R, al normalizar obtenemos R1, en la cual se han eliminado estas repeticiones. Segunda forma normal Una relacin est en segunda forma normal (2NF) si y slo si est en 1NF y todos los atributos no clave dependen por completo de la clave primaria. Esta forma aboga por relaciones en que solamente existan dependencias completas, eliminando, mediante proyeccin, las que estando en 1 forma normal no cumplan esa condicin. Por ejemplo: R( a,b,c,d,e) con DF: {a,b} c, a d, a e donde las dos ltimas no son completas con respecto de la clave primaria, as es necesaria una proyeccin que d como resultado dos o ms relaciones que tengan esta caracterstica, por ejemplo: R1( a,b,c ) con DF: {a,b} c, y R2( a,d,e ) con DF: a d, a e Tercera forma normal Una relacin est en tercera forma normal (3NF) si y slo si esta en 2NF y todos los atributos no clave dependen de manera no transitiva de la clave primaria.

Busca, para relaciones en 2 forma normal, aquellas en que existan dependencias transitivas con respecto de la clave primaria. As, cualquier relacin que tenga este tipo de dependencia, debe ser proyectada de modo que sea eliminada. Por ejemplo: R ( a,b,c ) con DF: a b, a c, b c Se puede apreciar que la dependencia funcional a c es transitiva, ya que puede ser expresada mediante las otras dos que existen, esto es: a b y b c. Para eliminar esto proyectamos sobre a,b y sobre b,c R1( a,b ) con DF: a b R2( b,c ) con DF: b c Forma normal de Boyce/Codd Una relacin est en forma normal Boyce/Codd (BCNF) si y slo si todo determinante es una clave candidata. Se debe definir el concepto de determinante como un atributo del cual depende funcionalmente (por completo) algn otro atributo. Por ejemplo, en el caso anterior, a es un determinante para todos los atributos de R1, tambin b es el determinante de todos los atributos de R2. Para la forma normal Boyce/Codd los nicos determinantes son las claves candidatas, es decir los atributos slo puede depender de las claves candidatas. Veamos un caso en que eso no ocurra, y sea necesaria una transformacin para normalizarla segn la forma Boyce/Codd: R( a,b,c ) donde existen las siguientes DF {a,b} c y c b. Esto se normaliza en Boyce/Codd como las siguientes dos relaciones: R1(a,c) con DF a c, y R2(c,b) con DF c b Cuarta Forma Normal Una relacin R est en cuarta forma normal (4NF) si y slo si, siempre que existe una Dependencia Multivaluada en R, digamos A B, todos los atributos de R dependen tambin funcionalmente de A. En otras palabras, las nicas dependencias (funcionales o multivaluadas) en R son de la forma K X (o sea, una dependencia funcional con respecto a una clave candidata K de algn otro atributo X). O lo que es equivalente: R est en 4NF si est en BCNF y todas las dependencias multivaluadas en R son de hecho dependencias funcionales. Por ejemplo, si tenemos la siguiente relacin, con dependencias multivaluadas: R(a,b,c) donde existen las DMV a b y a c, entonces la normalizacin en cuarta forma normal nos lleva a transformar esta relacin en otras en que todas las dependencias multivaluadas sean dependencias funcionales, esto slo lo logramos al proyectarlas sobre distintas relaciones, por ejemplo: R1(a,b) con DF a b, y R2(a,c) con DF a c Quinta forma normal Una relacin est en quinta forma normal (5NF) -llamada tambin forma normal de proyeccin/reunin (PJ/NF)- si y slo si toda dependencia de reunin en R es una consecuencia de las claves candidatas de R.

Introduccin a la Automatizacin del Proceso de normalizacin Una de las ventajas de cualquier formalizacin terica es la posibilidad de crear herramientas de apoyo a procesos que, basados en esta formalizacin, generen resultados consistentes. Aplicando lo anterior podemos vislumbrar una conceptualizacin tal que para el terreno de las bases de datos relacionales sea factible la automatizacin del procedimiento de normalizacin adicional. Esta conceptualizacin se basa en que si tenemos un esquema de base de datos R lo podemos llevar, mediante un proceso de normalizacin, a un esquema S, en lo que sera una adecuada representacin de R en trminos de las restricciones impuestas por S. Esta transformacin de R en S se logra, principalmente, mediante el uso de dos tipos de descomposiciones. Horizontales que usa el operador de seleccin y verticales mediante el uso de operador de proyeccin. Tambin, cualquier instancia R debe ser posible reconstruirla desde S mediante la aplicacin de una transformacin "inversa" a la que permiti llevar R a S. Dada la formalizacin algebraica de la teora de bases de datos relacionales, es posible expresar las relaciones que existen entre un esquema R y su descomposicin adecuada equivalente S, en trminos de requerimientos formales y operaciones no ambiguas sobre R, de manera que ste cumpla con las restricciones necesarias impuestas por S. Un ejemplo de transformaciones de ese tipo, corresponde a las anteriormente descritas.

Tcnicas de normalizacin Existen dos tcnicas principales para la normalizacin de esquema mediante descomposicin: anlisis y sntesis. Ambos reciben como entrada el diseo de una relacin, y el conjunto de las dependencias funcionales definidas sobre ella. Pero las dos tcnicas difieren en la estrategia que usan para obtener el esquema normalizado. El algoritmo de anlisis genera el esquema normalizado mediante la eliminacin de las causas que impiden la normalizacin. Si una relacin no satisface la deseada forma normal por causa de ciertas dependencias, ella es descompuesta en dos o ms relaciones en base a tal dependencia. El proceso es iterado hasta que todas las relaciones estn normalizadas. As, a cada paso el anterior esquema es cambiado en uno nuevo con ms relaciones. Por ejemplo, si una relacin como R con sus dependencias funcionales y queremos llevarla a tercera forma normal, los pasos que se ejecutan sern los siguientes: R( a,b,c,d,e,f ) con las DF a b, b c, c d, a e y a f Paso 1, primera iteracin: R12( a,b,c,e,f ) con las DF a b, b c, a e y a f R3( c,d ) con las DF c d Se puede ver que mientras R3 est en tercera forma normal R12 an mantiene una dependencia transitiva, iteramos nuevamente para R12. Paso 2, segunda iteracin: R1( a,b,e,f ) con las DF a b, a e y a f R2( b,c ) con las DF b c As, las tres relaciones resultantes R1,R2,R3 estn en tercera forma normal.

Por otro lado, la sntesis acta considerando las dependencias que existen, reducindolas a una cobertura estndar, y particionndolas en base a un criterio especfico. Una relacin, entonces, est asociada con cada elemento de la particin, conteniendo todos los atributos que estn involucrados en dependencias con ese elemento. La particin es generada como una forma en que la relacin correspondiente puede agrupar funcionalmente los atributos. As, al final la relacin es sintetizada sin generar relaciones intermedias. Por ejemplo, consideremos la misma relacin R que utilizamos en el caso del anlisis. Donde lo primero que haremos ser una particin en el conjunto de las dependencias funcionales y en base a eso e inspeccin se sintetizarn las nuevas relaciones: La particin nos entrega las siguientes dependencias funcionales, y con ellas es posible formar tres relaciones normalizadas: a b a e que forman R1( a,b,e,f ) a f b c que conforma R2( b,c ) c d que, finalmente, permite R3 ( c,d )

Estos dos algoritmos, someramente presentados, entregan una visin de las posibilidades de algoritmizacin del problema de la normalizacin gracias a la especificacin de dependencias funcionales.