MODELOS BASE DE DATOS

LUIS ERNESTO SUREZ RIVERA Cd.: 1094243607 Ing. EDGAR ALBORNOZ

UNIVERSIDAD DE PAMPLONA FACULTAD DE INGENIERIAS Y ARQUITECTURA PROGRAMA DE INGENIERA INDUSTRIAL REA DE BASE DE DATOS PAMPLONA 2011

MODELO ENTIDAD-RELACIN
Un diagrama o modelo entidad-relacin (a veces denominado por sus siglas, E-R "Entity relationship", o, "DER" Diagrama de Entidad Relacin) es una herramienta para el modelado de datos de un sistema de informacin. Estos modelos expresan entidades relevantes para un sistema de informacin as como sus interrelaciones y propiedades.

El Modelo Entidad-Relacin. 1. Se elabora el diagrama (o diagramas) entidad-relacin. 2. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama. Dado lo rudimentario de esta tcnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos. El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementable en una base de datos.

Brevemente:

Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa). Conversin en tablas (en caso de utilizar una base de datos relacional).

Base Terica y Conceptual El modelo de datos entidad-relacin est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos objetos. Entidad Representa una cosa u "objeto" del mundo real con existencia independiente, es decir, se diferencia unvocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad. Algunos Ejemplos:

Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos). Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos diferentes, por ejemplo, el nmero de bastidor). Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su direccin).

Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre, etc. (entidad abstracta).

Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona puede llevar consigo las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento, etc... Atributos Los atributos son las caractersticas que definen o identifican a una entidad. Estas pueden ser muchas, y el diseador solo utiliza o implementa las que considere ms relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades. En un conjunto de entidades, cada entidad tiene valores especficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca. Ejemplos: A la coleccin de entidades alumnos, con el siguiente conjunto de atributos en comn, (id, nombre, edad, semestre), pertenecen las entidades:

(1, Sofa, 38 aos, 2) (2, Josefa, 19 aos, 5) (3, Carlos, 20 aos, 2)

Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id. Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo

puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...). Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo. Relacin Describe cierta dependencia entre entidades o permite la asociacin de las mismas. Ejemplo: Dadas dos entidades "Habitacin 502" y "Mark", es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Mark. Una relacin tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, un husped (entidad), se aloja (relacin) en una habitacin (entidad).

Conjunto de Relaciones Consiste en una coleccin, o conjunto, de relaciones de la misma naturaleza. Ejemplo: Dados los conjuntos de entidades "Habitacin" y "Husped", todas las relaciones de la forma habitacin-husped, permiten obtener la informacin de los huspedes y sus respectivas habitaciones. La dependencia o asociacin entre los conjuntos de entidades es llamada participacin. En el ejemplo anterior los conjuntos de entidades "Habitacin" y "Husped" participan en el conjunto de relaciones habitacin-husped.

Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin. Restricciones Son reglas que deben mantener los datos almacenados en la base de datos. Correspondencia de Cardinalidades: Dado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:

Uno a Uno: Una entidad de A se relaciona nicamente con una entidad en B y viceversa (ejemplo relacin vehculo - matrcula: cada vehculo tiene una nica matrcula, y cada matrcula est asociada a un nico vehculo). Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A (ejemplo vendedor - ventas). Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleado-centro de trabajo). Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociacin, y cada ciudadano puede pertenecer a muchas asociaciones distintas).

Restricciones de Participacin Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participacin puede ser de dos tipos:

Total: Cuando cada entidad en A participa en al menos una relacin de R. Parcial: Cuando al menos una entidad en A NO participa en alguna relacin de R.

Claves Es un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar unvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones. Dentro de los conjuntos de entidades existen los siguientes tipos de claves:

Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave. Clave candidata: Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata. Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades.

Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias. Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos:

R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes. R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.

Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades:

R es de muchos a uno de A a B entonces slo se toma la clave primaria de A, como clave primaria de R. R es de uno a muchos de A a B entonces se toma slo la clave primaria de B, como clave primaria de R. R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R. R es de muchos a muchos de A a B entonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.

