En un modelo orientado a objetos (OOM), al presentar datos, es posible identificar registros de bases de datos individuales. Las relaciones se establecen entre los registros de la base de datos y sus funciones de procesamiento utilizando mecanismos similares a las instalaciones correspondientes en los lenguajes de programación orientados a objetos.

El OOM estándar se describe en las recomendaciones del estándar ODMG-93 (Grupo de administración de bases de datos de objetos, un grupo para administrar bases de datos orientadas a objetos). Todavía no ha sido posible implementar completamente las recomendaciones de ODMG-93. Para ilustrar las ideas clave, considere un modelo algo simplificado de una base de datos orientada a objetos.

La estructura de la OO DB se representa gráficamente como un árbol, cuyos nodos son objetos. Las propiedades de los objetos se describen mediante algún tipo estándar (por ejemplo, cadena - cadena) o un tipo construido por el usuario (definido como una clase).

El valor de una propiedad de tipo cadena es una cadena de caracteres. El valor de una propiedad de tipo clase es un objeto que es una instancia de la clase correspondiente. Cada objeto de instancia de clase se considera un elemento secundario del objeto en el que se define como una propiedad. Un objeto de instancia de una clase pertenece a su clase y tiene un padre. Las relaciones genéricas en la base de datos forman una jerarquía conectada de objetos.

Un ejemplo de la estructura lógica del OO DB de biblioteconomía se muestra en la fig. 3.14. Aquí, el objeto de tipo BIBLIOTECA es el padre de los objetos de instancia de las clases SUBSCRIBER, CATALOG y ISSUANCE. Los diferentes objetos de tipo BOOK que tienen el mismo padre deben diferir en al menos un número de acceso (único para cada instancia del libro), pero tienen los mismos valores de propiedad isbn, udk, título y autor.

Figura 3.14. Estructura lógica de la base de datos de biblioteconomía

La estructura lógica de la base de datos OO es aparentemente similar a la estructura de una base de datos jerárquica. La principal diferencia entre ellos está en los métodos de manipulación de datos. Para realizar acciones sobre los datos en la base de datos OOM, se utilizan operaciones lógicas, mejoradas por mecanismos orientados a objetos de encapsulación, herencia y polimorfismo. Las operaciones similares a los comandos SQL se pueden utilizar de forma limitada (por ejemplo, para crear una base de datos).

La creación y modificación de la base de datos va acompañada de la formación automática y el posterior ajuste de índices (tablas de índices) que contienen información para la recuperación rápida de datos.

Consideremos brevemente los conceptos de encapsulación, herencia y polimorfismo en relación con el OOM de una base de datos.

Encapsulación limita el alcance de un nombre de propiedad al objeto en el que se define. Entonces, si agrega una propiedad a un objeto de tipo CATALOG que especifica el número de teléfono del autor del libro y tiene el nombre teléfono, luego obtendremos las propiedades del mismo nombre para los objetos SUBSCRIBER y CATALOG. El significado de tal propiedad estará determinado por el objeto en el que se encapsula.

Herencia, en su lugar, extiende el alcance de la propiedad a todos los descendientes del objeto. Así, a todos los objetos de tipo LIBRO, que son descendientes de un objeto de tipo CATALOGO, se les pueden asignar las propiedades del objeto padre: isbn, udk, título y autor. Si es necesario extender la acción del mecanismo de herencia a objetos que no son parientes inmediatos (por ejemplo, entre dos descendientes del mismo padre), entonces se define una propiedad abstracta de tipo abs en su ancestro común. Así, la definición de propiedades abstractas boleto y habitación en el objeto BIBLIOTECA hace que todos los objetos secundarios de SUBSCRIBER, BOOK y LENDER hereden estas propiedades. No es casualidad que por lo tanto los valores de propiedad boleto las clases de SUSCRIPTOR y EMISIÓN que se muestran en la figura serán las mismas - 00015.

Polimorfismo en lenguajes de programación orientados a objetos significa la capacidad del mismo código de programa para trabajar con datos heterogéneos. En otras palabras, significa que objetos de diferentes tipos pueden tener métodos (procedimientos o funciones) con los mismos nombres. Durante la ejecución de un programa objeto, los mismos métodos operan en diferentes objetos dependiendo del tipo de argumento. En relación con nuestra OO DB, el polimorfismo significa que los objetos de la clase BOOK que tienen diferentes padres de la clase CATALOG pueden tener un conjunto diferente de propiedades. En consecuencia, los programas para trabajar con objetos de la clase BOOK pueden contener código polimórfico.

La búsqueda en la OO DB consiste en encontrar las similitudes entre el objeto especificado por el usuario y los objetos almacenados en la base de datos. Un objeto definido por el usuario llamado objeto objetivo (propiedad de objeto de tipo objetivo) generalmente puede ser un subconjunto de toda la jerarquía de objetos almacenada en la base de datos. El objeto de destino, así como el resultado de la ejecución de la consulta, se pueden almacenar en la propia base de datos. Un ejemplo de una consulta sobre los números de tarjetas de biblioteca y los nombres de suscriptores que recibieron al menos un libro en la biblioteca se muestra en la figura 3.15.

Principal dignidad Los datos OOM en comparación con los relacionales es la capacidad de mostrar información sobre las relaciones complejas de los objetos. Los datos OOM le permiten identificar un solo registro de la base de datos y determinar las funciones de su procesamiento.

desventaja Los OOM son de alta complejidad conceptual, inconvenientes en el procesamiento de datos y baja velocidad de ejecución de consultas.

Figura 3.15. Fragmento de base de datos con objeto de destino

Volvamos de nuevo al problema de los pedidos, presentado en forma de modelo de datos relacional en la fig. 3.8 y considérelo en términos de una base de datos orientada a objetos. Hay tres clases en total: Clientela», « Pedidos" y " productos". Objetos de la clase " Clientela» son clientes específicos; propiedades de clase: número de cliente, ciudad del nombre del cliente, estado, etc. Métodos de clase - " Crear orden», « Pagar la factura etc Un método es alguna operación que se puede aplicar a un objeto; un método es lo que debe hacer un objeto. La clase correspondiente a la tabla " Detalles del pedido", no requerido. Los datos de la tabla pueden ser parte de la clase " Pedidos". presencia en clase Clientela» método « Crear orden" conduce a la interacción con objetos de clases " Pedidos" y " productos". En este caso, el usuario no necesita saber acerca de esta interacción de objetos. El usuario solo accede al objeto " Pedidos' y utiliza el método ' Crear orden". El hecho de impacto en otras bases de datos se puede ocultar al usuario. Si el método Crear orden", a su vez, se refiere al método" Comprobar la solvencia del cliente”, entonces este hecho también se puede ocultar al usuario. Las bases de datos relacionales requieren que escriba procedimientos en Visual Basic para aplicaciones (VBA) para realizar las mismas funciones.

En la década de 1990 hubo prototipos experimentales de sistemas de gestión de bases de datos orientados a objetos. En la actualidad, tales sistemas son ampliamente utilizados. En particular, estos incluyen los siguientes DBMS: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltech Plus Research and Production Center) e Iris, Orion y postgres.

Base de datos orientada a objetos(OOBD): una base de datos en la que los datos se modelan en forma de objetos, sus atributos, métodos y clases.

Las bases de datos orientadas a objetos suelen recomendarse para aquellos casos en los que se requiere un procesamiento de datos de alto rendimiento con una estructura compleja.

