Está en la página 1de 40
Unidad 4. Nuevas tendencias. Las bases de datos relacionales se han establecido como el principal modelo de datos implementado para aplicaciones comerciales; sin embargo, no es el Unico modelo existente en el érea de las bases de datos. Los problemas de datos en informacién del mundo real actual tienden a ser complejos. Los requerimientos de informacién son mas extensos € incluyen el uso de tipos de datos tales como genes, sonido y video. El ambiente de datos complejo conduce 2 la busqueda de modelos de datos diferentes que faciliten el disefio, la administracién y la ejecucién El auge que he tenido internet y las nuevas opciones de almacenamiento € interconexién de banda ancha han generado nuevas expectativas en la forma de acceder a los datos. Una de las tendencias mas marcadas en la industria informética es el aumento de aplicaciones que necesitan acceder a diferentes fuentes de datos que a menudo se encuentran remotamente y que debe ser transparente a la aplicacién. 4. Bases de datos distribuidas. Un sistema de base de datos distribuida consiste en una coleccién de | sitios, conectados por medio de un tipo de red de comunicacién, en el cual | cada sitio es un sistema de base completo. En éste los sitios han cecidido trabajar juntos a fin de que un usuario de cualquier sitio pueda acceder a los datos desde cualquier lugar de la red, exactamente como si lo datos estuvieran guardados en el propio sitio del usuario. En otras palabras, una base de datos distribuida es una coleccién de datos que pertenece légicamente a! mismo sistema, pero que esta dispersa fisicamente entre los sitios de una red de computadoras. A diferencia de los sistemas paralelos, en los que los procesadores se hallan estrechamente acoplados y constituyen un Unico sistema de bases ce datos, los sistemas los de bases de datos consisten en sitios que no comparten ningun componente fisico. Cada sitio puede participar en la ejecucién de transaccionas que tienen acceso a los datos de uno o varios de los sitios. La diferencia principal entre jos sistemas de bases de datos centralizados y los distribuidos es que, en los primeros, los datos residen en una Gnica ubicacién, mientras que en los segundos los datos residen en varias ubicaciones. En un sistema distribuido de bases de datos se almacena la base en datos en varias computadoras. varios medios de comunicacién, como las redes de alta velocidad o las lineas telefénicas, son lo que pueden poner en contacto las distintas computadores en un sistema distribuido. No comparten ni memoria ni discos. Les computadores de un sistema distribuido pueden variar en tamafo y funclén pudiendo abarcar desde las estaciones de trabajo a los grandes sistemas. Las principales diferencias entre las bases de datos paralelas sin compartimientos y las bases de datos distribuidas son las que las bases de datos distribuidas normalmente se encuentran en varios lugares geograficos distintos, se administran de forma separada y poseen una interconexién més lenta. Otra gran diferencia es que en un sistema distribuido se dan dos tipos de transacciones las locales y las globales. Una transaccién local es aquella que accedes a los datos del Unico sitio en el cual se inicié la transaccién. Por otra Parte, una transaccién global ¢s aquella que, o bien accede @ los datos situados en un sitio diferente de aquel en el que se inicio la transaccién, o bien accede a datos de varios sitios distintos. Esquema general de las bases de datos distribuidas. Cade sitio es un sitio de sistema de bases de datos por derecho propio. En otras palabras, cada sitio tiene sus propias bases de datos “reales”, sus proplos usuarios locales, su propio DBMS local y software de administracion de transacciones, asi como su propio administrador de comunicacién de datos local. Un usuario determinado puede realizar operaciones sobre los datos desde su propio. sitio local, tal como si ese sitio nunca participara en el sistema dlistribuido, El sistema de base de datos distribuida puede ser considerado como un tipo de sociedad entre los DBMS locales en cada uno de los sitios locales; un nuevo. componente de software en cada sitio proporciona la funcionalidad de sociedad necesaria y es la combinacién de este nuevo componente y €l DBMS existente, Jo que constituye el sistema de administracién de base de datos distribulda La “regla cero de los sistemas distribuidos”, el cual conduce a 12 reglas secundarias 3 . o ites oe La “regla cero de los sistemas distribuldos”, el cual conduce a 12 reglas secundarias foe fae “ 44s & ‘ve on 4 ne woe 5 oe + oe h "% +e Autonomia local. Las localidades deben ser auténomas; es decir, que todas las operaciones realizadas en una localidad sean controladas en esta misma localidad. Es necesario sefialar que una localidad no puede ser totalmente auténoma, ya que existen varias situaciones en las cuales una de ellas debe ceder el control 2 otra, perdiendo ast parte de su autonomi No dependencia de una localidad central. Este principio es un corolario del primero, Es indeseable la dependencia de una localided central por dos razones: primero, el sistema seria vulnerable si la localidad central sufriré un desperfecto, y segundo, la localidad central llegaria a ser un cuello de botella. Operacién continua. Se refiere ‘a que el sistema nunca deberé necesitar suspenderse para realizar alguna funcén como se puede afiadir una nueva localidad 0 instalar la versi6n mejorada del sistema administrador de base de datos. Es decir, el sistema deberé mantener su funcionamiento de manere constant or ‘Transparencia de localizacion. Para los usuarios, el sistema deberd comportarse como si todos los datos estuvieran almacenados en Su propia localidad, esto simplifica la realizacién del trabajo a los usuarios, ya que no requieren conocer diinde se encuentran almacenados fisicamente los datos. : + oe: Sos ou Independencia con respecto a la fragmentacion. L2 fragmentacién se refiere ala divisién fisica de los datos de una tabla, la cual es deseable por razones de desempefio, del tal forma que los datos pueden almacenarse en la localidad donde sean més utilizados, con el fin de reducit el tréfico de la red y proporcionar una mejor servicio de acceso a la informacién. edererceperenecs'aer cence crete en que, desde el punto de vista del Ratan a lnforrst lig satereert ra mals aoa de aatastcn asta (orsefen od peuiice a teat Helge lens eae! importante, ya que ia aplicaciones (ee aon era ec anole eh ver de tener que comunicarse con localiades remotas, mejorando la cisponiilded de la informacion. La | Gesventaja principal de las réplicas | consisten en que al realizar una transaccién en una de ellas, ésta Gebers actualizarse en todas las demas réplicas. Procesamiento distribuido de consultas, Le realizacién de consultas en una base de datos ida implica la transmisién de mensajes entre las localidades. La optimizacién del procesarniento distribuide de consultas se ve afectada por la manera como los datos con transmitidos desde una Jocalidad inicial 2 una localidad final. 8 Manejo distribuide de transacciones. =| manejo de ‘transacciones cuenta con dos aspectos principales: el control de recuperacién y control de concurrencia, En el control de recuperacién, para asegurarse de la atomicidad de una transaccién, el sistema deberd verificar que todas las, operaciones corraspondientes a esta transaccién se comprometen (realicen commit), © bien retrocedan (realicen rollback) a un mismo tiempo; esto se lleva a cabo mediante el protocolo de ‘commit de dos fases. El control de concurrencia se realiza mediante la uitilizacién de bloqueos. e - Independencia con respecto al equipo. Debido a la gran variedad de equipos que existen, es conveniente poder intagrar los datos en diferentes equipos y lograr que el usuario vea la Informacién como si fuera un solo conjunto de datos almacenado en una misma localidad. Esto se logra al ejecutar el mismo sistema administrador de base de datos en diferentes equipos. 10 + Independencia con respecto al sistema operativo. Asi como existe una gran variedad de equipos, también existen en el mercado diversos sistemas operativos, por lo cual este principio sefiala la importancia de ejecutar el mismo sistema administrador de base de datos en diferentes sistemas operativos. J Independencia con respecto @ —:2!a red. Si es posible que el sistema funcione con equips diferentes, sistemas operativos diversos y multiples By fs i tee localidedes, también es Ap conveniente poder manejar en varias redes de comunicacién distintas. La red de = comunicacién utilizada influird eee . we si et tn eae ze | en la velocidad en que los tes | Ss page datos sean transmitidos, por lo ee esl bbe Me tanto, resulta importante eleir el medio de cornunicacién mas Sptimo, oe Independencia con respecto al sistema administrador de la base de datos. En un sistema de base de datos distribuida, no es necesario contar con el mismo sistema administrador de bases de datos, solo es necesario contar con la misma interfaz. Un sistema | distribuido Ideal deoerd cumplir este principio. 444 Arquitectura de las bases de datos distribuidas. Précticamente todos les grandes sistemas informaticos son en la actualidad sistemas distribuidos. Un sistema distribuido es un sistema en el que el procesamiento de informacién se distribuye sobre varias computadoras en vez de estar confinado en tuna ‘inca méquina. La ingeniera de sistemas distribuicos tiene mucho en comin con la ingenieria de cualquier otro software, pero existen cuestionas especticas que deben tenerse en cuenta cuando se disefia este tipo de sistemas. Ei reto pera el disefio es disefiar e software y hardware para proporcionar caracteristicas deseables a los sistemas distnibuidos y, al mismo tiempo, minimizar los problemes inherentes @ estos sistemas, Existen dos tipos cenéricos de arquitecturas de sistemas distribuidos: En esta aproximacién, el sistema puede ser visto como un conjunto de servicios que proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sisternas. En este caso, no hay distincién entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interacconan cuya localizaciin es irrelevante. No hay distincién entre un proveedor de servicios y el usuario de estos servicios. Los componentes en un sistema distribuido pueden implementarse en diferentes. lenguajes de pragramaciin y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la reoresentacién de la informacion y los protocolos de comunicacién pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asequrar que dichas partes se puedan comunicar ¢ intercambior datos. | término middleware se usa pare hacer referencia @ ese software; se sitda en medio de los diferentes componentes distribuidos del sistema, @ Arauitecturas cliente-servidor En una arquitectura cliente-servidor, una aplicacién se modela como un conjunto de servicios proporcionados por los servidores y un conjunto de clientes que usan estos servicios. Los clientes necesitan conocer qué servidores estén disponibles, pero normalmente no conocen la existencia de otros clientes. ae - Proceso Servidor eo S&S 2 Sistema cliente - servidor. Varios procesos servidores pueden ejecutarse sobre un dinico procesador servidor; por lo tanto, no hay necesariamente una correspondencia 1:1 entre procesos y procesadores en el sistema. Cuando se hace referencia a clientes y servidores, se refiere a los procesos ldgicos en vez de computadoras fisicas sobre las que se ejecutan. ci 2. 3,04 a Ordenador 869 52 ‘Computadoras en una red cliente ~ servidor El disefio de sistemas cliente-servidor deberia refiejar la estructura légica de la aplicecién que se esti desarrollando. Existen 3 eapas de aplicacién, las cuales sor La capa de presentacion. Estd relecionada con la presentacién de la Informacién al usuario y con toda la interaccin con él. Capas de las aplicaciones La capa de procesamiento La capa de gestion de datos. de la aplicacién. Esté relacionada con todas Esté relacionada con la las operaciones sobre le base implementacién de la ligica de datos. de la aplicacién. En jos sistemas centralizados, no es necesario que estas capas estén caramente separadas. Sin embargo, cuando se esta disefiando un sistema distribuido, deberia hacerse una Cara distincién enve ellas, de forma que sea posible distribuir cada cepa sobre una computadora diferente. la arquitectura cliente-servidor_maés simple se denomina _arquitectura cliente-servidor de dos capas, en la que una aplicacién se organiza como un servidor y un conjunto de clientes. Las arquitecturas clente-servidor de dos capas pueden ser de dos tipos: L7 Bs Es un modelo de cliente ligero, todo el procesamiento de las aplicaciones y la gestién de los datos se lleva a cabo en el servidor. I cliente simplemente es responsable de la capa de presentacién del software. @ Modelo cliente tigero (thin-client) En este modelo, el servidor solamente es responsable de la gestién de los datos. El software del cliente implementa la légica de la aplicacién y las interacciones con el usuario del sistema. © Modelo de cliente rico (fat-client) Presentacion Procesamiento de la aplicacién Nodelo de Cliente pesado ww -__ Una arquitectura de dos capas con dlientes ligeros es la aproximacién mas simple que se utiliza cuando fos sistemas heredados centralizados, evolucionan a una arquitectura cliente-servidor: La interfaz de usuario para estos sistemas se migra a las PC y la apiicacién en si misma actua como un servidor y maneja todo el procesarniento de la apicacién y gestién de datos. Un modelo de ciente ligaro también puade implementarse cuando los clientes son dispositivos de red sencillos en lugar de las PC o estaciones de trabaj interfaz de usuario es implementada a través de este sistema. El dispositivo de red ejecuta un navegador de Intemat y la El modelo de cliente rico hace uso de esta potencia de procesamiento disponible y distribuye tanto el procesamiento de la 6gica de la aplicacién como la presentacién al dliente. El servidor es esencialmente un servidor de transacciones que gestiona todas las transacciones de la base de datos. Un sistema ATM cliente - servidor Un ejemplo de esta arquitecture es la de los sistemas bancarios ATM, en donde cada ATM es un cliente y el servidor es un mainframe que procesa la cuenta del cliente en la base de datos. hardware de los cajeros automaticos realiza una Gran cantidad de procesamiento relaconaclo con el cliente y asociado a la transaccién, Este sistema dstribuide ATM no se conecta directamente con la base de datos de dientes sino con un monitor de teleproceso. Un monitor de teleproceso o gestor de transacciones es un sistema middleware que organiza las comunicaciones con los dientes remotos y serializa las transacciones de los dientes para su procesamiento en la base de datos. El uso de transaccones serializadas significa que el sistema puede recuperarse de los defectos sin corromper los datos da! sistema. I problema con une aproximacién cliente-servidor de dos capas es que les tres capas légicas deben asocarse con des computadoras: el cliente y el servidor. Aqui pusce haber problemas con la escalabilidad y rendimiento si se elige e! modelo de diente ligero, 0 problemas con la gestién da! sistema si se usa al modelo de cliente rico. Para eviter esos problemas, una aproximacién altemativa es usa une arquitectura dliente-servidor de tres capas. Arquitectura ciente-servidor de tras capas Es esta arquitectura, [a presentaciin, el procesamiento de la aplicacién y la gestién de los datos son procesos légicamente separedos que se ejecutan sobre procesadores diferentes. El uso de una arquitectura de tres cepas permite optimizar la transferencia ce informaci6n entre el servidor web y el servidor de la base de datos. Las comunicaciones entre estos sistemes pueden ser protocolos de comunicacién de bajo nivel muy répidos. Para manejar la recuperacién de Informacién de ia base de datos se utiliza un middleware eficient que soporte consultas a la base de datos en SQL. Interaccién HTTP so ‘query _ Servidor da bases de datos Arquitectura de distribucién de un sistema bancario en Internet Un sistema bancario por Internet es un ejemplo de una arquitectura cliente-servidor de tres capas. La base de datos de clientes del banco proporciona servicios de gestion de datos; un servicio web proporciona los servicios de gestién de datos; un servidor web proporciona los servicios de aplicacién tales como facilidades para transferir efectivo, generar estados de cuents, pager facturas y asi sucesivamente; y fa propia computadora del usuario con un navegador de Intemet es el cliente. EI sistema es escalable debido a que es relativamente facil afiadir nuevos servicios web e medida que el nimero de cientes crece. on 2 03 © arguitectura de — objetos distribuidos Una aproximacién mas general al _ la distincién entre os 06 cliente y servidor y disefiar la arquitectura del sistema como una arquitectura de objetos distribuidos. Arquitectura de objetos distribuidos En una arquitectura de objetos distribuidos, los componentes fundamentales del sistema son objetos que proporcionan una interfaz @ un conjunto de servicios que ellos suministran. Otros objetos realizen Namadas a estos servicios sin hacer ninguna distincién légica entre un cliente (el receptor de un servicio) y un servidor (el proveedor de un servicio). Los objetos pueden cistribuirse a través de varias computadoras en una red y comunicarse a través del middleware. Las ventajas del modelo de objetos distribuido son jas siguientes: Permite al disefiador del sistema retrasar decisiones sobre donde y cémo deberian proporcionarse los servicios. Los objetos que proporcionan servicios pueden ejecutarse sobre cualquier nodo en la red. Es una arquitectura de sistema muy abierta que permite afiadir nuevos recursos 5| 6s necesario. El sistema es flexible y escalable. Se pueden crear diferentes stancias del sisteria proporcionando los mismos servicios por objetos diferentes o por objetos reproducidos para hacer frente a las diferentes cargas del sistema. Pueden afiadirse nuevos objetos a medida que la carga del sistema se incrementa sin afectar al resto de los objetos del sistema. Es posible reconfigurar el sistema de forma dinémica mediante la migracion de objetos a través de la red. Un objeto que proporciona services puede migrar al mismo procesador que los objetos que demandan los servicios, en lo que mejora el rendimiento del sistema Una arquitectura de objetos distribuidos puede ser usada como un modelo légico que permite estructurar y organizer e! sistema para proporcionar las funcionalidades de la aplicacién tinicamente en términos de servicios y combinaciones de servicios. Un ejemplo de un tipo de sistema en el que una arquitectura de objetos distribuldos podria ser adecuada es un sistema de mineria de datos. Cada base de datos puede encapsularse como un objeto distribuido con una interfaz que proporciona acceso de sélo lectura a sus datos. Los objetos integradores se ocupan cada uno de ellos de tipos especificos de relaciones y recogen informacién desde todas las bases de datos pare intentar deducir dichas relaciones. Los objetos__visvalizadores interaccionan con los objetos integradores. para producir una visuelizaci6n 0 un informe de las relaciones descubiertas. A diferencia de un sistema bancario ATM (arquitectura Giente-servicor), el modelo légico del sistema no es el de provision de servicios en el que se pueden distinguir servicios de gestion de datos. Se pueden afiadir bases de datos al sistema sin mayor problema. Cada base de datos es otro objeto distribuido. Los objetos de bases de datos pueden proporcionar una interfaz simplificads que controle el acceso a los datos. Las bases de datos alas que se puede acceder pueden residir en diferentes méquinas. Permit explorar nuevos tipos de relaciones afadiendo nuevos objetos integradores. Las partes del negocio que estén interesadas en relaciones especificas pueden extender el sisterna afiadiendo objetos integradores que operen sobre sus computadoras sin requerir conocimiento de ningtin otro integrador que se use en cualquier otre parte del sistema. Las principal desventaja de las erquitecturas de objetas distribuldos es que son mucho mas complejas de disefiar que los sistemas cliente-servidor Los sistemas cliente-servidor parecen ser la forma mas natural de concebir a los sistemas. 41.2. Ventajas y desventajas. Una base datos distribuida 2s una coleccién de datos que pertenece légicamente al mismo sistema pero que esta dispersa fisicamente entre los sitios de una red de computadores. Varios factores han dado pie a la creacién de lo SGBDD. Entre las ventajas potenciales de los SGBDD estan las ‘siguientes: La naturaleza distribuida de algunas aplicaciones de bases de datos. Muchas de estas aplicaciones estén distribuidas naturelmente en diferentes lugares. Por ejemplo, una compahia puede tener oficinas en varias ciudades, 0 un banco puede tener mailtioles sucursales. ES natural que las bases de datos empleadas en tales aplicaciones estén distribuidas en esos lugares. Muchos usuarios locales tienen acceso exclusivamente a los datos que estén en el lugar, pero los usuarios alobales pueden requerir acceso acasional a los datos almacenados en varios de estos lugares. Los datos en cada sitio local describen un “mini mundo” en ese sitio. Mayor fial idad y disponil Estas son dos de las ventajas potenciales de las bases de datos distribuidas. La fiabilidad se define a grandes rasgos como la probabilidad de que un sistema esté en funciones en un momento determinado y la disponibilidad es la probabilidad de que el sistema esté disponible continuamente durante un intervalo de tiempo. Cuando los datos y el software del SGBD estan distribuidos en varios sitios, un sitio puede feller mientras que los demas siguen operando. Sélo los datos y el software que residen en el sitio que fallé estan inaccesibles. Esto mejora tanto la fiabilidad como la disponibilidad. Posibilidad de compartir los datos al tiempo x | que se mantiene un cierto grado de control local. En algunos tipos de SBDD es posible controlar los datos y al software localmente en cada sitio. Sin embargo, los usuarios de otros sitios remotos pueden tener acceso a ciertos datos a través del software del SGBDD. Esto hace posible el compartimiento controlado de los datos | en todo el sistema distribuido. Mayor sendimianto. ti Cuando una base de datos grande esta distribuida en miltiples sitios, hay bases de datos mas pequefias en cada uno de éstos. En consecuencia, las consultas locales y las transacciones que tienen acceso a datos de un solo sitio tienen un mejor rendimiento porque las bases de datos locales son mas pequefias. Ademés de que cada sitio tiene un menor niimero de transacciones | en ejecucién que si todas las transacciones se enviarén | auna sola base de datos centralizada. La distribucién produce un aumento en ta complejidad del disefio y en la implementacién del sistema. Para obtener las ventajas potenciales anteriormente descritas, el software de SGBDD debe contar con las funciones de un SGBD centralizado y ademés con las siguientes caracteristica: La capacidad de tener acceso a sitios remotos y ‘transmitir consultas y datos entre los diversos sitios @ través de una red de comunicaciones. La capacidad de seguir la pista a la distribucién y la replicacion de los datos en el catélogo del SGBDD La capacidad de eleborar estrategias de ejecuci6n para consultas y transacciones que tienen acceso a datos de mas de un sitio. La capacidad de decidir a cual copia de un elemento de informaci6n replicado se tendra acceso. La capacidad de mantener la consistencia de las copias de un elemento de informacién replicado. La capacidad de recuperarse de caidas de sitios individuales y de nuevos tipos de fallos, como el fallo de un enlace de comunicacién. doe steers sendin stilt: de bese de dale eines ete auger algunos problemas. Estos incluyen: ‘Complejidad de manejo y control | x | El menejo de datos distribuidos es més complejo que el de datos centralizades. Las aplicaciones deben reconocer la ubicacién de los datos y ser capaces de reunir los datos de diferentes sitios. Los administradores de las bases deben tener la capacidad de coordinar las actividades para evitar la degradacién de éstas provocada por anomalias de los datos. EI manejo de transacciones, el control de concurrenda, la seguridad, el respaldo, la recuperacién, la optimizacén de las consultas, la seleccién de la ruta de acceso, deben abordarse y resolverse. En suma, mantener los diversos componentas de base de datos distriouida sincronizados es una tarea dificil. Seguridad La probabilidad de fallas de seguridad s2 incrementa cuando los catos estén en varios sitios, La responsabilidad del manejo de los datos se reparte entre diferentes personas en varios sitios y las redes de area local no disponen de la compleja seguridad de las instalaciones mainframe centralizadas. Falta de estandares. Aunque las bases de datos dependen de la comunicacion eficaz, no existen protocolos de comuri estandar a nivel de base de datos. En realidad, existen pcos estandares oficiales en cualquiera de los protocolos de base de datos distribuida, ya sea que se ccupen de la comunicacién o del control de acceso a los datos. Requerimientos de almacenamiento incrementados La base de datos distribuida guarda varies copias de los datos requeridos en diferentes sitios, con lo que se requiere mas espacio de almacenamiento en disco. Esta desventaja es minima, porque el espacio de almacenamiiento en disco es relativamente barato y cada vez se abarata mas. Mayor dificultad en el manejo del ambiente de datos El acceso y almacenamiento en disco en un ambiente de almacenamiento de datos mas disperso, se vuelve mas dificil tanto desde la perspectiva del software como de la humana. Altos costos de entrenamiento Los costos de entrenamiento en general son mas adecuados en un modelo distribuido de lo que serian en modelo centralizado, indluso, en ocasiones al grado de neutralizar los ahorros operativos y de hardware. 4.2. Bases de datos orientados a objetos. La orientacién @ objetos es una metodologia de desarrollo y disefio basada en los conceptos orientados a objetos. La orientacién a objetos es definida camo un conjunto de principios de desarrollo y disefio basado en estructuras informéticas conceptuaimente auténomas conocidas como objetos. Cada objeto representa un entidad del mundo real con |a capacidad de actuar por si mismo e interactuar con otros objetos. Los origenes del término orientado 2 abjetos (00) se remontan a los lenguajes de programacién 00. Los conceptos de 00 se aplican ahora en las éreas de bases de datos, ingenieria de software, bases de conocimientos, inteligencla artificial _y sistemas de cémputo general. Un objetivo de las bases de datos ©O es mantener una correspondencia directa entre los objetos del mundo real y de la base de datos, de modo que dichos objetos no pierdan su integridad ni su identidad y se puedan identificar y manipular faciimente Une caracteristica Gave de las bases de datos orientadas a objetos es el poder que confieren al disefiador para especificar tanto la estructura de objetos complejos como la operacién que se pueden aplicar a esos objetos Otra caracteristica de las bases de datos 00 es que los objetos pueden tener una estructura de complejidad arbitraria con el fin de contener toda la informacion significetiva que describe al objeto. A continuaci6n se enlistan los conceptos més importantes dentro de la orientacién a objetos junto con las bases de datos orientadas a objetos Identidad de objetos. Un sistema de base de datos 00 provee una identidad Unica a cada objeto independiente almacenado en la base de datos. Esta identidad unica suele implementarse con un identificador de objeto Unico (OID), generado por el sistema, El valor de un OID no es visible para el usuario extero, sino que el sistema lo utiliza a nivel interno para identificar cada objeto de manera unica y para crear y manejar las referencias entre objetos, La principal propiedad que debe tener un OID es la de ser inmuteble; es decir, ef valor del OXD para un objeto en particular nunca debe cambier. Esto preserva la identidad del objeto del mundo real que se esta representando. Es preferible que cada OID se utilice sélo una vez; esto es, aunque un objeto se elimine de la base de datos, su OID no deberd asignar a otro objeto. Un sistema de base de datos OO debe contar con algiin mecanismo para generar los OID con Ia propiedad de inmutabilidad. Algunos modelo de datos 00 requieren que todo se represente como un objeto, ya sea un valor simple 0 un objeto complejo; asi, todo valor bésico, como un entero, una cadena 0 un valor booleano, tiene un OID. Estructura de objetos. En las bases de datos 00, los valores de los objetos complejos se pueden construir a partir de otros objetos mediante ciertos constructares de tipos. Los tres constructores mas basicos son los constructores de atomos, tuplas y conjuntos. Otros constructores de uso comin son los de listas y de arreglos, Los constructores de tipos conjunto, lista, arreglo y bolsa se denominan tipos de coleccién o tipos masivos, pars distinguirlos de los tipos basicos y de los tipos de tupla, Una lista es similar a un conjunto, con la excepcién de que los OID de una lista estan ordenados. Una bolsa también es similar a un conjunto, excepto que permite la existencia de valores repetidos. La caracteristice principal de un tipo de coleccién es que un valor es una coleccién de objetos que puede carecer de estructura (Como un conjunto 0 una bolsa) 0 tenerla (como una lista 0 un arreglo).. Se dice que dos objetos tienen valores idénticos si los grados que representan ‘sus valores son idénticos en todo sentido, incluidos los OID en todos los niveles. Ora definicién de la igualdad, menos estricta, dice que dos objetos son iguales si tienen valores iguales Se puede usar un lenguaje de definicién de datos 00 (OODDL) cue incorpore los constructores de tipos para definir tipos de objetos para una aplicacién de base de datos especifica, Asi, estos constructores de tipos pueden servir para definir las estructuras de datos de un esquema de base de datos 00. Se usan les palabras reservadas tuple, set y list para los constructores de tipos de tupla, conjunto lista respectivamente y se usan los tipos de datos esténdar disponibles para los tipos atémicos. Los atributos que hace referencia a otros objetos 1 son bésicamente referencis y, por tanto sirven para representar vinculos entre los tipos de objetos. Un vinoulo binario se puede representar en una direccidn, o puede tener una referencia inversa. Ceres define type Empleado: tuple (nombre: nss: fechanac: sexo: depto: string, string, Fecha, char, Departamento); define type Fecha: tuple( —afio: mes: dia: integer, integer); @ type Departamento: tuple (nombred: niimerod: gte: string, integer, tuple (gerente: fechainic: Empleado, Fecha), lugares: empleados Proyectos: set (string), set (Empleado), set (Proyecto); Ejemplo de OODDL para definir los tipos de Empleado, Fecha y Departamento | concepto de encapsulamiento es una de las caracteristicas principales de los lenguajes y sistemas 00. Esté relacionado con los conceptos de tipos de datos abstractos y de ocultacién de informacién en los lenguajes de progremacién. Por lo regular, varias operaciones de base de datos est4ndar son aplicables a objetos de cualquier tipo Los conceptos de ocultacion de la informacion y encapsulamiento se pueden aplicar a los objetos de una base de datos. La idea principal es definir el comportamiento de un tipo de objeto con base en las operaciones que se pueden aplicar externamente a objetos de ese tipo. La estructura interna del ‘objeto queda oculta, y s6lo se puede tener acceso a él a través de una serle de operaciones predefinides. En general, la implementacién de una operacién puede especificarse en un lenguaje de programacién de propésito general que ofrezca flexibilidad y potencia para definir las operaciones Los usuarios externas del objeto sélo perciben Ia interfaz del objeto, la cual define los nombre y argumentos de cada operacién. La implementacién del objeto queda ocuite a los usuarios externos; incluye la definicién de las estructuras de datos internas del objeto y la implementacién de las operaciones que tiene acceso a dichas estructuras. En terminologia de 00, Ie parte de interfaz de cada operacién se denomina signatura, y la implementacién de la operacién se llama método. Por lo regular, un métados se invoca enviando un mensaje al objeto para que ejecute el método correspondiente. En la mayorfa de los casos, [as operaciones que actualizan el estado de un objeto estén encapsuladas. esta es una forma de definir la seméntica de actualizacién de objetos, en vista de que en muchos modelos de datos 00 pocas restricciones de integridad estén predefinidas en el esquema. Cada tipo de objetos tiene sus restricciones de integridad programas en lo métodos que crean, eliminan y actualizacién los objetos. El términa clase se usa para referirse a una definicién de tipo de objetos, junto con las definiciones de las operaciones de ese tipo. Es comin que un SGBDOO esté acoplado intimamente 2 un lenguaje de programacin 00. Con este lenguaje se especifican las implementaciones de los métodos. No todos los objetos estén destinados a almacenarse permanentemente en la base de datos; hay objetos transitorios en el programa en ejecucién que desaparecen una vez que éste termine. Los objetos persistentes se almacenan ‘en la base de datos y persisten después de la terminaci6n del programa. El mecanismo de persistencia usual implica dar ai objeto un nombre persistente Unico a través del cual los programas puedan obtener el objeto, 0 bien hacer que el objeto sea alcanzable desde algiin objeto persistente. Jer quias de tipos y herenci En la mayor parte de las aplicaciones de bases de datos hay un gran niimero de abjetos del mismo tipo. Por ello, las bases de datos OO deben proporcionar una capacidad para clasificar los objetos con base en su tipo. En las bases de datos 00 hay un requisito adicional: que el sistema permita la definicién de nuevos tipos basados en otros tipos predefinidos, dando origen a una jerarquia de tipos. Para definir un tipo se le asigna un nombre de tipo y se listan en seguida los nombres de sus funciones. Como se muestra 2 continuacién NOMBRE_DE_TIPO: funci6n, funci6n, ..., funcién I concepto de subtipo resulta iitil cuando el disafiador 0 usuario debe crear una uevo tipo cue es similar, Dero no Idéntico, a un tipo ya definido. El subtipo hereca entonces todas las funciones del tipo predefinido, al cual llamaremos supertipo. La idea de definir un tipo implica definir todas sus funciones ¢ implementarlas ya sea comp atributos 0 como métodos. Cuando se define un subtipo, puede heredar todas sus funciones y su implementacion. S6io es necesario definir e implementar las funciones que son especfficas para e! subtipo y que por ello no se implementen en el supertipo. Como ejempio s2 muestra el siguiente PERSONA: Nombre, Direccién, Fechanac, Edad, NSS EMPLEADO subtype-of PERSONA; Salario, FechaContrato, Antigiiedad. ESTUDIANTE subtype-of PERSONA: Carrera, Promed | declarar ue EMPLEADO y ESTUDIANTE son subtipos de (subtype-of) PERSONA, se especifica que los dos heredan todas las funcones de PERSONA. En general, un subtipo incluye todas las funciones que estin definidas por su supertipo, mas alounes funciones adiconales que son especificas para el subtipo. Es posible generar una jerarqula de tipos para Indicar los vinculos supertipos/subtipo entre todos ios tipos declarados en el sistema. Algunos sistemas OO permiten cambier el nombre de las funciones heredadas en los diferentes subtipos pare que refleje mejor el significado. Una forma altematva de declarer estos subtipos es la siguiente: RECTANGULO subtype-of 05JETO_GEOMETRICO (Forma = ‘rectangulo’): Ancho, Altura. TRIANGULO subtype-of 0BJETO_GEOMETRICO (Forma = “triéngulo’): Ladot, Lado2, Angulo. ‘CERCULO subtype-of OBJETO-GEOMETRICO (Forma = ‘circulo’): Radio. Aqui solo los objetos OBJETO_GEOMETRICO para los que Forma = ‘rectaéngulo’ son del subtipo RECTANGULO, y de manera similar con los otros dos subtipos. En este caso, cada uno de los tres subtipos hereda todas les funciones del supertipo OBJETO_GEOMETRICO, pero el valor del atribute Forma esté restringdo a un valor espedfico para cada uno. Jerarquias de clases. Una clase es una coleccién de objetos que se significativa para alguna aplicacién. Por lo regular una clase se define por su nombre y por la coleccién de objetos incluidos en ella. A menudo conviene poder definir una sudcase de otra clase de objetos, donde esta Uitima sea la superclase. Algunos sistemas 0 tienen una clase predefinida del sistema que contiene todos los objetos del sistema. Entonces, la clasificacién se lleva acabo espacializando los objetos para generar clases adicionales que sean significativas para la aplicacin, creando asf una jerarquia de clases del sistema. En las bases de datos ©O basadas en tipos, una jerarquia de clases a menudo tiene una jerarquia de tipos correspondiente, por la restriccl6n de que todos los objetos de una clase sean del mismo tipo. Asi es posible crear una clase por omisién pare ceda tipo, que contenga todos los objetos persistentes de ese tipo. En la mayor parte de los sistemas 00, se hac una distincién entre los objetos y clases persistentes y transitorias. Una clase persistente es una clase cuya seleccin de objetos se elmacena permanentemente en la base de datos, de modo que multiples programas pueden tener acceso a ella y compartila. Una clase transitoria es una clase cuya coleccién de objetos existe temporelmente durante la ejecucién de un programa, pero que no se conserva cuando el programa termina. Objetos complejos. Una de las razones fundamentales para crear los sistemas OO fue el deseo de representar objetos completos. Hay dos dases principales de objetos complejos: estructurados y no estructurados. ‘Objetos complejos no estructurados Un recurso de objeto complejo no estructurado provisto por un SGBD permite almacenar y leer objetos extensos que necesita la aplicacién de base de datos. Ejemplos representativos de tales objetos son las imagenes de mapa de bits y las cadenas de texto largas; también se conocen como objetos binarios extensos (BLOB). Estos objetos carecen de estructura en el sentido de que el SGBD no sabe qué estructura tienen; sélo la aplicacién que usa los objetos puede interpretar su significado. Los objetos se consideran complejos porque requieren un drea de almacenamiento sustancial y no forman parte de los tipos de datos estdndar que suelen ofrecer los SGBD. El software del SGBD no cuenta con la capacidad de proceser directamante las condiciones de seleccién ni otras operaciones basadas en valores de estos objetos, a menos que la aplicacién provea el cddigo necesario para realizar las operaciones de comparacién que precisa la seleccién. Objetos complejos estructurado: La diferencia entre un objeto complejo estructurado y uno no estructurado consiste en que la estructura del objeto se define por aplicacién repetida de los constructores de tipos provistos por el SGBDOO. Asi, la estructura del objeto esté definida y el SGBDOO la conoce. Existen dos tipos de seméntica de referencia entre un objeto complejo @) y Sus Componentes en cada nivel. El primer tipo, que llamamos semantica de propiedad, se aplica cuando los subobjetos de un objeto complejo estén encapsulados dentro de éste y, por ello, se consideran parte de él. El segundo tipo, denominado seméntica de referencia, se aplica cuando los componentes de un objeto complejo son ellos mismo objetos ey independientes, pero en ocasiones pueden considerarse perte del objeto complejo. Los SGBDOO deben ofrecer opciones de almacenamiento para formar grupos con los objetos componentes de un objeto complejo en almacenamiento secundario, @ fin de aumentar le eficiencia de las @ operaciones que tienen acceso al objato completo. En muchos casos la estructura del objeto se almacena, sin ser interpretada, en paginas de @) disco. Cuando se lee a la memoria una pagina de disco que incluye un objeto, El SGBDOO puede construir el objeto complejo estructurado a partir de la informacién contenida en la paging, la cual puede hacer referencia a paginas de disco adicionales que serd preciso obtener. Esto se conoce como ensamble de objetos complejos. 4.21 Caracteristicas de un DBMS orientado a objetos. Un OODBMS (Sistema gestor de base de datos orientado a objetos) es el resultado de combinar caracteristicas orientadas a objetos, come herencia de dase, encapsulado y polimorfismo, con caracterfsticas como integridad, seguridad, persistencia, administraci6n de transacciones, control de concurrencia, respaldo, recuperacién, manipulacién de datos y afnacién del sistema. Existen 13 regias, algunas obligatorias y otras opcionales del OODBMS. Las 13 reglas estan divididas en dos conjuntos: las primeras 8 caracterizan un sistema orientado 2 objetos, las ultimas cinco a un DBMS. GeO es __ Regia Elsistoma debe soportar objetos complojos. | hegled Deb sporar dented de shes. | @ Regle3 Los objetos deben ser encapsulados Regla4 _Elsistema debe soportar tipos o clases '@ ReglaS _Elsistema debe soportar herencia. Regla6 _Elsistema debe evitar asignacion prematura. Caracteristicas de un DBMS orientado a objatos. siguon ) Regla7 __ Elsistema debe ser computacionalmente completo, Regla8 _ Elsistema debe ser extensible. aA PES Regla9 —_Elsistema debe ser capaz de recordar las ubicaciones de los datos. Regla10 _Elsistema debe ser capaz de manejar bases de datos muy grances. Reglali _Flsistema debe aceptar usuarios concurrentes | Regla 12 Fl sistema debe ser capa? de recuperarse de falas de hardware y| @)) software. Reglai3 La consulta de datos debe ser simpk Regia 4. El sistema debe soportar objetos complejos. Debe ser posible construir objetos complejos con aquellos que ya existen. Algunos ejemplos de constructores de objetos son conjuntos, listas y tuplas que permiten que el usuario defina agregaciones de objetos como atributos. Regle 2. Debe soportar identidad de objeto. Los objetos idénticos deben ser independientes del estado del objeto. Esta caracteristica permite que el sistema compare objetos en niveles diferentes: comparacién de los objatos idénticos y comparaci6n del estado del objeto. Regla 3. Los objetos deben ser encapsulados. Los objetos tienen una interface piiblica, pero la implementacién de datos y métodos es privada. Las caracteristicas de encapsulacién asegura solo el aspecto pliblico del objeto que se ve, mientras que los aspectos de Implementadién estén ocultos Regla 4. El sistema debe soportar tipos o clases. Esta regia permite al diseffador elegir si el sisterna soporta tipos de datos 0 clases. Los tipos de datos se utilizan sobre todo en tiempo de ejecucién para comprober los tipos de errores en las asignaciones de valor de los atributos. Las clases se utilizan para almacenar y manipular objetos similares en tiempo de ejecucién. En otras palabras, las clases son un concepto mas dindmico y los tipos de datos son un concepto mas estatico. Regla 5. El sistema debe soportar herencia. Un objeto debe heredar las propiedades de su super clase en la jerarquia de clases. Esta propiedad asegura la reutilizacién de cSdigo. Regla 6. El sistema debe evitar asignaci6n prematura. Esta caracteristica nos permite usar el mismo nombre de métodos en diferentes clases. Sobre la base de la dase a Ia que pertenece el abjeto, el sistema orientado a objetos decide que aplicacién se accede en tiempo de ejecucién. Esta caracteristica es ‘también conocida como asignacién tardia 0 dindmica. Regla 7. El sistema debe ser computacionalmente completo. Les notaciones bésicas de los lenguajes de programacién son caracteristicas comunes al lenguaje de manipulacién de datos en base de datos, asi permitiéndonos expresar cualquier tipo de operacién en el lenguaje. Regla 8. El sistema debe ser extensible. Las iitimas caracteristicas de la orientacién 2 objetos se refieren a la habilidad del sistema para definir nuevos tipos de datos. No hay diferencia entre los tipos de datos definidos por el usuario y los definidos por el sistema. Regla 9. El sistema debe ser capaz de recordar las ubicaciones de los datos. Los DBMS convencionales almacenan sus datos de forma permanente en disco, esto es, el DBMS muestra la persistencia ce datos. Fl sistema orientado a ‘objetos por lo general mantienen el espacio del objeto en memoria; una vez que el sistema es apagado, el espacio del objeto se pierde. Muchas investigaciones de los OODBMS se han centrado en encontrar una forma de guardar permanentemente ‘objetos y de recuperarios desde un almacenamiento secundario. Regla 10. El sistema debe ser capaz de manejar bases de datos muy grandes. Los sistemas orientados a objetos limitan el espacio del objeto a la cantidad de memoria primaria disponible. Por la tanto, una caracteristica critica del OOPBMS es optimizar la gestion de los dispositivos de almacenemiento secundario mediante el uso de buffers, indices, agrupacién de datos y las tScnicas de seleccién de rutas de acceso. Regla 11. El sistema debe aceptar usuarios concurrentes. Los DBMS convencionales son especialmente capaces de esta érea. Los OODBMS deben aceptar el mismo nivel de concurrencia que un sistema convencional. Regla 12. El sistema debe ser capaz de recuperarse de fallas de hardware y software. El OODBMS debe brindar el mismo nivel de proteccién de fellas de hardware y software que el tradicional DBMS proporciona; esto es, el OODBMS debe proporcionar apoyo para el respalco de seguridad automatico y herramnientas de recuperacién Regla 13. La consulta de datos debe ser simple. 2 consulta eficaz es una de las caracteristicas mAs importantes de cualquier DBMS. Los DBMS relacioneles han proporcionado un método esténdar de consulta de base de datos llamado SQL, y el OODBMS debe proporcionar un lenguaje de consulta de objetos (OQL) con cepacidades similares. Otras caracteristicas opconales de un OODBMS induyen: Wu Soporte para herencia miltiple. La herencia miiltiple presenta una mayor complejidad que requiere que el sistema maneje las propiedades potencialmente en conflicto entre las clases y subclases. uu Soporte para OODBMS distribuidos. La tendencia hacia la integracién de aplicacién de sistemas constituye a argumento podaroso a favor de las bases de datas distribuidas. Si el OODBMS se integra perfectamente con otros sistemas a través de la red, la base de datos debe aceptar el mismo grado de distribucion. ‘Soporte para el control de versiones. = control de versiones, en una caracteristica nueva del OODBMS que es especialmente Lit en aplicaciones como CAD y CAM. EI control de versiones permite mantener un historial que registra todas las, transformaciones de un cbjeto. Por la tanto, usted puede nevegar a través de los diferentes estados del objeto, lo que permite caminar hacie adelante y atras en el tiampo. 4.2.2 Ventajas y desventajas. ‘Comparado con el segmento del mercado del RDBMS, los OODBMS ticnen un largo cemino por recotrer, aunque el F | OODBMS ha sido el vehiculo pare la innovacién tecnoldgica ce la base de datos, atin no se ha beneficiado con el crecimiento de su segmento del mercado con base a sus innovaciones tecnolégicas. No obstante vale la pena examinar el OODBMS, sobre todo porque sus caracter(sticas de orlentacién a objetos promueven , cambios en la tecnologia de base de datos que definen el DBMS S relacional y el orientado a objetos de la actualidad. Una parte del problema de aceptacién del mercado del OODBMS es que el RDBMS ha incorporado muchas caracteristicas de orientacién de objetos al mismo tiempo que ha retenido su simplicidad conceptual. Sin embargo, en tanto que el RDBMS no incorpore la ejecucién de dominio el OODBMS ofrece beneficios que vale la pena examiner. La mayoria de estos beneficios se expresan en funcidn de las complejas capacidades de manejo de objetos. para obtener estos beneficios, el OODBMS depende el uso de un lenguaje de programacisn orientado a objetos, Ventajas i = Los QODBMS permiten la inclusién de mas informacién seméntica en la base de datos, y proporcionan asi una representacién més natural y realista de objetos reales. Los OODBMS llevan a ventaja en el soporte de objetos complejos, lo que los hace especialmente necesario en area de aplicaciones centralizadas. Las bases de datos convencionales simplemente carecen de la capacidad de proporcionar aplicaciones eficientes en CAD, CAM, creacién de imagenes médicas, creacién de imagenes espaciales y ambientes multimedia especializados. Los OODBMS permiten extender los tipos de datos base, con lo cual se incremente tanto la funcionelidad de la base de datos como sus capacidades de modelado. Si la plataforma permite un “caching” eficiente, los OODBMS proporcionan significativas mejoras de desempefio en comparacién con los sistemas de bases de datos relacionales, cuando se manejan objetos complejos. La determinacién de versiones en una caracteristica til de aplicaciones especializadas como CAD, CAM, creacién de imagenes mécicas, creacién de imagenes espacieles, ingenierfe, manejo de textos y edicién 0 \cién mediante computadora. YVuuuuuU = La reutilizaci6n de clases permite un desarrollo mas rapido mediante herenda y reutilizacién. Este beneficio se obtiene solo después de dominar el uso de las caracteristicas de desarrollo orientado a objetos como: * El uso apropiado de Ia jerarquia de clases; por ejemplo, cémo utilizar las clases existentes para crear nuevas. ‘* Metodologia de disefio orientado a objetos. Buu EL OODBMS proporciona una posible solucién al problema de integracién de DBMS existentes y futuros en un solo ambiente. Esta solucién se basa en sus fuertes capacidades de abstraccién de datos y en su promesa de portabilidad. Desventajas Yuu = Los OODBMS enfrentan una fuerte y eficaz oposicién de los RDBMS firmemente establecidos, en particular cuando los RDBMS Incorporan muchas caracteristicas orientadas a objetos que de lo contrario le habria dado al OODBMS Ia clara ventaja competitiva en un ambiente de datos complejo. Por consigulente, las complejidades de disafio y ejecucién del OODBMS se tornan mas dificiles de justificar. UuuUUUUUU El OODBMS esta basado en un modelo de objetos el cual carece del sdlido fundamente tedrico del modelo relacional en el que se basa el RDBMS. wueuuUuuUl Los OODBMS se consideran un retroceso con relacién a los, temas sefializadores tradicionales utilizados por modelos jerérquicos y de red. Esta critica no viene al caso cuando se asocia al sistema seflalizador con el estilo de manipulacién de datos navegacional y rutas de acceso fijas que condujeron al dominio del sistema relacional. No obstante, la complejidad de los sistemas sefializadores OODBMS no puede ser ignorada. wWuuuueuul SVS S LS S = Los OODBMS no proporcionan un lenguaje de consulta ad hoc estdndar, como los sistemas relacionales. En este punto, el desarrollo del lenguaje de objetos (OQL) esta muy lejos de estar completo. Algunas versiones de OODEMS estan comenzando a proporcionar extensiones del SQL relacional para hacer posible la integracién del OODBMS y cl RDBMS. YuUuuUuuUl =I DBMS relacional proporciona una amplia solucién a las necesidades de disefio y manajo de bases de datos empresariales, al ofrecer tanto un modelo como un conjunto de regias de normalizacién més 0 menos simples para disefar y evaluar bases de datos relacionales. Los OODBMS atin no proporcionan un conjunto de herramientas similares. YuleluUlueel = SS La curva de aprendizaje inicial del OODBMS es muy pronunciada. Si se consideran los costos de entrenamiento directos y el tiempo que se requiere para dominar por completo los usos y desventajas de la orientacién a objetos, se vera por qué los OODBMS rara vez son consideradas la primera opcién cuando se buscan soluciones a problemas orientado 2 negocios no complejos. IVAVAVAVIVIVAVEV) ——— — — La baja presencia en el mercado de los OODBMS, combinada con la inclinada curva de aprendizaje, significa que existen pocas personas calificadas que utilizan el presunto poder de la tecnologia orientada a objetos. En la actualidad, la mayoria de la temologia est enfocada en drea de aplicaciones de ingenieria de desarrollo de software. uYuuuUUuU La falta de compatibilidad entre diferentes OODBMS dificulta el cambio de una pieza de software a otra. En el caso de los RDBMS, los productos son muy similares, y el cambio de uno a otro es relativamente facil. Hace unos cuantos afios, se especulaba que los sistemas futuros manejarian objetos con métodos y datos insertados y no con registros, tuple o archivos. También se sugeria que, aunque los detalles de portabilidad avn no estaban claros, tendrian un mayor y duradero impacto en el disefio y uso de las bases de datos. Dado el beneficio de la percepcién ya pasada la ocasién, ahora se sabe que el alcance de los OODBMS ha sido limitado por la integracién exitosa del O/R DBMS de muchos Conceptos orientados a objetos dentro de su estructura relacional.