ES2938058T3 - Base de datos de objetos para la modelización de negocios con mayor seguridad de los datos - Google Patents

Abstract

Las bases de datos de objetos basadas en la metodología SBM son sistemas holísticos, es decir, pueden manejar cualquier número de estructuras de datos sin tener las desventajas de un sistema monolítico, se pueden definir con una semántica simple y ofrecen una seguridad de datos significativamente mejorada. Mientras que las bases de datos convencionales almacenan una serie de objetos en una base de datos junto con claves, valores y métodos, SBM ofrece posibilidades de partición, específicamente la fragmentación de objetos en objetos clave y de valor y el almacenamiento separado de atributos y métodos. Además, a diferencia de los métodos convencionales, la funcionalidad de la base de datos también está fragmentada en la medida en que se mantiene en forma de objetos en la base de datos de objetos y se realiza en forma de métodos a través de servicios asociados para que los objetos puedan funcionar de acuerdo con diferentes principios de base de datos. El código ejecutable también se almacena por separado de los métodos. Esta metodología en principio permite objetos autónomos. Con SBM son posibles nuevas estructuras de almacenamiento escalables para una base de datos de objetos y, en particular, el hecho de que la funcionalidad de la base de datos fragmentada se distribuya en una pluralidad de ubicaciones de memoria especialmente protegidas permite un aumento significativo en la seguridad de los datos. Las empresas pueden decidir por sí mismas cuántas ubicaciones de memoria dividida se utilizan para la base de datos de objetos, según sus requisitos de seguridad y protección de datos y sobre la base de la distribución local de sus sitios. La figura 2 muestra una posible implementación cliente-servidor y la figura 3 muestra una posible instalación de un solo cliente. Las estructuras de almacenamiento escalables para una base de datos de objetos son posibles con SBM y, en particular, el hecho de que la funcionalidad de la base de datos fragmentada se distribuya en una pluralidad de ubicaciones de memoria especialmente protegidas permite un aumento significativo en la seguridad de los datos. Las empresas pueden decidir por sí mismas cuántas ubicaciones de memoria dividida se utilizan para la base de datos de objetos, según sus requisitos de seguridad y protección de datos y sobre la base de la distribución local de sus sitios. La figura 2 muestra una posible implementación cliente-servidor y la figura 3 muestra una posible instalación de un solo cliente. Las estructuras de almacenamiento escalables para una base de datos de objetos son posibles con SBM y, en particular, el hecho de que la funcionalidad de la base de datos fragmentada se distribuya en una pluralidad de ubicaciones de memoria especialmente protegidas permite un aumento significativo en la seguridad de los datos. Las empresas pueden decidir por sí mismas cuántas ubicaciones de memoria dividida se utilizan para la base de datos de objetos, según sus requisitos de seguridad y protección de datos y sobre la base de la distribución local de sus sitios. La figura 2 muestra una posible implementación cliente-servidor y la figura 3 muestra una posible instalación de un solo cliente. Las empresas pueden decidir por sí mismas cuántas ubicaciones de memoria dividida se utilizan para la base de datos de objetos, según sus requisitos de seguridad y protección de datos y sobre la base de la distribución local de sus sitios. La figura 2 muestra una posible implementación cliente-servidor y la figura 3 muestra una posible instalación de un solo cliente. Las empresas pueden decidir por sí mismas cuántas ubicaciones de memoria dividida se utilizan para la base de datos de objetos, según sus requisitos de seguridad y protección de datos y sobre la base de la distribución local de sus sitios. La figura 2 muestra una posible implementación cliente-servidor y la figura 3 muestra una posible instalación de un solo cliente. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Base de datos de objetos para la modelización de negocios con mayor seguridad de los datos

La invención se refiere a un procedimiento para procesar datos de base de datos en un sistema distribuido de base de datos de objetos según el término genérico de la reivindicación de patente 1.

Además, la invención se refiere a un dispositivo para procesar datos de base de datos en un sistema de base de datos de objetos según el término genérico de la reivindicación de patente 8.

1. Campo de aplicación

La invención se refiere a una base de datos de objetos modular para la modelización de negocios holística y orientada a objetos, en la que los datos y procesos empresariales de cualquier tipo se mapean en objetos por separado en objetos clave y objetos de valor, almacenándose también por separado los atributos y métodos de los objetos, y cuyo sistema de gestión de base de datos se implementa a su vez como objetos de la base de datos de objetos, con lo que se consigue un manejo globalmente más sencillo de la base de datos de objetos y una seguridad de los datos sustancialmente mejorada.

Indicaciones:

Los temas de la modelización de negocios, las bases de datos y la seguridad de los datos que se abordan a continuación son muy complejos, por lo que en el capítulo sobre el estado de la técnica solo pueden tratarse aspectos y ejemplos concretos, pero estos se eligen para ilustrar la situación actual. Los ejemplos utilizados a continuación son solo una pequeña selección y no pretenden ser completos. Las denominaciones y nombres utilizados a continuación sirven para una mejor comprensión y pueden sustituirse por cualquier otra denominación y nombre, especialmente los pertenecientes a la base de datos de objetos propuesta, como "business object".

2. Estado de la técnica

2.1. Modelización de negocios

La expresión "modelización de negocios" se utiliza a menudo como sinónimo de modelización de procesos de negocio y no debe confundirse con la expresión "modelo de negocio". A continuación, la modelización de negocios va más allá de la pura modelización de procesos, ya que los datos y la modelización de procesos se consideran en conjunto. En aras de simplicidad, el término empresa incluye en lo sucesivo cualquier tipo de sociedad, negocio, comercio, administración, centro educativo, institución, organización, asociación, persona privada, etc.

El estado actual de la modelización de negocios se refleja mejor en normas reconocidas internacionalmente, como la ISO 9001 y la correspondiente IATF 16949 para la industria del automóvil. La norma ISO 9001 se aplica no solo a las empresas de fabricación, sino también a las que prestan cualquier tipo de servicios. La certificación de una empresa según la norma ISO 9001 debe ofrecer a los clientes, proveedores u otras partes implicadas la garantía de que una empresa actúa de forma global de acuerdo con criterios de calidad elevados y normalizados. Para ello, hay que definir los objetivos de la empresa, por ejemplo, en los ámbitos de la orientación al cliente, las relaciones con los proveedores y la gestión, comprobar la consecución de los objetivos y esforzarse por mejorar continuamente. La norma ISO exige un enfoque orientado a los procesos, lo que significa que una empresa debe definir un panorama y una estructura de procesos completos.