El manifiesto OODB propone características obligatorias que debe cumplir cualquier OODB. Su elección se basa en 2 criterios: el sistema debe estar orientado a objetos y ser una base de datos.

Características obligatorias

1. Soporte para objetos complejos. El sistema debe prever la posibilidad de crear objetos compuestos utilizando constructores de objetos compuestos. Es necesario que los constructores de objetos sean ortogonales, es decir, cualquier constructor se puede aplicar a cualquier objeto.

2. Apoyo a la individualidad de los objetos. Todos los objetos deben tener un identificador único que sea independiente de sus valores de atributo.

3. Soporte de encapsulación. La encapsulación correcta se logra debido al hecho de que los programadores tienen derecho a acceder solo a la especificación de la interfaz de los métodos, y los datos y la implementación de los métodos están ocultos dentro de los objetos.

4. Soporte para tipos y clases. Se requiere que el OODB soporte al menos un concepto de la distinción entre tipos y clases. (El término "tipo" es más apropiado para un tipo de datos abstracto. En los lenguajes de programación, una variable se declara con su tipo. El compilador puede usar esta información para verificar que las operaciones realizadas en la variable sean compatibles con su tipo, lo que ayuda a garantizar que el software es correcto Por otro lado, una clase es una plantilla para crear objetos y proporciona métodos que se pueden aplicar a esos objetos, por lo que "clase" se trata más del tiempo de ejecución que del tiempo de compilación).

5. Soporte para la herencia de tipos y clases de sus ancestros. Un subtipo o subclase debe heredar atributos y métodos de su supertipo o superclase, respectivamente.

6. Sobrecarga combinada con atascamiento total. Los métodos deben aplicarse a objetos de diferentes tipos. La implementación del método debe depender del tipo de objetos a los que se aplica el método. Para proporcionar esta funcionalidad, la vinculación de nombres de métodos en el sistema no debe tener lugar hasta el tiempo de ejecución del programa.

7. Completitud computacional. El lenguaje de manipulación de datos debe ser un lenguaje de programación de propósito general.

8. El conjunto de tipos de datos debe ser extensible. El usuario debe tener los medios para crear nuevos tipos de datos basados ​​en un conjunto de tipos de sistema predefinidos. Además, no debería haber ninguna diferencia entre la forma en que se utilizan los tipos de datos del sistema y los definidos por el usuario.

OO SGBD

Bases de datos orientadas a objetos- bases de datos en las que la información se representa en forma de objetos, como en los lenguajes de programación orientados a objetos.

¿Usar o no usar sistemas de gestión de bases de datos orientados a objetos (OODBMS) en proyectos reales hoy en día? ¿Cuándo se deben usar y cuándo no?

Aquí Beneficios utilizando OODBMS:

· No hay problema de inconsistencia entre el modelo de datos en la aplicación y la base de datos (desajuste de impedancia). Todos los datos se almacenan en la base de datos de la misma forma que en el modelo de aplicación.

· No es necesario mantener por separado el modelo de datos en el lado DBMS.

· Todos los objetos en el nivel de origen de datos están fuertemente tipados. ¡No más nombres de columnas de cadenas! Refactorizar una base de datos orientada a objetos y el código que funciona con ella ahora está automatizado, no es un proceso monótono y aburrido.

Estándar ODMG

primer manifiesto formalmente era solo un artículo presentado en Jornada sobre Bases de Datos Orientadas a Objetos y Deductivas un grupo de individuos. Como pudo ver en la subsección anterior, los requisitos del Manifiesto eran más emocionales que especificados explícitamente. En 1991, se formó el consorcio ODMG (entonces esta abreviatura se reveló como Grupo de administración de bases de datos de objetos, pero luego adquirió una interpretación más amplia - Grupo de gestión de datos de objetos). El consorcio ODMG está estrechamente relacionado con el consorcio OMG mucho más grande ( grupo de administración de objetos), que se formó dos años antes. El principal objetivo original de ODMG era desarrollar un estándar industrial para bases de datos orientadas a objetos (modelo común). Se adoptó como base el modelo de objeto básico OMG COM ( Modelo de objeto central). Durante su más de una década de existencia, ODMG ha publicado tres versiones de referencia del estándar, la última de las cuales se llama ODMG 3.0. dieciséis

Es curioso que aunque ODMG (según el autor) ha evolucionado a partir de OMG, en los últimos años algunos estándares OMG se basan en el modelo de objetos ODMG. En particular, la especificación OCL se basa en el modelo ODMG ( Lenguaje de restricción de objetos), que forma parte de la especificación general del lenguaje UML 1.4 (y UML 2.0). En este artículo, no pretendemos realizar una comparación detallada de los enfoques OMG y ODMG y referir a los lectores interesados ​​a Enciclopedia Kogalovsky y materiales de los sitios web de estos consorcios. Nos limitaremos a un breve resumen de las principales ideas contenidas en el estándar ODMG-3.

Arquitectura ODMG

La arquitectura ODMG propuesta se muestra en la Fig. 2.1. Esta arquitectura define la forma en que se almacenan los datos y los diferentes tipos de acceso de los usuarios a este “almacén de datos” 17 . Se puede acceder al almacén de datos unificado desde el lenguaje de definición de datos, el lenguaje de consulta y varios lenguajes de manipulación de datos. 18 En la fig. 2.1 ODL significa Lenguaje de definición de objetos (lenguaje de definición de objetos), OQL - Lenguaje de consulta de objetos (lenguaje de consulta de objetos) y OML- Lenguaje de manipulación de objetos (lenguaje de manipulación de objetos).

Arroz. 2.1. Arquitectura ODMG

El centro de la arquitectura es modelo de datos A que representa la estructura organizativa en la que se almacenan todos los datos gestionados por el OODBMS. El lenguaje de definición de objetos, el lenguaje de consulta y los lenguajes de manipulación están diseñados de tal manera que todas sus capacidades se basan en el modelo de datos. La arquitectura permite una variedad de estructuras de implementación para almacenar los datos que se modelan, pero un requisito importante es que todas las bibliotecas de software y todas las herramientas de soporte se proporcionen en un marco orientado a objetos y deben mantenerse consistentes con los datos.

Los componentes principales de la arquitectura son los siguientes.

• Modelo de datos de objetos. Todos los datos almacenados por un OODBMS están estructurados en términos de construcciones de modelos de datos. La semántica exacta de todos los conceptos se define en el modelo de datos (consulte a continuación para obtener más detalles).

• Lenguaje de definición de datos (ODL). Los esquemas de bases de datos se describen en términos del lenguaje ODL, en el que las construcciones del modelo de datos se instancian en forma de un lenguaje de definición. ODL le permite describir un esquema como un conjunto de interfaces de tipo de objeto, que incluye una descripción de las propiedades de tipo y las relaciones entre ellos, así como los nombres de las operaciones y sus parámetros. ODL no es un lenguaje de programación completo; la implementación de los tipos debe hacerse en uno de los lenguajes de la categoría OML. Además, ODL es virtual lenguaje en el sentido de que el estándar ODMG no requiere su implementación en productos de software OODBMS que se consideran compatibles con el estándar. Es aceptable que estos productos admitan lenguajes de definición equivalentes que incluyan todas las funciones del ODL, pero que se adapten a las especificaciones de un sistema en particular. Sin embargo, la presencia de una especificación de lenguaje ODL en el estándar ODMG es importante porque el lenguaje especifica las propiedades del modelo de datos.