Diagrama Entidad-Relacin Anteriormente detallamos los conceptos relacionados al modelo ER, en esta seccin profundizaremos en como representarlos grficamente. Cabe destacar que para todo proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan conocimiento necesario y adems fundamentan nuestro modelo al momento de presentarlo a terceros. Formalmente, los diagramas ER son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen

informacin que trata un sistema de informacin y el software que lo automatiza. Entidad Las entidades son el fundamento del modelo entidad relacin. Podemos adoptar como definicin de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podran interpretar como entidades. Las entidades pueden representar entes concretos, como una persona o un avin, o abstractas, como por ejemplo un prstamo o una reserva. Se representan por medio de un rectngulo.

Atributo Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Relaciones Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona, para as saber cul es la relacin que lleva cada uno. Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidad-relacin, sino que se describen textualmente en otros documentos adjuntos.

Diagramas Extendidos

DER extendido Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje: Entidades Fuertes y Dbiles Cuando una entidad participa en una relacin puede adquirir un papel fuerte o dbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin, es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos. Una entidad fuerte (tambin conocida como entidad regular) es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad dbil para que, esta ltima, se pueda identificar.

Las entidades dbiles se representan- mediante un doble rectngulo, es decir, un rectngulo con doble lnea. Cardinalidad de las relaciones El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente: "1:1", "1:N" y "N:M", aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta una entidad con una relacin:

"0" si cada instancia de la entidad no est obligada a participar en la relacin. "1" si toda instancia de la entidad est obligada a participar en la relacin y, adems, solamente participa una vez. "N" , "M", "*" si cada instancia de la entidad no est obligada a participar en la relacin y puede hacerlo cualquier nmero de veces.

Ejemplos de relaciones que expresan cardinalidad:

Cada esposo (entidad) est casado (relacin) con una nica esposa (entidad) y viceversa. Es una relacin 1:1. Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relacin 1:N. Un cliente (entidad) puede comprar (relacin) varios artculos (entidad) y un artculo puede ser comprado por varios clientes distintos. Es una relacin N:M.

Atributos en Relaciones Las relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo "histrico" donde debe constar una fecha o una hora. Por ejemplo, supongamos

que es necesario hacer constar la fecha de emisin de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisin" de la factura debera colocarse en la relacin "se emite". Herencia La herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relacin entre una entidad "padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no necesitan ser representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del tringulo. Agregacin

Ejemplo agregacin: Es una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se utiliza para expresar relaciones entre relaciones o

entre entidades y relaciones. Se representa englobando la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se muestra un ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un determinado software, etc.).

MODELO RELACIONAL
El para la gestin de una base de datos es un modelo de datos basado en la modelo relacional lgica de predicados y en la teora de conjuntos. Es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de relaciones. Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados tuplas. Pese a que sta es la teora de las bases de datos relacionales creadas por Edgar Frank Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar, esto es, pensando en cada relacin como si fuese una tabla que est compuesta por registros (cada fila de la tabla sera un registro o tupla), y columnas (tambin llamadas campos). Descripcin En este modelo todos los datos son almacenados en relaciones, y como cada relacin es un conjunto de datos, el orden en el que stos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar por un usuario no experto. La informacin puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la informacin.

Este modelo considera la base de datos como una coleccin de relaciones. De manera simple, una relacin representa una tabla que no es ms que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le puede llamar campo o atributo. Para manipular la informacin utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el lgebra relacional y el Clculo relacional. El lgebra relacional permite describir la forma de realizar una consulta, en cambio, el Clculo relacional slo indica lo que se desea devolver. Esquema Un esquema es la definicin de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relacin y que tipo de informacin podr ser almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relacin. Todo esquema constar de:

Nombre de la relacin (su identificador). Nombre de los atributos (o campos) de la relacin y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de dato por ejemplo character, integer, date, string, etc.

Instancias Una instancia de manera formal es la aplicacin de un esquema a un conjunto finito de datos. En palabras no tan tcnicas, se puede definir como el contenido de una tabla en un momento dado, pero tambin es vlido referirnos a una instancia cuando trabajamos o mostramos nicamente un subconjunto de la informacin contenida en una relacin o tabla, como por ejemplo:

Ciertos caracteres y nmeros (una sola columna de una sola fila). Algunas o todas las filas con todas o algunas columnas

