ES2204962T3

ES2204962T3 - Metodos y sistemas x.500.

Info

Publication number: ES2204962T3
Application number: ES95930331T
Authority: ES
Inventors: Richard Hans Harvey
Original assignee: Computer Associates Think Inc
Current assignee: CA Inc
Priority date: 1994-09-01
Filing date: 1995-08-30
Publication date: 2004-05-01
Anticipated expiration: 2015-08-30
Also published as: EP1313036A3; EP1313036A2; EP1313037A3; EP1313039B1; US7685142B2; JPH10505690A; US20030208478A1; US20020107828A1; US20030213316A1; DE69530595D1; EP1313038A3; ATE239257T1; US20030191759A1; EP0777883B1; US7620623B2; US20060020613A1; EP0777883A4; US20020116370A1; EP1313039A3; WO1996007147A1

Abstract

LA INVENCION SE DIRIGE AL PROBLEMA DE LA IMPLEMENTACION DE X.500 UTILIZANDO UN PRODUCTO SQL. LA INVENCION DESCUBRE UNA APLICACION DEL X.500 A UNA BASE DE DATOS RELACIONAL, UN DISEÑO DE BASE DE DATOS Y EL USO DE LA BASE DE DATOS PARA REALIZAR SERVICIOS X.500. PARTICULARMENTE, LA INVENCION SE REFIERE A LA IMPLEMENTACION UTILIZANDO UN RDBMS (SISTEMA DE ADMINISTRACION DE BASES DE DATOS RELACIONALES). LA INVENCION PRESENTADA DESCANSA EN EL MODELADO DEL SERVICIO, EL PROCESAMIENTO ARBITRARIO DE DATOS UTILIZANDO UN CONJUNTO FIJO DE INTERROGACIONES/SERVICIOS. OTRA INVENCION RESIDE EN LA IMPLEMENTACION DE UN MODELO BASADO EN DISCO QUE UTILIZA INTERROGACIONES RELACIONALES PARA SATISFACER SERVICIOS X.500 Y HACE POSIBLE QUE SEAN EXPLOTADAS LAS CARACTERISTICAS POSITIVAS DEL RDBMS. ADEMAS, LA INVENCION SUMINISTRA UNA APLICACION DE X.500 BASADA EN SQL QUE SE PUEDE REALIZAR A VELOCIDADES INFERIORES AL SEGUNDO Y QUE NO ES RELATIVAMENTE AFECTADA POR EL TAMAÑO DE LA BASE DE DATOS, LA FORMA DE DIT, EL TIPO DE DATOS O LA COMPLEJIDAD DEL SERVICIO, INCLUYENDO ALIAS.

Description

Métodos y sistemas X.500.

Ámbito

La presente invención se refiere a aparatos de proceso de datos y es de especial uso en la aplicación de X.500 a una base datos relacional. Particularmente, la presente invención se describe aquí como dirigida a implementación empleando un RDBMS (Sistema de Gestión de Base de Datos Relacional).

Técnica anterior

El X.500 es el Estándar Internacional para Directorios Electrónicos (CCITT89). Estos estándares definen los servicios, protocolos y modelo de información de un directorio muy flexible y de propósito general. El X.500 es aplicable a sistemas de información donde los datos son bastante estáticos (por ejemplo un directorio telefónico) pero pueden necesitar ser distribuidos (por ejemplo, a través de organizaciones o países), extensibles (por ejemplo, almacena nombres, direcciones, cargos, esquemas, etc.), orientados a objeto (es decir para hacer cumplir reglas en los datos) y/o con acceso remoto.

Sistema de Gestión de Base de Datos Relacional

El (RDBMS) proporciona facilidades para aplicaciones de almacenar y manipular datos. Entre las muchas características que ofrecen están: integridad de datos, consistencia, concurrencia, mecanismos de indexación, optimización de consultas, recuperación, repetición, seguridad. Asimismo proporcionan muchas herramientas para ajuste del rendimiento, importación/exportación, salvar datos, auditoría y para desarrollo de aplicaciones.

El RDBMS es la elección preferida de la mayoría de los gestores de datos a gran escala. Estos están disponibles fácilmente y se sabe que son fiables y que contienen múltiples herramientas de gestión útiles. Hay una gran base de instalaciones RDBMS y por tanto una gran cantidad existente de especialización e inversión en personas y procedimientos para hacer funcionar a estos sistemas y así los gestores de datos buscan emplear este cuando adquieren nuevos sistemas. La mayoría de los productos de bases de datos relacionales soportan el estándar de la industria SQL (Lenguaje de Consulta Estructurado).

También ha habido un movimiento hacia sistemas Orientados a Objetos que proporcionan extensibilidad de datos y la capacidad de gestionar ítems de datos arbitrariamente complejos. Además muchas corporaciones y departamentos gubernamentales tienen grandes cantidades de aplicaciones de bases de datos que no están interconectadas. Los gestores de datos están buscando soluciones que les permitan integrar sus datos y simplificar la gestión de estos datos. El X.500 y sus estándares asociados proporcionan un marco y un grado de funcionalidad que permite conseguir esto. El hecho de que el X.500 sea un estándar internacional significa que se puede conseguir la conectividad de los datos entre corporaciones y entre diferentes países.

El problema, por tanto, es tratar la necesidad de gestores de datos e implementar el X.500 con toda de flexibilidad de los sistemas orientados a objeto pero empleando un producto SQL de forma de forma que este pueda conseguir la escalabilidad y rendimiento inherente a los sistemas relacionales unido a la estabilidad, robustez, portabilidad y efectividad de coste de los productos SQL actuales.

Ha habido varios intentos de resolver el problema anterior y a lo largo de un periodo de tiempo considerable. Ninguno de los intentos ha dado como resultado un producto que se haya probado comercialmente aceptado por el mercado, y por tanto en el mercado hay una necesidad largamente sentida aún por ser atendida.

La Fig. 1 muestra un resumen de "GOSIP News", edición No. 4, fechada en Abril de 1994 (Fuente: "Interoperanbillity Products" distribuido en Australia por el Centro para Sistemas Abiertos) y que lista los productos X.500 disponibles actualmente. Ninguno de estos productos emplea una base de datos SQL como almacenamiento de datos subyacente y por tanto ninguno de estos productos atiende sustancialmente la necesidad de mercado de implementar el X.500 empleando un RDBMS SQL.

Las Actas del Simposio Internacional IFIP WG6.6 (ISBN: 0444 889 167) han publicado un documento presentado por Francois Perruchond, Cuno Lanz y Bernard Plattner y titulado "Un Diseño de Base de Datos Relacional para un Agente Sistema Directorio X.500". El Sistema Directorio descrito, como muchos sistemas de la técnica anterior, es relativamente lento de funcionamiento, especialmente cuando la base de datos es relativamente extensa y es incompleto en su implementación del X.500, como alias, subbúsquedas e información de entrada.

Otro intento se describe en las actas del IREE, ISBN 0909 394 253, actas de 22-24 de Abril de 1991 por C.M.R. Leung. En tal descubrimiento se describe un esquema de base de datos en el que una tabla de simple entrada mantiene información detallada sobre cada objeto de directorio y es asimismo incompleta en su implementación del X.500.

Esta aproximación ha sido desacreditada por varios libros de texto y conocimiento de la técnica, como "Modelado y Diseño Orientado a Objetos" por J. Rumbaugh et al, 1991, ISBN 0-13-630054-5, en el que en el párrafo 17.3.8 se afirma claramente que "poner todas las entidades en la única tabla no es una buena aproximación al diseño de bases de datos relacionales".

COOKE B E ET AL: "SERVICIOS DIRECTORIOS EN EL ENTORNO HP MAP 3.0" HEWLETT PACKARD JOURNAL, vol. 41, no. 4, 1 de Agosto de 1990, páginas 15-23, XP000149608 describe un sistema para proveer servicios directorios empleando una base de datos relacional que comprende tres tablas. Se usa el estándar directorio X.500.

Resumen de la invención

Un objeto de la presente invención es tratar el problema de implementar el X.500 en un RDBMS que soporta SQL o cualquier otro lenguaje relacional. Los servicios X.500 se pueden invocar a través de varios protocolos como X.500 y LDAP.

En este documento, en el momento de su presentación, SQL es el lenguaje relacional más popular y aunque solo es una forma de lenguaje relacional, el propósito de la presente invención es que tenga aplicación a cualquier otra forma de lenguaje relacional, no solo SQL.

De acuerdo con la presente invención se proporciona un aparato de proceso de datos para proveer servicios directorios relacionados con objetos de datos teniendo cada uno al menos un atributo y teniendo cada atributo uno o más valores, que comprende: medio de recepción para recibir instrucciones de operación de servicio directorio; y medio de bases de datos preparados para almacenar datos y realizar operaciones de servicio directorio de acuerdo con instrucciones de operación de servicio directorio recibidas por dichos medio receptores; caracterizado porque dichos medio de bases de datos comprenden: un medio de definición de jerarquía (como una tabla de jerarquía JERARQUIA;DIT) para definir relaciones entre objetos y un identificador de entrada que identifica a cada objeto; medio de definición de atributo (como una tabla de atributos ATRIBUTO) para almacenar una pluralidad de definiciones de atributo definiendo cada una un atributo respectivo y comprendiendo cada una un identificador de atributo; medio (como una tabla de objetos OBJETO; ENTRADA) para almacenar datos de valor para cada objeto, comprendiendo dichos datos de valor (por ejemplo, ValorNorm; ValorBruto) valores de atributo, el correspondiente identificador de atributo (AID) y un identificador de entrada (EID) que identifica el objeto al que se refiere dicho valor de atributo; y medio que responde a dicha instrucción de operación de servicio directorio para localizar y devolver dichos objetos de datos empleando las relaciones definidas por dicho medio de definición de jerarquía, dichas definiciones de atributo almacenadas y dichos datos de valor almacenados.

Se prefiere que el medio de definición de jerarquía (JERARQUIA;DIT) esté preparado para almacenar datos padre (Padre; Ruta) que relacionan la EID de cada objeto con otra EID o con un objeto raíz.

Preferiblemente, el medio de base de datos está asimismo preparados para almacenar asociado con el EID de cada objeto, datos de ruta (Ruta) representativos de la relación jerárquica relativa de dicho objeto con un objeto raíz, estando dispuestos dichos medio de base de datos para realizar operaciones de servicio directorio empleando dichos datos de ruta. Por ejemplo, el medio de base de datos puede estar preparados para almacenar dicho dato de ruta (Ruta) en un medio de definición de ruta (ARBOL) separado de dicho medio de definición de jerarquía (JERARQUIA;DIT).

El medio de base de datos está preparado preferiblemente para almacenar datos alias (Alias) indicativos de la equivalencia de un objeto con otro objeto, donde dichos medio de base de datos están preparados para realizar operaciones de servicio directorio mediante conversión de referencias a una EID de un objeto indicado como un equivalente a otro objeto por datos alias (Alias) en referencias a las EIDs de sus objetos equivalentes, empleando los datos alias. Por ejemplo, la base de datos puede ser organizada para almacenar los datos de alias (Alias) en medio de definición de alias (ALIAS) separados de dicha medio de definición de jerarquía.

El medio de base de datos está organizado preferiblemente para almacenar datos de valor para cada objeto en una primera forma (ValorNorm) y en una segunda forma (ValorBruto), donde el medio de base de datos está organizado para realizar operaciones de servicio directorio que implican la comparación de dichos datos de valor con datos recibidos por dicho medio receptor utilizando los datos almacenados en dicha primera forma (ValorNorm) y para sacar datos utilizando datos almacenados en dicha segunda forma (ValorNorm). Por ejemplo, el medio de base de datos puede ser organizado para almacenar dichos datos de valor (ValorNorm) en dicha primera forma y datos de valor en dicha segunda forma (ValorBruto) en medios separados de definición de atributos (BUSQUEDA, ENTRADA).

El medio de base de datos puede además estar organizado para almacenar datos de conversión para convertir datos entre datos recibidos como parte de una instrucción de operación de servicio directorio que representan datos de tipo (Tipo; ID Objeto) e identificadores de atributo (AID).

El medio de base de datos está preferiblemente organizado para almacenar datos de identificación de nombre (Disting) que identifican datos de valor (ValorNorm; ValorBruto) para un objeto como datos que forman parte de un nombre único para dicho objeto, y más preferiblemente está organizada para generar datos de nombre para cada objeto utilizando dichos elementos de datos de valor arriba mencionados (ValorNorm; ValorBruto) asociados con dichos datos de identificación de nombre (Disting) indicando que dicho dato de valor forma parte de un nombre para un objeto y para generar un nombre único (RDN) para cada objeto utilizando dicho dato de identificación de nombre (Disting) y dicho dato representativo para un objeto de su relación jerárquica relativa con un objeto raíz directamente o vía dichos otros objetos. Está organizada más preferiblemente para almacenar dicho nombre único (RDN) para un objeto en asociación con la EID asociada con dicho objeto y para generar dicho nombre único para dicho objeto utilizando dicho dato de identificación de nombre y dicho datos de ruta. Aún más preferiblemente está organizada para almacenar dicho nombre único (RDN) con dicha EID asociando dicho dato de nombre con su objeto respectivo en un medio de definición de nombre (NOMBRE) separado de dicho medio de definición de jerarquía (JERARQUIA;DIT).

El nombre único (RDN) para cada objeto puede almacenarse en una primera forma (Nombre Norm) y en una segunda forma (Nombre Bruto), y el medio de base de datos puede ser organizado para realizar operaciones de servicio directorio que implican la comparación de datos de nombres únicos (RDN) con datos recibidos por dicho medio receptor empleando datos almacenados en dicha primera forma (Nombre Norm) y para sacar datos utilizando datos (Nombre Bruto) almacenados en dicha segunda forma.

El medio receptor puede estar adaptado para recibir instrucciones de servicio directorio, incluyendo datos de búsqueda definiendo criterios de búsqueda, identificando una petición para realizar una función de búsqueda. Los datos de búsqueda pueden comprender datos que definen una o más condiciones a cumplir por datos de valor (ValorNorm; ValorBruto) y dicho medio que responde puede organizarse tras la recepción de dicha instrucción por dicho medio receptor para sacar datos almacenados en dicho medio de base de datos en asociación la EID correspondiente a las EIDs almacenadas en asociación con valores de atributo que cumplen dicha una o más condiciones a satisfacer.