• Lenguaje de consulta de objetos (ODL). El lenguaje tiene una sintaxis similar a la del lenguaje SQL, pero se basa en la semántica del modelo de objetos ODMG. El estándar permite el uso directo de OQL y su incrustación en uno de los lenguajes de la categoría OML.

modelo de datos relacionales

Casi todos los sistemas modernos se basan en relacional modelos de gestión de bases de datos (relacionales). Nombre relacional debido al hecho de que cada registro en dicha base de datos contiene información relacionada con un solo objeto específico.

V relacional DBMS todos los datos procesados ​​se presentan en forma de tablas planas. La información sobre los objetos de un determinado tipo se presenta en forma tabular: las columnas de la tabla contienen varios atributos de los objetos y las filas pretenden reducir las descripciones de todos los atributos a instancias de objetos individuales.

El modelo creado en la etapa de modelado infológico satisface al máximo los principios de relacionalidad. Sin embargo, para llevar este modelo a relacional, es necesario realizar un procedimiento llamado normalización.

La teoría de la normalización opera con cinco formas normales. Estos formularios están diseñados para reducir la redundancia de información, por lo que cada formulario normal posterior debe cumplir con los requisitos del anterior y algunas condiciones adicionales. En el diseño práctico de una base de datos, por lo general no se utilizan las formas cuarta y quinta. Nos hemos limitado a las primeras cuatro formas normales.

Introduzcamos los conceptos necesarios para comprender el proceso de llevar un modelo a un esquema relacional.

Actitud- abstracción del objeto descrito como un conjunto de sus propiedades. Durante la etapa infológica del diseño, hablamos sobre la abstracción de los objetos y les asignamos algunas propiedades. Ahora, con el diseño conceptual, pasamos al siguiente nivel de abstracción. En esta etapa, los objetos, como tales, ya no existen. Operamos con un conjunto de propiedades que definen un objeto.

Instancia de relación- un conjunto de valores de las propiedades de un objeto en particular.

Clave primaria- conjunto identificador de atributos, es decir, el valor de estos atributos es único a este respecto. No hay dos instancias de una relación que contengan los mismos valores en la clave principal.

atributo simple- un atributo cuyos valores son indivisibles.

Atributo complejo- un atributo cuyo valor es un conjunto de valores de varias propiedades diferentes de un objeto o varios valores de una propiedad.

Conceptos de esencia.

Dominio

El concepto de dominio es más específico de las bases de datos, aunque tiene algunas analogías con los subtipos en algunos lenguajes de programación. En su forma más general, un dominio se define especificando algún tipo de datos básico al que pertenecen los elementos del dominio y una expresión lógica arbitraria aplicada al elemento del tipo de datos. Si esta expresión booleana se evalúa como verdadera, entonces el elemento de datos es un elemento de dominio.

La interpretación intuitiva más correcta del concepto de dominio es la comprensión de un dominio como un conjunto potencial válido de valores de un tipo dado. Por ejemplo, el dominio "Nombres" en nuestro ejemplo se define en el tipo de cadena de caracteres base, pero sus valores solo pueden incluir cadenas que pueden representar un nombre (en particular, dichas cadenas no pueden comenzar con un carácter suave).

También se debe tener en cuenta el significado semántico del concepto de dominio: los datos se consideran comparables solo si pertenecen al mismo dominio. En nuestro ejemplo, los valores de los dominios "Pass Numbers" y "Group Numbers" son del tipo entero, pero no son comparables. Tenga en cuenta que la mayoría de los DBMS relacionales no utilizan el concepto de dominio, aunque ya se admite en Oracle V.7.

Las tecnologías de base de datos basadas en MD descritas anteriormente se basan en el concepto estático de almacenamiento de información, centrado en el modelado de datos. Sin embargo, nuevas áreas de aplicación de tecnología con objetos de base de datos complejos e interrelacionados, tales como:

Diseño asistido por ordenador;

Producción automatizada;

Desarrollo de software automatizado;

Sistemas de información de oficina;

sistemas multimedia;

sistemas de geoinformación;

Los sistemas de publicación y otros han demostrado las limitaciones del concepto estático en términos de modelado de objetos del mundo real.

Para nuevos tipos de aplicaciones de bases de datos complejas y especializadas, el concepto dinámico de almacenamiento de información es efectivo, lo que permite el modelado paralelo de datos y procesos que actúan sobre estos datos. Esto permite tener en cuenta la semántica del área temática y, por lo tanto, describir más adecuadamente estas aplicaciones. Este concepto se basa en el enfoque orientado a objetos ampliamente utilizado en el desarrollo de software. El MD que implementa este concepto y se basa en el paradigma orientado a objetos (OOP) se denomina modelo de datos orientado a objetos (OODM).

La construcción del OOMD se basa en la suposición de que el área temática puede describirse mediante un conjunto de objetos. Cada objeto es una entidad identificable de forma única que contiene atributos que describen el estado de los objetos del "mundo real" y sus acciones asociadas. El estado actual de un objeto se describe mediante uno o más atributos, que pueden ser simples o complejos. Un atributo simple puede tener un tipo primitivo (por ejemplo, entero, cadena, etc.) y tomar un valor literal. Un atributo compuesto puede contener colecciones y/o enlaces. Un atributo de enlace representa una relación entre objetos.

La propiedad clave de un objeto es la singularidad de su Identificación. Por lo tanto, cada objeto en un sistema orientado a objetos debe tener su propio identificador.

Un identificador de objeto (OID) es una forma interna de base de datos de marcar objetos individuales. Los usuarios que trabajan con una consulta o un cuadro de diálogo de visualización normalmente no ven estos identificadores. Son asignados y utilizados por el propio DBMS. La semántica del identificador en cada DBMS es diferente. Puede ser un valor aleatorio o contener la información necesaria para encontrar el objeto en el archivo de la base de datos, como el número de página en el archivo y el desplazamiento del objeto desde su inicio. Es el identificador que debe usarse para organizar las referencias al objeto.

Todos los objetos están encapsulados, es decir, la representación o estructura interna del objeto permanece oculta para el usuario. En cambio, el usuario solo sabe que el objeto puede realizar alguna función. Por ejemplo, para un objeto WAREHOUSE, se pueden aplicar métodos como ACCEPT_ITEM, ISSUE_TOBAP, etc.. La ventaja de la encapsulación es que permite cambiar la representación interna de los objetos sin rediseñar las aplicaciones que utilizan estos objetos. En otras palabras, la encapsulación implica independencia de datos.

Un objeto encapsula datos y funciones (métodos, según OOP). Los métodos definen el comportamiento de un objeto. Se pueden usar para cambiar el estado de un objeto cambiando los valores de sus atributos, o para consultar los valores de los atributos seleccionados. Por ejemplo, puede haber métodos para agregar información sobre una nueva propiedad de alquiler, para actualizar la información sobre el salario de un empleado o para imprimir información sobre un producto en particular.

Los objetos que tienen el mismo conjunto de atributos y responden a los mismos mensajes se pueden agrupar en Clase(en la literatura, los términos "clase" y "tipo" a menudo se usan indistintamente). Cada una de estas clases tiene su propio representante: un objeto, que es el elemento de datos. Los objetos de cierta clase se llaman copias.