En este tipo de modelización de negocios orientada a procesos, los procesos con sus responsabilidades ocupan el primer plano, mientras que los datos solo actúan como parámetros. Los procesos suelen almacenarse en bases de datos independientes, donde normalmente solo están documentados y son recuperables como información y no pueden automatizarse. Así, los flujos de datos suelen ser difíciles de rastrear y la automatización suele ser muy costosa porque los datos se almacenan en diferentes bases de datos, como sistemas de gestión de datos de productos, sistemas de requisitos de productos, sistemas de información sobre normas, bases de datos de personal o sistemas de gestión de proyectos. Debido a las diferentes bases de datos, lleva mucho tiempo vincular datos o información entre sí, como por ejemplo vincular un dibujo de una norma de fábrica, que se almacena como documento en una base de datos de normas, con la geometría de un componente de un producto, que se almacena en una base de datos de datos de productos, o incluso insertar automáticamente el dibujo en el componente. Además de las bases de datos individuales mencionadas como ejemplo, existen sistemas monolíticos que abarcan áreas temáticas enteras, como los sistemas ProductLifecycleManagement (PLM). Los distintos aspectos de PLM se basan en una base de datos común, para que sea más fácil establecer vínculos entre los datos, por ejemplo, entre los requisitos del producto y los datos del producto. Sin embargo, los cambios en la base de datos conllevan un esfuerzo considerable.

Existen varios métodos para describir las estructuras de los procesos. La invención se refiere a un método para procesar datos de base de datos en un sistema distribuido de base de datos de objetos según el término genérico de la reivindicación de patente 8. Los diagramas de flujo son una representación visual de los procesos que se modelan con métodos como EPK (cadena de procesos dirigida por eventos) o BPMN (modelo y notificación de procesos empresariales, un lenguaje de descripción normalizado). Una forma muy utilizada de visualizar los procesos es la representación en carriles de natación. Para cada área de responsabilidad o actor de un proceso, hay una fila o columna que muestra los pasos del proceso de los que el actor es responsable. Las flechas indican el flujo del proceso y, al pasar de una etapa del proceso en un carril a otra en un carril diferente, las responsabilidades se muestran claramente de forma visual. Este tipo de representación deja claro que uno de los objetivos de la modelización empresarial orientada a procesos es describir qué función de la empresa tiene que hacer qué y cuándo. Diferentes funciones de una empresa son responsables de la creación y ejecución de procesos; por regla general, no está previsto que los datos puedan controlar y ejecutar procesos de forma independiente.

2.2 Gestión del conocimiento

La revisión de 2015 de la norma ISO 9001 también contiene requisitos para la gestión del conocimiento, ya que este tema es cada vez más importante en las empresas. Aunque el valor del conocimiento no pueda cuantificarse concretamente, el conocimiento es un capital importante para las empresas. La protección del conocimiento desempeña aquí un papel fundamental, porque no todo el mundo puede acceder a la totalidad de los conocimientos. El objetivo de la gestión del conocimiento es hacer que la información adecuada esté disponible en el lugar adecuado y en el momento oportuno en una empresa. Diferentes categorías especifican el conocimiento: implícito frente a explícito, individual frente a organizativo y externo frente a interno. Mientras que el conocimiento explícito es fácilmente documentable, como en manuales, normas, procesos, reglas, etc., el conocimiento tácito es difícil de captar porque se basa en la experiencia, las habilidades, etc., lo que lo convierte en un conocimiento individual, o está presente en conjuntos de datos en los que primero hay que obtenerlo mediante análisis. El conocimiento puede documentarse de diversas formas, como se ha descrito anteriormente o en grandes bases de datos de conocimiento, que proporcionan una enorme cantidad de información y no han demostrado su utilidad, o en forma de reglas. Las reglas suelen formularse como sentencias condicionales: Si se cumple una condición, entonces toma una determinada decisión o reacciona con una acción. Las reglas pueden ayudar, por ejemplo, en el análisis de conjuntos de datos: Si B es hijo de A y A es mujer, entonces A es la madre de B. Esto permite encontrar a las madres en la base de datos sin que la propia "madre" aparezca en el conjunto de datos. Y pueden desencadenar acciones: Si el producto A tiene como componente el componente B, inserte la geometría estándar C en el componente B. Los sistemas de gestión de reglas de negocio (BRMS) ofrecen a las empresas la posibilidad de disponer de reglas definidas por expertos, que son aplicadas por expertos informáticos o automáticamente en el software. Las reglas son una forma importante de expresión del conocimiento que actúa por sí mismo. El problema es que las reglas tienen que acceder a datos almacenados en distintos sistemas de bases de datos, por lo que ese acceso solo es posible con interfaces cuya implementación resulta costosa.

2.3 Bases de datos

Las bases de datos relacionales suelen utilizarse para almacenar los datos que se acumulan en una empresa; los procesos suelen ser sólo datos, como se ha descrito anteriormente. Almacenan datos en forma de tablas relacionales, que contienen datos concretos y al mismo tiempo claves de filas de otras tablas, las relaciones. El responsable de acceder a los datos concretos de las tablas es el sistema de gestión de bases de datos (SGBD), que, entre otras cosas, proporciona operaciones con los datos y garantiza su integridad. El SGBD procesa órdenes programadas en lenguaje de consulta estructurado (SQL) y, por lo tanto, puede crear estructuras y almacenar o leer datos. Las estructuras de datos complejas son difíciles de trasladar a las estructuras de tablas relacionales planas. Del mismo modo, los cambios y ampliaciones de estructuras de tablas complejas sólo pueden hacerse con un esfuerzo considerable.

En comparación con las bases de datos relacionales, las bases de datos orientadas a objetos (OODB) son más bien escasas. Una OODB ofrece la posibilidad de crear objetos con sus propiedades (atributos) y comportamiento (métodos) como estructura o esquema de los datos y almacenar valores como sus instancias. Los propios atributos pueden consistir en otros objetos. También en este caso, un sistema de gestión de bases de datos regula los correspondientes pasos del procesamiento de datos, en este caso el sistema de gestión de bases de datos orientado a objetos (ooDBMS). A diferencia de los métodos relacionales, el enfoque orientado a objetos admite una asignación más sencilla de estructuras de datos complejas. En cambio, las bases de datos orientadas a objetos tienen una desventaja a la hora de procesar grandes cantidades de datos porque, por ejemplo, las vías de acceso se vuelven más complejas debido a mecanismos como la herencia, etc.