Cada fila es una tupla. El nmero de filas es llamado cardinalidad. El nmero de columnas es llamado aridad o grado.

BASE DE DATOS RELACIONAL Una base de datos relacional es un conjunto de una o ms tablas estructuradas en registros (lneas) y campos (columnas), que se vinculan entre s por un campo en comn, en ambos casos posee las mismas caractersticas como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional. Estrictamente hablando el trmino se refiere a una coleccin especfica de datos pero a menudo se le usa, en forma errnea como sinnimo del software usado para gestionar esa coleccin de datos. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del ingls relational database management system). Las bases de datos relacionales pasan por un proceso al que se le conoce como normalizacin de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera ptima. Entre las ventajas de este modelo estn: 1. Garantiza herramientas para evitar la duplicidad de registros, a travs de campos claves o llaves. 2. Garantiza la integridad referencial: As al eliminar un registro elimina todos los registros relacionados dependientes. 3. Favorece la normalizacin por ser ms comprensible y aplicable.

BASE DE DATOS ORIENTADA A OBJETOS

En una base de datos orientada a objetos, la informacin se representa mediante objetos como los presentes en la programacin orientada a objetos. Cuando se integra las caractersticas de una base de datos con las de un lenguaje de programacin orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system). Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programacin en uno o ms lenguajes de programacin a los que d soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de concurrencia, recuperacin de datos, consultas asociativas y otras capacidades. Las bases de datos orientadas a objetos se disean para trabajar bien en conjuncin con lenguajes de programacin orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programacin. Los ODBMS son una buena eleccin para aquellos sistemas que necesitan un buen rendimiento en la manipulacin de tipos de dato complejos. Los ODBMS proporcionan los costes de desarrollo ms bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integracin transparente con el programa escrito en un lenguaje de programacin orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento. Historia Los orgenes del trmino orientados a objetos (abreviado OO) se remontan a los lenguajes de programacin orientadas a objetos. Los lenguajes de programacin OO tienen sus races en el lenguaje SIMULA 67, propuesto a finales de la dcada de 1960. En Simula, el concepto de clase agrupa la estructura de datos interna de un objeto en una declaracin de clase, es decir,

introduce en el lenguaje Algol los conceptos de objeto y de clase. Como Algol, Simula es un lenguaje fuertemente utilizado para entornos compilados. Sin embargo, el primer lenguaje que populariz la aproximacin a objetos fue Smalltalk (1976); este puede considerarse una sntesis de aos del lenguaje Lisp, que ofrece una gran flexibilidad gracias a la interpretacin, y de Simula, aadiendo el concepto de metaclase. Smalltalk ha podido responder a las necesidades de flexibilidad presentadas por el desarrollo de entornos de programacin grficos, favoreciendo la rpida creacin de prototipos de interfaces de usuarios amigables. Fue utilizado con xito en la primera estacin grfica de Xerox. Con la llegada de las estaciones de trabajo en los aos 80, han crecido numerosos lenguajes orientados a objetos inspirados en Simula o Smalltalk. Entre los lenguajes compilados, los ms celebres son C++, Objective C y Eiffel, debido a la compatibilidad del lenguaje o del cdigo producido con el lenguaje de programacin C. La mayor parte de los lenguajes interpretados son extensiones del Lisp; por ejemplo, Loops y CLOS. Es interesante notar que la mayor parte de los lenguajes populares existentes se encuentran en curso de ampliacin para convertirse en orientados a objetos, incluyendo al Cobol y Ada (ms exactamente Ada 9X, que aporta la herencia). En aos recientes, han aparecido muchos prototipos experimentales y sistemas de bases de datos comerciales orientados a objetos. Entre los primeros se encuentran los sistemas ORION, OpenOODB, IRIS, ODE y el proyecto ENCORE/ObServer. Y entre los sistemas disponibles en el mercado estn: GEMSTONE/OPAL de ServicLogic, ONTOS de Ontologic, Objectivity de Objectivity Inc., Versant de Versant Technologies, ObjecStore de Object Design y O2 de O2 Technology. Esta es solo una lista parcial de los prototipos experimentales y de los sistemas de bases de datos comerciales orientados a objetos. Desafortunadamente, es an demasiado pronto para saber cules sistemas se instalarn como lderes en este campo. Las bases de datos orientados a objetos han adoptado muchos de los objetos creados para los lenguajes de programacin orientados a objetos.

