Repblica Bolivariana de Venezuela Ministerio del Poder Popular para La Educacin Universitaria Universidad Politcnica Territorial del Oeste

de Sucre ClodosbaldoRussin Programa Nacional de Formacin en Informtica Modelado de base de datos

DISEO AVANZADO DE BASES DE DATOS

Profesora: Luisana Parejo Autores: Marcano Jess C.I:18212043 Codino Douglas C.I:19239376

Cuman, octubre del 2013

Introduccin

Para la introduccin a este captulo se toman algunos prrafos del texto de Batini, Ceri y Navathe (1994). "El diseo de bases de datos es el proceso por el que se determina la organizacin de una base de datos, incluidos su estructura, contenido y las aplicaciones que se han de desarrollar. Durante mucho tiempo, el diseo de bases de datos fue considerado una tarea para expertos: ms un arte que una ciencia. Sin embargo, se ha progresado mucho en el diseo de bases de datos y ste se considera ahora una disciplina estable, con mtodos y tcnicas propios. Debido a la creciente aceptacin de las bases de datos por parte de la industria y el gobierno en el plano comercial, y a una variedad de aplicaciones cientficas y tcnicas, el diseo de bases de datos desempea un papel central en el empleo de los recursos de informacin en la mayora de las organizaciones. El diseo de bases de datos ha pasado a constituir parte de la formacin general de los informticos, en el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de programacin convencional." "Las ltimas dos dcadas se han caracterizado por un fuerte crecimiento en el nmero e importancia de las aplicaciones de bases de datos. Las bases de datos son componentes esenciales de los sistemas de informacin, usadas rutinariamente en todos los computadores [...]. El diseo de bases de datos se ha convertido en una actividad popular, desarrollada no slo por profesionales sino tambin por no especialistas. A finales de la dcada de 1960, cuando las bases de datos entraron por primera vez en el mercado del software, los diseadores de bases de datos actuaban como artesanos, con herramientas muy primitivas: diagramas de bloques y estructuras de registros eran los formatos comunes para las especificaciones, y el diseo de bases de datos se confunda frecuentemente con la implantacin de las bases de datos. Esta situacin ahora ha cambiado: los mtodos y modelos de diseo de bases de datos han evolucionado paralelamente con el progreso de la tecnologa en los sistemas de bases de datos. Se ha entrado en la era de los sistemas relacionales de bases de datos, que ofrecen poderosos lenguajes de consulta, herramientas para el desarrollo de aplicaciones e interfaces amables con los usuarios. La tecnologa de bases de datos cuenta ya con un marco terico, que incluye la teora relacional de datos, procesamiento y optimizacin de consultas, control de concurrencia, gestin de transacciones y recuperacin, etc. Segn ha avanzado la tecnologa de bases de datos, as se han desarrollado las metodologas y tcnicas de diseo. Se ha alcanzado un consenso, por ejemplo, sobre la descomposicin del proceso de diseo en fases, sobre los principales objetivos de cada fase y sobre las tcnicas para conseguir estos objetivos."

"Desafortunadamente, las metodologas de diseo de bases de datos no son muy populares; la mayora de las organizaciones y de los diseadores individuales confa muy poco en las metodologas para llevar a cabo el diseo y esto se considera, con frecuencia, una de las principales causas de fracaso en el desarrollo de los sistemas de informacin. Debido a la falta de enfoques estructurados para el diseo de bases de datos, a menudo se subestiman el tiempo o los recursos necesarios para un proyecto de bases de datos, las bases de datos son inadecuadas o ineficientes en relacin a las demandas de la aplicacin, la documentacin es limitada y el mantenimiento es difcil. Muchos de estos problemas se deben a la falta de una claridad que permita entender la naturaleza exacta de los datos, a un nivel conceptual y abstracto. En muchos casos, los datos se describen desde el comienzo del proyecto en trminos de las estructuras finales de almacenamiento; no se da peso a un entendimiento de las propiedades estructurales de los datos que sea independiente de los detalles de la realizacin."