En principio, todas las cosas y sujetos reales y virtuales que pertenecen a una determinada clase con propiedades definidas e idénticas, es decir, también todo lo que constituye las empresas, pueden representarse como objetos: por ejemplo, un producto con sus subconjuntos, un servicio, un requisito del producto, el cliente, una oferta, una norma, una unidad organizativa, un curso de formación. Los ejemplos muestran que un objeto puede tener una estructura más o menos compleja y que puede estar compuesto estructuralmente por otros objetos. Por ejemplo, un cliente puede incluir una empresa con su nombre y dirección, una persona de contacto con sus datos, consultas, pedidos, entregas, etc., que también pueden representarse como objetos (Fig. 1). El enfoque orientado a objetos con la integración de datos y métodos ofrece muchas ventajas sobre las tablas relacionales con los mecanismos de herencia, encapsulación y polimorfismo. En el desarrollo de software, el enfoque orientado a objetos ha prevalecido sobre el procedimental, pero aún no en las bases de datos. Por ejemplo, la memoria de patente EP 0504085 B1 describe un método para acceder a una base de datos relacional desde un entorno orientado a objetos.

El documento DE 102010 010 035 A1 describe una base de datos de objetos en la que los objetos constan de unidades con atributos y métodos. Las plantillas de objetos se utilizan para crear nuevos objetos. Para ello, se copian y guardan los objetos existentes y las relaciones asociadas.

Además, también existen las denominadas bases de datos NoSQL (a menudo entendidas como No sólo SQL). Las bases de datos clave-valor son representativas de este grupo. Como su nombre indica, existen claves únicas a las que se asignan uno o varios valores. No se accede a los datos a través de las relaciones, sino sólo a través de las claves. Por lo tanto, el acceso a través de los valores no es posible a menos que se cree una entrada posterior adicional con la relación ValueKey. Las bases de datos clave-valor no funcionan con esquemas fijos como las relacionales, son muy adecuadas para la distribución, pero no sirven para todas las aplicaciones, por ejemplo, no para la Web Semántica.

La Web Semántica se apoya en bases de datos de grafos, que también son aplicaciones NoSQL. Mapean estructuras conectando nodos (entidades) con aristas (relaciones) y definiendo estos grafos, por ejemplo, con tripletes. Las bases de datos de grafos presentan ventajas cuando se trata de datos en red de varias capas, como en las redes sociales: Hombre1 conoce a Mujer1; Hombre1 conoce a Mujer2; Mujer1 conoce a Mujer3. El recorrido por la red de grafos puede utilizarse, por ejemplo, para determinar de forma muy eficaz los contactos de 2° grado de Hombre1: Mujer3. Las bases de datos gráficas no requieren un esquema fijo, por lo que son muy fáciles de ampliar. Una extensión es el modelo de gráfico de propiedades. Aquí, los nodos reciben propiedades adicionales como pares clave-valor. En la red de contactos mencionada, podría tratarse de la edad de las personas.

Si un conjunto de datos se almacena en un único servidor de una base de datos, se denomina dato único. Este ordenador se encuentra en una ubicación de una empresa y todas las consultas de otras ubicaciones se envían a esta única base de datos, lo que puede provocar problemas de rendimiento en empresas que operan a escala internacional. Las bases de datos distribuidas ofrecen una solución. Los datos pueden distribuirse de forma redundante como réplica en varios servidores situados en distintos lugares, pero esto plantea mayores exigencias en cuanto a la coherencia de los datos. Otra opción para distribuir bases de datos es el almacenamiento de datos particionado. Con la fragmentación horizontal, los registros de datos no se almacenan de forma redundante en distintos servidores, sino que sólo se almacenan en ese lugar los datos necesarios para una ubicación concreta. En el caso de la fragmentación vertical, se dividen los datos relacionados lógicamente para la ubicación respectiva, por ejemplo, en el caso de una base de datos de personal, los salarios en el departamento de personal y los datos de contacto en la ubicación de producción. En la memoria de patente EP 13895720.4, se propone una metodología para una base de datos relacional escalable dinámicamente para una plataforma heterogénea distribuida con un servidor de agenda y un módulo de proceso supervisor. Estas se refieren a la gestión de datos, los datos propiamente dichos siguen almacenándose en bases de datos relacionales. Las bases de datos orientadas a objetos almacenan los datos en bases más o menos grandes en función de las necesidades y también pueden fragmentarse si es necesario. Sin embargo, las relaciones orientadas a objetos no facilitan la fragmentación. También en este caso hablamos de fragmentación cuando se dividen objetos relacionados lógicamente. Almacenar los objetos individualmente haría que el esfuerzo de administración del ooDBMS fuera inusualmente alto.

2.4 Seguridad de los datos

Como muestran los ejemplos, las empresas almacenan cantidades considerables de datos procedentes de ámbitos muy diversos. En el curso del desarrollo de nuevos modelos de negocio digitales, el tipo y la cantidad de datos recopilados, almacenados y que deben protegerse aumentan rápidamente. Los datos personales desempeñan un papel especial en este sentido. La Ley Federal de Protección de Datos (BDSG) regula en su artículo 1 la protección de las personas en el tratamiento de sus datos personales. Además de estos requisitos legales, las empresas tienen un gran interés en proteger todos los demás datos del acceso no autorizado, ya que las bases de datos contienen gran parte, si no todo el saber hacer: productos innovadores, procesos de producción eficientes, procesos empresariales, normas de fábrica e instrucciones de trabajo que describen conocimientos especiales, etc. Proteger los datos de accesos no autorizados es vital para la supervivencia de una empresa. El tema de la seguridad de los datos es muy complejo, por lo que conviene remitirse aquí a los catálogos básicos de protección informática de la Oficina Federal de Seguridad de la Información (BSI). Otro ejemplo es el Reglamento General de Protección de Datos (RGPD) de la UE, que entrará en vigor en mayo de 2018. Esto significa que los datos personales pertenecen al usuario, no al servicio de Internet implicado en el tratamiento de datos. Para aplicar la normativa, se concede a las empresas un período transitorio de dos años para que tomen las medidas oportunas, como adaptar las bases de datos y establecer procesos de protección de datos. A pesar de medidas de seguridad como la autenticación multifactor y los procedimientos criptográficos, sigue ocurriendo que personas no autorizadas acceden a datos confidenciales. Si un ciberataque da acceso a registros de datos únicos en una base de datos, todos los datos almacenados, incluidas sus estructuras, están a disposición del atacante. Si se produce un acceso no autorizado a los datos particionados, no todos los conjuntos de datos quedan expuestos sin protección, sino sólo los almacenados en el servidor correspondiente.

Se conoce un método de tratamiento de datos del documento US 6078926 A, en el que los datos se extraen de una base de datos relacional y se almacenan en objetos. A continuación, los datos se procesan en programas orientados a objetos. Sólo se genera un software sin referencia a una base de datos orientada a objetos.