Continua aquí una descripción de la implementación de la presente invención, puesta en el contexto de los problemas asociados con la técnica anterior. Se presenta convenientemente la descripción bajo los siguientes encabezamientos:

1.: Diseño de Principios

2.: Diseño Conceptual

3.: Método(s) Conceptual(es)

4.: Diseño Lógico

5.: Método(s) Lógico(s)

6.: Diseño Físico

7.: Implementación de Ejemplo

El estándar X.500 de ninguna forma ordena cómo se va a implementar el directorio, solo sus capacidades y comportamiento. Una clave para resolver el problema de la implementación es la realización de lo que X.500 define como conjunto fijo de servicios (por ejemplo, Agregar, Modificar, Buscar, etc.) que pueden operar sobre datos arbitrarios.

Se ha descubierto que los problemas asociados con la técnica anterior se pueden mitigar mediante un enfoque único, mediante lo que puede describirse como teoría relacional inversora que modela a partir de un enfoque de modelado de datos a un enfoque de modelado de servicio. Esto es, desde el problema de:

procesamiento de consultas arbitrarias sobre un conjunto fijo de datos al presente enfoque de procesamiento de datos arbitrarios empleando un conjunto fijo de consultas/servicios.

Se modela cada servicio (en vez de cada tipo de dato) y las relaciones entre cada servicio definido (en vez de las relaciones entre cada tipo de dato).

La implementación de modelado de servicios empleando consultas relacionales para satisfacer servicios X.500 permite que se exploten los beneficios del RDBMS.

Los beneficios de este enfoque son muchos. En la Fig. 3 se muestra un resumen. Algunos de los beneficios incluyen:

\bullet: tiempo de arranque relativamente rápido.

\bullet: facilidad para reducir requerimientos de memoria en relación con sistemas residentes en memoria.

\bullet: capacidad para basar el X.500 en cualquier base de datos SQL y proteger por ello la inversión en productos, especialización y procedimientos en la gestión de sistemas existentes.

\bullet: capacidad de conseguir rendimiento relativamente independiente del tamaño y relativamente independiente de la complejidad del tipo de datos. Cada tipo de datos es tratado de forma genérica. Cada tipo de dato tiene un índice sobre él. El resultado de la indexación da la capacidad de buscar eficientemente el directorio sin colocar grandes porciones de directorio en memoria. A diferencia de la técnica anterior donde o solo se puede usar un índice para satisfacer una consulta dada o grandes porciones de información son colocadas y exploradas intensivamente en memoria del sistema.

\bullet: la capacidad de soportar diferentes lenguas (por ejemplo, español, hebreo y kanji) que pueden tener diferentes secuencias de intercalación. También puede ser soportados conjuntos de caracteres de byte simple, doble u otros.

\bullet: empleo de un modelo basado en disco para minimizar la entrada/salida y recuperar eficientemente la entrada/salida.

\bullet: la capacidad de servir a búsquedas X.500 complejas.

\bullet: la capacidad de crear bases de datos X.500 de mucho mayor tamaño de lo posible previamente sin comprometer el funcionamiento o la robustez. Las bases de datos pueden ser pequeñas o grandes (250,000, 1 millón o más entradas).

\bullet: un diseño óptimo de tablas minimiza el despilfarro de espacio en disco.

\bullet: la capacidad de eliminar cientos de hombres-año en desarrollo de bases de datos relacionales y empleo de bases de datos con "fortaleza industrial" con fiabilidad, integridad, seguridad probadas y herramientas para desarrollar aplicaciones de alto rendimiento.

Basada en este enfoque único, la descripción siguiente detallará varias invenciones en un orden con referencia a las Figs. 2A y 2B que ilustran esquemáticamente una visión global del presente sistema X.500. La tabla y columna, nombres, orden de columnas y valores numéricos descritos se dan sobre una base arbitraria en la visión global. El número de columnas descritas representa un requisito operable preferido. Las columnas adicionales no alteran el uso de la tabla contemplada aquí dentro.

1. Diseño de Principios

Los Intentos de la técnica anterior X.500 en implementación han sido incapaces de superar las diferencias estructurales y operacionales relativamente básicas entre los requisitos y la funcionalidad X.500 y SQL. El estándar X.500 tiene una estructura particular por naturaleza, mientras que el SQL está diseñado para operar sobre tablas estructuradas relacionales.

Para una aplicación de base de datos relacional típica, la naturaleza de los datos es bien conocida, es decir, las tablas comprenderán un número de columnas y cada columna tiene datos relativos a un tipo de datos particular (ver Tabla B1). Los diferentes tipos de datos que pueden almacenarse están limitados a las columnas de la tabla. Los tipos de datos están limitados asimismo a los tipos soportados por la base de datos (por ejemplo, ristras, numéricos, monetarios, fechas). La base de datos puede también almacenar datos no entendidas por la base de datos per se, sino entendidos por la aplicación, por ejemplo datos binarios.

TABLA B1 Tabla de Empleados

1

Si se necesita agregar un nuevo tipo de datos (por ejemplo móvil) entonces tiene que agregarse una nueva columna a la tabla. Esto puede causar problemas si los cambios de tabla de datos no son fáciles de implementar. Asimismo, si los nuevos tipos de datos no son bien empleados (por ejemplo menos del 1% de la organización) entonces se puede producir una redundancia significativa de almacenamiento de datos. Ver Tabla B2.

TABLA B2 Tabla de Empleados

2

En esencia, una invención en la aplicación del X.500 reside en superar la extensibilidad representando los atributos X.500 de la técnica anterior:

empl#

nombre

edad

salario

como se ha descrito más arriba, como

tipo

sintaxis

valor,

siendo la última representación una representación extensible y está adaptada por tanto a implementación con SQL. La última representación es conocida como metadatos. El "valor" metadato puede ser binario.

Un desarrollo adicional basado en el anterior diseño de principio es la adaptación del "diseño de principio" al X.500. Esta adaptación puede realizarse mediante la provisión de una "tabla de propiedades" en la que se agrega al "diseño de principio " el nombre de objeto y nombre de padre.

De la implementación descrita arriba se acumulan beneficios adicionales, incluyendo:

a): independencia de complejidad de filtro - la implementación descrita puede utilizar un optimizador de consulta provisto en SQL y por tanto no hay necesidad de replicar un optimizador de consulta en cada base de datos propietaria a la que se aplique la presente invención,

b): independencia de tamaño - la implementación descrita tiene la capacidad de ser escalada,

c): independencia de la profundidad de árbol - la implementación descrita tiene una comparabilidad jerárquica,

d): rendimiento - si se pone índice en la columna tipo, entonces todos y cada uno de los tipos están indexados.

2. Diseño Conceptual

La técnica anterior tiene dificultad en la implementación del X.500 porque no ha sido estructurada para extensibilidad, orientación a objeto y jerarquía que son requisitos de X.500.

Esto se trata de acuerdo con la presente invención, descomponiendo funcionalmente la "tabla de propiedad" y resultando por tanto en lo que aquí se denomina Diseño Conceptual.

El diseño conceptual reside en proporcionar:

1.: Tabla de Atributo, donde la extensibilidad se trata permitiendo la definición de un nuevo tipo de atributo en esta tabla añadiendo una nueva fila a la tabla;

2.: Tabla Objeto que defina los atributos dentro de cada objeto; y/o

3.: Tabla de Jerarquía que define la relación entre los objetos.

Las estructuras de tabla deben estar de acuerdo con aquellas expuestas en las Figs. 2A y 2B.

Incluso otros aspectos preferidos de la invención residen en tratar los problemas de tolerancia de datos proporcionando en el presente sistema X.500 la posibilidad de reemplazamiento de la columna "valor" de la tabla objeto con las columnas valor "norm" y valor "bruto" y sustituyendo la columna RDN en la tabla de jerarquía con las columnas "nombre norm" y "nombre".

Además, la dificultad en la técnica anterior para acomodar alias es tratada en el presente sistema X.500 proveyendo una columna de "alias" en la tabla de jerarquía. La columna de "alias" es marcada para indicar que la entrada es un alias.

\newpage

Se puede proporcionar un refinamiento adicional reemplazando la columna "alias" con columnas alias y A_EID. La A_EID proporciona información sobre a dónde apunta el alias.

Incluso se puede proporcionar un refinamiento adicional reemplazando la columna "padre" en la tabla de jerarquía con columnas "padre" y "ruta".

La "ruta " va dirigida al problema de implementar la búsqueda X.500 con alias y subárboles. La "ruta" tiene al menos dos propiedades únicas: a) determina la posición absoluta en la jerarquía; y b) se usa para determinar si una entrada está en un subárbol dado mediante su prefijo.

3. Método Conceptual

Varios métodos únicos de interrogar al diseño conceptual se exponen en la siguiente descripción detallada, incluyendo:

a): mapear los servicios X.500 en una secuencia de instrucciones SQL;

b): la estrategia de búsqueda es aplicar el filtro sobre el área de búsqueda empleando las columnas ruta o padre, y/o;

c): trato con alias durante la navegación - donde un alias que apunta es recogido en la columna A_EID;

d): trato de alias durante la búsqueda - encontrar el único conjunto de objetos base que definen áreas del árbol que necesitan ser buscadas, y entonces aplicar b) encima de cada área del árbol.

Una nueva invención se realiza empleando la tabla de atributo para datos entrantes para encontrar la AID a partir de la ID del objeto X.500 y datos salientes leídos de la base de datos, viceversa.

Además, para cualquier nombre distinguido entrante, se navega hasta su EID adecuada y luego cada búsqueda se realiza como se requiere por X.500.

Aún más, se puede proveer un filtro y búsquedas de subárbol para una búsqueda mediante una resolución de un solo paso y empleando la columna de ruta. Una invención es utilizar un campo de "ruta" para aplicar simultáneamente un filtro arbitrario sobre un subárbol arbitrario. Las complicaciones de los alias se gestiona aplicando el método anterior a un subárbol resuelto únicamente.

Incluso otro método único es almacenar la "ruta" para cada entrada como una ristra. A cada ruta se añade un prefijo con la ruta de su entrada padre. Esto es útil para el filtro en el servicio de búsqueda.

4. Diseño Lógico

El diseño lógico está basado en una descomposición del diseño conceptual, aunque la realización de esos componentes de servicio X.500 es independiente.

Las ventajas que se suman por esto incluyen:

1.: Reduce el número de índices por tabla, según se proveen más tablas. Se ha encontrado que los índices primarios son más eficientes (velocidad, tamaño) y los índices secundarios pueden tener grandes sobrecargas (velocidad, tamaño).

2.: Permite que los datos en tablas se encadenen. El encadenamiento de produce como resultado de su primera clave (estructura de almacenamiento) y por tanto los datos pueden organizarse en el disco alrededor de su clave. Por ejemplo, para la tabla de "búsqueda", los apellidos se pueden encadenar juntos.

3.: Gestión - las tablas más pequeñas son más fáciles de gestionar, por ejemplo, más rápidas para actualizar índices, recoger estadísticas, auditoría, copia de seguridad, etc.

4.: Entrada/Salida reducida - mejoras de velocidad debido a filas más pequeñas significan más filas por página y por tanto las operaciones realizan menos E/Ss.

5. Métodos Lógicos

En la descripción detallada siguiente se exponen varios métodos únicos de interrogación de las tablas de diseño lógico.

Además un método reside en mapear en memoria la tabla de atributos. Así, (con la excepción de la carga inicial) no se emiten instrucciones a la base de datos. En el presente sistema X.500, las conversiones se realizan en memoria. Esto proporciona una substancial ventaja en velocidad.

Además, la validación se lleva a cabo en memoria lo que evita la repetición de la base de datos. Las repeticiones gastan tiempo y sistema.

Aún más, para el filtro arbitrario se construye un SQL dinámico equivalente. Esto permite complejidad arbitraria en búsquedas X.500.

También para resultados de búsquedas, el presente sistema emplea consultas de orientación de conjunto de SQL para evitar el procesamiento de "una fila cada vez". Así los resultados de búsqueda se pueden ensamblar en paralelo en memoria.

6. Diseño Físico

Se introducen nuevas tablas y nuevas columnas para superar las restricciones de ancho de columna y de tamaño de clave y para conseguir optimizaciones de espacio.

El texto siguiente es una exposición de las realizaciones de la invención perfilada:

1. Diseño de Principio

Con referencia a la Fig. 2A, el diseño de principio va dirigido al problema básico de representar la naturaleza extensible, orientada a objeto y jerárquica del X.500 en tablas relacionales. En esta sección se expondrá (con ejemplos) que el diseño de tabla de principio se puede representar mediante una simple tabla como se muestra en la Tabla 1 debajo.

TABLA 1 Tabla de Propiedades X.500

3

En esta y en las siguientes secciones todos los nombres de columna y sus posiciones son arbitrarios. La intención es definir lo que contienen y cómo se usan.

1.1 Extensibilidad

Para una aplicación típica de base de datos relacional, la naturaleza de los datos es bien conocida, es decir, las tablas constarán de un número de columnas y cada columna contiene datos relativos a un tipo particular de dato (ver Tabla 1.1a). La tabla es autodescriptiva, es decir, las relaciones entre elementos de datos están implícitas por ser de la misma fila (esta es la base de la teoría relacional).

TABLA 1.1a Tabla relacional típica

4

Sin embargo, el enfoque anterior no es extensible porque el número de tipos de dato diferentes está limitado al número de columnas de la tabla. Si se necesita agregar un nuevo tipo de datos (por ejemplo, número de teléfono móvil)entonces se tiene que añadir una nueva columna a la tabla (ver Tabla 1.1b). Cualquier aplicación que acceda a esta tabla necesitará ser actualizada para consultarla explícitamente.

TABLA B2 Tabla relacional con una columna extra

5

En la práctica también existen otros problemas. Si el nuevo tipo de dato no se emplea bien (por ejemplo, menos del 1% de la organización tiene un teléfono móvil) entonces la tabla será dispersa (por ejemplo, si una persona dada no tiene un móvil entonces esa entrada de fila/columna será NULO). Además, los tipos de datos están limitados a los tipos soportados por la base de datos (por ejemplo, ristras, numéricos, monetario, fecha, etc.).