Esquema de una base de datos El esquema de una base de datos (en ingls, Database Schema) describe la estructura de una Base de datos, en un lenguaje formal soportado por un Sistema administrador de Base de datos (DBMS). En una Base de datos Relacional, el Esquema define sus tablas, sus campos en cada tabla y las relaciones entre cada campo y cada tabla. El esquema es generalmente almacenado en un Diccionario de Datos. Aunque es comn que el esquema sea definido en un lenguaje de Base de datos, el trmino se usa a menudo para referirse a una representacin grfica de la estructura de base de datos.

PARADIGMAS DE BASES DE DATOS. * Relacionales, es la base de todo. El modelo ms estudiado, comercializado y utilizado. No por ello el mejor, sino que ciertos aspectos (estar en el momento justo, en el lugar indicado) han hecho que as llegue a ser. En definitiva, actualmente hablar de BD es hablar de BD relacionales. Pero todo est cambiando, sino no escribira este post realmente. Si no sabes qu es el modelo relacional, significa que no sabes que es una BD, por lo que no creo que entiendas el resto de cosas que voy a contar y no se ni para que me lees este tochaco, pero bueno. * Orientadas a objeto, si todas nuestras aplicaciones son con objetos, es tontera querer mantener el modelo relacional por debajo, no? Existen diferentes ORM que permiten solventar ese inmenso puente entre un modelo de objetos y el modelo relacional, pero si podemos prescindir de l, qu mejor que nuestro SGBD nos entienda directamente y nos guarde objetos directamente? Hay ciertas cosas bastante llamativas en una BDOO, como que no es necesario tener claves primarias, o las claves ajenas en verdad ahora son referencias. Se podra hablar mucho sobre este tema, pero resumiendo una BDOO son simplemente nuestros objetos hechos persistentes. * Activas, una SGBD activo es aquel, que bajo ciertas condiciones, y de manera automtica ejecuta acciones anteriormente especificadas, todo ello sin intervencin del usuario. Es decir una especie de BD + super-triggers (BD relacional con triggers no es una BD activa). Se puede subdividir en dos modelos que lo constituyen: * Modelo del conocimiento: especifica las reglas del sistema, en resumen seran tuplas (Evento, Condicin, Accin).

* Modelo de ejecucin: se encarga de realizar un seguimiento de la situacin y de gestionar el comportamiento. Vamos, el jefe que dice qu hacer y cmo.

Estrategias de Dise o Conceptual

El dise o conceptual de una base de datos es un proceso iterativo de refinamientos sucesivos. Los fundamentos de una metodolog a de dise o consisten de primitivas de refinamiento del dise o y estrategias de dise o. Dentro de las primitivas tenemos dos grupos: las top-Down (son 8) y las botn-up (son 5). Los conjuntos de primitivas pueden tener algunas propiedades deseables como lo son la completitud y la nominalidad. En cuanto a las estrategias, tenemos cuatro: top-Down, botn-up, por conceptos centrales (de adentro hacia afuera) y mixta. (Ver copias del libro BCN 92 para los detalles.) Adicionalmente, el modelo ERE ofrece algunas heur sticas de dise o, para decidir entre las siguientes alternativas: Entidad o Atributo? En el ejemplo de la empresa de servicios el ctricos, el titular de pago puede representarse como un atributo del contrato de servicios o como una entidad asociada al contrato. Generalizacion o Atributo ? Si en el ejemplo anterior se decide representar al titular de pago como una entidad, entonces para indicar que los titulares de pago pueden ser una persona natural o una persona jur dica, se puede utilizar una generalizaci n o simplemente colocar un atributo que indique el tipo de titular de pago en esa entidad. Atributo compuesto o Conjunto de atributos simples? Entidad o Interrelacion ? Si el concepto a representar es un concepto muy importante en el esquema y va a estar relacionado con otros conceptos, es preferible representarlo como una entidad. La nocin de pago, por ejemplo, puede ser la interrelaci n entre un cliente y un producto o puede ser una entidad que se asocia con el cliente, pues es quien paga y se asocia con el producto pues es lo que se estpagando.

Los creadores de la metodolog a OMT tambi n dan algunas sugerencias para construir el modelo de datos. Estas son:

1. No se deben escribir clases, asociaciones y herencia a lo lo co. Primero hay que entender el problema y el contenido del modelo de objetos se obtiene de acuerdo a la relevancia en la solucin al problema. 2. Haga un modelo simple, evite complicaciones innecesarias. 3. Elija nombres apropiados con mucho cuidado. Los nombres tienen una poderosa carga de connotaciones impl citas para cada quien que los lee. (Este es uno de los aspectos ms dif ciles de lograr.) 4. No esconda las referencias a otros objetos en apuntadores. Modele estas referencias con asociaciones. 5. No trate de colocar las cordialidades perfectas muy temprano. 6. No coloque los atributos de la asociacin en una de las clases. 7. Use asociaciones calificadas cuando sea posible. 8. Construir un modelo de objetos correcto, requiere de revisiones y de varias iteraciones, nunca sale bien a la primera. 9. Trate de que otros revisen su modelo. 10. Documente siempre su modelo de objetos, no basta con el diagrama. Hace falta una gua del modelo y la explicacin de porque se tomaron ciertas decisiones. Estas explicaciones clarifican el modelo. 11. No sienta que debe usar todas las primitivas de modelacin de objetos. No todos los problemas las necesitan todas. Use solo lo que necesite y haga a su modelo expresivo y auto explicativo,

Modelo Conceptual Unificado Las tcnicas OO utilizan los mismos modelos conceptuales para el anlisis, diseo y construccin. La tecnologa de las BDOO da un paso ms hacia la unificacin, el modelo conceptual de la base de datos OO es igual al del resto del mundo OO, en lugar de utilizar tablas por relacin independientes como SQL. El uso del mismo modelo conceptual para todos los aspectos del desarrollo simplifica ste, particularmente con las herramientas CASE OO; mejora la comunicacin entre usuarios, analistas y programadores, adems de que reduce las posibilidades de error. Estrategias para desarrollar una base de datos objeto-relacional Varios proveedores de bases de datos relacionales estn intentando desarrollar una solucin objeto-relacional. Las distintas estrategias que utiliza cada proveedor tienen sus ventajas y sus inconvenientes. Las estrategias bsicas son las siguientes: a. Unir un gestor objeto-relacionales ya existente a un gestor relacional b. Escribir un nuevo gestor a partir de cero c. Perfeccionar iterativamente un gestor existente mediante la incorporacin de nuevas funciones d. Unin de dos productos e. El intento de integracin de dos productos existentes ofrece la ventaja de aportar una solucin rpida a corto plazo. Se puede crear rpidamente un pasaje entre los dos gestores para permitir un acceso transparente entre ambos servidores. Sin embargo, un gestor unido a otro equivale a construir un puente entre un automvil y una embarcacin, esperando que ambos puedan interactuar. Por una parte, existe la funcionalidad de ambos gestores, pero por otra, slo se puede utilizar eficazmente uno al mismo tiempo. f. Se necesitarn varios aos de integracin antes de que los dos servidores puedan utilizar eficazmente su funcionalidad respectiva a un nivel aceptable de rendimiento. Este enfoque tiene una alta probabilidad de "romper" las aplicaciones existentes diseadas para funcionar con uno de los dos productos. g. Escribir un gestor a partir de cero h. La creacin de un gestor objeto-relacional completamente nuevo ofrece el atractivo de una solucin elegante y a medida. Naturalmente, para escribir

i.

un gestor de base de datos se necesitan varios aos de trabajo de desarrollo y esta opcin no resulta atractiva por este motivo. Perfeccionar un servidor de base de datos relacional ya existente Esta solucin ofrece ventajas ms claras. La tecnologa existente de las bases de datos relacionales se puede potenciar de forma evolutiva para aplicaciones existentes que dependen del almacenamiento relacional. Es por eso que las aplicaciones existentes pueden coexistir con nuevas aplicaciones orientadas a objetos. Adems, las nuevas representaciones de objetos pueden aprovechar y utilizar la fiabilidad, escalabilidad, seguridad y optimizacin de consultas que ya estn incorporadas al servidor de base de datos.