En algunos sistemas orientados a objetos, una clase también es un objeto y tiene sus propios atributos y métodos llamados atributos de clase y métodos de clase.

Los conceptos importantes de OOP son jerarquía de clases y jerarquía de contenedores.

jerarquía de clases implica la posibilidad de que cada clase, llamada en este caso superclase, tenga su propia subclase. Se puede citar como ejemplo la siguiente cadena: todos los programadores de una empresa son sus empleados, por lo tanto, cada programador que, en el marco de los OODM, es un objeto de la clase PROGRAMADOR, es también un empleado, que a su vez , es un objeto de la clase EMPLEADOS. Así, PROGRAMADORES sería una subclase, PERSONAL sería una superclase. Pero los programadores también se pueden dividir en programadores de sistemas y de aplicaciones. Por lo tanto, PROGRAMMERS será una superclase de las subclases SIS_PROGRAMMERS y APPLIC_PROGRAMMERS. Continuando con esta cadena, obtenemos una jerarquía de clases, en la que cada objeto de subclase hereda instancias de variables y métodos de la superclase correspondiente.

Hay varios tipos de herencia: única, múltiple y selectiva. La herencia singular es cuando las subclases heredan como máximo de una superclase. Herencia múltiple: herencia de más de una superclase. La herencia selectiva permite que una subclase herede un número limitado de propiedades de su superclase.

La herencia de instancias variables se llama herencia estructural, herencia de método - herencia conductual, y la habilidad de usar el mismo método para diferentes clases, o más bien, usar diferentes métodos con el mismo nombre para diferentes clases, se llama polimorfismo.

La arquitectura orientada a objetos también tiene otro tipo de jerarquía: jerarquía de contenedores. Consiste en el hecho de que algunos objetos pueden estar conceptualmente contenidos dentro de otros. Así, un objeto de la clase DEPARTAMENTO debe contener una variable pública JEFE, que es una referencia al objeto de la clase EMPLEADO correspondiente al jefe del departamento, y también debe contener una referencia a un conjunto de referencias a objetos correspondientes a los empleados que trabajan en este departamento

En algunos sistemas orientados a objetos, una clase también es un objeto y tiene sus propios atributos y métodos. Las características generales de una clase son descritas por sus atributos. Los métodos de una clase de objeto son una especie de analogía de las propiedades de los objetos en el mundo real. Cada objeto que pertenece a una clase particular tiene estas propiedades. Por lo tanto, cuando se crea un objeto, es necesario declarar la clase a la que pertenece para definir sus propiedades inherentes.

El usuario y el objeto interactúan a través de mensajes. En respuesta a cada mensaje, el sistema ejecuta el método correspondiente.

Todas las relaciones en el modelo de objetos se realizan mediante atributos de referencia, que normalmente se implementan como OID.

Las relaciones en una base de datos relacional se representan mediante la coincidencia de claves primarias y externas. No hay estructuras en la propia base de datos para formar asociaciones entre tablas; los enlaces se utilizan según sea necesario al conectar las tablas. Por el contrario, las relaciones son la columna vertebral de una base de datos orientada a objetos porque cada objeto incluye los ID de los objetos con los que está asociado.

En OOMD, no solo se pueden implementar enlaces tradicionales, sino también enlaces por herencia.

Relación uno a uno (1:1) entre los objetos A y B se implementa agregando un atributo de referencia en el objeto B al objeto A y (para mantener la integridad referencial) un atributo de referencia en el objeto A al objeto B.