BASE DE DATOS JERRQUICA

Una base de datos jerrquica es un tipo de sistema de gestin de bases de datos que, como su nombre indica, almacenan la informacin en una estructura jerrquica que enlaza los registros en forma de estructura de rbol (similar a un rbol visto al revs), en donde un nodo padre de informacin puede tener varios nodos hijo. Esta relacin jerrquica no es estrictamente obligatoria, de manera que pueden establecerse relaciones entre nodos hermanos. En este caso la estructura en forma de rbol se convierte en una estructura en forma de grafo dirigido. Esta variante se denomina Bases de datos de red. Resea Histrica Las bases de datos jerrquicas fueron concebidas en los aos 1960. El primer metamodelo de base de datos propuesto fue la mencionada Base de datos en red, concebida bajo el auspicio de CODASYL (Conference on Data Systems Languages). Posteriormente se refin la idea dando lugar a la base de datos jerrquica. La primera implementacin de este metamodelo fue IMS (Information Management System). Se trata de un diseo de IBM y otros colaboradores en 1966 para el Programa Apoyo de la NASA. IMS an se encuentra activo. El sector de la banca y las Administraciones Pblicas adoptaron rpidamente esta tecnologa, sin la cual, no hubiese sido posible el grado de automatizacin que tienen hoy da. Estos sectores eran los nicos con capacidad econmica suficiente para adquirir los enormes mainframe para la automatizacin de bases de datos, nica solucin posible en la poca. Poco despus, en 1970, E. F. Codd propuso el modelo relacional. Las ventajas de estos modelos y su enfoque matemtico centraron los esfuerzos de la industria dando lugar a los sistemas gestores de bases de datos relacionales. Estos ltimos han reemplazado a las bases de datos jerrquicas hoy da, pero no completamente. La mayora de las antiguas bases de datos jerrquicas de bancos y Administraciones Pblicas an siguen en actividad. Esto se debe a que el rendimiento de las bases de datos jerrquicas sigue sin ser superado por las

bases de datos relacionales. Adems estos sectores sufren un gran volumen de transacciones. Obsrvese, por ejemplo, la cantidad de apuntes contables que requiere una red de cajeros automticos en un solo da. Cmo Funcionan A diferencia del modelo relacional, el modelo jerrquico no diferencia una vista lgica de una vista fsica de la base de datos. De manera que las relaciones entre datos se establecen siempre a nivel fsico, es decir, mediante referencia a direcciones fsicas del medio de almacenamiento (sectores y pistas). Los datos se almacenan en la forma de registros, el equivalente a las filas del modelo relacional. Cada registro consta de un conjunto de campos, el equivalente a las columnas del modelo relacional. Un conjunto de registros con los mismos campos se denomina fichero (record type, en ingls), el equivalente a las tablas del modelo relacional. El modelo jerrquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del modelo relacional. Pero a diferencia de ste ltimo, las relaciones son unidireccionales. En justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de un empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre), pero no al contrario. Esto implica que solamente se puede consultar la base de datos desde los nodos hoja hacia el nodo raz. La consulta en el sentido contrario requiere una bsqueda secuencial por todos los registros de la base de datos (por ejemplo, para consultar todos los empleados de un departamento). En las bases de datos jerrquicas no existen ndices que faciliten esta tarea. Obsrvese que, a priori, no existen relaciones N:M (de muchos a muchos) en el modelo jerrquico. Salvo que se simulen mediante varias relaciones 1:N. No obstante, esto puede provocar problemas de inconsistencia, ya que el gestor de base de datos no controla estas relaciones. Como ya se ha mencionado, las relaciones se establecen mediante punteros entre registros. Es decir, un registro hijo contiene la direccin fsica en el medio de almacenamiento de su registro padre. Esto tiene una ventaja fundamental sobre las bases de datos relacionales: el rendimiento. El acceso de

