|
|
OBJETOS EN ORACLE
Estrategias para desarrollar una base de datos objeto-relacional
Varios proveedores de bases de datos relacionales están intentando desarrollar una solución objeto-relacional. Las distintas estrategias que utiliza cada proveedor tienen sus ventajas y sus inconvenientes.
Las estrategias básicas son las siguientes:
Se necesitarán varios años de integración 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 diseñadas para funcionar con uno de los dos productos.
La migración evolutiva de un sistema existente es la opción más segura. Aunque este enfoque es el preferido y ofrece muchas ventajas, tiene un inconveniente: para conseguirlo se necesitan varios años 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 diseño en las próximas versiones de Oracle Server para perfeccionar los requisitos de una base de datos objeto-relaciona.
Base de Datos Objeto-Relacional
La tecnología relacional es válida para numerosas aplicaciones. Muchas empresas y organizaciones han realizado cuantiosas inversiones en sistemas de gestión de bases de datos relacionales. Lo que se necesita es un puente entre la funcionalidad y los servicios que proporcionan los avanzados gestores de bases de datos relacionales de la actualidad y la representación de objetos que necesitan las herramientas de desarrollo de alto nivel utilizadas para desarrollar las avanzadas aplicaciones clientes actuales. La base de datos objeto-relacional permite que las tablas relacionales que almacenan datos existentes y los nuevos objetos coexistan y accedan a los mismos datos subyacentes.
Oracle8 representa un importante avance en la tecnología de gestión de datos con la introducción de un paradigma objeto-relacional. A menudo, varias aplicaciones independientes con datos similares, tales como información de clientes, facturación y envío, existen en distintos esquemas de base de datos, y el departamento de sistemas debe gestionar su interacción, lo que se convierte en una tarea muy difícil consistente en integrar distintos objetos relacionales y diferentes aplicaciones, para formar un modelo de datos de usuario final más uniforme y coherente.
Considérese una empresa que dispone de un simple modelo de introducción de pedidos. Incluso un sistema estándar de pedidos/envío/facturación puede plantear cuestiones complejas de modelización de datos. Por ejemplo, puede haber más de un tipo de cliente, según se realicen ventas directas, ventas por catálogo o compras impulsivas, entre otras. Además, los productos se pueden enviar de distintas maneras, como por ejemplo transporte por carretera, servicio postal o entrega urgente por servicio de mensajería. Toda la información de los sistemas de pedidos y envío debe introducirse antes o después en un sistema central de facturación. El coste de esta interacción ha redoblado los esfuerzos de desarrollo para proporcionar la integración entre las aplicaciones y los esquemas de base de datos. Sin embargo, este sistema funciona sobre la base de un modelo de datos común: clientes, pedidos, entregas y facturas.
Otra tendencia que se percibe en los actuales sistemas de las empresas consiste en ampliar el gestor de la base de datos con datos complejos, tales como coordenadas
espaciales, imágenes, vídeo o sonidos. Por ejemplo, una aplicación de seguros podría almacenar información de sus clientes, como nombres, direcciones, infracciones y datos de vehículos. Estos simples datos pueden ayudar a responder a preguntas útiles tales como "¿Cuál es el factor de riesgo de este cliente concreto?" o "¿Cuántos clientes son propietarios de automóviles que tienen una antigüedad de menos de tres años?" Pero no se puede realizar un análisis más complicado del tipo "¿Qué clientes viven en un radio de 10 kilómetros del cruce más peligroso?". Este tipo de consulta utilizaría idealmente datos espaciales extraídos de las direcciones de los clientes y de los lugares en que se producen los accidentes, y efectuaría funciones tales como distancia y superficie. Los tipos relacionales pueden almacenar datos complejos , pero no permiten el uso de extensiones para efectuar un procesamiento especial.
Los sistemas de gestión de bases de datos relacionales cuentan con las posibilidades de procesamiento de consultas, seguridad, control de concurrencia y gestión de transacciones que necesitan los sistemas críticos. Al mejorar la base de datos relacional con extensiones de objetos para proporcionar una completa solución objeto-relacional, Oracle utiliza una estrategia que no consiste en revolucionar la manera en que las empresas y organizaciones desarrollan aplicaciones y almacenan datos, sino más bien permitir que los datos evolucionen para satisfacer las nuevas necesidades de las aplicaciones actuales. Toda la funcionalidad está integrada en un mismo servidor de base de datos y todas las aplicaciones pueden acceder a los datos.
Aplicaciones indicadas para bases de datos objeto-relacional
Cualquier tipo de aplicación que utilice datos complejos representados como una unidad lógica es un buen candidato para un sistema de base de datos objeto-relacional. Por ejemplo, considérense los sistemas de inventario, introducción de pedidos, envío, facturación y datos de clientes. Todos estos sistemas pueden tener diseños distintos y un contenido diferente sobre los mismos tipos de información y pedidos de clientes.
La modelización de objetos aporta una manera de crear un marco común que puedan utilizar y comprender todas las aplicaciones. Cada aplicación puede disponer de una interfaz común para interactuar con los datos. Utilizando el ejemplo anterior, un objeto podría ser VentaCliente. En lugar de crear una compleja correlación entre los datos de objetos en cada una de las aplicaciones y los datos físicos del esquema relacional, el usuario puede crear en la base de datos un objeto que todas las aplicaciones puedan utilizar.
Esto facilita el desarrollo de todas las aplicaciones, ya que gran parte del código se sitúa fuera de ellas. Además, la tecnología de objetos, como puede ser el almacenamiento de punteros y colecciones de objetos, también simplifica en gran medida las instrucciones SQL.
Otra aplicación para las bases de datos objeto-relacional son las páginas Web, que integran imágenes, vídeo, sonidos, etc. Cada página Web se puede representar como un objeto en un servidor Web de base de datos. Una aplicación desde el servidor de aplicaciones puede solicitar objetos de página Web y convertirlos a código HTML que podrán visualizarse en el browser del cliente. Para una aplicación Web del tipo de introducción de pedidos, los datos introducidos por el usuario se ponen a disposición de las aplicaciones de envío y facturación, así como de herramientas de análisis de datos para realizar operaciones de soporte a la toma de decisiones.
Tipos de objetos
Las bases de datos relacionales admiten tres tipos de datos: caracteres, números y fechas. Los tipos de objetos permiten definir nuevos tipos de datos y utilizarlos de la misma manera que se usarían los tipos de datos relacionales normales. Por ejemplo, se puede crear un nuevo tipo denominado Dirección que puede contener datos, denominados atributos, tales como la calle, la población y el código postal. El tipo de objeto también puede contener métodos, tales como Distancia, para calcular la distancia entre las direcciones. Estos métodos se pueden escribir en PL/SQL, C o Java. La dirección se podrá utilizar entonces en cualquier lugar en el que pueda usarse un tipo de datos normal, tanto en definiciones de columna como en variables PL/SQL, o incluso como definición de una tabla de objetos.
Los tipos de objetos de Oracle pueden utilizar potentes técnicas de modelización de objetos para crear objetos complejos. Por ejemplo, pueden representarse colecciones de objetos similares en estructuras de matriz o en tablas anidadas. También pueden almacenarse punteros de objetos para desplazarse rápidamente sin necesidad de combinar tablas.
Los tipos de objetos permiten a los desarrolladores de aplicaciones codificar la lógica de la aplicación en la base de datos o en el servidor de aplicaciones de nivel intermedio, en lugar de utilizar código en el lado del cliente. Todas las aplicaciones podrán compartir entonces la lógica de los nuevos tipos de datos, por lo que los desarrolladores no tienen que volver a escribir el código. Esta característica ofrece las ventajas de crear componentes de código reutilizables y una segmentación transparente de las aplicaciones, por lo que el código puede residir y ejecutarse en el nivel que mayor rendimiento aporte ya sea el cliente, el servidor de aplicaciones o el servidor de base de datos.
Oracle8 sigue el estándar SQL3 en lo relativo a la definición de tipos de objetos y las técnicas de modelización de objetos. SQL3 define la sintaxis para crear y modificar tipos de objetos, generar y almacenar identificadores de objetos, crear referencias o punteros de objetos y modelizar colecciones de objetos similares.
Requisitos de una base de datos objeto-relacional
Los objetos se han integrado completamente en Oracle8, a todos los niveles del servidor. Todas las propiedades avanzadas del servidor Oracle se proporcionan con objetos, incluidas avanzadas posibilidades tales como el modelo de concurrencia, alto rendimiento, escalabilidad, fiabilidad, capacidad de gestión y disponibilidad.
Un sistema de gestión de base de datos objeto-relacional (ORDBMS) debe combinar las prestaciones más útiles la modelización de objetos y almacenamiento relacional. Un ORDBMS debe ofrecer las siguientes posibilidades:
Tipos de datos definidos por el usuario
Una base de datos objeto- relacional debe ofrecer tipos de datos definidos por el usuario que permitan a las empresas y organizaciones ampliar la funcionalidad del servidor para gestionar las operaciones realizadas con estos tipos. Además, un tipo definido por el usuario debe interactuar con los otros datos del sistema de la misma manera que cualquier otro tipo de datos.
Por ejemplo, un sistema de gestión de base de datos objeto-relacional debe permitir a los usuarios definir un tipo de dato, en el que los atributos serían similares a las columnas de una tabla relacional. En este tipo de datos, los métodos definen cómo interactúa una aplicación con los datos, de la misma manera que los procedimientos almacenados se pueden definir en una base de datos relacional.
Una aplicación sólo tiene que solicitar el objeto deseado, y la base de datos devuelve toda la información asociada al mismo.
También debe permite a las empresas y organizaciones modelizar objetos con cualquier nivel de detalle y a continuación referenciar esos objetos para crear objetos más complejos. Por ejemplo, en una empresa, un departamento está formado por varios objetos más complejos: personas, activos, un jefe y ubicaciones, entre otros. Para modelizar un departamento en un gestor de base de datos objeto-relacional, debe definirse las características de cada uno de sus componentes es decir los objetos. Las ubicaciones tendrían atributos tales como "Oficina", "Número" y "Edificio". Las personas tendrían los atributos de "Nombre" y "Dirección", y referencias o punteros a los objetos Ubicación, Activos y Jefe.
Funciones de tipos de datos flexibles y seguras
Para que un sistema sea verdaderamente objeto-relacional, los tipos de datos definidos por el usuario deben proporcionar un mecanismo flexible y seguro para ampliar las funciones. Por ejemplo, las funciones de miembro de un tipo deben ejecutarse en el cliente o en el servidor, dependiendo de las necesidades de seguridad y rendimiento del sistema. Las siguientes características son esenciales para las extensiones de tipos objeto-relacional:
Oracle8 satisface todas estas necesidades. Las funciones de un tipo pueden ser procedimientos ejecutados en el servidor, o bien llamadas vinculadas dinámicamente y realizadas a aplicaciones codificadas mediante lenguajes de tercera generación. En la parte del servidor, las funciones se pueden escribir en PL/SQL o en Java. Ambos protegen el código del servidor contra un posible bloqueo si la función dada por el usuario experimenta un fallo, y ambos se pueden añadir dinámicamente a un objeto. Cualquier función de un objeto tiene acceso a los datos del servidor para realizar consultas u operaciones de callback.
Mejor soporte de aplicaciones multimedia y grandes objetos de datos
Al añadir vídeo, imágenes y sonidos a los datos escalares tradicionales se mejora la utilidad de la aplicación, pero también aumenta considerablemente la cantidad de almacenamiento que ocupa un objeto. El ORDBMS debe gestionar objetos grandes (LOBs) de manera eficaz y con un rendimiento razonable. La base de datos también debe proporcionar a las aplicaciones clientes un acceso aleatorio y por partes a grandes objetos, con el fin de que sólo sea necesario recuperar a través de la red la parte solicitada de los datos.
Los objetos grandes, llamados LOBs
gestionan datos no estructurados tales como imágenes, sonidos,
vídeo y texto, y cuentan con una funcionalidad superior que sus
predecesores LONG y LONG RAW. Los LOBs de caracteres (CLOB o
NCLOB), los LOBs binarios y los BFILES o LOBs almacenados
externamente se pueden duplicar y utilizarse como atributo de un
objeto. También se puede disponer de más de un LOB por
tabla/objeto. Los LOBs tienen un tamaño máximo superior que los
LONGs y cuentan con mecanismos diferentes para mantener la
coherencia de lectura y el acceso aleatorio.
Los datos de los LOBs están indexados para permitir un acceso
rápido a partir de un byte especificado. También es posible
leer/escribir LOBs a través de la memoria caché intermedia de
Oracle8, o acceder a los mismos directamente desde disco.
Los LOBs tales como vídeo, programas ejecutables, o incluso grandes bloques de texto se pueden almacenar en tabla/objetos separados o en dispositivos independientes, como unidades de CD-ROM. Las empresas y organizaciones deben ser capaces de especificar los nombres de los sistemas de archivos para los objetos grandes almacenados externamente, o bien nombres de tabla/objetos independientes para los objetos grandes almacenados en la misma base de datos que otros datos. Asimismo, uno o más objetos grandes pueden formar parte de un objeto y aprovechar cualquier función de objeto ampliada, independientemente de las características de almacenamiento de los LOBs.
Compatibilidad con los standares actuales y con SQL
Oracle ha definido una arquitectura, llamada NCA, que representa un modelo para el proceso distribuido orientado a objetos en la. Esta arquitectura ofrece un marco unificado que permite que los diversos sistemas de procesamiento cliente/servidor, World Wide Web y la tecnología de objetos distribuidos como CORBA o DCOM compartan un modelo común basado en estándares.
La arquitectura NCA está basada en cartridges programables que se utilizan para ampliar cualquier nivel en un entorno de "n" niveles. Un cartridge es un programa escrito por el usuario que se comunica con el servidor, el servidor de aplicaciones o el cliente mediante el protocolo inter-orbe de Internet (IIOP).
Los tipos de objetos definidos en SQL3 constituyen la base de los objetos de Oracle8. Oracle ha desarrollado su estrategia de objetos en conjunto con el desarrollo del estándar SQL3 y ha contribuido a la definición de esta norma. Así, Oracle sigue el nuevo estándar SQL3 definido por el comité ANSI/ISO y ha adoptado las normas CORBA del Object Management Group (OMG) y DCOM (Distributed Common Object Model) de Microsoft para el procesamiento basado en objetos distribuidos.
CORBA y DCOM definen cómo se comunican los objetos entre sí y son una parte importante de NCA.
Llamadas a procedimientos externos desde la base de datos
Oracle proporciona un método rápido y seguro para que la base de datos realice una llamada a un programa externo escrito en C, C++ o Java. La llamada también se puede realizar a través de protocolos abiertos como HTTP o IIOP. Los procedimientos externos permiten utilizar el código existente de las aplicaciones, o bien escribir código optimizado para fines específicos, como por ejemplo un algoritmo complejo como una transformación rápida de Fourrier (FFT). Tambien, pueden utilizarse procedimientos externos para interactuar con otras aplicaciones o con dispositivos especializados, como sistemas integrados.
Soporte de objetos en el lado del cliente
La memoria caché de objetos del lado del cliente permite a las aplicaciones del usuario recuperar una jerarquía compleja de objetos en una memoria caché de aplicación. La aplicación puede entonces desplazarse a través de los objetos sin realizar recuperaciones adicionales en la red. Esto ofrece una manera práctica y rápida de utilizar objetos en una aplicación cliente y escribir código que sea más parecido al código nativo orientado a objetos.
Evolución de los entornos relacionales
Oracle8 se ha diseñado para facilitar la evolución hacia la nueva funcionalidad orientada a objetos por parte de los usuarios, ya que todas las aplicaciones existentes serán compatibles con las versiones posteriores. Las nuevas extensiones objeto-relacional se fundamentan en la misma base que la funcionalidad relacional, por lo que los usuarios no tienen que desechar o volver a escribir sus aplicaciones relacionales existentes antes de realizar la migración a Oracle8. A diferencia de lo que ocurre con otras bases de datos objeto-relacionales, este diseño permite que las aplicaciones relacionales más antiguas coexistan con las nuevas aplicaciones orientadas a objetos, que leen y escriben objetos.
Oracle8 proporciona vistas de objetos para recuperar datos relacionales y presentar los datos a un cliente como si fuesen un objeto, y viceversa.
Por ejemplo, un sistema relacional de introducción de pedidos ya existente podría necesitar un nuevo front-end, parte del programa que es responsable de la interface del operador, para World Wide Web. Las aplicaciones existentes que acceden al esquema relacional pueden seguir en funcionamiento y se puede desarrollar un nuevo conjunto de vistas de objetos como una representación de objetos para el cliente Web. Las aplicaciones nuevas y antiguas se pueden basar en los mismos datos, pero cada una tiene su propia representación.
Soporte de estándares abiertos: Java
Oracle ha elaborado tres iniciativas para admitir Java:
Oracle8 ofrece Java en el nivel de base de datos. Esto extiende el soporte de la VM ("máquina virtual") Java por parte de Oracle al nivel de aplicación y al nivel de base de datos. Puesto que las VMs Java ya se admiten en el cliente, ello ofrece a los programadores una portabilidad a través de distintos niveles y una potencia para segmentar la aplicación de manera flexible a través de esos niveles. En la base de datos, los desarrolladores pueden utilizar Java con el fin de escribir procedimientos, triggers y métodos almacenados para los objetos de Oracle8, por lo que Java se convierte en una excelente elección para escribir bloques de datos. La VM Java está estrechamente integrada en el motor del SGBDR y se ejecuta en el mismo espacio de dirección, aportando un elevado rendimiento.
Herramientas de desarrollo para la modelización de objetos
Las herramientas de desarrollo y de modelización gráfica son muy importantes para asegurar el éxito de cualquier proyecto de desarrollo. Un buen ORDBMS debe disponer de una serie complementaria de herramientas de desarrollo para modelización, desarrollo rápido de aplicaciones y generación de informes. Las herramientas existentes de Oracle, tales como Designer/2000 y Developer/2000, son capaces de comunicarse con los objetos Oracle8. Además, una nueva herramienta, denominada Sedona&trade, es el mejor entorno de desarrollo de objetos para Oracle8. Sedona está integrada con la funcionalidad del servidor y aporta funciones de modelización de objetos y creación directa de objetos Oracle8. Además, otros proveedores de herramientas, como Rational Software Corporation, admiten el desarrollo de objetos con Oracle8.
Sedona proporciona una correlación automática de objetos definidos por el usuario con objetos contenidos en el servidor Oracle o en las tablas relacionales. Una vez que se haya desarrollado un modelo de objetos, las empresas podrán integrarlo de forma persistente en la base de datos a través de herramientas de desarrollo GUI. Las aplicaciones cliente podrán entonces acceder a, y generar una instancia para cualquiera
de los objetos creados. El administrador de objetos de Sedona gestiona toda la conversión de objetos a tablas relacionales.
Objeto frente a objeto-relacional
Durante la última década, varios proveedores de productos orientados a objetos han desarrollado bases de datos de objetos. Los DBMSs de objetos son capaces de modelizar complejas jerarquías de objetos y están estrechamente integrados con lenguajes de desarrollo orientados a objetos como C++ y Smalltalk. Sin embargo, el enfoque orientado a objetos carece de las avanzadas prestaciones de optimización de consultas, seguridad, escalabilidad y fiabilidad que precisa una base de datos empresarial.
Las bases de datos orientadas a objetos no abordan las mismas necesidades que las bases de datos relacionales de objetos. Las bases de datos de objetos resultan indicadas para la modelización de datos técnicos y para desplazarse con rapidez a través de gráficos de tamaño moderado o redes de datos. Las aplicaciones CAD/CAM y científicas se pueden beneficiar del modelo de persistencia orientado a objetos. En esos tipos de aplicaciones, la representación de los datos y la complejidad de su estructura son más importantes que un acceso seguro a los datos o consultas a gran escala. Las bases de datos de objetos no están diseñadas para dar soporte a elevados números de usuarios concurrentes o para aportar un control transaccional del acceso a los datos.
Por otra parte, aunque aplicaciones convencionales como sistemas de información de clientes, de introducción de pedidos, de fabricación y de facturación normalmente precisan una representación menos avanzada, sí exigen fiabilidad, disponibilidad y escalabilidad. Asimismo, ya que las bases de datos de objetos están integradas con los lenguajes orientados a objetos, no existe una vía de migración desde los datos relacionales a las bases de datos de objetos. Por lo tanto, resulta difícil, y hasta imposible, trasladar o acceder a los datos relacionales ya existentes. Para las aplicaciones convencionales, una evolución del modelo relacional es la mejor solución.
Otras mejoras
Migración e interoperatividad
Una utilidad de migración sencilla y rápida reconstruye el diccionario de datos y convierte los archivos de control, los archivos de registro y los bloques de datos. La utilidad de migración convierte cualquier base de datos Oracle, ya sea 7.1, 7.2 ó 7.3, en una base de datos Oracle8. Las aplicaciones Oracle7 se ejecutan sin cambio alguno con Oracle8, mientras que los comandos distribuidos de Oracle8 se ejecutan con Oracle7, y viceversa.