Relación de uno a muchos (1:M) entre los objetos A y B se implementa agregando un atributo de referencia al objeto B al objeto A y un atributo que contiene un conjunto de enlaces al objeto A al objeto B (por ejemplo, se agrega un atributo de referencia B (OID2, OID3 ...) al objeto A, e instancias del objeto B con OID2, OID3, ... se le añade el atributo de referencia A: OID1.

Relación de muchos a muchos (M:N) entre los objetos A y B se implementa agregando un atributo que contiene un conjunto de enlaces a cada objeto.

En OODM, puede utilizar la relación "total-parte", que describe que un objeto de una clase contiene objetos de otras clases como sus partes. En el caso de una base de datos de producción, habría una relación de "parte entera" entre la clase PRODUCTO y las clases PARTE y MONTAJE. Esta relación es una variante de la relación muchos a muchos que tiene una semántica especial. Una relación todo-parte se implementa como cualquier otra relación muchos a muchos, con un conjunto de identificadores de objetos asociados. Sin embargo, a diferencia de la relación habitual de muchos a muchos, tiene un significado semántico diferente.

Dado que el paradigma orientado a objetos admite la herencia, es posible utilizar una relación "es" y una relación "extiende" en OODM. La relación "es", también conocida como relación de generalización-especialización, crea una jerarquía de herencia en la que las subclases son casos especiales de superclases. Esto permite no describir características reheredadas. Cuando se utiliza la relación "extiende", la subclase amplía la funcionalidad de la superclase en lugar de limitarse a su caso especial.

Consideremos cómo se implementan en OOMD componentes como las restricciones de integridad y las operaciones en los datos.

Las características de estos componentes están determinadas por los detalles del modelo. Esta especificidad en OOMD está dictada principalmente por conceptos internos como la encapsulación de objetos, es decir, el secreto de la estructura interna, el acceso a los datos solo a través de métodos definidos de antemano, la jerarquía de clases y la jerarquía de contenedores.

Los detalles del OOMD también están dictados por los detalles del objeto. Se manifiesta en la necesidad de agrupar objetos en clases. Cada objeto se incluye en una clase u otra dependiendo de la tarea, y un objeto puede pertenecer a varias clases a la vez (por ejemplo, las familias PROGRAMADORES y MUY PAGADORES). Otra característica específica de un objeto es que puede "ejecutarse" de una clase (subclase) a otra. Así, un PROGRAMADOR DE SISTEMAS puede llegar a convertirse eventualmente en un PROGRAMADOR APLICADO. Por lo tanto, la jerarquía de clases no es análoga al modelo jerárquico, como podría parecer antes, sino que requiere que el sistema pueda cambiar la ubicación de cada objeto dentro de la jerarquía de clases, por ejemplo, mover "arriba" o "abajo" dentro la jerarquía dada. Pero también es posible un proceso más complejo: el sistema debe proporcionar la capacidad de que un objeto se adjunte (separe) a una parte superior arbitraria de la jerarquía en cualquier momento.

Las restricciones de integridad de enlace juegan un papel importante en OODM. Para que funcionen los enlaces en un DM orientado a objetos, los identificadores de objetos en ambos lados del enlace deben coincidir. Por ejemplo, si existe una asociación entre EMPLEADOS y sus HIJOS, entonces debe haber alguna garantía de que cuando un objeto que describe a un niño se inserta en un objeto que representa a un empleado, la identificación del empleado se agrega al objeto correspondiente. Este tipo de integridad de enlace, algo análoga a la integridad referencial en el modelo de datos relacionales, se establece con la ayuda de backlinks. Para garantizar la integridad de los enlaces, el diseñador cuenta con la sintaxis especial necesaria para especificar la ubicación del identificador inverso del objeto. Es responsabilidad del diseñador establecer restricciones sobre la integridad de las relaciones (así como la integridad referencial en una base de datos relacional).

En OOMD, tanto la descripción de los datos como su manipulación se realizan utilizando el mismo lenguaje de procedimiento orientado a objetos.

El ODMG (Grupo de gestión de bases de datos de objetos) se ocupa de los problemas de estandarización de la tecnología de las bases de datos de objetos. Ha desarrollado un modelo de objetos (ODMG 2.0 se adoptó en septiembre de 1997) que define un modelo estándar para la semántica de los objetos de la base de datos. Este modelo es importante porque define la semántica incorporada que un DBMS orientado a objetos (OODBMS) entiende y puede implementar. La estructura de las bibliotecas y aplicaciones que usan esta semántica debe ser portátil entre los diversos OODBMS que admiten el modelo de datos de objetos dado. Los componentes principales de la arquitectura ODMG son: modelo de objetos (OM), lenguaje de definición de objetos (ODL), lenguaje de consulta de objetos (OQL) y la capacidad de vincularse a C++, Java y Smalltalk.

El modelo de datos de objetos según el estándar ODMG 2.0 se caracteriza por las siguientes propiedades:

Los bloques de construcción básicos son objetos y literales. Cada objeto tiene un identificador único. Un literal no tiene su propio identificador y no puede existir por separado como un objeto. Los literales siempre están incrustados en los objetos y no pueden referenciarse individualmente;

Los objetos y los literales difieren según el tipo. Cada tipo tiene su propio dominio, compartido por todos los objetos y literales de ese tipo. Los tipos también pueden tener comportamiento. Si un tipo tiene algún comportamiento, todos los objetos de ese tipo tienen el mismo comportamiento. En la práctica, el tipo puede ser la clase a partir de la cual se crea el objeto, una interfaz o un tipo de datos simple (como un número entero). Se puede pensar en un objeto como una instancia de un tipo;

El estado de un objeto está definido por un conjunto de valores actuales implementados por un conjunto de propiedades. Estas propiedades pueden ser atributos de un objeto o relaciones entre un objeto y uno o más objetos;

El comportamiento de un objeto se define por un conjunto de operaciones que se pueden realizar sobre el objeto o sobre el objeto mismo. Las operaciones pueden tener una lista de parámetros de entrada y salida, cada uno de los cuales tiene un tipo estrictamente definido. Cada operación también puede devolver un resultado escrito;

La definición de la base de datos se almacena en un esquema escrito en el lenguaje de definición de objetos (ODL). La base de datos almacena objetos, lo que permite compartirlos entre diferentes usuarios y aplicaciones.

Los DBMS basados ​​en OODM se denominan DBMS orientados a objetos (OODBMS). Estos DBMS se denominan DBMS de tercera generación* (* La historia del desarrollo de modelos de almacenamiento de datos a menudo se divide en tres etapas (generaciones): la primera generación (finales de 1960 - principios de los 70) - modelos jerárquicos y de red; segunda generación (aproximadamente 1970-1980) - modelo relacional; tercera generación (década de 1980 - principios de la década de 2000) - modelos orientados a objetos)..

Hoy en día, las bases de datos orientadas a objetos se utilizan en varias organizaciones para resolver una amplia gama de problemas. El análisis y la generalización de la experiencia acumulada en el campo de los datos de tecnología de la información permitió identificar aplicaciones en las que se justifica el uso de bases de datos orientadas a objetos:

Una aplicación consta de un gran número de partes que interactúan. Cada uno de ellos tiene su propio comportamiento, que depende del comportamiento de los demás;

El sistema debe procesar grandes cantidades de estructura de datos compleja o no estructurada;

La aplicación tendrá un acceso predecible a los datos, por lo que la naturaleza de navegación de las bases de datos orientadas a objetos no será una desventaja significativa;

La necesidad de solicitudes no planificadas es limitada;

La estructura de los datos almacenados es de naturaleza jerárquica o similar.

En este momento, hay muchos DBMS orientados a objetos en el mercado de software. En mesa. 10.6 muestra algunos de los sistemas comerciales de esta clase.

Tabla 10.6

OODBMS comercial moderno,

sus empresas de fabricación y áreas de aplicación

Una de las diferencias fundamentales entre las bases de datos relacionales y de objetos es la capacidad de crear y utilizar nuevos tipos de datos. Una característica importante del OODBMS es que la creación de un nuevo tipo no requiere la modificación del núcleo de la base de datos y se basa en los principios de la programación orientada a objetos.

El kernel OODBMS está optimizado para operaciones con objetos. Sus operaciones naturales son el almacenamiento en caché de objetos, el control de versiones de objetos y la separación de derechos de acceso a objetos específicos. Los OODBMS se caracterizan por un mayor rendimiento en las operaciones que requieren acceso y recuperación de datos empaquetados en objetos, en comparación con los DBMS relacionales, para los cuales la necesidad de obtener datos relacionados lleva a operaciones internas adicionales.

De considerable importancia para OODBMS es la capacidad de mover objetos de una base de datos a otra.

Al crear varias aplicaciones basadas en OODBMS, la estructura de clases integrada de un DBMS en particular es importante. La biblioteca de clases, por regla general, admite no solo todos los tipos de datos estándar, sino también un conjunto extendido de multimedia y otros tipos de datos complejos, como video, sonido, secuencia de cuadros de animación. En algunos OODBMS se han creado bibliotecas de clases que permiten el almacenamiento y la búsqueda de texto completo de información documental (por ejemplo, Jasmine, ODB-Jupiter). Un ejemplo de la estructura de clases básica se muestra en la fig. 10.17.

La posición principal está ocupada por la clase TOdbObject, que contiene todas las propiedades y métodos necesarios para controlar el acceso a la base de datos y realizar la indexación. Todas las demás clases anulan sus métodos, agregando la validación del tipo que implementan y un indexador específico.

Como puede verse en la fig. 10.17, en la estructura hay varias clases enfocadas en el procesamiento de información documental: TOdbText, TOdbDocument, TODBTextDocument, etc. Cada documento está representado por un objeto separado. Así, se asegura la naturalidad del almacenamiento de documentos. Una de las operaciones más importantes es la búsqueda de documentos bajo demanda. Para la mayoría de las clases, se implementa la capacidad de buscar objetos por el valor de una clave específica. Para la clase TOdbText se implementa la capacidad de generar una consulta de búsqueda a partir de una frase escrita en lenguaje natural.

La clase TOdbDocument es especial, capaz de contener objetos de diferentes tipos. Consta de campos, cada uno de los cuales tiene un nombre y está asociado a un objeto de un determinado tipo. La presencia de esta clase le da al usuario la oportunidad de expandir el conjunto de tipos. Al modificar el objeto contenedor (documento), puede establecer un conjunto específico de campos y obtener un nuevo tipo de Documento.

Sobre la base de ODB-Jupiter, los desarrolladores de OODBMS han creado un sistema completo de recuperación de información ODB-Text, que tiene una estructura universal de datos almacenados y un poderoso mecanismo de búsqueda. El sistema ODB-Text es una herramienta para el procesamiento colectivo de documentos y el mantenimiento de un archivo corporativo. Entre las posibles aplicaciones, nombraremos la automatización de la contabilidad para el flujo de documentos de una oficina moderna, la construcción de sistemas de referencia e información (similares a las conocidas bases de datos legales), el mantenimiento de bases de datos en red, registros de personal, bibliografía, etc

41. Características de diseño de los SI aplicados. Fases del desarrollo de SI. (Tema 11, págs. 100-103).

11.1.3. Características del diseño del sistema de IC aplicado.

Al construir (seleccionar, adaptar) un sistema de información, puede usar dos conceptos principales, dos enfoques principales (el tercer concepto es su combinación):

1. Orientación a los problemas que necesitan ser resueltos con la ayuda de este sistema de información, es decir enfoque orientado a problemas (o enfoque inductivo);

2. centrarse en la tecnología que está disponible (actualizada) en un sistema o entorno determinado, es decir, enfoque orientado a la tecnología (o enfoque deductivo).

La elección del concepto depende de criterios, problemas y recursos estratégicos (tácticos) y (o) a largo plazo (corto plazo).

Si primero se estudian las capacidades de la tecnología existente y luego se determinan los problemas reales que se pueden resolver con su ayuda, entonces es necesario confiar en un enfoque orientado a la tecnología.

Si primero se identifican los problemas reales y luego se introduce la tecnología suficiente para resolver estos problemas, entonces es necesario confiar en un enfoque basado en problemas.

Al mismo tiempo, ambos conceptos de construir un sistema de información dependen el uno del otro: la introducción de nuevas tecnologías cambia los problemas que se resuelven, y cambiar los problemas que se resuelven lleva a la necesidad de introducir nuevas tecnologías; Ambos influyen en las decisiones que se toman.

El diseño (desarrollo) del sistema y el uso de cualquier sistema de información aplicado (corporativo) debe pasar por el siguiente ciclo de vida del sistema de información:

- análisis de anteproyecto (experiencia en la creación de otros sistemas similares, prototipos, diferencias y características del sistema que se está desarrollando, etc.), análisis de las manifestaciones externas del sistema;

– análisis intrasistema, análisis interno (análisis de subsistemas del sistema);

- descripción (morfológica) del sistema (representación) del sistema (descripción del objetivo del sistema, relaciones del sistema y conexiones con el medio ambiente, otros sistemas y recursos del sistema: material, energía, información, organización, humano, espacial y temporal);

– determinación de criterios de adecuación, eficiencia y sostenibilidad (fiabilidad);

– descripción funcional de los subsistemas del sistema (descripción de modelos, algoritmos para el funcionamiento de los subsistemas);

- creación de prototipos (descripción ficticia) del sistema, evaluación de la interacción de los subsistemas del sistema (desarrollo de un modelo - implementación de subsistemas con descripciones funcionales simplificadas, procedimientos y pruebas de la interacción de estos modelos para satisfacer el objetivo del sistema ), mientras que es posible utilizar "modelos" de criterios de adecuación, estabilidad, eficiencia;

- "ensamblaje" y prueba del sistema: la implementación de subsistemas y criterios funcionales completos, evaluación del modelo de acuerdo con los criterios formulados;

- operación del sistema;

– determinación de objetivos para un mayor desarrollo del sistema y sus aplicaciones;

- mantenimiento del sistema - aclaración, modificación, expansión de las capacidades del sistema en el modo de su operación (con el propósito de su evolución).

Estas etapas son las principales para la reingeniería de sistemas de información.

El desarrollo de un sistema de información corporativa, por regla general, se lleva a cabo para una empresa bien definida. Las características de la actividad en cuestión de la empresa, por supuesto, afectarán la estructura del sistema de información. Pero al mismo tiempo, las estructuras de las diferentes empresas son generalmente similares entre sí. Cada organización, independientemente del tipo de su actividad, consta de una serie de divisiones que realizan directamente uno u otro tipo de actividad de la empresa. Y esta situación es cierta para casi todas las organizaciones, sin importar en qué tipo de actividad se dediquen.

Por lo tanto, cualquier organización puede considerarse como un conjunto de elementos que interactúan (subdivisiones), cada uno de los cuales puede tener su propia estructura, bastante compleja. Las relaciones entre departamentos también son bastante complejas. En el caso general, existen tres tipos de vínculos entre las unidades de negocio:

Enlaces funcionales: cada división realiza ciertos tipos de trabajo dentro de un solo proceso comercial;

Comunicaciones de información: las unidades intercambian información (documentos, faxes, órdenes escritas y orales, etc.);

Comunicaciones externas: algunas unidades interactúan con sistemas externos y su interacción también puede ser tanto informativa como funcional.

La similitud de la estructura de diferentes empresas nos permite formular algunos principios comunes para construir sistemas de información corporativos.

En general, el proceso de desarrollo de un sistema de información se puede considerar desde dos puntos de vista:

Por tiempo, o por etapas del ciclo de vida del sistema en desarrollo. En este caso, consideramos la organización dinámica del proceso de desarrollo, descrito en términos de ciclos, etapas, iteraciones y etapas.

El sistema de información empresarial se desarrolla como un proyecto. Muchas características de las fases de gestión y desarrollo de proyectos (fases del ciclo de vida) son comunes y no dependen no solo del área temática, sino también de la naturaleza del proyecto (no importa si es un proyecto de ingeniería o uno económico). ). Por lo tanto, tiene sentido considerar primero una serie de cuestiones generales de gestión de proyectos.