A partir del documento US 2005/149344 A1 se conoce una base de datos relacional en la que sólo se almacenan combinaciones de determinados parámetros de búsqueda y las reglas asignadas a los mismos. Esto no cambia la estructura de la base de datos en sí.

Se conoce un método para procesar datos en un sistema de base de datos de objetos por el documento US 9600 136 B1. Cada uno de los objetos del sistema de base de datos consta de atributos, relaciones y métodos. Si el atributo hace referencia a otro objeto, el atributo se denomina relación. Así pues, una relación se define dentro de un objeto. El procedimiento conocido se limita, pues, a definir varios atributos de una base de datos de objetos para una ampliación de las clases. Es sólo un programa para solicitar la ampliación de objetos y no para modificar la estructura de la base de datos. Los cambios solicitados se aplican a la base de datos de objetos mediante un administrador de base de datos.

3. Tarea

Es tarea de la invención proponer una metodología de base de datos para un modelado empresarial holístico con todos los datos y procesos empresariales de una empresa, que permita una definición, ampliación y modificación más sencillas de los datos, incluidas sus estructuras, y que esté organizada de tal forma que se garantice un concepto de seguridad escalable con el consiguiente aumento de la seguridad de la base de datos.

Para resolver el problema, la invención tiene las características de la reivindicación de patente 1 y la reivindicación de patente 8.

En principio, se opta por el enfoque orientado a objetos para la base de datos porque esta metodología permite una definición más sencilla e intuitiva de las estructuras de datos. Todos los datos y procesos de negocio de una empresa pueden considerarse en sí mismos objetos y, por lo tanto, pueden transferirse fácilmente a la estructura de objetos de la base de datos de objetos propuesta como objetos de negocio (BO). El término objeto de negocio (BO) es un nombre elegido arbitrariamente para distinguirlo de los objetos habituales en las bases de datos de objetos. La metodología propuesta se denomina Semantic Business Modelling (SBM). En la Fig. 1 se muestra un ejemplo. Una empresa vende productos a diferentes empresas y quiere crear una base de datos de objetos de clientes. El BO "Cliente" tiene como atributo el BO "Empresa", que a su vez tiene como subobjetos un nombre de empresa y una dirección, que a su vez se subestructuran según la Fig. 1. Además, la BO "Cliente" tiene como componentes los pedidos y una persona de contacto en el cliente, por ejemplo en la central de compras, con las correspondientes subestructuras adicionales. Además de la sencilla definición de las estructuras, aquí se pone de manifiesto otra ventaja: Una vez definido el BO "Dirección", puede reutilizarse en varios puntos de la estructura del objeto, no sólo la estructura y los datos que contiene como instancias, sino también los procesos asociados en un sentido orientado a objetos. La reutilización de los BO en la metodología SBM permite aplicar estrategias de plataforma en la base de datos de objetos.

Mientras que las bases de datos convencionales almacenan varios objetos en una base de datos con claves, valores y métodos juntos, la SBM ofrece posibilidades de partición, a saber, la fragmentación de los objetos en objetos clave y objetos de valor y el almacenamiento por separado de atributos y métodos. Además, también a diferencia de los métodos convencionales, la funcionalidad de la base de datos está fragmentada en el sentido de que ella misma se mantiene como objetos en la base de datos de objetos y se realiza como métodos a través de servicios asignados, lo que permite que los objetos funcionen según diferentes principios de la base de datos. Además, el código ejecutable se almacena por separado de los métodos. En principio, esta metodología permite que los objetos actúen de forma autónoma. Con SBM, son posibles nuevas estructuras de almacenamiento escalables para una base de datos de objetos y, sobre todo porque la funcionalidad fragmentada de la base de datos se distribuye en varias ubicaciones de almacenamiento especialmente protegidas, hay una clara ganancia en la seguridad de los datos.

Claves de Business Objects (objetos clave):

Las claves BO (objetos clave), destacados en la Fig. 1, están diseñados de tal forma que, en primer lugar, no contienen ningún dato concreto en sus instancias almacenadas, sino sólo claves que representan una referencia a una instancia de un BO subordinado (los nombres de los BO también son sólo claves), y en segundo lugar, pueden almacenarse por sí solos, es decir, independientemente de otros BO. Todos los BO se derivan de un BO "base", de modo que tienen ciertos atributos básicos y

- funcionalidades. El almacenamiento de los BO puede organizarse en grupos arbitrarios (clústeres), con lo que la independencia de los BO no se ve afectada. El clúster en sí es un BO que proporciona servicios para manejar las solicitudes y accesos del propio clúster, y delega estos a los BO individuales. Las instancias de los clústeres pueden distribuirse en cualquier número de servidores (Fig. 2) o, si es necesario para aplicaciones individuales, instalarse en un único cliente (Fig. 3). Preferiblemente, se utilizarán procedimientos criptográficos y de autenticación. También se puede utilizar el almacenamiento de datos fragmentado horizontalmente y/o la replicación. La fragmentación vertical ya está implícita en la gestión modular e independiente de cada BO. Este planteamiento ofrece varias ventajas:

1. Si se produce un acceso no autorizado a un servidor con un clúster de BOs, no se dispone de valores concretos como el nombre de la empresa. Además, se excluyen posibles conclusiones sobre subestructuras si los BO pertenecientes a una estructura se almacenan en servidores diferentes. Esto proporciona una seguridad de datos significativamente mejorada, que es escalable en el sentido de que una empresa puede decidir cuántos servidores están equipados con cuántos clústeres cada uno. La flexibilidad llega hasta el punto de que el almacenamiento de varios clústeres o incluso de un solo clúster con todos los BO puede tener lugar en un solo cliente; una pequeña asociación con una simple base de datos de miembros no necesitará, desde luego, su propio entorno de servidores.

2. Las bases de datos convencionales almacenan datos relacionados lógicamente, como todos los tipos de datos pertenecientes a un producto, por ejemplo en una base de datos de datos de productos, y todos los tipos de datos pertenecientes a un cliente, por ejemplo en una base de datos de clientes. Así pues, están organizados de forma temática y, por lo tanto, imposibilitan una visión holística de los datos y procesos interrelacionados. Los sistemas monolíticos cubren varios temas, pero también sólo áreas parciales del modelado empresarial y sólo pueden modificarse con gran esfuerzo. Por otra parte, el tratamiento independiente de los BO rompe las estructuras monolíticas y la estructuración arbitraria de los BO permite un enfoque holístico.

3. Los BO Keys y 'Cluster' asumen partes del sistema de gestión de bases de datos en sus métodos: está descentralizado. Esto tiene efectos positivos sobre la seguridad de los datos y el rendimiento.