La migracin evolutiva de un sistema existente es la opcin ms segura. Aunque este enfoque es el preferido y ofrece muchas ventajas, tiene un inconveniente: para conseguirlo se necesitan varios aos y varias iteraciones de producto. Oracle lleva trabajando desde 1992 para definir e implantar una funcionalidad de objetos e integrarla en los productos Oracle Server, y seguir refinando el proceso de diseo en las prximas versiones de Oracle Server para perfeccionar los requisitos de una base de datos objeto-relaciona.

Esquema Conceptual El primer paso en el diseo de una base de datos es la produccin del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los usuarios tienen de la informacin. Cada una de estas visiones suelen corresponder a las diferentes reas funcionales de la empresa como, por ejemplo, produccin, ventas, recursos humanos, etc. Estas visiones de la informacin, denominadas vistas, se pueden identificar de varias formas. Una opcin consiste en examinar los diagramas de flujo de datos, que se pueden haber producido previamente, para identificar cada una de las reas funcionales. La otra opcin consiste en entrevistar a los usuarios, examinar los procedimientos, los informes y los formularios, y tambin observar el funcionamiento de la empresa. A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina esquemas conceptuales locales. Cada uno de estos esquemas se compone de entidades, relaciones, atributos, dominios de atributos e

identificadores. El esquema conceptual tambin tendr una documentacin, que se ir produciendo durante su desarrollo. Las tareas a realizar en el diseo conceptual son las siguientes: 1. 2. 3. 4. 5. 6. 7. 8. Identificar las entidades. Identificar las relaciones. Identificar los atributos y asociarlos a entidades y relaciones. Determinar los dominios de los atributos. Determinar los identificadores. Determinar las jerarquas de generalizacin (si las hay). Dibujar el diagrama entidad-relacin. Revisar el esquema conceptual local con el usuario.

La Tecnologa Objeto Relacional Motivacin La introduccin a esta tpico poda haber sido la introduccin a esta materia, pues en ella vamos a motivar la necesidad de modelar datos complejos que requieren de otros paradigmas de modelaje. Sin embargo, el curso esta naturalmente dividido en dos partes, por un lado los aspectos metodolgicos del modelaje conceptual donde se hace nfasis en esa etapa del diseo de una base de datos, y por el otro la tecnologa que puede apoyar la implementacin del esquema conceptual. El modelo relacional ha sido suficiente para las aplicaciones tradicionales comerciales o de negocios, estas aplicaciones se caracterizan por manejar datos muy simples en grandes volmenes. Datos simples generalmente se refieren a datos alfanumricos que, con bastante precisin y facilidad, pueden ser representados en un computador. Estas aplicaciones han evolucionado en cuanto a sus necesidades de manipulacin, y de almacenamiento y anal- si de datos histricos en lo que se ha denominado data warehouses y OLAP (o nline analytical processing).

Supongamos una aplicacin donde se quieren llevar las historias mdicas de los paz- cientos de una clnica o de un centro integral de medicina. Si se quieren almacenar datos alfanumricos de los pacientes, como por ejemplo, sus datos personales, lista de las alergias que sufre, historia familiar de enfermedades, tratamientos quirrgicos recibidos, y resulta- dos de exmenes de sangre, el modelo ER-E es suficiente, y el esquema conceptual se puede implementar eficientemente en un manejador que siga el modelo relacional. Sin embargo, si la historia mdica incluye tambin: imgenes de resonancia magntica de la rodilla del paciente, video de alguna operacin, fotos de algn rgano o de los cromosomas encontrados como resultado de una amniocentesis, con anotaciones de los mdicos, los modelos ER-E y OMT dejan de ser suficientemente expresivos, y el modelo relacional es completamente inconveniente, pues no tiene estructura ni operaciones apropiadas para manejar esos datos. Existen muchas aplicaciones con necesidades similares a la aplicacin medica descrita anteriormente, por ejemplo, las de CAD/CAM, los sistemas de informacin geogrficos, las bases de datos multimedia, entre otras. Una primera aproximacin a este problema fue la de extender el modelo relacional (en teora) para dar cabida a estos nuevos datos y sus necesidades de manipulacin, lo cual dio lugar a las bases de datos extensibles, que planteaban modelos con extensiones al relacional para albergar otros tipos de datos y sus operaciones. Una de las primeras imple- tentaciones de estas ideas fue el manejador Postres (Stonebraker 1987), el cual todava existe, con el nuevo nombre de PostgresSQL y es uno de los productos de software libre ms robustos en el rea de base de datos. En paralelo, estaban los investigadores del rea de orientacin por objetos definiendo las bases de datos orientadas por objeto, pues el paradigma de OO es naturalmente extensible, y con ello se podan representar esos datos e incluir sus operaciones encapsuladas en la misma nocin de objeto. De estos esfuerzos nacieron varias generaciones de software para manejar bases de datos orientadas por objeto, conocidos como OODBMS. Otra corriente de pensamiento, propuso liberar al modelo relacional de la restriccin de que los dominios de los atributos fuesen atmicos, con lo cual las relaciones no tenan que estar en 1NF (primera forma normal) y se llamaron non-fiesta normal forma relaciones o NFNF o N F 2. Llevando esta nocin hasta el extremo, se poda definir una tabla con atributos cuyos valores pudieran ser tablas completas. Por ejemplo, se puede definir una tabla