Un proyecto es un cambio intencionado de tiempo limitado en un sistema separado con objetivos inicialmente claramente definidos, cuyo logro determina la finalización del proyecto, así como con requisitos establecidos para términos, resultados, riesgo, gasto de fondos y recursos, y estructura organizativa.

Por lo general, para un concepto complejo (que, en particular, es el concepto de un proyecto), es difícil dar una formulación inequívoca que cubra completamente todas las características del concepto introducido. Por lo tanto, la definición anterior no pretende ser única y completa.

Se pueden distinguir las siguientes características principales diferenciadoras del proyecto como objeto de gestión:

Variabilidad: transferencia intencionada del sistema de lo existente a algún

el estado deseado, descrito en términos de las metas del proyecto;

Limitación del objetivo final;

duración limitada;

Presupuesto limitado;

Se requieren recursos limitados;

Novedad para la empresa para la que se ejecuta el proyecto;

Complejidad: la presencia de una gran cantidad de factores que afectan directa o indirectamente el progreso y los resultados del proyecto;

Apoyo legal y organizativo: creación de una estructura organizativa específica para la duración del proyecto.

La eficiencia del trabajo se logra a través de la gestión del proceso de implementación del proyecto, que asegura la asignación de recursos, la coordinación de la secuencia de trabajo que se está realizando y la compensación de perturbaciones internas y externas.

Desde el punto de vista de la teoría de los sistemas de control, el proyecto como objeto de control debe ser observable y manejable, es decir, se distinguen unas características por las cuales es posible monitorear constantemente el progreso del proyecto (propiedad de observabilidad). Además, existe la necesidad de mecanismos de impacto oportuno en el curso de la implementación del proyecto (propiedad de controlabilidad).

La propiedad de controlabilidad es especialmente relevante en las condiciones de incertidumbre y variabilidad del área temática, que suelen acompañar a los proyectos de desarrollo de sistemas de información.

Cada proyecto, independientemente de la complejidad y la cantidad de trabajo requerida para su implementación, pasa por ciertas etapas en su desarrollo: desde el estado en que "todavía no hay proyecto" hasta el estado en que "el proyecto ya no existe". El conjunto de etapas de desarrollo desde el surgimiento de una idea hasta la finalización completa del proyecto generalmente se divide en fases (etapas, etapas).