Objeto de negocio "Asignación":

La asignación, es decir, la distribución de los BO a los distintos almacenes, puede almacenarse en un BO "Asignación". No contiene valores concretos, sino sólo claves. Las vías de acceso a los BO individuales se dividen de forma razonable en varios BO estructurados, como el nombre de dominio, el nombre del servidor, etc. Si el BO "Asignación" se almacena separado de otros BO, esto aumenta adicionalmente la seguridad de los datos.

Valores de Business Objects (objetos de valor):

Mientras que las claves BO sólo contienen referencias, los BOs especiales almacenan los valores concretos, como el código postal (BO 'Postcode') y el nombre de pila (BO 'Proper Name') en la Fig. 1. Cada valor BO (ValueObjects) es responsable de manejar un tipo de datos, por lo que se puede definir cualquier tipo de datos en contraste con los tipos de datos fijos de las bases de datos convencionales, ya que el mencionado principio de independencia también existe para los valores BO. Por lo tanto, los valores BO contienen relaciones clave-valor, por ejemplo, para fechas, números de teléfono, nombres propios, datos orientados a cadenas (palabras), etc. Sólo las claves BO del nivel más bajo de la Fig. 1, como nombre y apellidos, contienen una clave que puede encontrarse en el BO "nombre propio" (en la Fig. 1, la clave resuelta aparece resaltada en gris). Los valores BO especiales también pueden contener fórmulas en lugar de valores concretos. Para el almacenamiento de valores BOs, se aplican los mismos procedimientos que los descritos para las claves BO. Los valores BO especiales se derivan en un sentido orientado a objetos de un objeto base, el BO 'Valores Base', que contiene los atributos y métodos válidos para todos los valores BO especiales. Además de la distribución hardware de los BO, la división del contenido en claves y datos concretos tiene las siguientes ventajas:

1. Una clara ganancia adicional en seguridad de datos. Los valores concretos de, por ejemplo, los datos personales con nombre, dirección, fecha de nacimiento, etc. no se almacenan en una base de datos, pero todos los nombres y apellidos, por ejemplo en un BO "nombre propio", y todos los códigos postales, por ejemplo en un BO "código postal", pueden almacenarse por separado en distintas ubicaciones de almacenamiento. Sólo los BO de nivel superior contienen combinaciones válidas a través de las claves.

2. La división estricta en claves y valores permite intercambiar fácilmente los valores de los BO, por ejemplo, para realizar el multilingüismo. Si existe un valor BO, el BO 'Dictionary', que contiene todos los datos orientados a cadenas, es decir, palabras sin nombres propios, en un idioma, se puede garantizar el multilingüismo intercambiando este BO 'Dictionary' con otro diccionario, por ejemplo, el BO 'Dictionary-Eng', que contiene las palabras en inglés, sin que ello afecte a la funcionalidad de la base de datos de objetos.

Business Object 'Structure Semantics' (Objeto de Semántica de Estructura):

La creación de BO, incluida la definición de sus relaciones estructurales, es posible con SBM mediante frases en lenguaje natural con sujeto, predicado y objeto de la frase. Es posible ampliar la frase con un adverbio, adjetivos y/u otros componentes gramaticales. El BO "Semántica estructural" (objeto de la semántica estructural) se compone a su vez de los BO "Sujeto", "Predicado" y "Objeto de la oración". Sus valores concretos se encuentran en el BO 'Diccionario'. Por lo tanto, la definición de las estructuras de los BO se trata en sí misma como un BO y, por lo tanto, lo que se dijo anteriormente para los BO también se aplica aquí. La Fig. 4 muestra un ejemplo de la estructura del BO "Nombre". Si el usuario crea la instancia 'nombre' 'tiene como parte' 'nombre' en el BO 'semántica de estructura', los BO 'nombre' y 'nombre', si no existen ya, se crean en la base de datos de objetos con ayuda de los métodos correspondientes del BO 'semántica de estructura' y se crean o amplían con la estructura correspondiente. No sólo son posibles relaciones simples como "tiene como componente", sino también otras estructuras más complejas como "es especial" para permitir la herencia entre dos BO. La estructura completa de un BO para resolver las claves en valores como "cliente" en la Fig. 1 sólo puede reconstruirse con ayuda de la semántica estructural. Otras ventajas son la definición semántica y la separación de datos y estructura:

1. Una mayor seguridad de los datos: Si hay un acceso no autorizado a los BO, la resolución completa de las estructuras también requiere el acceso a la "semántica de la estructura" del BO, que se almacena ventajosamente en una ubicación separada. Y aunque se conozca la estructura de los BO, sigue siendo necesario acceder a los valores de los BO.

2. No se requieren conocimientos de programación para crear nuevos BO con sus estructuras. Utilizando la semántica del lenguaje natural, los respectivos expertos de una empresa pueden definir BO en la base de datos SBM sin conocimientos especiales de bases de datos. Los métodos del BO "Semántica de la estructura" se encargan de la creación en la base de datos de objetos.

3. Sólo se crean los objetos de datos que realmente se necesitan, mientras que con las bases de datos adquiridas, como un sistema de gestión de datos de productos, no todas las estructuras de datos y funciones disponibles son utilizables para todas las empresas. Esto puede ahorrar costos. Los usuarios reciben exactamente lo que necesitan y se ahorran tediosas búsquedas. El trabajo se vuelve más eficaz.

Objeto de negocio "semántica de servicio" (objeto de semántica de servicio):

Hasta ahora, en el sentido orientado a objetos, hemos estado hablando del manejo de los atributos y todavía no del de los métodos. En la metodología SBM, los atributos de los BO son a su vez BO creados con la "semántica estructural" del BO y los métodos son servicios introducidos en la "semántica de servicio" del BO (objeto de semántica de servicio). Los servicios también se definen con frases en lenguaje natural compuestas por sujeto, predicado y objeto de la frase, siendo este último opcional.

Es posible realizar ampliaciones semánticas con otros objetos gramaticales. A un BO, el sujeto de la frase, se le asigna un servicio, el predicado, por ejemplo "ofrecer" "crear" o "producto" "detallar" (Fig. 5). Los ejemplos son partes de un proceso de creación de productos e ilustran que los servicios también pueden representar procesos en una empresa. En este caso, los pasos del proceso ya no se asignan a funciones específicas (responsabilidades), sino a BO. Esto también se aplica al sistema descentralizado de gestión de bases de datos. El BO "Base", por ejemplo, define servicios como la búsqueda, la modificación, la visualización en forma de tabla (Fig. 5), etc. para todos los BO derivados. En el BO "Semántica del servicio" sólo se almacenan las asignaciones del servicio y ninguna regla de ejecución concreta. Así, un BO sabe qué servicios puede ofrecer: Funcionalidad de la base de datos de objetos, pasos del proceso, acciones, etc. Para el BO 'Service semantics' incl. el BO subordinado, se aplica lo mencionado anteriormente para los BO.