La solución es tratar los tipos de datos como genéricos. La presente invención adopta el método de representar atributos arbitrarios (por ejemplo, XOM[X/Gestión de Objeto ABIERTA] API [Interfaz de Programación de Aplicación]) como tipo, sintaxis, combinación de valor (ver Tabla 1.1c)

TABLA 1.1c Representación de atributos arbitrarios

6

1.2 Orientado a Objeto

X.500 define objetos (por ejemplo, personas, organizaciones, etc.) que pueden contener un número arbitrario de "atributos". Como en la tabla deben aparecer muchos objetos se necesita un mecanismo para distinguir cada objeto. Con este fin se añade a la tabla una columna "nombre de objeto" (ver Tabla 1.2a).

TABLA 1.2a Representación de objetos con valores arbitrarios

7

El método anterior permite asignar (relacionar) cualquier número de atributos a una entrada. Estos atributos podrían ser de complejidad arbitraria (por ejemplo, se podría gestionar una dirección postal multilínea). Como el número de columnas está fijado, se pueden agregar nuevos atributos a cualquier objeto sin tener que redefinir la aplicación. Si se agrega un nuevo atributo entonces una aplicación que lea la entrada devolverá una fila extra.

1.3 Jerárquico

Un método de representar sistemas jerárquicos (por ejemplo, explosión de piezas) es emplear una combinación padre/hijo (ver Tabla 1.3a).

TABLA 1.3a Jerarquía de explosión de piezas

8

El X.500 define sus objetos para ser jerárquicos. Las relaciones entre objetos sigue una estructura en árbol donde cada objeto tiene un objeto padre y cada padre puede tener cero o más hijos. Esta relación se puede representar en una tabla de PROPIEDAD general mediante la adición de una columna "nombre de padre", que se emplea para almacenar el nombre del objeto padre (ver Tabla 1.3b).

TABLA 1.3b Tabla de Propiedad X.500

9

Nótese que la raíz del árbol no tiene padre. Por tanto si Chis y Alana trabajan para Datacraft y Datacraft es un hijo de la raíz entonces podemos decir que Chris y Alana son hijos de Datacraft y que Datacraft es el padre de Chris y Alana.

2. Diseño Conceptual

En la Sección 1 se mostró que una simple Tabla de Propiedad podría representar la naturaleza extensible, orientada a objeto y jerárquica del X.500 (ver Tabla 2a).

TABLA 2a Tabla de Propiedad

10

En referencia a la Fig. 2A, en esta sección se mostrará que la funcionalidad completa de X.500 se puede representar mediante el uso de tres tablas como se muestran debajo (ver Tabla 2b y Fig. 2A).

TABLA 2b Diseño Conceptual Completo

11

El diseño conceptual va dirigido a los mayores problemas con la implementación de la funcionalidad plena del X.500 en tablas relacionales. Según se presenta cada punto de diseño principal, se proporcionan ejemplos para ilustrar la solución.

2.1 Descomposición Funcional

La Tabla de Propiedad (Fig. 2A) se puede descomponer en tablas separadas que reflejen la naturaleza jerárquica, orientada a objetos y extensible del X.500, preferiblemente como sigue;

\bullet una Tabla de Jerarquía que define la relación estructural entre objetos.

\bullet una Tabla Objeto que define los valores de atributo dentro de cada objeto.

\bullet una Tabla de Atributo que define los diferentes tipos de atributos.

Estas tablas resultan de un proceso denominado descomposición funcional.

Para tratar el problema de correlar las relaciones entre tablas, se introducen identificadores numéricos arbitrarios. El EID o "identificador de entrada" correlaciona cada objeto con su información jerárquica. El AID o "identificador de atributo" correlaciona cada valor en la tabla objeto con su información de atributo.

El diseño se considera muy eficiente porque los grupos que se repiten en la Tabla de Propiedad (síntaxis-tipo y nombre objeto-nombre padre) se han eliminado. Además, para SQL, las columnas asociadas son simples enteros.

(Tabla pasa a página siguiente)

TABLA 2.1 Diseño Conceptual Básico

14

2.2 Atributos X.500

Los atributos X.500 tienen un identificador de protocolo que se transfiere cuando se comunica cualquier dato entre sistemas extremos. Estos identificadores están definidos internacionalmente y se denominan IDENTIFICADORES DE OBJETO (por ejemplo, 2.5.4.4 significa una ristra de apellido). Por tanto se puede agregar una columna (Objetid) a la tabla de Atributos de forma que se pueden realizar las conversiones entre identificadores de objetos X.500 y los identificadores internos de atributo.

Además, el X.500 permite que un atributo tenga un número arbitrario de valores (por ejemplo, el teléfono móvil se puede tratar simplemente como un segundo número de teléfono). Por tanto se introduce un "identificador de valor" o VID para identificar valores dentro de un atributo en la Tabla Objeto.

TABLA 2.2 Diseño Conceptual con atributos X.500

18

2.3 Nombres X.500

En X.500, cada entrada usa uno o más de sus valores de atributo (Valores Distinguidos) para nombrar a la entrada. Se añade una columna "Disting" a la Tabla Objeto para marcar los valores distinguidos.

Los Valores Distinguidos se combinan para formar un Nombre Distinguido Relativo (RDN) que denomina a la entrada. La columna "Nombre" en la tabla de Jerarquía almacena el RDN. Esto es una optimización que anula la necesidad de que el RDN sea construido a partir de valores distinguidos en la tabla Objeto.

Una entrada es denominada únicamente mediante un Nombre Distinguido (DN) que consta de todos los RDNs de sus ascendientes desde la raíz hacia abajo y el RDN del propio objeto. Una innovación es agregar una columna de "ruta" a la tabla de Jerarquía que defina la posición absoluta de la entrada en el árbol como una lista de EIDs. La ruta tiene tres importantes propiedades;

1): permite una rápida construcción de los DNs, (la lista EID define todos los RDNs)

2): permite rápidas búsquedas en subárbol (ver Métodos Conceptuales)

3): es independiente de su DN (cualquiera de los RDNs en el DN puede renombrarse sin afectar a la ruta).

TABLA 2.3 Diseño Conceptual con atributos X.500 y nombres

21

2.4 Alias X.500

El X.500 tiene también el concepto de "alias". Un objeto alias apunta efectivamente a otra entrada y por tanto proporciona un nombre alternativo para esta entrada. Por tanto se añade una marca "alias" a la Tabla de Jerarquía. Cuando se descubre un alias durante la Navegación (es decir el DN suministrado contiene un alias), entonces el valor de alias debe leerse de la Tabla Objeto. Este alias DN debe resolverse a dónde apunta el alias antes de que pueda continuar la Navegación de la entrada original.

Una innovación es emplear una columna "EID alias" o A_EID para almacenar "a dónde" "apunta" el alias. Esto elimina la necesidad de navegar repetidamente por un alias.

TABLA 2.4 Diseño Conceptual con atributos X.500, nombres y alias

24

2.5 Tolerancia de Datos X.500

Cada atributo X.500 tiene una sintaxis (internacionalmente definida). Las sintaxis de atributos X.500 definan cómo debe ser tratado cada atributo. En todas las sintaxis de ristra (por ejemplo, Imprimibles, Numéricas, etc.) los espacios superfluos deben ser ignorados. En algunas sintaxis la caja no es importante (por ejemplo, Ristra Ignorar Caja y Lista Ignorar Caja) y así los nombres "Chris Masters", "Chris MASTERS" y "ChRis MaSTeRS" se consideran idénticos.

Con el fin de hacer comparaciones (por ejemplo, búsqueda de un valor particular), las reglas de sintaxis se pueden aplicar para crear una forma normalizada (por ejemplo, "CHRIS MASTERS"). Si esta forma normalizada se almacena en la base de datos, entonces se eliminan cualesquiera variaciones en la forma de entrada y se puede emplear la igualación exacta (que es necesaria cuando se emplea SQL).

Ambos, los datos normalizados y los datos brutos se almacenan en la base de datos. Los datos brutos son necesarios de forma que los usuarios puedan recuperar los datos de la misma forma que fueron introducidos originalmente. Por tanto la columna "Nombre" en la Tabla de Jerarquía se convierte en "NombreBruto" y se añade una columna "NombreNorm". Igualmente la columna "Valor" en la Tabla Objeto se convierte en "ValorBruto" y se agrega una columna "ValorNorm".

TABLA 2.4 Diseño Conceptual Completo

28

3. Métodos Conceptuales

Esta sección introduce los servicios básicos X.500 y muestra cómo el diseño de tabla conceptual, mostrado en la Tablas 3a o en la Fig. 2A, es suficiente para implementar servicios X.500 y sus complejidades.

TABLA 3a Diseño de Tabla Conceptual

32

La jerarquía ejemplo mostrada en la Tabla 3b se empleará para ilustrar estos servicios. Cada nombre en el diagrama representa una entrada objeto en la base de datos. El triángulo representa una entrada alias y la línea de puntos representa la conexión entre la entrada alias y el objeto al que esta apunta. Los números próximos a cada entradas son las EIDs de entrada.

En el ejemplo, la entrada "1" tiene un RDN con un valor de "Datacraft", la entrada "11" tiene un RDN con un valor de "Ventas", la entrada "20" tiene un RDN con un valor de "Productos de Red" y la entrada "31" tiene un RDN con un valor de "Alana Morgan". El DN de la entrada "31" está formado por una secuencia de RDNs, a saber, "Datacraft", "Ventas", "Productos de Red", "Alana Morgan".

La entrada alias "Datacrfat/Redes" apunta a la entrada "Datacraft", "Ventas", "Productos de Red". Cuando se navega hasta esta entrada el proceso de navegación encontraría la entrada alias, luego buscaría el DN del objeto apuntado por el alias y luego navegaría desde la raíz hasta la entrada objeto devolviendo una EID de "20" y una ruta de "1.11.20.".

TABLA 3b Arbol de Entrada

35

Listadas más abajo hay tablas de muestra que muestran cómo se almacenan los datos. La Tabla de Jerarquía (Tabla 3c) muestra como se almacenan las entradas para le jerarquía ejemplo. La Tabla de Atributo (Tabla 3e) muestra atributos que están contenidos en la entrada "Datacraft/Ventas/Productos de Red/Chris Masters". La Tabla Objeto (Tabla 3d) muestra como se almacenan los valores de estos atributos.

TABLA 3c Tabla de Jerarquía de Muestra

36

TABLA 3d Tabla Objeto de Muestra

37

TABLA 3e Tabla de Atributos Muestra

38

Nombres Distinguidos

Para la entrada mostrada en la Tabla Objeto de muestra (Tabla 3d) dos de los atributos y apellido, son valores distinguidos (o valores de denominación) que se combinan para formar el RDN para la entrada. Este RDN se almacena en la Tabla de Jerarquía.

Atributos Multivalor

En X.500 es permisible a un atributo ser multivalor. La columna VID se emplea para distinguir entre valores para un atributo. En la Tabla Objeto muestra, el atributo númeroteléfono es multivalor.

3.1 Mapeando Servicios en SQL 3.1.1 Tipos y Valores de Atributos

Cualquier dato suministrado por un servicio X.500 se suministra como una lista de ObjetIds y de sus valores asociados. Estos deben convertirse en AIDs (empleando la Tabla de Atributo) y valores normalizados (empleando la Tabla Objeto) para uso por la aplicación X.500. La base de datos devuelve datos como AIDs y Valores Brutos, que deben luego ser convertidos en ObjetIds y sus valores asociados en el resultado X.500.

3.1.2 Navegación

Cada servicio X.500 proporciona un Nombre Distinguido que es convertido en una EID para uso por la aplicación X.500.

Cuando la aplicación procesa un servicio devuelve una o más EIDs. Estas EIDs pueden ser traducidas inversamente a Nombres Distinguidos en el resultados X.500.

Todos los servicios X.500 dependen de la navegación en al árbol directorio. Para navegar hacia una entrada particular, se realiza el siguiente proceso:

\bullet Dado el DN de la entrada, localizar la entrada en la tabla de jerarquía que tenga un RDN igual al primer RDN en el DN.

\bullet Almacenar la EID.

\bullet Localizar recursivamente la entrada que tenga un RDN igual al próximo RDN en el DN y un padre igual a la EID almacenada.

\newpage

Ejemplo

Navegar hacia la entrada "Datacraft/Ventas/Productos de Red/Peter Evans". Esto será el resultado de varias instrucciones de selección, con cada una devolviendo un EID que se usa como el valor del PADRE en la próxima instrucción.

: Seleccionar EID de JERARQUIA

: Donde PADRE = 0 y RDN = "DATACRAFT"

: Seleccionar EID de JERARQUIA

: Donde PADRE = 1 y RDN = "VENTAS"

: Seleccionar EID de JERARQUIA

: Donde PADRE = 11 y RDN = "PRODUCTOS DE RED"

: Seleccionar EID de JERARQUIA

: Donde PADRE = 20 y RDN = "PETER EVANS"

3.1.3 Lectura

Los atributos seleccionados para lectura pueden ser proporcionados. Solo se devolverán los valores de estos atributos (si están presentes en la entrada).

Como una opción de lectura se puede seleccionar 'solo Tipos', en cuyo caso no se devolverán valores. Se devolverán todos los tipos presentes en la entrada o aquellos seleccionados.

Navegar hasta la entrada a leer. Almacenar la EID. En la Tabla Objeto leer los valores de todas las filas que igualan la EID almacenada.

Ejemplo

\bullet: Leer la entrada "Datacraft/HQ/Productos de Red" y devolver todos los tipos de valores.

Navegar hasta la entrada (como en 3.1.2) y entonces;

: Seleccionar AID, VALORBRUTO de OBJETO

: Donde EID = 20

3.1.4 Comparación

Comparación devuelve un resultado 'igualado' o 'no igualado'. Se introduce un valor bruto pero la comparación se realiza empleando el valor normalizado.

Navegar hasta la entrada pedida. Almacenar la EID. En la Tabla Objeto verificar un valor que case en todas las filas que igualan la EID almacenada y la AID especificada.

Ejemplo