un registro a otro es prcticamente inmediato sin necesidad de consultar tablas de correspondencia. Las relaciones jerrquicas entre diferentes tipos de datos pueden hacer que sea muy sencillo responder a determinadas preguntas, pero muy difcil el contestar a otras. Limitaciones del Modelo Jerrquico A continuacin se mencionan los problemas tpicos de las bases de datos jerrquicas y que no existen en las bases de datos relacionales. Todos estos problemas derivan del hecho de que el sistema gestor de base de datos no implementa ningn control sobre los propios datos, sino que queda en manos de las aplicaciones garantizar que se cumplen las condiciones invariantes que se requieran (por ejemplo, evitar la duplicidad de registros). Dado que todas las aplicaciones estn sujetas a errores y fallos, esto es imposible en la prctica. Adems dichas condiciones suelen romperse ex profeso por motivos operativos (generalmente, ajustes debidos a cambios en el negocio) sin evaluarse sus consecuencias. Duplicidad de Registros No se garantiza la inexistencia de registros duplicados. Esto tambin es cierto para los campos "clave". Es decir, no se garantiza que dos registros cualesquiera tengan diferentes valores en un subconjunto concreto de campos. Integridad Referencial No existe garanta de que un registro hijo est relacionado con un registro padre vlido. Por ejemplo, es posible borrar un nodo padre sin eliminar antes los nodos hijo, de manera que stos ltimos estn relacionados con un registro invlido o inexistente. Desnormalizacin Este no es tanto un problema del modelo jerrquico como del uso que se hace de l. Sin embargo, a diferencia del modelo relacional, las bases de datos

jerrquicas no tienen controles que impidan la desnormalizacin de una base de datos. Por ejemplo, no existe el concepto de campos clave o campos nicos. La desnormalizacin permite ingresar redundancia de una forma controlada, seguir a una serie de pasos conlleva a:

Combinar las relaciones Duplicar los atributos no claves Introduccin de grupos repetitivos Crear tablas de extraccin

Cuando se debe desnormalizar:

Se debe desnormalizar para optimizar el esquema relacional. Para hacer referencia a la combinacin de 2 relaciones que forman una sola relacin.

Ejemplo: Proveedor (Nro_proveedor, calle, ciudad, cod_postal, descripcin) La relacin Proveedor esta desnormalizada, ya que para normalizarla deberamos crear una tabla con ciudad y cdigo postal Gestores de bases de datos jerrquicas

Adabas GT.M IMS Focus

BASE DE DATOS DE RED

Una base de datos de red es una base de datos conformada por una coleccin o set de registros, los cuales estn conectados entre s por medio de enlaces en una red. El registro es similar al de una entidad como las empleadas en el modelo relacional. Un registro es una coleccin o conjunto de campos (atributos), donde cada uno de los que contiene solamente un nico valor almacenado, exclusivamente el enlace es la asociacin entre dos registros, as que podemos verla como una relacin estrictamente binaria. Una estructura de base de datos de red, llamada algunas veces estructura de plex, abarca ms que la estructura de rbol, porque un nodo hijo en la estructura red puede tener ms de un nodo padre. En otras palabras, la restriccin de que en un rbol jerrquico cada hijo puede tener slo un padre, se hace menos severa. As, la estructura de rbol se puede considerar como un caso especial de la estructura de red. Ejemplo Para ilustrar la estructura de los registros en una base de datos de red, mostraremos la base de datos alumno materia, con los siguientes registros (en el Lenguaje de programacin Pascal): type materia = record clave: string[7] nombreM: string[25] cred: string[2]; end; type alumno = record nombre: string[30];

control: string[8]; materia: Materia; {Enlace a materia} end; En sntesis una base de datos en red puede tener 1 o ms elementos padre.

BASES DE DATOS TRANSACCIONALES

Son bases de datos cuyo nico fin es el envo y recepcin de datos a grandes velocidades, estas bases son muy poco comunes y estn dirigidas por lo general al entorno de anlisis de calidad, datos de produccin e industrial, es importante entender que su fin nico es recolectar y recuperar los datos a la mayor velocidad posible, por lo tanto la redundancia y duplicacin de informacin no es un problema como con las dems bases de datos, por lo general para poderlas aprovechar al mximo permiten algn tipo de conectividad a bases de datos relacionales.