DEPARTAMENTO con cinco atributos: cdigo-D, nombre-D, jefe-D, Empleados y Proyectos, donde el atributo Empleados toma como valores, tablas con dos atributos nombre y direccin del empleado, y el atributo Proyectos es otra tabla, con atributos nombre- Proyecto y presupuesto. Las bases de datos extensibles evolucionaron en lo que hoy en da se llama la tecnologa objeto relacional (OR) (object-relational), en la cual se combinan las nociones de extensibilidad, orientacin por objetos, y en algunos casos hasta tablas anidadas. En este curso vamos a hacer una breve revisin histrica de los avances que dieron lugar a la tecnologa OR y nos concentramos en esa tecnologa para implementar nuestros esquemas conceptuales, como una alternativa actual, prctica y valida al uso de un OODBMS.

Definiciones El paradigma de orientacin por objetos se desarroll en las reas de lenguajes de pro- grabacin e ingeniera de software. En un lenguaje de programacin orientado por objetos, los objetos existen solo durante la ejecucin del programa que los crea. Por otro lado, en una base de datos orientada por objetos, los objetos se crean, pueden ser persistentes y se pueden compartir entre varios programas. Por lo tanto, las bases de datos orientadas por o- jeto almacenan objetos persistentes en almacenamiento secundario y soportan el compartir objetos entre diferentes aplicaciones. Los OODBMS son el resultado de integrar la tecnologa de base de datos con l para- digna OO. Para soportar los objetos persistentes hace falta agregarle a este paradigma, mecanismos de manejador de base de datos, como por ejemplo, indizacin de los datos, control de concurrencia y manejo de transacciones. Desde finales de la dcada de las 80 se han construido OODBMS, en muy pocos aos se desarrollaron tres generaciones de estos productos. La primera generacin de OODBMS data de 1986, cuando la empresa francesa Raphael introdujo G-Base al mercado. En 1987, la campan ya estadounidense Serbio Corporacin introdujo Festone. En 1988, Ontolgica introdujo Base y Simbolices introdujo Estatice. El objetivo comn de todos estos desarrollos era darle persistencia a los lenguajes de objetos utilizados en inteligencia artificial.