\bullet: Comparar el Número de teléfono "03 727 9256" con la entrada "Datacraft/Ventas//Productos de Red/Chris Masters".

Navegar hasta la entrada y luego;

: seleccionar VALORBRUTO de OBJETO

: donde EID = 30

: y AID = 20

: y VALORNORM = "03 727 9456"

Si se selecciona un valor entonces devuelve "igualado", en otro caso devuelve "no igualado".

3.1.5 Listado

Navegar hasta la entrada pedida. Almacenar la EID. En la Tabla de Jerarquía devuelve los RDNs para todas las filas con un padre que iguale la EID almacenada.

Ejemplo

\bullet: Listado de la entrada "Datacraft/Ventas".

Navegar hasta la entrada y luego;

: Seleccionar NOMBREBRUTO de JERARQUIA

: Donde PADRE = 11

3.1.6 Añadir Entrada

Navegar hasta la entrada padre pedida. Almacenar la EID del padre. Agregar una nueva EID a la Tabla de Jerarquía y añadir filas a la Tabla Objeto para cada valor en la nueva entrada.

Ejemplo

\bullet: Agregar una nueva entrada bajo la entrada "Datacraft/Ventas/Productos de Red".

Navegar hasta la entrada y entonces;

insertar en OBJETO

: (EID, AID, VID, DISTING, VALORNORM, VALORBRUTO)

: valores (33,3, 1, 1, EDWIN MAHER, Edwin Maher)

e

: insertar en JERARQUIA

: (EID, PADRE, RUTA, ALIAS, A_EID, NOMBRENORM, NOMBREBRUTO)

: valores (33, 20, 1.11.20.33., 0, 0, EDWIN MAHER, Edwin Maher)

3.1.7 Eliminar Entrada

Navegar hasta la entrada pedida. Verificar que la entrada es una hoja en el árbol, (es decir verificar que no tiene entradas subordinadas en el árbol). Almacenar la EID. Eliminar la entrada de la Tabla de Jerarquía. En la Tabla Objeto eliminar todas las filas que igualen la EID almacenada.

Ejemplo

: \bullet Eliminar una entrada (con EID = 33) bajo la entrada "Datacraft/Ventas/Productos de Red".

Navegar hasta la entrada y entonces;

: borrar de OBJETO

: donde EID = 33

y

: borrar de JERARQUIA

: donde EID = 33

3.1.8 Modificación de Entrada

Navegar hasta la entrada pedida. Almacenar EID. En la Tabla Objeto, Agregar, Eliminar o Modificar filas que igualen la EID almacenada.

Ejemplo

\bullet: Modificar la entrada "Datacraft/Ventas/Productos de Red/Alana Morgan".

Añadir valor - puesto = "Gerente de Sucursal".

Navegar hasta la entrada y entonces;

: seleccionar EID, AID, VALORNORM de OBJETO

: donde EID = 31

Comprobar las filas devueltas en un atributo puesto. Si no existe ninguno, se puede agregar el atributo, de otro modo debe comprobarse el atributo para ver si puede ser multivalor y si ya existe.

: Insertar en OBJETO

: (EID, AID, VID, DISTING, VALORNORM, VALORBRUTO)

: valores (31, 12, 1, 0, GERENTE DE SUCURSAL, Gerente de Sucursal)

3.1.9 Modificar RDN

Navegar hasta la entrada pedida. Verificar que el nuevo nombre (RDN) no existe en el nivel actual del subárbol ( es decir, que el nuevo DN es distinto). Almacenar la EID. Modificar la entrada en las tablas de Jerarquía y Objeto.

Ejemplo

\bullet: Modificar el RDN de la entrada "Datacraft/Ventas/Productos de Red/Chris Masters" a "Christine Masters".

Navegar hasta la entrada y entonces;

: seleccionar EID de JERARQUIA

: donde PADRE = 20

: y VALORNORM = "CHRISTINE MASTERS"

Si ninguna entrada se devuelve entonces se puede insertar el nuevo RDN. Primero poner el antiguo RDN para que sea un valor no distinguido.

: actualizar OBJETO

: poner DISTING = 0

: donde EID = 30 y VALORNORM = "CHRIS"

y

: actualizar JERARQUIA

: poner NOMBRENORM = "CHRISTINE MASTERS" y

: poner NOMBREBRUTO = "Christine Masters"

: donde EID =30

e

: insertar en OBJETO

: (EID, AID, VID, DISTING, VALORNORM, VALORBRUTO)

: valores (30, 3, 1,1, "CHRISTINE", "Christine")

\newpage

3.2 Estrategia de Búsqueda

El servicio X.500 más potente y útiles el servicio de búsqueda. El servicio de búsqueda permite que se aplique un filtro complejo arbitrario sobre una porción del Arbol de Información de Directorio (el área de búsqueda).

\bullet: Un filtro es una combinación de uno o más elementos de filtro conectados mediante los operadores AND, OR y NOT. Por ejemplo; apellido = "MASTERS" AND puesto = "DIRECTOR DE VENTAS"

\bullet: El área de Búsqueda es la parte del árbol que es cubierta por el ámbito de la búsqueda (solo-objeto-base, un-nivel o subárbol completo).

Una técnica para resolver búsquedas es aplicar el filtro y luego ver si alguna entrada que casa está en el área de búsqueda. En este caso se aplica un filtro al árbol completo y se devuelven las EIDs de todas las filas que casan con el filtro. Luego, para cada EID encontrado, se hace un paso de búsqueda por la jerarquía para ver si la entrada es una subordinada del objeto base (es decir, la entrada tiene un padre/abuelo/... que es el objeto base). Si el número de igualdades es grande y el subárbol pequeño esto es muy ineficiente. Esta técnica no puede hacer frente a los alias porque un alias no es un padre del objeto al que apunta y muchos alias pueden apuntar a un solo objeto.

Una segunda estrategia es obtener una lista de todos las EIDs en el área de búsqueda y luego aplicar el filtro a estas EIDs. Si se resuelve que un alias apunta fuera del área de búsqueda original entonces se expande el subárbol apuntado por el alias y las EIDs en este subárbol se añaden a la lista. Entonces se aplica el filtro al conjunto de EIDs expandido. Esto es muy mediocre si el área de búsqueda es grande.

Una innovación es aplicar simultáneamente el filtro sobre el área de búsqueda (en vez de secuencialmente como en los dos métodos descritos antes). Esto se denomina resolución en un solo paso. Se considera que este método proporciona una mejora de rendimiento considerable sobre los métodos anteriores porque las filas que recupera son aquellas que satisfacen los requisitos del filtro y del ámbito de la búsqueda.

Cuando se lleva a cabo una búsqueda a un nivel el filtro se aplica a todas las entradas que tienen un padre igual a la EID del objeto base (por ejemplo; búsqueda donde padre = 20 se aplicará a entradas 30, 31 y 32).

Cuando se realiza una búsqueda en subárbol, la ruta se emplea para expandir el área de búsqueda. La "ruta" de cada entrada es una ristra de números (por ejemplo, "1.10.50.222." que indica que la entrada 222 tiene un padre de 50, un abuelo de 10 y un bisabuelo de 1). La ruta tiene la propiedad única de que la ruta de una entrada es un prefijo de la ruta de todas las entradas que están subordinadas a la entrada. Esto es, la ruta de una entrada forma el prefijo de las rutas de todas las entradas en el subárbol debajo de la entrada. Por tanto, cuando se realiza una búsqueda de subárbol obtenemos el objeto base del subárbol y entonces aplicar el filtro a todas las entradas que tienen una ruta que va antepuesta con la ruta del objeto base (por ejemplo; para buscar todas las entradas bajo "Ventas" realizamos una búsqueda donde RUTA COMO 1.11.%).

Búsqueda de Objeto Base

Navegar hasta el objeto base. Almacenar la EID. En la Tabla Objeto leer valores designados de filas que casan con la EID almacenada donde se satisface un criterio de filtro, por ejemplo, prefijo telefónico ="727".

Ejemplo

\bullet: Búsqueda a partir de "Datacraft/Ventas/Productos de Red" de una entrada con apellido = "MORGAN", empleando una búsqueda "solo-objeto-base".

Navegar hasta el objeto base y luego;

: seleccionar AID, VALORBRUTO de OBJETO

: donde EID =20 y AID = 4

: y NOMBRENORM = "MORGAN"

Búsqueda a un Nivel

Navegar hasta el objeto base. Almacenar la EID. Devolver la lista de EIDs que tienen una EID padre que casa con la EID almacenada (en la Tabla de Jerarquía) y tienen valores que satisfacen los criterios de filtro (Tabla Objeto). En la Tabla Objeto leer valores designados para los EIDs devueltos.

\newpage

Ejemplo

\bullet: Búsqueda a partir del objeto base "Datacraft/Ventas/Productos de Red" de una entrada con apellido = "MORGAN", empleando una búsqueda "un-solo-nivel".

Navegar hasta el objeto base y luego;

: seleccionar H.EID de JERARQUIA H, OBJETO O

: donde PADRE = 20 y AID = 4 y NOMBRENORM = "MORGAN"

: y H.EID = O.EID

luego colocar los EIDs devueltos en una EIDLIST y

: seleccionar AID, VALORBRUTO a partir de OBJETO

: donde EID en [EIDLIST]

Búsqueda en Subárbol

Navegar hasta el objeto base. Almacenar la EID. Devolver la lista de todos los EIDs con una ruta como la del objeto base (Tabla de Jerarquía)y tienen valores que satisfacen los criterios de filtro (Tabla OBJETO). En la Tabla Objeto leer valores designados para los EIDs devueltos.

Ejemplo

\bullet: Búsqueda a partir del objeto base "Datacraft/Ventas/Productos de Red" de una entrada con apellido = "MORGAN", empleando una búsqueda "subárbol-completo".

Navegar hasta el objeto base y luego;

: seleccionar H:EID de JERARQUIA H, OBJETO O

: donde RUTA como "1.11.20.%" y AID = 4

: y NOMBRENORM = "MORGAN"

: y H.EID = O.EID

luego colocar EIDs devueltos en una EIDLIST y

: seleccionar AID, VALORBRUTO de OBJETO

: donde EID en [EIDLIST]

3.3 Alias y Navegación

Los alias se resuelven durante la navegación si no está puesta la marca "no-desreferenciar-alias" y el servicio no es un servicio de actualización (agregar, borrar, modificar, modificar RDN).

Cuando se descubre un alias durante la navegación se debe resolver el alias. Esto es, se debe obtener el objeto al que el alias apunta. Primero comprobamos la columna A_EID de la Tabla de Jerarquía. Si el A_EID es 0 entonces al objeto al que apunta el alias se debe obtener de la Tabla Objeto y este objeto debe ser navegado entonces y la EID resultante almacenada en la columna A_EID. Si esto se hace exitosamente entonces el resto de la ruta se puede navegar. Mediante el almacenamiento del EID del objeto alias en la columna A_EID de la Tabla de Jerarquía es posible evitar navegar hasta objetos alias. Esto puede ahorrar tiempo, especialmente si el objeto alias está a un nivel bajo de la jerarquía.

3.4 Alias y Búsqueda

Los alias son desreferenciados durante una búsqueda si la marca "búsqueda-alias" en el argumento de búsqueda está puesta. La ejecución del servicio de búsqueda aun desreferenciando aliases se vuelve un proceso de dos pasos. Primeramente definir el área de búsqueda y luego aplicar el filtro a las entradas dentro del área de búsqueda. Los alias desreferenciados como parte del servicio de búsqueda pueden expandir el área de búsqueda a la que se aplica el filtro. También restringen el área de búsqueda porque cualesquiera alias desreferenciados son excluidos del área de búsqueda.

Alias y Búsquedas a un Nivel

Si los alias están siendo desreferenciados como parte de una búsqueda a un nivel y se encuentra una entrada alias entonces debe resolverse el alias (usando la Tabla Objeto o la A_EID). El objeto alias es añadido luego al área de búsqueda a la que se aplica el filtro. En una búsqueda a un nivel donde se encuentran alias el área de búsqueda constará de entradas no-alias directamente subordinadas al objeto base y a todos los alias desreferenciados.

Alias y Búsqueda de Subárbol

Si los alias están siendo desreferenciados como parte de una búsqueda de subárbol completo y se encuentra una entrada alias entonces debe resolverse el alias (empleando la Tabla Objeto o la A_EID) y esta EID debe entonces ser tratada como otro objeto base, a menos que sea parte de un subárbol ya procesado.

Cuando se están desreferenciando alias durante una búsqueda la columna "Ruta" puede usarse para encontrar entradas alias dentro de una unión subárbol. Si se encuentra una entrada alias que apunte fuera del subárbol actual entonces el subárbol apuntado por el alias también puede ser buscado para alias. Una propiedad de la estructura de árbol jerárquica es que cada subárbol es representado únicamente por un único objeto base (es decir, los subárboles no se solapan). Cuando se ejecuta una búsqueda en subárbol construimos una lista de objetos base que definen subárboles únicos. Si no se encuentran alias entonces la lista contendrá solo un objeto base. Si se encuentra un alias que apunta fuera del subárbol que se está procesando entonces agregamos el objeto alias a la lista de objetos base (a menos que uno o más de los objetos base está subordinado al objeto alias en cuyo caso el(los) objeto(s) base subordinado(s) son reemplazados por el objeto alias). El área de búsqueda constará por tanto de entrada no-alias que tienen una ruta prefijada por la ruta de uno de los objetos base.

4. Diseño Lógico

Aunque el Diseño Conceptual (ver Tabla 4a) es suficiente para implementar la funcionalidad X.500, se pueden hacer nuevas mejoras de funcionamiento.

TABLA 4a Diseño Conceptual

39

Se pueden conseguir mejoras de rendimiento en diseño relacional convencional porque se pueden hacer hipótesis sobre los datos - el dato es esencialmente fijado al tiempo de diseñar la aplicación. En X.500 ninguno de los tipos de datos son conocidos. No obstante incluso se pueden conseguir mejoras de rendimiento porque se pueden hacer presunciones sobre los servicios - estos son conocidos al tiempo en que la aplicación X.500 bes diseñada.