Objeto de negocio "Proceso" (objeto de proceso):

El BO "Proceso" define los pasos concretos del proceso para las asignaciones de servicio en el BO "Semántica del servicio". La estructura del BO 'Proceso' consta de un BO 'Semántica del Servicio', que representa el servicio llamante, y un BO 'Paso del Proceso', que a su vez contiene un BO 'Estado de Inicio', otro BO 'Semántica del Servicio', el servicio o delegado a ejecutar, y un BO 'Estado de Fin'. Los BO pueden tener cualquier estado inicial y final; indican en qué estado se encuentra un BO, como el estado de "desarrollo" de un producto que actualmente está en "detallado". Si se solicita un servicio y se encuentra en el BO 'Proceso' como servicio de llamada, se ejecuta el paso de proceso asociado estableciendo el estado de inicio asociado de un BO e iniciando el delegado asociado, que también puede incluir la creación de una tarea para un empleado. El propio delegado también puede ser un servicio de llamada en otro proceso, de modo que éste se inicie automáticamente. Cuando finaliza el servicio a ejecutar, se establece el estado final. Si el estado final es también un estado de inicio de otro proceso, el nuevo proceso se inicia automáticamente, haciendo posibles los flujos de procesos secuenciales. Los estados no tienen por qué asignarse al mismo BO responsable del servicio de llamada; esto también se aplica al servicio a ejecutar. De este modo, se puede definir y ejecutar cualquier secuencia de procesos. El BO "Proceso" puede recibir otros BO como atributos con la ayuda del BO "Semántica de la estructura", como propietario del proceso, etc. Para los BO "Procesos", incluidos los BO subordinados, se aplica lo mencionado anteriormente para los BO. Este tipo de definición de procesos, incluida la definición de servicios, presenta las siguientes ventajas:

1. Los BO saben independientemente lo que hay que hacer. Mientras que en el modelado empresarial orientado a procesos los datos están subordinados a los procesos como parámetros, el enfoque SBM orientado a objetos invierte esta relación: Los datos se definen primero como BO y los procesos se asignan a estos objetos como métodos. Por lo tanto, los procesos pueden ejecutarse automáticamente bajo el control de los BO, sin ningún esfuerzo adicional de programación del flujo de trabajo, y los BO pueden mostrar al usuario exactamente aquellos y sólo aquellos procesos que realmente puede ejecutar. Los procesos ya no permanecen latentes en su propia base de datos como simples documentos y no hay necesidad de buscarlos porque los propios BO saben lo que hay que hacer.

2. La simple delegación y propagación de tareas entre BOs es libremente definible porque los servicios y estados pueden ser asignados a diferentes BO. Esto significa que no hay restricción a los procesos que sólo pueden ser ejecutados por un BO.

3. Si hay que añadir un proceso a un BO como nuevo método, no se modifica el BO en la base de datos de objetos, sino que simplemente se añade una nueva instancia a los BOs 'semántica de servicio' y 'proceso'.

4. No sólo el almacenamiento separado de datos (atributos) y procesos (métodos) aporta una mayor seguridad de los datos, sino también el hecho de que los BO (servicios, estados) utilizados en un proceso puedan almacenarse por separado en distintos lugares de almacenamiento. Los procesos contienen conocimientos técnicos sensibles de una empresa.

Objeto de negocio "Acción":

En principio, el BO "Acción" está estructurado de la misma manera que el BO "Proceso", con la única diferencia de que el delegado no define un servicio, sino que contiene el nombre de un módulo de software ejecutable. Los mismos principios se aplican también al proceso, salvo que aquí, en lugar de un servicio, se inicia un módulo de software a través de su nombre para ejecutar acciones concretas. Los módulos de software se crean como BO en la base de datos de objetos y pueden almacenarse en varias bibliotecas distribuidas en varias ubicaciones de almacenamiento. Para el BO "Acción", incluidos los BO subordinados, se aplica lo mencionado anteriormente para los BO. Además de las ventajas ya mencionadas para la BO "Proceso", las acciones ofrecen otras ventajas:

1. Los BO se vuelven inteligentes porque pueden realizar acciones concretas de forma independiente cuando se alcanza un determinado estado. Por ejemplo, si una norma de fábrica especifica una geometría 3D estándar que debe utilizarse siempre en el diseño de un determinado componente de un producto, una acción correspondiente puede insertar automáticamente esta geometría en el diseño.

2. El código ejecutable en BO específicos está separado de otros BO de forma modular, lo que apoya el requisito de un sistema no monolítico. Gracias a la modularización, el software es mucho más fácil de mantener. Los principios descritos para los procesos y acciones pueden aplicarse a las propias funcionalidades de las bases de datos. Por ejemplo, si un usuario quiere buscar en los registros (instancias) de BO 'Cliente', BO 'Cliente' le ofrece servicios como 'buscar', 'mostrar como' 'tabla', 'introducir' etc. de forma independiente. Si el usuario selecciona "visualizar como" "tabla", se lleva a cabo el procedimiento descrito para los procesos y acciones, de modo que finalmente obtiene la máscara de visualización deseada para los registros de clientes. Si el nombre "buscar" del módulo en el BO "acción" se sustituye, por ejemplo, por el nombre "encontrar", se puede iniciar otro módulo de software con este simple intercambio y se puede mostrar otra interfaz de usuario.

3. La separación de los BO de código y otros BO de base de datos y la división de los propios BO de código en diferentes bibliotecas en diferentes ubicaciones de almacenamiento crean una ganancia adicional en la seguridad de los datos.

4. En cooperación con las BO "Proceso" y "Acción", los objetos pueden ejecutar procesos de forma autónoma y automática, no sólo con fines de control, sino también de simulación holística.

Objeto de negocio "Autorización":

Los empleados de una empresa suelen tener asignadas determinadas funciones y, por lo tanto, responsabilidades. Las distintas funciones también suelen estar sujetas a diferentes normativas de protección de datos. Por lo tanto, los conceptos de autorización controlan en detalle qué datos puede ver y cuáles no un empleado con una función determinada. Las autorizaciones de los roles individuales se definen en el BO "Autorización", mediante el cual se asignan a un BO "Rol" otro u otros BO que incluyen la autorización como lectura, modificación, etc. Esto permite acceder a BO individuales o a jerarquías enteras de BO. Si es necesario, también se puede restringir el acceso a instancias individuales de un BO. Los BO pueden asignarse a contextos específicos mediante un "Contexto" de BO, por ejemplo, compras, personal, desarrollo, etc. De este modo, también se pueden establecer autorizaciones para contextos completos sin asignar BO individuales. Cambiando el contexto, el multilingüismo antes mencionado también puede aplicarse fácilmente. Para el BO "Autorización", incluidos los BO subordinados, se aplica lo mencionado anteriormente para los BO. Esta forma de crear un concepto de autorización tiene las siguientes ventajas:

1. Las bases de datos adquiridas, por ejemplo para la gestión del ciclo de vida de los productos, suelen contener una gestión de autorizaciones muy compleja y difícil de mantener. La metodología SBM con el BO "Autorización" permite a las empresas adaptar la complejidad de un concepto de autorización a sus propias necesidades y asignar autorizaciones fácilmente. Las opciones de autorización multinivel para contextos, estructuras de BO, BO individuales hasta instancias de BO mejoran la visión de conjunto y ahorran tiempo en la definición. Si, por ejemplo, un empleado recibe permiso de lectura para el BO "Cliente" (Fig. 1), toda la subestructura también puede liberarse para él, si así lo desea.

2. El BO "Autorización" también puede tener procesos y métodos que apoyen la asignación de derechos, como un flujo de trabajo de liberación.

3. Como en el caso de los otros BO, también existe la posibilidad de un almacenamiento separado y especialmente protegido.

Objeto de negocio "Regla":

La gestión del conocimiento es más eficiente y eficaz cuando no sólo proporciona información, sino que el propio conocimiento adopta un papel activo y sabe por sí mismo dónde aplicarlo. Dado que la gestión de procesos siempre forma parte de la gestión del conocimiento, las BO "Servicio", "Procesos" y "Acciones" ya forman parte del conocimiento activo. El BO 'Regla' soporta decisiones y servicios almacenando reglas, que se definen semánticamente con frases en lenguaje natural como en el BO 'Semántica de la estructura'. En la parte de las condiciones, se hace referencia a los atributos de BO o a sus estados, por lo que también se pueden vincular lógicamente varias condiciones entre sí. La parte de consecuencias contiene servicios o describe nuevos contextos que no necesariamente tienen que hacer referencia a BO. Además de la posibilidad de representar el conocimiento en reglas, son concebibles otras BO que permitan almacenar el conocimiento y actuar sobre él en otras representaciones. Para la "norma" BO, incluidos los BO subordinados, se aplica lo mencionado anteriormente para los BO. Esta forma de gestionar el conocimiento tiene las siguientes ventajas:

1. Tal como exige el BRM, las normas y los procesos se definen por separado, pero se vinculan fácilmente a través de la metodología SBM.

2. Como en el caso de los otros BO, también existe la posibilidad de un almacenamiento separado y especialmente protegido.

3. Aunque el conocimiento suele almacenarse en bases de conocimiento separadas, el enfoque holístico de la SBM también se pone de manifiesto aquí en el almacenamiento y el uso del conocimiento. El BO "Regla", como todos los demás BO, es arbitrariamente enlazable con otros BO, de modo que los propios BOs pueden proporcionar conocimiento en forma de reglas y también actuar independientemente de acuerdo con ellas. La actuación independiente y basada en el conocimiento de los comités de empresa va mucho más allá del planteamiento de "la información adecuada en el momento adecuado y en el lugar adecuado".

Objeto de negocio 'Dispatcher':

Los clientes se comunican con la base de datos a través de instancias del BO 'Dispatcher'. El despachador sabe qué otros BO le proporcionan servicios, procesos y acciones para proporcionar la información solicitada. Por ejemplo, pregunta al BO "Asignación" dónde encontrar los datos, al BO "Autorización" si se permite el acceso, y a los correspondientes BO "Clusters" que le proporcionen valores. Sus propios métodos también se definen y controlan a través de los BO "Servicio", "Proceso" y "Acción". Para el BO 'Dispatcher' incl. los BO subordinados, se aplica lo mencionado anteriormente para los BO. Crear este tipo de acceso a los datos tiene las siguientes ventajas:

1. Los accesos a la base de datos pueden ser controlados por varias instancias del despachador, de modo que la carga computacional se distribuya entre distintos servidores.

2. Como en el caso de los otros BO, también existe la posibilidad de un almacenamiento separado y especialmente protegido.

Objeto de Negocio 'Gráfico Base':

Mientras que los BO Keys están orientados a tablas y, por tanto, son menos adecuados para datos en red, el BO 'Gráfico Base' ofrece atributos y métodos que son necesarios para los BO que funcionan según el principio de grafos y que pueden heredarse de este BO. Por poner sólo un ejemplo, se puede crear un BO "Contactos". Contiene el ejemplo mencionado como 3 instancias: Hombre1' 'conoce' 'Mujer1'; 'Hombre1' 'conoce' 'Mujer2'; 'Mujer1' 'conoce' 'Mujer3'. Otros casos pueden ser: 'Mujer1' 'está casada con' 'hombre3'; 'hombre3' 'es padre de' 'mujer2'. Los métodos proporcionan, por ejemplo, algoritmos transversales a través del BO "Acción". Se puede definir cualquier otro BO que funcione según el principio del grafo. Para el BO 'Gráfico Base' y los BO derivados de él incl. los BO subordinados, se aplica lo mencionado anteriormente para los BO. La posibilidad de utilizar principios gráficos tiene las siguientes ventajas:

1. En una base de datos existen distintos principios para el tratamiento de datos (orientados a tablas, a objetos y a gráficos). Esto significa que se puede seleccionar el mejor método para una aplicación específica. Además del principio de grafos, otras metodologías como las de bases de datos basadas en documentos, blockchain y redes neuronales también pueden utilizarse del mismo modo.

2. Los BO gráficos no son independientes, sino que pueden tener vínculos con cualquier otro BO. Los nodos de un grafo pueden ser, por ejemplo, las claves de las instancias de una base de datos personales, lo que permite extraer conclusiones sobre nombres, direcciones, fechas de nacimiento, etc. en el nodo. Así, los contenidos de otros BO pueden considerarse propiedades de los nodos. El uso de diferentes principios con vinculación simultánea de sus datos apoya especialmente la demanda de modelización empresarial holística.

5. Lista de identificadores

BO Objetos empresariales

BO-Ki-j Objeto del negocio Claves número i a j

BO-W Objetos del negocio Valores

BO-StS Objeto de negocio "Estructura semántica"

BO-SeS Objeto de negocio "Semántica del servicio"

BO-P Objeto de negocio "Proceso"