Estos eran sistemas independientes, basados en lenguajes propietarios, que no usaban ninguna plataforma industrial estndar. Los sistemas construidos con estos productos residan en los departamentos de investigacin de grandes empresas y se construyeron unos 500. La segunda generacin de OODBMS comenz en 1989 con la liberacin del producto Untos por la empresa del mismo nombre. A Untos le siguieron los productos: ObjectStore (de Object Design), Objectivity/DB (de Objectivity), y Versant ODBMS (de Versant Object Technology). Estos sistemas ya usaban la arquitectura de cliente/servidor y tenan una plataforma comn: C++, X Windows y estaciones UNIX. Atasca fue el primer producto de la tercera generacin de OODBMS y fue liberado en Agosto de 1990 (apenas unos meses despus de los productos de la segunda generacin). Este producto era la versin comercial de Orin, proyecto de MCC (Microelectrnicas and Competer Corporacin), instituto de investigacin financiado por empresas estadounidenses fabricantes de hardware. Los otros productos de esta generacin eran O2, producido por la empresa francesa Altar, y Sitges, desarrollado internamente por Texas Instruments. Los productos de la tercera generacin de OODBMS tenan caractersticas ms van- zedas y tenan lenguajes de definicin y manipulacin de datos que eran orientados por objetos y computacionalmente completos. En este ambiente, de desarrollo de muchos sistemas por parte de empresas pequeas, estos sistemas fueron revolucionarios con respecto a los DBMSs existentes, pues se construyeron desde cero con una base muy diferente y con modelos de datos distintos. En este momento se sinti la necesidad de por lo menos definir lo que era un OODBMS y Atkinson en 1989 escribi lo que se llam el Manifiesto de los Sistemas de Base de Datos Orientados por Objeto, el cual describa lo que eran las caractersticas principales de un sistema para poder calificar como OODBMS. Otras particularidades de esta poca eran: que estos sistemas no tenan un modelo de da- tos comn y se haban utilizado solo en aplicaciones experimentales. La falta de un estndar para las base de datos de objetos era una limitante muy importante de su aceptacin en el mercado y por otro lado, uno de los secretos de los RDBMS era precisamente la existen- cita de un estndar. Como respuesta a ello, en el verano de 1991 se forma ODMG (Objeto Databas Management Grupo) un consorcio de empresas (casi todas las que desarrollaban OODBMS), para tratar de proveer un estndar. ODMG estaba

afiliado al OMG (Objeto Management Grupo), establecido en 1989 y cuya principal contribucin era la arquitectura CORBA para la interoperabilidad de sistemas distribuidos de objetos. ODMG produjo los primeros estndares en 1993, ellos fueron: ODMG Objeto modelo, que define el modelo de datos de las bases de datos orientadas por objetos; ODL (Objeto Definicin Lenguaje) que es el DDL para definir un esquema en este modelo de datos; OQL (Objeto Quera Lengua- ge) que es un lenguaje declarativo, inspirado en SQL, para hacer la correspondencia entre los conceptos del modelo de datos para OODB y los lenguajes considerados en el estndar y para definir como los objetos de ODMG podan ser acusados y manipulados por estos lenguajes (C++, Smalltalk, LISP, Java).

A continuacin listamos mercado.

ordenadamente los OODBMS

ms importantes del

ORION/Atasca (nombre de la versin comercial a partir de 1990) MCC Austin, Texas. Won Kim lo desarrollo, el primer producto se construy desde 1985 hasta 1989. Se han desarrollado tres generaciones de este producto.

O2 (Consorcio Altar, 1986-1991) Esta descrito en un libro: Te Storey of O2 (Bancaron 1992). Hacan ms nfasis en los lenguajes de programacin que en la arquitectura.

Festone (1987) Es el producto comercial ms antiguo que est disponible hoy en da. Extiende Suma- letal en un sistema de base de datos. Ha sido el ms visible de todos, hoy existen dos versiones Festone/S (versin Smalltalk) y Festone/J (versin Java).

IRIS/Open (1989)

Prototipo de investigacin de HP, sigue el modelo funcional.

Base/Untos (1988) De lenguajes propietarios pasaron a C++. Es totalmente distribuido.

ObjectStore (1989) Tiene soporte para documentos XML.

POET (1999) C++ y Java. Con su Content Management Suite soporta documentos XML y SGML. Los conceptos fundamentales del paradigma de orientacin por objetos son:

Objetos OID (object id). Igualdad por identidad (idnticos): si son el mismo objeto, es decir, tienen el mismo identificador. Igualdad por valor (iguales): dos objetos son iguales si sus estados son recursivamente iguales. Estado de un objeto: valores de las propiedades del objeto, pueden cambiar en el tiempo. Propiedades: atributos e interrelaciones con otros objetos.

Comportamiento: especificado por las operaciones que pueden ser ejecutadas por el objeto o sobre el objeto, y posiblemente actan sobre el estado del objeto.