En referencia a la Fig. 2b, una aproximación innovadora es reconocer que cada tabla se puede organizar alrededor de las relaciones de servicio principales (en vez de alrededor de las relaciones de datos principales en un diseño convencional). Se mostrará que las anteriores tablas se pueden descomponer en varias tablas menores y más eficientes como se muestra debajo.

\newpage

TABLA 4b Diseño Lógico

42

46

4.1 Descomposición de Servicios

La realidad práctica para la mayoría de las RDBMSs es que las tablas grandes con muchas columnas no funcionan tan bien como las tablas menores con menos columnas. Las principales razones tienen que ver con las opciones de indexación, el funcionamiento de E/S y la gestión de tabla(ver secciones 4.5 y 4.6). Esto es por lo que las técnicas de diseño relacional de la técnica anterior apuntan a enfocar la información primaria en tablas separadas y derivan información secundaria vía uniones de tablas (es decir técnicas de normalización y fragmentación).

Una innovación en la consecución de funcionamiento X.500 es descomponer las tablas alrededor de relaciones de servicio primario y derivar servicios secundarios vía asociaciones. Este proceso se denomina descomposición de servicio. Se hacen las siguientes consideraciones:

(1): Las columnas que tienen fuertes relaciones se prefiere mantenerlas juntas (para evitar asociaciones innecesarias);

(2): Si el número de filas significativas en una columna dada es independiente de las otras columnas relacionadas, entonces esta columna dada es una candidata a una tabla separada;

(3): Si una columna se usa solamente para localizar información (entrada) o se usa solamente para devolver resultados (salida) entonces es candidata a su propia tabla;

(4): Si una columna se usa como clave para más de un servicio entonces es preferido que sea una clave primaria y por tanto en su propia tabla (cada tabla puede tener solo una clave primaria).

(5): Las claves se prefiere que sean únicas o al menos fuertes (no repetitivas).

En la Tabla 4.1 se muestra un análisis de primer nivel de uso de columnas.

49

Clave para símbolos en la tabla anterior:

: J - Tabla de Jerarquía

: O - Tabla Objeto

: S - Valor suministrado(usado en SQL para Búsqueda en tabla)

: D - Valor devuelto (valor recuperado de las tablas)

: () - elemento que puede o no estar presente dependiendo de las opciones del servicio.

A partir de la anterior información y de un análisis adicional, las Tablas de Diseño Conceptual pueden descomponerse en varias tablas menores como se describe en las siguientes secciones.

4.2 Descomposición de Tabla de Jerarquía

La Tabla de Jerarquía contiene las siguientes columnas:

TABLA 4.2a Tabla de Jerarquía

51

La Tabla de Jerarquía contiene información sobre objetos y sus padres, sus nombres, sus posiciones absolutas en la jerarquía y si son alias. Por tanto esta tabla puede dividirse en cuatro tablas: DIT, NOMBRE, ARBOL Y ALIAS.

La información padre se usa para encontrar un hijo dado o para actuara sobre entradas que tienen un padre dado. Encontrar un hijo dado (por ejemplo, Padre = 0, NombreNorm = "Datacraft") es la basa para la Navegación y actualización verificación (verificación de la existencia de un objeto entes de un Agregar o ModificarRdn). La actuación sobre entradas que tienen un padre dado se emplea durante Listado o Búsqueda a un Nivel. Por tanto la tabla DIT (Arbol de Información de Directorio) tiene información requerida para Navegación, pero permite que se use su columna PADRE por otros servicios.

TABLA 4.2b Tabla DIT

52

Un objeto se diferencia de sus hermanos por su Nombre Distinguido Relativo (RDN). Los RDNs son devueltos para una Lista (en conjunción con un Padre dado) o como parte de un Nombre Distinguido completo (Lectura, Búsqueda). Así la tabla NOMBRE tiene información requerida para devolver nombres (el RDN bruto).

TABLA 4.2c Tabla NOMBRE

53

Es necesaria una posición absoluta de objeto en la jerarquía para construir DNs (a partir de los que se recuperan los RDNs brutos) y para expandir subárboles durante Búsqueda. Así la tabla ARBOL tiene información sobre la Ruta de una entrada (la secuencia de EIDs hacia abajo desde la raíz).

TABLA 4.2d Tabla ARBOL

54

La información Alias es ubicada en memoria cache de forma que cada vez que se encuentra un alias durante Navegación no tiene que ser resuelto repetidamente. Así la tabla ALIAS contiene solamente entradas que son alias. También es usada durante la Búsqueda a Un Nivel (en conjunción con la columna DIT Padre) y durante Búsqueda en Subárbol (en conjunción con la columna Ruta) para determinar si hay algún alias en el área de búsqueda.

TABLA 4.2e Tabla ALIAS

55

4.3 Descomposición de Tabla Objeto

La Tabla Objeto contiene las siguientes columnas:

TABLA 4.3a Tabla Objeto

56

La Tabla Objeto esencialmente contiene información para encontrar un valor particular (por ejemplo, AID = apellido, ValorNorm = "Harvey") y para recuperar valores (por ejemplo, AID = apellido, ValorBruto = "Harvey"). Por tanto esta tabla puede dividirse en dos tablas: BÚSQUEDA y ENTRADA.

La Tabla Búsqueda se emplea para resolver filtros en el servicio de Búsqueda. También se usa para encontrar valores durante Comparación, Modificación y ModificaciónRDN. La Tabla de Búsqueda contiene una fila para cada valor de atributo de cada entrada. Solo los valores normalizados se almacenan en esta tabla.

TABLA 4.3b Tabla de BÚSQUEDA

57

La tabla Entrada se usa para devolver valores en Lecturas y Búsquedas. La tabla Entrada contiene una fila por cada valor de atributo para cada entrada. El valor BRUTO es el valor tal como se ha proporcionado inicialmente cuando la entrada se agregó o se modificó.

TABLA 4.3c Tabla ENTRADA

58

4.4 Tabla Atributo

La tabla Atributo es esencialmente la misma que el Diseño Conceptual. En la práctica el campo "tipo" es solo descriptivo ya que cualquier Identificador de Objeto X.500 entrante/saliente es convertido al/del identificador de atributo interno, AID. Por tanto esta columna ha sido renombrada DESC para significar que es un campo descriptivo.

TABLA 4.4 Tabla ATTR

59

4.5 Selección de Indice

Se consigue el rendimiento empleando SQL porque el RDBMS es capaz de satisfacer la consulta usando un índice relevante. Esto significa que toda consulta que tiene una condición (la cláusula "donde" en SQL) se prefiere que tenga un índice asociado (de otro modo el RDBMS tiene que recurrir a una exploración a nivel de tabla). No obstante, en los RDBMSs prácticos:

\bullet: El número de índices es restringido;

\bullet: Puede haber una elevada sobrecarga por mantener índices secundarios;

\bullet: Se pueden necesitar índices compuestos para satisfacer cualquier consulta. Así si se realiza una consulta por columnas (por ejemplo, tipo = apellido y valor = "SMITH") entonces índices separados sobre tipo y valor pueden no dar como resultado un acceso totalmente indexado. Se requerirá un índice compuesto sobre ambos tipo y valor.

Una innovación de la descomposición de tabla en las secciones previas es maximizar el uso de índices primarios en las tablas. Esto reduce el número de índices secundarios (es decir, se convierten en índices primarios sobre su propia tabla). Seguidamente hay una lista de los índices para cada una de las tablas empleadas en el diseño lógico.

TABLA 4.5 Indices de Tabla para el Diseño Lógico

60

El diseño de tabla significa que muchas consultas se pueden manejar sin asociaciones, dando una mejora sustancial de rendimiento.

Las asociaciones que se consideran necesarias se listan debajo:

\bullet: Listado - para devolver los RDNs_BRUTO bajo un objeto dado (DIT asociado con NOMBRE).

\bullet: Búsqueda /Subárbol - para encontrar EIDs que casa con un filtro en un subárbol completo (donde el objeto base no es el raíz) (ARBOL asociado con BÚSQUEDA).

\bullet: Búsqueda/ Un Nivel - para encontrar EIDs que casan con un filtro de un nivel bajo el objeto base (DIT asociado con BÚSQUEDA).

\bullet: Búsqueda/Alias/Subárbol - para encontrar todos los alias en un subárbol (ARBOL asociado con ALIAS).

\bullet: Búsqueda/Alias/Un Nivel - para encontrar todos los alias bajo un objeto dado (ARBOL asociado con ALIAS).

Nótese que las anteriores asociaciones son asociaciones de primer nivel (es decir, entre solo dos tablas). Es preferible no usar asociaciones de mayor orden.

4.6 Rendimiento de Entrada/Salida

Una innovación de la descomposición de tablas alrededor de servicios, lo que incrementa el número de tablas, es que las nuevas tablas son mucho menores que las tablas no fragmentadas. Esto puede reducir significativamente la cantidad de E/S por las siguientes razones:

Tamaño de Fila

Por la reducción del número de filas, en cualquier columna se acortará el ancho de fila. Esto significa que en una página se encajarán más filas (donde se asume que una E/S de disco devuelve una "página" de información). En combinación con el agrupamiento de abajo, siempre que un conjunto de filas necesite ser recuperado, solo una (o unas pocas) páginas deben realmente ser leídas del disco (por ejemplo, cuando se leen los atributos de un objeto, si la tabla ENTRADA está en clave EID, AID, VID entonces todas las filas relacionadas con tal objeto estarán juntas y probablemente estarán en la misma página).

Agrupamiento

Cada una de las tablas fragmentadas se prefiere que tengan sus propias claves primarias (independientes) que les permite agrupara datos de acuerdo con como se emplee. La clave primaria puede imponer la "estructura de almacenamiento". Así en la tabla BÚSQUEDA, si la clave primaria está en AID, NORM (es decir, tipo, valor) entonces todos los datos del mismo tipo (por ejemplo, apellido) y valores similares (por ejemplo, Harvey, Harrison) estarán agrupados en la misma área del disco. Esto significa que durante una Búsqueda (por ejemplo, apellidos que comienzan por "HAR") datos similares serán recogidos juntos en la una (o solo unas pocas) paginas de disco. Si las filas son pequeñas entonces en número de páginas de disco que tienen que accederse se reduce significativamente.

Cache

La mayoría de las RDBMSs comerciales tienen la capacidad de crear caches de páginas que se acceden frecuentemente. Como las tablas son efectivamente introducidas (por ejemplo, Navegación usando tabla DIT) o extraídas (por ejemplo, recuperando información de la tabla ENTRADA) entonces peticiones similares (por ejemplo, Búsquedas sobre la misma porción del Arbol) tenderán a resultar que las páginas frecuentemente usadas sean guardadas en cache, significando que consultas invocadas frecuentemente ganarán ventajas significativas. Además el cache es más eficiente ya que las páginas son de "información intensiva" como resultado del pequeño tamaño de fila y del agrupamiento.

Gestión

Las tablas más pequeñas son generalmente más sencillas de manejar: por ejemplo, visualización, creación de índices, recogida de estadísticas, auditoria, copias de seguridad, etc.

5. Métodos Lógicos

Esta sección describe métodos para interrogar a las tablas de Diseño Lógico, con referencia a la Fig. 2B.

A lo largo de esta sección, cada método X.500 es definido e ilustrado con un ejemplo. La Tabla 5a muestra un pequeño árbol de jerarquía que incluye una referencia alias. Los correspondientes contenidos de Tabla se muestran en la Tabla 5b.

TABLA 5a Arbol de Jerarquía Simple

61

TABLA 5b Tablas Ejemplo

62

65

68

5.2 Servicios Comunes Navegación en Arbol

Todos los servicios X.500 dependen de la navegación en el árbol directorio. El fin de la navegación en árbol es recuperar la EID de la entrada correspondiente al Nombre Distinguido suministrado. La navegación comienza a partir de la raíz del árbol y continúa hacia abajo del árbol hasta que se han resuelto (verificado) todos los RDNs en un DN. Este proceso se conoce como un "Paseo por Arbol".

La Tabla DIT es la tabla primaria empleada para navegación en árbol. En referencia al árbol de jerarquía de ejemplo, la resolución del DN "Datacraft/Ventas/Productos de Red/Peter Evans" implica los siguientes procesos:

\bullet: Explorar la tabla DIT por una fila que contiene PADRE = 0 y RDN = "Datacraft". La EID para esta fila es 1.

\bullet: Explorar la tabla DIT por una fila que contiene PADRE = 1 y RDN = "Ventas". La EID para esta fila es 11.

\bullet: Explorar la tabla DIT por una fila que contiene PADRE = 11 y RDN = "Productos de Red". La EID para esta fila es 20.

\bullet: Explorar la tabla DIT por una fila que contiene PADRE = 20 y RDN = "Peter Evans". La EID para esta fila es 32.

Ahora se ha resulto el DN y se pueden obtener cualesquiera valores relativos al objeto de la Tabla Entrada empleando la clave 32.

Alias

A veces un DN contiene un alias que es efectivamente otro DN. Los alias complican el proceso del paseo por árbol porque el paseo por árbol no puede continuar hasta que se resuelve el alias. Esto requiere un paseo por árbol separado para el alias.

Como ejemplo considérese el DN "Datacraft / Ventas / Productos de Red / Peter Evans". Los dos primeros pasos en la resolución de este DN serían:

\bullet: Explorar la tabla DIT por una fila que contiene PADRE = 1 y RDN = "Redes". La EID para esta fila es 10.

En esta etapa descubrimos que esta entrada es un alias. Se comprueba la tabla Alias para ver si la EID del alias ha sido puesta en cache. Si esta es la primera vez que se ha hecho un intento de resolver este alias entonces la columna A_EID en la Tabla Alias será cero. Para el propósito de la discusión se asumirá que esta es la primera vez.

Para resolver el alias, se debe determinar el DN del objeto con alias. Este se almacena en el atributo "NombreObjetoalias" de la entrada alias. El NombreObjetoalias tiene una AID = 1 (de la tabla ATTR) y así se obtiene el DN de la Tabla Entrada (valor BRUTO) donde EID = 10 y AID = 1.

En este ejemplo el DN del alias es "Datacraft/Ventas/Productos de Red". Este DN se resuelve completamente empleando la técnica normal de paseo por árbol. El valor de EID es 20.

En esta etapa la navegación continua para los RDNs no resueltos en el DN original, a saber "PETER EVANS". El último paso requerido es entonces:

\bullet: Explorar la tabla DIT por una fila que contiene PADRE = 20 y RDN = "PETER EVANS".

Una vez que se ha resuelto el alias este se puede añadir (poner en cache) en la Tabla Alias. Esta tabla contiene una referencia, A_EID, al objeto con alias. En el ejemplo anterior, una entrada en la Tabla Alias con una EID de 10 tendría una A_EID de 20. Una vez que un alias se ha puesto en cache no es necesario más un paseo por árbol para resolver el alias.

Rutas de Directorio

Cuando se añaden objetos a la tabla DIT, se agrega una fila correspondiente a otra tabla llamada la Tabla Arbol. Esta tabla almacena la lista de las EIDs que identifican una "Ruta" al objeto.

Nombres Distinguidos

La mayoría de los servicios necesitan que se devuelva el nombre distinguido en el Resultado de Servicio. Empleando la ruta de directorio de Tabla Arbol, se puede construir un DN a partir de los valores BRUTO RDN almacenados en la Tabla Nombre.

Selección de Información de Entrada

Muchos de los Servicios X.500 so requeridos con un argumento llamado "SelecciónInformaciónEntrada" o EIS. El argumento EIS se emplea para indicar qué información sería devuelta en la Entrada. Básicamente, el EIS puede ser opcionalmente;

\bullet no información

\bullet atributos y valores para los atributos seleccionados o todos

\bullet valores solo para atributos seleccionados o todos

Información de Entrada

La Información de Entrada es un parámetro de vuelta para Lectura y Búsqueda. Contiene siempre los Nombre Distinguidos de las entradas seleccionadas y, opcionalmente, atributos y/o valores según se especifique en el argumento EIS de la petición.

Argumentos Comunes

Todos los Servicios X.500 pasan un conjunto de argumentos comunes en la Petición de Servicio. Los Argumentos Comunes contienen información como controles de servicio (límite de tiempo y límite de tamaño), el DN del peticionario del servicio e información de seguridad.

Resultados Comunes

Algunos Servicios X.500 pasan un conjunto de resultados comunes en la Respuesta de Servicio. Los Resultados Comunes contienen información como parámetros de seguridad, el DN del ejecutor del servicio y una marca de alias desreferenciado.

5.2 Servicio de Lectura

Se usa una operación de Lectura para extraer información de una entrada identificada explícitamente.

70

Método

\bullet: Realiza un paseo por árbol usando la tabla DIT, resolviendo alias si es necesario. Obtiene la EID base.

\bullet: Usando RUTA de la Tabla Arbol y los RDNs BRUTO de la Tabla Nombre, construye un DN.

\bullet: Si EIS no especifica atributos o valore, solo devuelve el DN.

\bullet: Si EIS especifica TODOS tipos y valores, devuelve los valores BRUTO de la Tabla Entrada para la EID que casa.

\bullet: Si EIS especifica tipos y valores seleccionados, obtiene las AIDs de la Tabla de Atributo y entonces devuelve tipos y/o valores para la EID que casa.

Ejemplo

Leer la entrada "Datacraft / Ventas / Productos de Red / Peter Evans". EIS se fija a: Tipos atributos = todos Atributos, TiposInfo = TiposyValoresatributo.

Empleando la tabla DIT realizar un Paseo por Arbol recorriendo EIDs 1, 11, 20 y 32 para RDNs normalizados DATACRAFT, VENTAS, PRODUCTOS DE RED, PETER EVANS. La EID del objeto seleccionado es 32.

Extraer la RUTA de la Tabla Arbol para EID = 32. La RUTA es 1.11.20.32.

Construir un DN de los valores BRUTO y de la Tabla de Atributo para cada EID que case;

\bullet Devolver las IDOBJETOs de la Tabla de Atributo y los valores BRUTO codificados ASN.1 de la Tabla Entrada

	2.5.4.0	[2.5.6.7]
	2.5.4.3	[PETER]
	2.5.4.4	[EVANS]
	2.5.4.9	[VENDEDOR]
	2.5.4.20	[(03) 727-9454]

\bullet Devolver el DN

5.3 Servicio Comparación

Una operación Comparación se usa para comparar un valor (que es suministrado como un argumento de la petición) con el(los) valor(es) de un tipo particular de atributo en una entrada de objeto particular.

71

Método

\bullet: Realizar un paseo por árbol usando la tabla DIT, resolviendo alias si es necesario,. Obtiene la EID del objeto base.

\bullet: De la Tabla Atributo obtiene la AID del atributo a ser comparado.

\bullet: De la Tabla Entrada selecciona la(s) fila(s) que casan la EID y la AID.

\bullet: Compara el valor.

\bullet: Devuelve VERDADERO o FALSO como resultado de Comparación.

\bullet: Si un alias es desreferenciado, devuelve el DN del objeto seleccionado usando la ruta de la Tabla Arbol y los RDNs BRUTO de la Tabla Nombre.

Ejemplo

Comparación del DN "Datacraft / Ventas / Productos de Red / Peter Evans" con un pretendido AfirmaciónValorAtributo de "puesto = [Vendedor]".

Obtiene la EID para el DN dado usando un PaseoporArbol. La EID del objeto seleccionado es 32.

Usando la tabla Atributo obtiene la AID para "puesto", es decir AID = 12.

Usando la Tabla Búsqueda localizar filas con EID 0 32 y AID = 12 y comprobar para "NORM = VENDEDOR".

Devuelve VERDADERO o FALSO dependiendo del resultado de esta comprobación. En este caso el resultado sería VERDADERO.

Como no se desreferenciaron alias no se devuelve el DN de la entrada.

5.4 Servicio Listado

Se emplea una operación listado para obtener una lista de subordinados inmediatos de una entrada identificada explícitamente.

72

Método

\bullet: Realizar un paseo por árbol usando la tabla DIT, resolviendo alias si es necesario. Obtiene la EID del objeto base.

\bullet: Usando las tablas DIT y Nombre, devuelve el indicador ALIAS y el PADRE RDN BRUTO es igual a la EID del objeto base.

Ejemplo

Realiza una lista para el DN "Datacraft".

Obtiene la EID para el DN usando un PaseoporArbol. La EID del objeto seleccionado es "1".

Para cada EID con un PADRE = 1

\bullet devolver el RDN BRUTO de la Tabla Nombre, es decir, [Redes], [Ventas], [Marketing]

\bullet devuelve las marcas alias, es decir, VERDADERO, FALSO, FALSO.

Como ningún alias fue desreferenciado en el paseo por árbol, el DN del objeto seleccionado no se devuelve. Nótese también que la entrada alias [Redes] no es desreferenciada.

5.5 Servicio Búsqueda

El Servicio Búsqueda es el más complejo de todos los servicios X.500. Los argumentos de búsqueda indican dónde comenzar la búsqueda (Objetobase), el alcance de la búsqueda (subconjunto), las condiciones a aplicar (filtro) y qué información se debe devolver (selección). Además se pasa un indicador para indicar si los alias deben ser desreferenciados (Aliasbúsqueda).

Los posibles valores para subconjunto son Objetobase, unNivel y Subárbolcompleto. El objeto base indica que el filtro de búsqueda se aplicará solo a atributos y valores dentro del objeto base. UnNivel indica que el filtro de búsqueda se aplicará a loa subordinados inmediatos del objeto base. Subárbol completo indica que el filtro de Búsqueda se aplicará al objeto base y a todos sus subordinados.

Un ejemplo sencillo de una condición de filtro sería: apellido = "EVANS" o Númeroteléfono PRESENTE.

73

Los procedimientos de búsqueda para cada alcance de búsqueda se esbozan como sigue:

Objeto Base

\bullet: Realiza un paseo por árbol usando la tabla DIT, resolviendo alias si es necesario. Obtiene la EID del objeto base.

\bullet: Aplica el filtro a los atributos y valores en la Tabla de Búsqueda con la EID del objeto seleccionado.

\bullet: Si se iguala la condición de filtro devuelve la Información Entrada de la Tabla Entrada.

\bullet: Si un alias es desreferenciado devuelve el DN usando la Tabla Arbol para extraer la RUTA y la Tabla Nombre para construir el DN.

Un Nivel

Realiza un paseo por árbol usando la Tabla DIT, resolviendo alias si es necesario. Obtiene la EID del objeto base.

\bullet: Comprueba para ver si existe algún alias con PADRE = EID y si es así los resuelve para obtener una lista de alias desreferenciados.

\bullet: Usando las Tablas Búsqueda y DIT aplica el filtro (condiciones atributo / valor) y el ámbito (PADRE = EID del objeto seleccionado y cualquier alisas desreferenciado). Se devolverá una lista de EIDs que casan.

\bullet: Si un alias es desreferenciado, devuelve el DN usando la Tabla Arbol para extraer la RUTA y la Tabla Nombre para construir el DN.

Para cada EID que casa:

\bullet: Devuelve la Información de Entrada obtenida de la Tabla Búsqueda usando la Tabla Entrada (como para el Servicio Lectura).

Subárbol completo

\bullet: Comprueba para ver si existe algún alias con prefijo RUTA que casa con la RUTA del objeto seleccionado.

\bullet: Para cada alias descubierto, comprobación para ver si el alias apunta fuera del subárbol actual y si es así repite el paso previo. Una vez que se han resuelto todos los alias, se ha encontrado un conjunto de objetos base única (sin áreas de solapamiento).

\bullet: Usando las Tablas Búsqueda y Arbol aplica el filtro (condiciones atributo / valor) y el ámbito (RUTA COMO RUTA del objeto seleccionado). Se devolverá una lista de EIDs que casan.

\bullet: Si un alias es desreferenciado durante Navegación (no durante Búsqueda), devuelve el DN usando la Tabla Arbol para extraer la RUTA y la Tabla Nombre para construir el DN.

Para cada EID que casa:

Ejemplo

Realiza una búsqueda en el Objetobase "Datacraft /Ventas" con:

\bullet Ambito fijado a SubárbolCompleto

\bullet Un filtro de "apellido, subristra inicial = M". (Busca todos los apellidos que comienzan por "M")

\bullet BúsquedaAlias fijado a VERDADERO

\bullet EIS fijado a Tipos atributo = todosAtributos, TiposInfo = TiposyValoresatributo

Método

Obtiene la EID para el DN del objeto base usando un PaseoporArbol. La EID del objeto base es "11".

De la Tabla Arbol obtiene la RUTA para EID = 11, es decir "1.11".

Comprueba cualesquiera alias entre las entradas que tengan una ruta que comienza con "1.11". No hay alias en este caso.

Obtiene la AID para el atributo "apellido" en la Tabla Atributo, es decir 4.

Aplica simultáneamente filtro y ámbito. Es decir, usando la Tabla Búsqueda, obtiene una lista de EIDs de la lista objetivo donde AID = 4 y el valor comienza con "M" asociado con la Tabla Arbol cuya RUTA es COMO "1.11.%". Los EIDs que casan son 30 y 31.

Usando la Tabla Entrada y la Tabla Atributo para cada EID que casa:

\bullet: devuelve las IDOBJETOs de la Tabla de Atributo y los valores BRUTO codificados ASN.1 de la Tabla Entrada es decir

2.5.4.0,	[2.5.6.7],
2.5.4.3,		[Chris],
2.5.4.4		[Masters]
2.5.4.9		[Director de Ventas]
2.5.4.20	[(03) 727 9456]
2.5.4.20	[(018) 042 671]
2.5.4.0		[2.5.6.7]
2.5.4.3		[Alana]
2.5.4.4		[Morgan]
2.5.4.9		[Soporte de Ventas]
2.5.4.20		[(03) 727 9455]

5.6 Servicio Agrega Entrada

La operación AgregaEntrada se emplea para añadir una entrada hoja bien una entrada de objeto o bien una entrada alias al Arbol de Información de Directorio.

74

Método

\bullet: Usando la tabla DIT, realiza un paseo por árbol hasta el padre de la entrada a agregar (EID padre).

\bullet: Usando la tabla DIT comprueba si la entrada existe (comprueba si RDN = nuevo RDN y PADRE = EID Padre).

\bullet: Si la entrada no existe asigna una nueva EID y añade la entrada. Inserción en la tabla DIT, en la tabla Nombre, en la tabla Arbol, en la tabla Búsqueda, en la tabla Entrada y, si es una entrada alias, en la tabla Alias.

Ejemplo

Agregar un objeto bajo el objeto con un DN de "Datacraft /Marketing" con los siguientes atributos y valores.

apellido	[Delahunty]
Nombrepropio		[Mary]
Puesto		[Directora de Marketing]
Númeroteléfono	[(03) 727-9523]

Obtiene la EID para el DN de objeto base usando un PaseoporArbol. La EID del objeto base es "12".

Usando la Tabla DIT busca una entrada duplicada, es decir, PADRE = 12 y RDN = "MARY DELAHUNTY". No existe duplicado.

Agrega las siguientes filas a las tablas mostradas.

75

76

77

78

79

5.7 Servicio Elimina Entrada

Una operación EliminaEntrada se usa para eliminar una entrada hoja (bien una entrada objeto o bien una entrada alias) del Arbol de Información de Directorio.

80

Método

\bullet: Realiza un paseo por árbol usando la tabla DIT. Obtiene el EID del objeto base.

\bullet: Si la entrada existe y si es una entrada hoja, entonces para la condición EID = EID del objeto seleccionado, borra de la tabla DIT, de la tabla Nombre, de la tablas Arbol, de la tabla Búsqueda, de la Tabla Entrada y si es una entrada alias, de la tabla Alias.

Ejemplo

Obtiene la EID para el DN de objeto base usando un paseo por árbol. La EID del objeto base es "21". Comprueba que ninguna entrada tiene PADRE = 21.

Borra todas las filas añadidas a las tablas DIT, a la tabla Nombre, a la tabla Arbol, a la tabla Búsqueda, a la Tabla Entrada (consulta el ejemplo Agrega Entrada) donde EID = 21.

5.8 Servicio Modifica Entrada

La operación ModificaEntrada se usa para realizar una serie de una o más de las siguientes modificaciones a una simple entrada:

\bullet agrega un nuevo atributo

\bullet elimina un atributo

\bullet agrega valores de atributo

\bullet elimina valores de atributo