BASES DE DATOS MULTIDIMENSIONALES

Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como creacin de Cubos OLAP. Bsicamente no se diferencian demasiado de las bases de datos relacionales (una tabla en una base de datos relacional podra serlo tambin en una base de datos multidimensional), la diferencia est ms bien a nivel conceptual; en las bases de datos multidimensionales los campos o atributos de una tabla pueden ser de dos tipos, o bien representan dimensiones de la tabla, o bien representan mtricas que se desean estudiar.

BASES DE DATOS DOCUMENTALES

Permiten la indexacin a texto completo, y en lneas generales realizar bsquedas ms potentes. Tesaurus es un sistema de ndices optimizado para este tipo de bases de datos.

BASES DE DATOS DEDUCTIVAS

Un sistema de base de datos deductiva, es un sistema de base de datos pero con la diferencia de que permite hacer deducciones a travs de inferencias. Se basa principalmente en reglas y hechos que son almacenados en la base de datos. Las bases de datos deductivas son tambin llamadas bases de datos lgicas, a raz de que se basa en lgica matemtica. Este tipo de base de datos surge debido a las limitaciones de la Base de Datos Relacional de responder a consultas recursivas y de deducir relaciones indirectas de los datos almacenados en la base de datos.

LENGUAJE
Utiliza un subconjunto del lenguaje Prolog llamado Datalog el cual es declarativo y permite al ordenador hacer deducciones para contestar a consultas basndose en los hechos y reglas almacenados.

VENTAJAS

Uso de reglas lgicas para expresar las consultas. Permite responder consultas recursivas. Cuenta con negaciones estratificadas Capacidad de obtener nueva informacin a travs de la ya almacenada en la base de datos mediante inferencia. Uso de algoritmos de optimizacin de consultas. Soporta objetos y conjuntos complejos.

DESVENTAJAS

Crear procedimientos eficaces de deduccin para evitar caer en bucles infinitos. Encontrar criterios que decidan la utilizacin de una ley como regla de deduccin. Replantear las convenciones habituales de la base de datos.

FASES

Fase de Interrogacin: se encarga de buscar en la base de datos informaciones deducibles implcitas. Las reglas de esta fase se denominan reglas de derivacin. Fase de Modificacin: se encarga de aadir a la base de datos nuevas informaciones deducibles. Las reglas de esta fase se denominan reglas de generacin.

INTERPRETACIN
Encontramos dos teoras de interpretacin de las bases de datos deductivas:

Teora de Demostracin: consideramos las reglas y los hechos como axiomas.

Los hechos son axiomas base que se consideran como verdaderos y no contienen variables. Las reglas son axiomas deductivos ya que se utilizan para deducir nuevos hechos.

Teora de Modelos: una interpretacin es llamada modelo cuando para un conjunto especfico de reglas, stas se cumplen siempre para esa interpretacin. Consiste en asignar a un predicado todas las combinaciones de valores y argumentos de un dominio de valores

constantes dado. A continuacin se debe verificar si ese predicado es verdadero o falso.

MECANISMOS
Existen dos mecanismos de inferencia:

Ascendente: donde se parte de los hechos y se obtiene nuevos aplicando reglas de inferencia. Descendente: donde se parte del predicado (objetivo de la consulta realizada) e intenta encontrar similitudes entre las variables que nos lleven a hechos correctos almacenados en la base de datos.

GESTIN DE BASES DE DATOS DISTRIBUIDA (SGBD)

La base de datos y el software SGBD pueden estar distribuidos en mltiples sitios conectados por una red. Hay de dos tipos: 1. Distribuidos homogneos: utilizan el mismo SGBD en mltiples sitios. 2. Distribuidos heterogneos: Da lugar a los SGBD federados o sistemas multibase de datos en los que los SGBD participantes tienen cierto grado de autonoma local y tienen acceso a varias bases de datos autnomas preexistentes almacenados en los SGBD, muchos de estos emplean una arquitectura clienteservidor. Estas surgen debido a la existencia fsica de organismos descentralizados. Esto les da la capacidad de unir las bases de datos de cada localidad y acceder as a distintas universidades, sucursales de tiendas, etc.