Clases: todos los objetos del mismo tipo tienen el mismo conjunto de propiedades y de operaciones. Un tipo de objeto se define a travs de una clase. Extinta de una clase: todos los objetos que pertenecen a ella.

Herencia: por subtipos, por implementacin y por inclusin.

Manejadores Objeto Relacionales A diferencia de los OOBDMS que tienen un enfoque revolucionario, los Manejadores de Base de Datos Objeto Relacionales (ORDBMS) son una evolucin de los RDBMS, pues integran los objetos al modelo de datos relacional y extienden los RDBMS existentes con caractersticas del paradigma orientado por objetos. A principios de los 90, los dos enfoques entraron en conflicto, los OO puros proponan extensiones a los lenguajes de programa- con OO, y los del otro bando, el enfoque hibrido, proponan partir de las bases de datos relacionales y agregarle extensiones OO. La idea de los ORDBMS data de 1990 con la publicacin del Tirad Generacin Databas Sistema Manifest de Stonebraker. La premisa bsica de este manifiesto es que la nueva (tercera) generacin de manejadores de base de datos, deberan poder manejar objetos y reglas, y deberan ser compatibles con los manejadores de la segunda generacin, es decir, los relacionales. Por ese mismo ao, Anisal, Inc., fundada por Won Kim, produjo un manejador objeto relacional, el Anisal, que usaba SQL/X, una extensin de SQL-92 como lenguaje de base de datos. Durante esa dcada, otras empresas que se iniciaban, desarrollaron productos objeto relacionales, como Ilustra y Omnisciente. Ya para 1996, Informe compra Ilustra y todos los grandes productores de manejadores de base de datos, a saber, Sbase, IBM y Oracle, comenzaron a trabajar en productos objeto relacionales. Ese mismo ao se logr un consenso en cuanto a las particularidades del modelo objeto relacional que se plasmaron en el estndar SQL-3 y todos los actores en el mundo de base de datos, lo adoptaron, cada uno de ellos ha liberado su producto objeto relacional. Los sistemas OR son relacionales porque soportan SQL, y son OO porque soportan datos complejos. Si consideramos la complejidad en los datos y la complejidad en las consultas y las combinamos en dos ejes perpendiculares,

obtenemos una matriz Stonebraker 1999)

con cuatro