\bullet reemplaza valores de atributo

\bullet modifica un alias

81

Método

\bullet: Para el objeto seleccionado, realiza una o más de las acciones siguientes: Agrega Valor, Borra Valor, Agrega Atributo, Borra Atributo.

Las operaciones requeridas para cada acción son como sigue:

Agrega Valor

\bullet Si existe el atributo, agrega el valor a la tabla Entrada y a la tabla Búsqueda. Las comprobaciones son: si el atributo es de un solo valor comprueba un valor existente; si el atributo es multivalor comprueba un valor duplicado.

Borra Valor

\bullet Para la Tabla Entrada y la Tabla Búsqueda, si el valor existe, borrarlo. Un Valor Distinguido no puede borrarse.

Agrega Atributo

\bullet Si el atributo no existe, agrega Valores de Atributo a la tabla Entrada y a la tabla Búsqueda.

Borra Atributo

\bullet Para la tabla Entrada y la tabla Búsqueda, si el atributo existe, borrarlo. Borrar todos los valores con AID = attr y EID = objeto base. Los atributos de designación no pueden borrarse.

Ejemplo

Modifica la Entrada "Datacraft / Ventas / Productos de Red / Chris Masters" con los siguientes cambios:

	Borra atributo y valor	Númeroteléfono	018 - 042 671
	Modifica atributo y valor	puesto	Ayudante de ventas

Las Tablas Búsqueda y Entrada reflejan los cambios.

82

83

5.9 Servicio Modifica RDN

La operación ModificaRDN se usa para cambiar el Nombre Distinguido Relativo de una entrada hoja (bien una entrada objeto o una entrada alias) del Arbol de Información de Directorio.

85

Método

\bullet: Realiza un paseo por árbol usando la tabla DIT. Obtiene la EID y EID Padre del objeto base.

\bullet: Usando la tabla DIT comprueba para entradas equivalentes y devuelve error si se encuentra una. Una entrada equivalente tienen RDN = nuevo RDN y PADRE = EID Padre.

\bullet: Usando la tabla Nombre sustituir el antiguo RDN por el nuevo RDN.

\bullet: Usando la tabla DIT sustituir el antiguo RDN por el nuevo RDN.

\bullet: Usando la tabla Entrada insertar el nuevo valor.

\bullet: Usando la tabla Búsqueda localizar valor = antiguo RDN y fijar DISTING a =. Insertar el nuevo valor.

Si borraAntiguoRDN está puesto a VERDADERO los procesos que siguen a Paseo por Arbol son como sigue:

\bullet Usando la tabla DIT buscar un hermano con el mismo nombre y una EID no igual a la EID base.

\bullet Usando la tabla Nombre sustituir el antiguo RDN por el nuevo RDN.

\bullet Usando la tabla DIT sustituir el antiguo RDN por el nuevo RDN.

\bullet Usando la tabla Entrada borra el(los) valor(es) antiguo(s) e insertar el(los) nuevo(s) valor(es).

\bullet Usando la tabla Búsqueda borra el(los) valor(es) antiguo(s) e inserta el(los) nuevo(s) valor(es).

Ejemplo

Modifica el RDN de "Datacraft /Ventas / Productos de Red / Chris Masters". El nuevo RDN es "Christine Masters".

borraAntiguoRDN se fija a FALSO.

Los cambios en las Tablas serán como sigue:

86

87

88

89

5.10 Complicaciones

Si ocurre durante el proceso un error, límite o abandono de cualquiera de los servicios, entonces se interrumpe el procesamiento y se devuelve un mensaje de error adecuado.

Errores

Cada servicio X.500 consta de 3 partes: ARGUMENTO, RESULTADO y ERRORES. En las anteriores descripciones de los servicios, se han incluido en las definiciones X.500 ARGUMENTO y RESULTADO. Las condiciones de error son muchas y variadas y no se intenta describirlas en este documento. El documento del Instituto Nacional de Estándares y Tecnología (NIST) "Acuerdos de Implementación Estable para Protocolos de Interconexión de Sistemas Abiertos: Versión 3", proporciona una cobertura de errores completa para el estándar X.500.

Límite Tiempo y Límite Tamaño

El Límite Tiempo y el Límite Tamaño forman parte de los Controles de Servicio. Estos pueden ser fijados en algún límite finito e incluidos en los Argumentos Comunes. El Límite Tiempo indica el tiempo máximo transcurrido, en segundos, dentro del cual el servicio se debe suministrar. El Límite Tamaño (sólo aplicable a Listado y Búsqueda) indica el máximo número de objetos a devolver. Si se alcanza cualquier límite se reporta un error. Para un límite alcanzado en un Listado o Búsqueda, el resultado es una selección arbitraria de los resultados acumulados.

Abandono

Las operaciones que interrogan al Directorio, es decir Lectura, Comparación, Listado y Búsqueda, pueden abandonarse usando la operación Abandono si el usuario no está más interesado en los resultados.

Alias y Búsqueda

Si en una búsqueda se encuentra un alias y este alias apunta a una rama separada del árbol directorio, entonces la desreferenciación del alias requiere:

\bullet Navegación desde la entrada raíz hasta la entrada referenciada

\bullet Búsqueda de todos los elementos subordinados a la entrada referenciada

En el ejemplo mostrado en la tabla 5.10, si se realizó una Búsqueda de ArbolCompleto sobre un objeto base de "Telo / Corporal / Servicio de Datos", serían buscadas las entradas "Mervyn Purvis" y el alias "Estratégico". Sin embargo estratégico apunta a una rama del árbol diferente que requiere búsqueda de la entrada "Estratégico" y de todos sus subordinados, es decir, "Alan Bond", "Rex Hunt", "Wayne Carey" y "John Longmire".

TABLA 5.10 Un árbol muestra con una alias referenciado una rama diferente del árbol

91

5.11 Optimizaciones de implementación

Los métodos Lógicos incluyen varias optimizaciones que mejoran el rendimiento. Estos métodos se esquematizan más abajo.

Crear Cache

La tabla Atributo se puede poner en cache. Esto significa que (aparte de la carga inicial de los atributos) no se tiene que emitir instrucciones SQL a la base de datos cuando se codifican o decodifican los atributos. En el presente sistema X.500 las conversiones de atributos se realizan en memoria. Esto proporciona una ventaja sustancial en velocidad.

Validación

La validación de consulta se realiza en memoria cuando es posible. Esto evita la vuelta atrás de la base de datos que consume tiempo y sistema. Por ejemplo, cuando se agrega una entrada cada atributo es validado antes de hacer cualquier intento de agregar la entrada. Si se encuentra un error entonces no necesita emitirse ninguna llamada SQL.

Optimiza Gestión de Consulta

Como el formato de la mayoría de los servicios es conocido, muchas peticiones de estos servicios se pueden resolver usando instrucciones SQL estáticas. Los servicios más complejos, como búsquedas con filtros complejos se pueden resolver usando SQL dinámico. Esto permite que se realicen búsquedas arbitrariamente complejas.

Consultas Paralelas

Además cuando se procesan resultados de búsqueda el presente sistema utiliza conjuntos de consultas de orientación de SQL para evitar el procesamiento de "una fila cada vez". Así los resultados de b pueden ensamblarse en paralelo en memoria.

\newpage

Almacenamiento de Datos

Las tablas que almacenan datos brutos almacenan los datos en formato ASN.1. Esto proporciona un medio eficiente de transferencia de datos dentro y fuera de la base de datos.

Técnicas de Base de Datos

Los servicios complejos se pueden mejorar adicionalmente mediante el uso de optimizador de consulta, que proporciona un mecanismo para reducir el gasto de tiempo para resolver la consulta. El uso de una base de datos relacional proporciona asimismo un empleo eficiente de memoria y permite que se construyan grandes bases de datos sin la necesidad de tener disponibles grandes cantidades de memoria. Muchas otras aplicaciones X.500 ponen en cache la base de datos completa en memoria para conseguir rendimiento. Este método consume grandes cantidades de memoria y no es escalable.

6. Diseño Físico

El diseño físico resulta de un proceso llamado transformación física del diseño lógico. El diseño físico representa una construcción preferida o realización del diseño lógico. La Fig. 2B y las tablas debajo muestran una forma del diseño físico. Las nuevas columnas y tablas se destacan mediante bordes dobles.

TABLA 6 Diseño Físico

92

93

Las razones de los anteriores cambios se describen más abajo.

6.1 Eficiencia Tabla INFO

Esta tabla mantiene el mayor valor EID que se ha empleado n la base de datos. La inclusión de la tabla INFO permite que el próximo EID se obtenga sin ningún cálculo del máximo EID siendo realizado por la base de datos. Esto proporciona una eficiencia mejorar en la adición de entradas a la base de datos. De forma más importante la inclusión de la tabla INFO elimina problemas de conflictos que pueden ocurrir cuando múltiples ASGs están añadiendo entradas al mismo tiempo.

Claves Ensombrecidas

Tres tablas tienen añadidas claves ensombrecidas. Estas son:

a): La columna CLAVENORM en la tabla BÚSQUEDA.

b): La columna CLAVERDN en la tabla DIT

c): Las columnas NIV1, NIV2, NIV3 y NIV4 en la tabla ARBOL.

Cada una de estas columnas clave ensombrecida es una versión acortada de una columna mayor. Estas se han agregado para acortar los índices en cada tabla. Esto proporciona un rendimiento mejorado para cualquier consulta que use índices y estos también mejora el uso del espacio en disco ya que los índices pequeños toman menos espacio que los índices grandes.

Las claves ensombrecidas en la tabla RUTA utilizan la naturaleza estructurada de la RUTA. Por ser una clave compuesta se puede emplear una igualación exacta en el SQL en vez del operador "COMO".

: Por ejemplo, DONDE NIV1 = 1 AND NIV2 = 10 AND ...

: en vez de DONDE RUTA COMO '1.10.%'.

Si cada una de las columnas NIV tiene su propio índice, entonces una búsqueda en subárbol necesita usar solo el objeto base. Por ejemplo, NIV'' = 10 ya que todos los objetos bajo la entrada 10 tendrán NIV2 = 10.

Tabla ENTRADAS

Algunos tipos de valores de atributos no necesitan estar normalizados, por ejemplo, entero, boleano, fecha. En vez de almacenarlos dos veces (BÚSQUEDA.NORM y ENTRADA.BRUTO) se pueden almacenar solo una vez en una tabla híbrida llamada tabla ENTRADAS. Esto reduce los tamaños de tabla e incrementa la eficiencia de almacenamiento con el coste de tener que buscar en dos tablas y recuperar de dos tablas.

Tabla CLASEO

La mayoría de los atributos tienen una amplia variación de sus valores por ejemplo, los apellidos pueden estar en el rango desde AALDERS hasta ZYLA con una gran cantidad de valores diferentes entre ellos. Sin embargo Clases Objeto (cuyos valores son IdentificadoresObjeto u IDOs) tienen muy pocos valores, por ejemplo, en una organización de 10,000 personas, las únicas clases de objeto en el directorio pueden ser para organización, UnidadOrganizacional y Persona organizacional (de las que la mayoría pueden ser las últimas). La tabla CLASEO proporciona un descriptor numérico para una clase de objeto llamado IDOC. La IDOC puede entonces almacenarse en la tabla ENTRADAS y hecho un mapeo siempre que una Clase Objeto es buscada o recuperada. Las otras columnas LISTA almacenan información de configuración de clase de objeto estándar - a saber el debe y puede contienen atributos y las superclases heredadas.

6.2 Portabilidad Tabla BLOB

Esta tabla se ha incluido para mantener "Objetos Binarios Grandes". El tamaño máximo de una entrada de fila en la tabla ENTRADA está limitado por la longitud del campo BRUTO. Esto significa que las entradas deben fragmentarse. Las entradas fragmentadas ocuparán más de una fila y así un campo VFREG se usará para denotar el fragmento de la entrada que se está almacenando en una fila particular.

Hay dos opciones para almacenamiento de valores muy grandes:

a): Añadir una "marca fragmento" a la tabla ENTRADA y almacenar la entrada en fragmentos sobre varias líneas; o

b): Añadir una tabla BLOB para almacenar la entrada y agregar una "marca BLOB" a la tabla ENTRADA para indicar que este valor está almacenado en la BLOB.

La segunda opción tiene varias ventajas. Primeramente la inclusión de una tabla BLOB evita que la tabla ENTRADA se vuelva excesivamente grande. Generalmente la mayoría de las entradas serán de menos de unos pocos cientos de caracteres de longitud, de manera que la longitud del campo BRUTO en la tabla ENTRADA puede ser reducido consecuentemente para atender a esas entradas y el campo BRUTO en la tabla BLOB se puede incrementar hasta un valor que se aproxime al máximo tamaño de registro. Esto hará más eficiente el almacenamiento, es decir reduce la cantidad de bytes no usados en cada columna de cada tabla y reduce el número de fragmentos necesarios para cada entrada en la tabla BLOB. Esto significa también que cada valor solo tendrá una entrada en la tabla ENTRADA y que las tablas ENTRADA y BÚSQUEDA mantienen su correlación uno-a-uno. En segundo lugar el uso de una tabla BLOB permite a la aplicación hacer uso de cualquier soporte de base de datos para Objetos Binarios Largos. (por ejemplo, Columnas Binarias 64k).

6.3 Extensibilidad Funcional Columnas MARCAS

Se prefiere añadir la(s) columna(s) MARCAS. Esta(s) columna(s) se añaden para proporcionar extensibilidad al diseño. Se pueden añadir valores específicos a las marcas según se necesite una nueva funcionalidad, sin cambiar la estructura de tabla.

Nótese:

a) En la tabla BÚSQUEDA, el campo DISTING puede ser absorbido en al campo MARCAS.

b) En la tabla DIT, el campo ALIAS puede ser absorbido en el campo MARCAS.

La(s) columna(s) MARCAS pueden proporcionar también una función "resumen" para cada una de las tablas. Esto significa que la naturaleza de una entrada puede determinarse hasta cierto punto mediante la comprobación del valor del campo MARCAS. Por ejemplo, se puede poner una marca en la tabla DIT cuando una entrada es una hoja. La comprobación de esta marca es mucho más sencilla que la comprobación de hijos de la entrada.