BO-A Objeto de negocio "Acción"

BO-B Objeto de comercio "Autorización"

BO-Wi Objeto de negocio "Conocimiento"

BO-D Objeto de negocio "Dispateher"

BO-Ck Objeto de negocio "Cluster" número k

Cl-p Número de cliente p

CL-Ao Número de solicitud del cliente o

CL-Ps Número de proceso cliente s

Mod Módulos de software como objeto de negocio

DBS-m Número de servidor de base de datos m

DBS-Sn Servidor de base de datos con mayor número de seguridad n PS-q Número de almacenamiento permanente q

PS-Sr Almacenamiento permanente con mayor número de seguridad r RSM Ordenador con seguridad reforzada para Mod

KN Red de comunicaciones

KP Comunicación entre procesos

5. Lista de identificadores

BO-Ki-j Objeto del negocio Claves número i a j

BO-W Objetos del negocio Valores

BO-StS Objeto de negocio "Estructura semántica"

BO-SeS Objeto de negocio "Semántica del servicio"

BO-P Objeto de negocio "Proceso"

BO-A Objeto de negocio "Acción"

BO-B Objeto de comercio "Autorización"

BO-Wi Objeto de negocio "Conocimiento"

BO-D Objeto de negocio "Dispatcher"

BO-Ck Objeto de negocio "Cluster" número k

Cl-p Número de cliente p

CL-Ao Número de solicitud del cliente o

CL-Ps Número de proceso cliente s

Mod Módulos de software como objeto de negocio

DBS-m Número de servidor de base de datos m

DBS-Sn Servidor de base de datos con mayor número de seguridad n PS-q Número de almacenamiento permanente q

PS-Sr Almacenamiento permanente con mayor número de seguridad r RSM Ordenador con seguridad reforzada para Mod

KN Red de comunicaciones

KP Comunicación entre procesos

Claims (10)

REIVINDICACIONES

1. Procedimiento de procesamiento de datos en un sistema de base de datos de objetos, en donde el procedimiento comprende la creación de una pluralidad de objetos (BO),

caracterizado porque

- los objetos (BO) se almacenan como objetos fragmentados (BO) en diferentes ubicaciones, en donde se vinculan a otros objetos fragmentados (BO) por relaciones,

- los objetos (BO) se fragmentan en atributos y métodos, almacenándose los atributos y métodos por separado y los atributos como objetos fragmentados (BO),

- las relaciones entre los objetos fragmentados (BO, BO-StS) se crean según una sintaxis libremente definible para la formación de relaciones estructurales y

- los métodos se crean como una asignación de servicios formados como objetos (BO-SeS) o acciones formadas como objetos (BO-A) a objetos fragmentados de acuerdo con una sintaxis libremente definible para formar métodos estructurales, y

- los objetos fragmentados (BO) y las relaciones estructurales y los métodos estructurales se almacenan en un almacén de datos en una ubicación o en un almacén de datos de una base de datos (DBS-Sn) distribuido en varias ubicaciones,

- para la modelización de negocios orientada a objetos, los datos se definen como objetos fragmentados (BO) y los procesos se asignan a estos objetos fragmentados (BO) como métodos, de modo que los procesos se ejecutan automáticamente bajo el control de los objetos fragmentados (BO).

2. Procedimiento de acuerdo con la reivindicación 1, caracterizado porque los objetos fragmentados (BO) se almacenan en clústeres arbitrarios y porque cada clúster se almacena como un objeto modular fragmentado independientemente de otros clústeres.

3. Procedimiento de acuerdo con la reivindicación 1 o 2, caracterizado porque los objetos fragmentados (BO) están formados exclusivamente por objetos clave o por objetos-valor, conteniendo el objeto clave en sus instancias almacenadas únicamente referencias a una instancia de un objeto fragmentado (BO) subordinado y ningún dato concreto.

4. Procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 3, caracterizado porque los métodos estructurales de un proceso dado se definen en un objeto-proceso, en donde los pasos del proceso se definen mediante asignaciones de un objeto de semántica de servicio en el que se almacenan los métodos estructurales, porque al objeto-proceso se le asigna un servicio a invocar, un estado de inicio, un servicio a ejecutar y un estado final, en el que la ejecución del proceso prevé:

- solicitar la invocación de un servicio en el objeto de semántica de servicio,

- establecer un estado de inicio de un objeto y/o un objeto fragmentado,

- ejecutar el servicio,

- establecer un estado final del objeto y/o del objeto fragmentado tras la finalización del servicio.

5. Procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 4, caracterizado porque las relaciones estructurales y/o los métodos estructurales se definen mediante frases en lenguaje natural.

6. Procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 5, caracterizado porque el sistema de gestión de la base de datos de objetos propiamente dicha se realiza mediante objetos y/u objetos fragmentados en la base de datos, realizándose la funcionalidad del sistema de gestión de la base de datos mediante métodos de la misma.

7. Procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 6, caracterizado porque el objeto y/u objeto fragmentado con sus atributos y métodos realiza la definición, el manejo, las extensiones y el almacenamiento de relaciones estructurales de los objetos u objetos fragmentados entre sí y crea los objetos u objetos fragmentados en la base de datos de objetos.

8. Dispositivo para procesar datos en un sistema de base de datos de objetos, siendo los objetos previstos como datos, caracterizado porque

- los objetos (BO) se almacenan en cada caso como objetos fragmentados (BO) en diferentes ubicaciones, en las que están vinculados a otros objetos fragmentados (BO) mediante relaciones entre sí,

- los métodos se crean como una asignación de servicios formados como objetos (BO-SeS) o acciones formadas como objetos (BO-A) a objetos fragmentados de acuerdo con una sintaxis libremente definible para formar métodos estructurales, y

- los objetos fragmentados (BO) y las relaciones estructurales y/o los métodos estructurales se almacenan en un almacén de datos en una ubicación o en un almacén de datos de una base de datos (DBS-Sn) distribuido en varias ubicaciones,

- para la modelización de negocios orientada a objetos, los datos se definen como objetos fragmentados (BO) y los procesos se asignan a estos objetos fragmentados (BO) como métodos, de modo que los procesos se ejecutan automáticamente bajo el control de los objetos fragmentados (BO).

9. Dispositivo de acuerdo con la reivindicación 8, caracterizado porque los métodos estructurales y/o las relaciones estructurales se almacenan cada uno en un objeto separado.

10. Dispositivo de acuerdo con la reivindicación 8 o 9, caracterizado porque las relaciones estructurales se almacenan en un objeto de semántica estructural y los métodos estructurales se almacenan en un objeto de semántica de servicio.