cuadrantes, a saber: (Nvate 2000 y

(I) datos simples, consultas simples (editores de texto, hojas de clculo estilo Excel, file sistema). (II) datos simples, consultas complejas (RDBMS). (III) datos complejos, consultas simples (algunos OODBMS, Choros, sistema de procesa- miento de imgenes). (IV) datos complejos, consultas complejas (ORDBMS). Al final de la dcada de los 90, los OODBMS y los ORDBMS dejaron de estar en conflicto, cuando mejoraron las funciones de DBMS ofrecidas por los OODBMS y mejoraron sus facilidades para soportar un lenguaje de consulta declarativo (con la definicin de OQL que es muy parecido a SQL-3). Las principales diferencias en estos productos actualmente se concentran en los siguientes aspectos: Los OODBMS proveen persistencia para los objetos creados con los lenguajes OO, como Java, C++ y Smalltalk; los programadores definen clases y crean objetos de esas clases, y con los mecanismos de DBMS que tienen, permiten almacenar estos objetos y compartirlos, por lo tanto, la integracin con estos lenguajes es transparente. Sin embargo, en los ORDBMS se introduce un API separado (basado en SQL) para manipular los datos almacenados, las definiciones de clase se deben mapear a los tipos de datos soportados por el sistema de base de datos. A nivel de arquitectura, los OODBMS estn centrados en los clientes, manejan un cache de objetos en las maquinas cliente y permiten la navegacin entre objetos relacionados, lo cual es muy apropiado para ciertas aplicaciones. Por otro lado, los ORDBMS tienen un enfoque ms centrado en el servidor, lo cual es ms apropiado para satisfacer muchas consultas concurrentes a los datos.

En esencia, los conceptos de la tecnologa objeto relacional son: Tipos abstractos de datos (Tas), definidos por el usuario.

Tipos complejos (o estructurados, o agregados), definidos en base a los tipos atmicos con la utilizacin de constructores de tipo para crear: conjuntos, tupas, arreglos, secuencias, entre otros. Herencia: definicin de tipos de datos como subtipos de otros. Tipos referencia. Apuntadores a objetos de otro tipo. Blobs (eran lo nico que tenan los RDBMS). Estos nuevos tipos de datos, necesitan nuevas funciones de manipulacin. Estas funciones son: Mtodos definidos por el usuario: mtodos asociados a los Tas. Operadores para los tipos complejos (estructurados o agregados): por ejemplo, el con- tractor conjunto tiene los mtodos: pertenece-a, subconjunto de, igualdad de conjunto- tos, interseccin, unin y diferencia de conjuntos.

Conclusin

El diseo de bases de datos se descompone en tres etapas: diseo conceptual, diseo lgico y diseo fsico. El diseo conceptual es el proceso por el cual se construye un modelo de la informacin que se utiliza en una empresa u organizacin, independientemente del SGBD que se vaya a utilizar para implementar el sistema y de los equipos informticos o cualquier otra consideracin fsica. Un modelo conceptual es un conjunto de conceptos que permiten describir la realidad mediante representaciones lingsticas y grficas. Los modelos conceptuales deben poseer una serie de propiedades: expresividad, simplicidad, minimalidad y formalidad. El modelo conceptual ms utilizado es el modelo entidad-relacin, que posee los siguientes conceptos: entidades, relaciones, atributos, dominios de atributos, identificadores y jerarquas de generalizacin. En la metodologa del diseo conceptual se construye un esquema conceptual local para cada vista de cada usuario o grupo de usuarios. En el diseo lgico se obtiene un esquema lgico local para cada esquema conceptual local. Estos esquemas lgicos se integran despus para formar un esquema lgico global que represente todas las vistas de los distintos usuarios de la empresa. Por ltimo, en el diseo fsico, se construye la implementacin de la base de datos sobre un SGBD determinado. Ya que este diseo debe adaptarse al SGBD, es posible que haya que introducir cambios en el esquema lgico para mejorar las prestaciones a nivel fsico. Cada vista de usuario comprende los datos que un usuario maneja para llevar a cabo una determinada tarea. Normalmente, estas vistas corresponden a las distintas reas funcionales de la empresa, y se pueden identificar examinando los diagramas de flujo de datos o entrevistando a los usuarios, examinando los

procedimientos, informes y formularios, y observando el funcionamiento de la empresa. Cada esquema conceptual local est formado por entidades, relaciones, atributos, dominios de atributos, identificadores y puede haber tambin jerarquas de generalizacin. Adems, estos esquemas se completan documentndolos en el diccionario de datos. Bibliografa

Los aspectos sobre el modelo entidad-relacin en donde se incorporan caractersticas del modelo entidad-relacin extendido, como las jerarquas de generalizacin, se tratan muy bien en los textos de Batini, Ceri y Navathe (1994) y Connolly, Begg y Strachan (1996). Estos ltimos son los que mejor presentan la metodologa del diseo conceptual, proporcionando todo tipo de "trucos" para identificar cada uno de los componentes de un esquema conceptual. Paradigmas de Modelado de Base de Datos I. CI5311. Apuntes de clase Prof. Soraya Abad Mota Consultas por Internet: Universidad de Oviedo. Desarrollo de SGBDOO en Oviedo3 www.Uniovi.es/~oviedo3/belen/jindbd96.html.6/Nov/1999 Boletn Informtico. Panorama de las DBOO http://www.uaemex.mx/publica/informatia/boletin/panorama.html 3/Nov/99 Infoseek. "Trabajos relacionados" http://www.infoseek.com 26/Dic/99 Manifesto de Atkinson . "Sistemas manejadores de bases de datos OO" http://www.cs.cmu.edu/afs/cs.cmu.edu/user/clamen/OODBMS/Manifesto/htM anifesto/Manifesto.html10/Dic/99

Leer ms: http://www.monografias.com/trabajos5/tipbases/tipbases.shtml#ixzz2hlxYNY 00