La columna MARCAS se puede usar también para almacenar información de seguridad, si un alias apunta adentro de su subárbol padres, si un valor es un BLOB, etc.

7. Ejemplo de Implementación

Lo que sigue proporciona un ejemplo del funcionamiento y capacidades del sistema. Se debe entender que las presentes invenciones no deben ser limitadas por la siguiente descripción.

7.1 Beneficios globales del sistema

Se considera que la presente invención proporciona un rendimiento mejorado respecto a las implementaciones de la técnica anterior. El rendimiento se puede evaluar de muchas formas incluyendo:

: alias;

: tamaño (uso de teoría relacional);

: complejidad (uso de optimizador de consulta y de método(s) de búsqueda(s));

: extensibilidad (uso de metadatos); y

: sustancialmente sin degradar la eficiencia (uso de modelo basado en disco) y fiabilidad (uso de RDBMS).

La presente invención se considera única en su capacidad para reivindicar mejora de rendimiento en todas las áreas anotadas más arriba.

7.2 Resultados de Prueba

Se han realizado pruebas de rendimiento de la presente invención con los objetivos de:

\bullet: Probar que una aplicación SQL basada en X.500 puede realizarse a velocidades por debajo del segundo, disipando un mito ampliamente mantenido en el mercado de que es imposible implementar una aplicación ASG X.500 como una aplicación RDBMS y conseguir eficiencia y rendimiento.

\bullet: Probar que el diseño de una aplicación SQL basada en X.500 mejorar diseños X.500 de estilo residente en memoria existentes, especialmente para bases de datos con más de 100k entradas, un límite típico de los diseños actuales.

\bullet: Proporcionar una colección estructurada de pruebas que pueden demostrar el anterior rendimiento bajo demanda para una amplia variedad de servicios y tamaños de base de datos.

Los resultados de las pruebas se revelan en la Tabla 7A siguiente:

TABLA 7A

94

\newpage

Notas:

1. Todas las búsquedas y lecturas devolvieron toda la información

2. Todas las pruebas se realizaron en el siguiente entorno;

\bullet: SparcStation 5 de Sun con 32 Mb de memoria (máquina UNIX de nivel de entrada)

\bullet: Ingres 6.4/04 configurada para 32 usuarios (instalación Ingres estándar)

\bullet: Prototipo ASG V2.1.2

\bullet: Tiempos medidos en consola ASG (es decir, no incluyen sobrecargas de red)

Todos los números están en unidades de segundo y "K" significa miles.

7.3 Conclusiones de Prueba

Se construyó un conjunto de directorios en el rango de 1K a 200K entradas con profundidad y anchura variable de la jerarquía y se elaboró un plan de pruebas correspondiente. Las pruebas se realizaron varias veces para asegurar la consistencia. De estos resultados se pueden extraer las siguientes conclusiones;

1.: Los efectos de la navegación en las pruebas fueron despreciables.

2.: La lectura de un objeto vía un alias en la prueba no mostró un descenso apreciable de rendimiento y en algunos casos la lectura de un objeto vía un alias fue en efecto más rápida que la lectura del objeto directamente. Esto es debido a la reducida navegación requerida cuando un alias apunta "hacia abajo" a un objeto que está más profundo en la estructura árbol que la entrada alias.

3.: Los resultados de búsqueda fueron "planos" en subárboles de diferentes tamaños en directorios de diferentes tamaños para ambas búsquedas exacta y de ristra inicial.

4.: Las búsquedas completas inicial y exacta en las pruebas fueron ligeramente más rápidas que sus respectivas búsquedas en subárbol, aunque el número de entradas buscadas fue mayor. Esto es debido al hecho de que las búsquedas de árbol completo son capaces de usar SQL más eficiente (no requieren asociaciones de tablas).

5.: Todos los servicios se realizaron en las pruebas por debajo de un segundo, excepto para las búsquedas que devuelven grandes cantidades de datos. No obstante, el tiempo medio de recuperación por entrada cae según se incrementa el número de entradas recuperadas (por ejemplo, el tiempo de recuperación para 10 entradas es aproximadamente 50 milisegundos por entrada, para 100 entradas este cae hasta aproximadamente 20 milisegundos por entrada).

6.: Todas las búsquedas complejas en las pruebas se realizaron en menos de un segundo. Sin embargo, puede haber algunas búsquedas vagas (por ejemplo, que contienen combinaciones de NOT) que pueden no funcionar tan bien.

Como este es un sistema basado en disco (en lugar de un sistema basado en memoria) el rendimiento es esencialmente dependiente solo del número de entradas realmente devueltas. Es relativamente independiente de la complejidad de la búsqueda, de la profundidad de la jerarquía, del número de atributos por entrada o de los tipos de atributos empleados en la consulta. En una aplicación "viva" del sistema puede ser posible mejorar los resultados de prueba conseguidos afinando los parámetros de cache y teniendo una mayor diversidad de atributos.

Claims

1. Aparato de procesamiento de datos para proporcionar servicios de directorio relativos a objetos de datos teniendo cada uno al menos un atributo y teniendo cada atributo uno o más valores, que comprende:

medio receptor para recibir instrucciones de operación de servicio de directorio; y

medio de base de datos dispuesto para almacenar datos y para realizar operaciones de servicio de directorio de acuerdo con instrucciones de operación de servicio de directorio recibidas por dicho medio receptor;

caracterizado porque dicho medio de base de datos comprende:

medio de definición de jerarquía para definir relaciones entre objetos y un identificador de entrada que identifica a cada objeto;

medio de definición de atributos para almacenar una pluralidad de definiciones de atributos que definen cada una un atributo respectivo y que comprende un identificador de atributo;

medio para almacenar datos de valor para cada objeto, comprendiendo dichos datos de valor valores de atributo y, asociado con dicho valor de atributo, el correspondiente identificador de atributo y un identificador de entrada que identifica al objeto al que dicho atributo se refiere; y

medio que responde a dichas instrucciones de operación de servicio de directorio para localizar y / o devolver dichos objetos de datos utilizando las relaciones definidas por dicho medio de definición de jerarquía, por dichas definiciones de atributo almacenadas y por dichos datos de valor almacenados.

2. Un aparato de acuerdo con la reivindicación 1, donde dicha definición de jerarquía está organizada para almacenar datos padre que relacionan el identificador de entrada de cada objeto con otro identificador de entrada o con un objeto raíz, por lo cual almacena datos representativos de cada objeto de una relación jerárquica relativa a dicho objeto raíz directamente o vía dichos otros objetos, estando organizado dicho medio de base de datos para realizar operaciones de servicio de directorio utilizando dichos datos padre.

3. Un aparato de acuerdo con la reivindicación 1 ó 2, donde dicho medio de base de datos está además organizado para almacenar asociado con el identificador de entrada de cada objeto, datos de ruta representativos de la relación jerárquica relativa de dicho objeto con un objeto raíz, estando organizado dicho medio de base de datos para realizar operaciones de servicio de directorio utilizando dichos datos de ruta.

4. Un aparato de acuerdo con la reivindicación 3, donde dicho medio de base de datos está dispuesto para almacenar dichos datos de ruta en un medio de definición de ruta separado de dicho medio de definición de jerarquía.

5. Un aparato de acuerdo con cualquier reivindicación precedente, donde dicho medio de base de datos está dispuesto para almacenar datos de alias indicativos de la equivalencia de un objeto con otro objeto, donde dicho medio de base de datos está dispuesto para realizar operaciones de servicio de directorio por conversión de referencias a un identificador de entrada de un objeto indicado como un equivalente a otro objeto mediante datos de alias en referencias a los identificadores de entrada de sus objetos equivalentes, utilizando dichos datos de alias.

6. Un aparato de acuerdo con la reivindicación 5, donde dicho medio de base de datos está dispuesto para almacenar dichos datos de alias en un medio de definición de alias separado de dicho medio de definición de jerarquía.

7. Un aparato de acuerdo con cualquier reivindicación precedente, donde dicho medio de base de datos está dispuesto para almacenar datos de valor para cada objeto en una primera forma y en una segunda forma, donde dicho medio de base de datos está dispuesto para realizar operaciones de servicio de directorio que implican la comparación de dichos datos de valor con datos recibidos por dicho medio de recepción utilizando datos almacenados en dicha primera forma y para sacar datos utilizando datos almacenados en dicha segunda forma.

8. Un aparato de acuerdo con la reivindicación 7, donde dicho medio de base de datos está dispuesto para almacenar dichos datos de valor en dicha primera forma y datos de valor en dicha segunda forma en medio separados de definición de atributos.

9. Aparato de acuerdo con cualquier reivindicación precedente, donde dicho medio de base de datos está dispuesto para almacenar datos de conversión para convertir datos entre datos recibidos como parte de una instrucción de operación de servicio de directorio que representan datos de tipo e identificadores de atributo.

10. Un aparato de acuerdo con cualquier reivindicación precedente, donde dicho medio de base de datos está dispuesto para almacenar datos para generación para cada uno de dichos objetos de nombres únicos para dichos objetos, estando dispuesto dicho medio de base de datos para realizar operaciones de servicio de directorio utilizando dichos nombre únicos para dichos objetos.

11. Un aparato de acuerdo con la reivindicación 10, donde dicho medio de base de datos está dispuesto para almacenar datos de identificación de nombre que identifican datos de valor para un objeto como datos que forman parte de un nombre único para dicho objeto.

12. Un aparato de acuerdo con la reivindicación 11 cuando depende directa o indirectamente de la reivindicación 2, donde dicho medio de base de datos está dispuesto para generar datos de nombre para cada objeto utilizando dichos ítems de datos de valor asociados con datos de identificación de nombre indicando que dicho dato de valor forma parte de un nombre para un objeto y para generar un nombre único para cada objeto utilizando dichos datos de identificación de nombre y dichos datos representativos para un objeto de su relación jerárquica relativa a un objeto raíz directamente o vía dichos otros objetos.

13. Aparato de acuerdo con la reivindicación 11 o la reivindicación 12 cuando son dependientes directa o indirectamente de la reivindicación 3, donde dicho medio de base de datos está dispuesto para almacenar dicho nombre único para un objeto en asociación con el identificador de entrada asociado con dicho objeto, dicho medio de base de datos estando dispuesto para generar dicho nombre único para dicho objeto utilizando dichos datos de identificación de nombre y dichos datos de ruta.

14. Aparato de acuerdo con la reivindicación 14, donde dicho medio de base de datos está dispuesto para almacenar dicho nombre único con dicho identificador de entrada asociando dichos datos de nombre con su respectivo objeto en un medio de definición de nombre separado de dicho medio de definición de jerarquía.

15. Aparato de acuerdo con la reivindicación 14, donde dicho medio de base de datos está dispuesto para almacenar dicho nombre único para cada objeto en una primera forma y en una segunda forma, donde dicho medio de base de datos está dispuesto para realizar operaciones de servicio de directorio que implican la comparación de datos de nombres únicos con datos recibidos por dicho medio de recepción utilizando datos almacenados en dicha primera forma y para sacar datos utilizando datos almacenados en dicha segunda forma.

16. Un aparato de acuerdo con cualquier reivindicación precedente, donde dicho medio de recepción está adaptado para recibir instrucciones de servicio de directorio identificando una petición para realizar una función de comparación, y dicho medio de base de datos está dispuesto a la recepción de una de dichas instrucciones por dicho medio receptor para sacar la petición de una comparación de datos asociados con objetos de datos y otros datos.

17. Un aparato de acuerdo con la reivindicación 16, donde dicho medio receptor está adaptado para recibir una petición para realizar una función de comparación donde dicha instrucción comprende datos a ser comparados con datos asociados con objetos de datos.

18. Un aparato de acuerdo con la reivindicación 16, donde dicho medio receptor está adaptado para recibir instrucciones de servicio directorio identificando una petición para comparar, donde dichas instrucciones comprenden datos indicativos de una pluralidad de objetos de datos y dicho medio que responde está dispuesto tras la recepción de una de dichas instrucciones por dicho medio receptor para localizar dichos objetos de datos y para sacar los resultados de una comparación de datos asociados con dichos objetos de datos localizados.

19. Un aparato de acuerdo con cualquier reivindicación precedente, donde dicho medio receptor está adaptado para recibir instrucciones de servicio de directorio identificando una petición para modificar datos almacenados en dicho medio de base de datos, y dicho medio que responde está dispuesto tras la recepción de una dicha instrucción por dicho medio receptor para modificar datos almacenados en dicho medio de base de datos.

20. Un aparato de acuerdo con cualquier reivindicación precedente, donde dicho medio receptor está adaptado para recibir instrucciones de servicio directorio identificando una petición para realizar una función de búsqueda incluyendo dicha instrucción datos de búsqueda que definen criterios de búsqueda, donde dicho medio que responde está dispuesto tras la recepción de una de dichas instrucciones por dicho medio receptor para sacar datos almacenados en dicha base de datos en asociación con identificadores de entrada correspondientes con identificadores de entrada almacenados en asociación con datos que cumplen los criterios de búsqueda definidos por dichos datos de búsqueda recibidos.

21. Un aparato de acuerdo con la reivindicación 20, donde dichos datos de búsqueda comprenden datos que definen una o más condiciones a ser cumplidas por los datos de valor y dicho medio que responde está dispuesto tras la recepción de una de dichas instrucciones por dicho medio receptor para sacar datos almacenados en dicho medio de base de datos en asociación con identificadores de entrada correspondientes a identificadores de entrada almacenados en asociación con valores de atributo que cumplen dichas una o más condiciones a ser cumplidas.

22. Un aparato de acuerdo con la reivindicación 20 o la reivindicación 21 cuando son dependientes directa o indirectamente de la reivindicación 2, donde dichos datos de búsqueda comprenden datos de alcance que definen una o más condiciones definiendo el alcance de una búsqueda, y dicho medio que responde está dispuesto tras la recepción de una de dichas instrucciones por dicho medio receptor para sacar datos que cumplen el criterio de búsqueda definido por dicho dato de búsqueda recibido almacenado en asociación con identificadores de entrada donde dicho medio de base de datos tiene allí almacenados datos que asocian dichos datos identificadores de entrada con una relación jerárquica que cumple la una o más condiciones definidas por dichos datos de alcance.