Existen algunas diferencias en la determinación del número de fases y su contenido, ya que estas características dependen en gran medida de las condiciones para la implementación de un proyecto en particular y la experiencia de los principales participantes. Sin embargo, la lógica y el contenido principal del proceso de desarrollo de un sistema de información en casi todos los casos son comunes.

Se pueden distinguir las siguientes fases del desarrollo del sistema de información:

Formación de conceptos;

Desarrollo de especificaciones técnicas;

Diseño;

Fabricación;

Puesta en funcionamiento del sistema.

Consideremos cada uno de ellos con más detalle. La segunda y parcialmente la tercera fase se denominan generalmente fases de diseño del sistema, y ​​las dos últimas (a veces incluyen la fase de diseño) son las fases de implementación.

Fase de concepto

Formación de ideas, fijación de objetivos;

Formación del equipo clave del proyecto;

Estudiar la motivación y los requisitos del cliente y otros participantes;

Recopilación de datos iniciales y análisis del estado existente;

Definición de requisitos básicos y restricciones, recursos materiales, financieros y laborales requeridos;

Evaluación comparativa de alternativas;

Presentación de propuestas, su examen y aprobación.

Desarrollo de una propuesta técnica.

Desarrollo del contenido principal del proyecto, la estructura básica del proyecto;

Desarrollo y aprobación de términos de referencia;

Planificación, descomposición del modelo estructural básico del proyecto;

Elaborar estimaciones y presupuestos para el proyecto, determinando la necesidad de recursos;

Desarrollo de planes de calendario y horarios de trabajo ampliados;

Firmar un contrato con el cliente;

Puesta en funcionamiento de medios de comunicación de los participantes del proyecto y control sobre el avance de obra.

Diseño

En esta fase, se determinan los subsistemas y sus interconexiones, se seleccionan las formas más efectivas de implementación del proyecto y uso de recursos. Obras características de esta fase:

Implementación del trabajo de diseño básico;

Desarrollo de especificaciones técnicas privadas;

Implementación del diseño conceptual;

Elaboración de especificaciones técnicas e instrucciones;

Presentación del desarrollo del diseño, examen y aprobación.

Desarrollo

En esta fase, se lleva a cabo la coordinación y el control operativo del trabajo en el proyecto, se fabrican, combinan y prueban los subsistemas. Contenido principal:

Realización de trabajos de desarrollo de software;

Realizar los preparativos para la implementación del sistema;

Control y regulación de los principales indicadores del proyecto.

Puesta en marcha del sistema

En esta fase se realizan pruebas, prueba de funcionamiento del sistema en condiciones reales, se están negociando los resultados del proyecto y posibles nuevos contratos. Principales tipos de trabajo:

Pruebas complejas;

42. El concepto del ciclo de vida de la PI. (Tema 11, págs. 103-105).

Introducción

El surgimiento de la dirección de las bases de datos orientadas a objetos (OODB) estuvo determinado, en primer lugar, por las necesidades de la práctica: la necesidad de desarrollar sistemas de aplicación de información complejos para los cuales la tecnología de los sistemas de bases de datos anteriores no era del todo satisfactoria. Por supuesto, los OODB no surgieron de la nada. Tanto el trabajo previo en el campo de las bases de datos como el desarrollo de lenguajes de programación con tipos de datos abstractos y lenguajes de programación orientados a objetos proporcionaron una base adecuada.

Con respecto a la conexión con el trabajo previo en el campo de las bases de datos, el desarrollo del DBMS y la siguiente familia de bases de datos cronológicamente, que apoyaba la gestión de objetos complejos, tuvo la mayor influencia en el trabajo en el campo de OODB. Estos trabajos sirvieron de base estructural para la organización de la OODB. En este ensayo, se considerarán OOMD y OODBMS.

Modelo de datos orientado a objetos

Considere uno de los enfoques para crear una base de datos: el uso de un modelo de datos orientado a objetos (OODM). El modelado de datos en OOMD se basa en el concepto de un objeto. OOMD se suele utilizar en áreas temáticas complejas para el modelado en las que la funcionalidad de un modelo relacional no es suficiente (por ejemplo, para sistemas de automatización de diseño (CAD), sistemas de publicación, etc.).

El modelo de datos orientado a objetos ODMG difiere de otros modelos principalmente en un aspecto fundamental. En el modelo de datos SQL y el modelo de datos relacional verdadero, una base de datos es una colección de contenedores de datos con nombre del mismo tipo genérico: tablas o relaciones, respectivamente. En el modelo de datos orientado a objetos, una base de datos es un conjunto de objetos (contenedores de datos) de un tipo arbitrario.

Al crear DBMS orientado a objetos (OODBMS), se utilizan diferentes métodos, a saber:

incrustar en el lenguaje orientado a objetos herramientas diseñadas para trabajar con la base de datos;

extensión del lenguaje de base de datos existente con funciones orientadas a objetos;

creación de bibliotecas de funciones orientadas a objetos para trabajar con la base de datos;

creación de un nuevo lenguaje y un nuevo modelo de datos orientado a objetos.

Las ventajas de OOMD incluyen una amplia gama de capacidades de modelado de dominio, un lenguaje de consulta expresivo y alto rendimiento. Cada objeto en el OOMD tiene un identificador único (OID - identificador de objeto). La recuperación por OID es significativamente más rápida que las búsquedas en una tabla relacional.

Entre las deficiencias de OODM, cabe señalar la falta de un modelo generalmente aceptado, la falta de experiencia en la creación y operación de OODB, la complejidad de uso y la falta de herramientas de protección de datos.

Ahora veamos cómo se implementa el soporte del modelo de datos en los sistemas de administración de bases de datos reales.

En un modelo orientado a objetos (OOM), al presentar datos, es posible identificar registros de bases de datos individuales. Las relaciones se establecen entre los registros de la base de datos y sus funciones de procesamiento utilizando mecanismos similares a las instalaciones correspondientes en los lenguajes de programación orientados a objetos.

El OOM estándar se describe en las recomendaciones del estándar ODMG-93 (Grupo de administración de bases de datos de objetos, un grupo para administrar bases de datos orientadas a objetos). Todavía no ha sido posible implementar completamente las recomendaciones de ODMG-93. Para ilustrar las ideas clave, considere un modelo algo simplificado de una base de datos orientada a objetos.

La estructura de la OO DB se representa gráficamente como un árbol, cuyos nodos son objetos. Las propiedades de los objetos se describen mediante algún tipo estándar (por ejemplo, cadena - cadena) o un tipo construido por el usuario (definido como una clase).

El valor de una propiedad de tipo cadena es una cadena de caracteres. El valor de una propiedad de tipo clase es un objeto que es una instancia de la clase correspondiente. Cada objeto de instancia de clase se considera un elemento secundario del objeto en el que se define como una propiedad. Un objeto de instancia de una clase pertenece a su clase y tiene un padre. Las relaciones genéricas en la base de datos forman una jerarquía conectada de objetos.

El modelo relacional de Codd fue el primer modelo de datos formalizado y generalmente aceptado. En este modelo, como en todos los siguientes, se distinguieron tres aspectos: estructural, holístico y manipulativo. Las estructuras de datos en el modelo relacional se basan en relaciones planas normalizadas, las restricciones de integridad se expresan mediante lógica de primer orden y, por último, la manipulación de datos se basa en álgebra relacional o su cálculo relacional equivalente. Como señalan muchos investigadores, el éxito del modelo de datos relacionales se debe en gran medida al hecho de que se basó en el riguroso aparato matemático de la teoría de conjuntos, las relaciones y la lógica de primer orden. Los diseñadores de cualquier sistema relacional particular sintieron que era su deber mostrar que su modelo de datos particular se ajustaba al modelo relacional general, que actuaba como una medida de la "relatividad" del sistema.

Las principales dificultades del modelado de datos orientado a objetos provienen del hecho de que no existe un aparato matemático tan desarrollado, en el que podría basarse un modelo general de datos orientado a objetos. En gran medida, por lo tanto, todavía no existe un modelo básico orientado a objetos. Por otro lado, algunos autores argumentan que un modelo de datos general orientado a objetos en el sentido clásico no se puede definir debido a la inadecuación del concepto clásico de modelo de datos para el paradigma orientado a objetos.

Uno de los teóricos más famosos en el campo de los modelos de datos, Beery, ofrece en términos generales un marco formal para OODB, que está lejos de ser completo y no es un modelo de datos en el sentido tradicional, pero permite a los investigadores y desarrolladores de sistemas OODB al menos hable el mismo idioma (a menos, por supuesto, que las oraciones Beeri sean desarrolladas y respaldadas). Independientemente del destino de estas propuestas, consideramos útil volver a contarlas brevemente.

Primero, siguiendo la práctica de muchos OODB, se propone distinguir dos niveles de modelado de objetos: inferior (estructural) y superior (comportamental). A nivel estructural se soportan objetos complejos, su identificación y tipo de relación "isa". Una base de datos es una colección de elementos de datos vinculados por una relación de "parte de una clase" o "es un atributo". Por lo tanto, la base de datos se puede considerar como un gráfico dirigido. El punto importante es mantener, junto con el concepto de objeto, el concepto de valor (más adelante veremos cuánto se construye sobre esto en uno de los exitosos O2 DBMS orientados a objetos).

Un aspecto importante es una clara separación del esquema de la base de datos y la propia base de datos. Los conceptos principales del nivel de esquema OODB son tipos y clases. Se observa que en todos los sistemas que utilizan un solo concepto (ya sea un tipo o una clase), este concepto está inevitablemente sobrecargado: un tipo implica la presencia de un cierto conjunto de valores determinados por la estructura de datos de este tipo; la clase también asume la presencia de un conjunto de objetos, pero este conjunto lo define el usuario. Por lo tanto, los tipos y las clases juegan diferentes roles, y el rigor y la falta de ambigüedad requieren soporte simultáneo para ambos conceptos.

Beery no presenta un modelo formal completo del nivel estructural OODB, pero expresa confianza en que el nivel actual de comprensión es suficiente para formalizar dicho modelo. En cuanto al nivel conductual, sólo se ha propuesto una aproximación general al aparato lógico requerido para ello (la lógica del primer nivel no es suficiente).

La suposición importante, aunque no bien fundada, de Beery es que las dos capas tradicionales (esquema y datos) no son suficientes para OODB. Una definición precisa de OODB requiere un nivel de metaesquema, cuyo contenido debe definir los tipos de objetos y relaciones que se permiten en el nivel de esquema de la base de datos. El metaesquema debe desempeñar el mismo papel para OODB que la parte estructural del modelo de datos relacionales para los esquemas de bases de datos relacionales.

Hay muchas otras publicaciones relacionadas con el tema de los modelos de datos orientados a objetos, pero tocan temas bastante específicos o utilizan un aparato matemático que es demasiado serio para esta revisión (por ejemplo, algunos autores definen un modelo de datos orientado a objetos basado en la teoría de categorías).

Para ilustrar el estado actual de las cosas, veremos brevemente las características de un modelo de datos específico utilizado en O2 DBMS (esto, por supuesto, tampoco es un modelo de datos en el sentido clásico).

O2 apoya objetos y valores. Un objeto es un par (identificador, valor) y los objetos están encapsulados, es decir sus valores están disponibles solo a través de métodos: procedimientos adjuntos a objetos. Los valores pueden ser atómicos o de estructura. Los valores estructurales se construyen a partir de valores u objetos representados por sus identificadores utilizando constructores de conjuntos, tuplas y listas. Los elementos de valor estructural son accesibles a través de operaciones predefinidas (primitivas).

Son posibles dos tipos de organización de datos: clases, cuyas instancias son objetos que encapsulan datos y comportamiento, y tipos, cuyas instancias son valores. Cada clase está asociada con un tipo que describe la estructura de las instancias de clase. Los tipos se definen recursivamente en función de tipos atómicos y tipos y clases previamente definidos mediante constructores. El lado conductual de una clase está definido por un conjunto de métodos.

Se pueden nombrar objetos y valores. El nombramiento de un objeto o valor está asociado con su almacenamiento a largo plazo (persistencia): cualquier objeto o valor nombrado es a largo plazo; cualquier objeto o valor que sea parte de otro objeto o valor con nombre es duradero.

Con la ayuda de una sugerencia especial dada al definir una clase, es posible lograr el almacenamiento a largo plazo de cualquier objeto de esta clase. En este caso, el sistema genera automáticamente un valor establecido cuyo nombre es el mismo que el de la clase. Se garantiza que este conjunto contiene todos los objetos de la clase dada.

Un método es un código de programa adjunto a una clase específica y aplicable a objetos de esta clase. La definición de un método en O2 se realiza en dos pasos. Primero, se declara la firma del método, es decir su nombre, clase, tipos o clases de argumentos y el tipo o clase de resultado. Los métodos pueden ser públicos (accesibles desde objetos de otras clases) o privados (accesibles solo dentro de la clase dada). En la segunda etapa, la implementación de la clase se determina en uno de los lenguajes de programación O2 (los lenguajes se analizan con más detalle en la siguiente sección de nuestra revisión).

El modelo O2 admite la herencia de múltiples clases en función de la relación supertipo/subtipo. Se permite agregar y/o redefinir atributos y métodos en una subclase. Las posibles ambigüedades en la herencia múltiple (nombrando atributos y métodos) se resuelven cambiando el nombre o especificando explícitamente la fuente de la herencia. El objeto de subclase es el objeto de cada superclase de la que se deriva la subclase.

Se admite la clase predefinida "Objeto", que es la raíz de la red de clases; cualquier otra clase es descendiente implícita de la clase "Object" y hereda los métodos predefinidos ("is_same", "is_value_equal", etc.).

Una característica específica del modelo O2 es la capacidad de declarar atributos y métodos "exclusivos" adicionales para objetos con nombre. Esto significa que una instancia con nombre particular de una clase puede tener un tipo que sea un subtipo del tipo de clase. Por supuesto, los métodos de clase estándar no funcionan con dichos atributos, pero se pueden definir métodos adicionales (o estándares anulados) específicamente para un objeto con nombre, para el cual ya hay disponibles atributos adicionales. Se enfatiza que los atributos y métodos adicionales no están vinculados a un objeto específico, sino a un nombre que puede ser seguido por diferentes objetos en diferentes momentos. La implementación de atributos y métodos exclusivos requiere el desarrollo de técnicas de enlace tardío.

En la siguiente sección, entre otras cosas, consideraremos las características de los lenguajes de programación y las consultas del sistema O2 que, por supuesto, están estrechamente relacionadas con los detalles del modelo de datos.