A Relational Model of Data for Large Shared Data Banks ESPaÑOL

A Relational Model of Data for Large Shared Data Banks
E. F. Codd

Abstracto

Los futuros usuarios de grandes bancos de datos deben ser protegidos de tener que saber cómo están organizados los datos en la máquina (la representación interna). Un servicio que provocó que suministra dicha información no es una solución satisfactoria. Actividades de los usuarios en las terminales y la mayoría de los programas de aplicación deberían verse afectadas cuando la representación interna de los datos se cambia e incluso cuando se cambian algunos aspectos de la representación exterior. Con frecuencia, se necesitan cambios en la representación de datos como "resultado de los cambios en la consulta, actualización, y el tráfico de informe y el crecimiento natural de los tipos de información almacenada.
sistemas de datos existentes no inferencial con formato ofrecen a los usuarios con los archivos de estructura de árbol o modelos de red ligeramente más generales de los datos. En la sección 1, se discuten las deficiencias de estos modelos. Un modelo basado en relaciones n-aria, se introdujo una forma normal para las relaciones de bases de datos, y el concepto de un idioma secundario de datos universal. En la Sección 2, ciertas operaciones sobre las relaciones (distintos de inferencia lógica) se discuten y se aplican a los problemas de redundancia y la consistencia en el modelo del usuario.

1.1 Introducción

Este documento se refiere a la aplicación de la teoría elemental relación a los sistemas que proporcionan acceso compartido a los grandes bancos de datos con formato. A excepción de un artículo de Childs [1], la aplicación principal de las relaciones de los sistemas de datos ha sido cuestionar deductivos - sistemas de contestar. Levein y Maron [2] proporcionan numerosas referencias de trabajos en esta área.
Por el contrario, los problemas tratados aquí son los de independencia de datos - la independencia de los programas de aplicación y actividades del terminal de crecimiento de los tipos de datos y los cambios en la representación de datos N y ciertos tipos de inconsistencia de datos que se espera que sea problemático incluso en sistemas deductivas.
La vista relacional (o modelo) de los datos que se describen en la Sección 1 parece ser superior en varios aspectos de la gráfica o una red de modelo [3, 4] actualmente en boga para sistemas no-inferencial. Se proporciona un medio de descripción de datos con su estructura natural solamente - es decir, sin la superposición de cualquier estructura adicional para la representación de la máquina plantea. En consecuencia, se proporciona una base para un lenguaje de datos de alto nivel que producirá la máxima independencia entre los programas en la representación por un lado y de la máquina y la organización de los datos en el otro.
Una ventaja adicional de la vista relacional es que forma una base sólida para el tratamiento de derivabilidad, la redundancia y la consistencia de las relaciones - que se discuten en la Sección 2. El modelo de red, por otro lado, se ha generado una serie de confusiones, no el menos de la que se duda de la derivación de conexiones para la derivación de relaciones (véanse las observaciones de la Sección 2 de la "trampa de conexión").
Finalmente, la vista relacional permite una evaluación más clara de los alcances y limitaciones lógicas de los sistemas de datos actuales con formato, así como los méritos relativos (desde un punto de vista lógico) de competir representaciones de datos en un único sistema. Los ejemplos de esta perspectiva más clara se citan en varias partes de este documento. No se discuten las implementaciones de sistemas para apoyar el modelo relacional.

La dependencia 1.2 datos en los sistemas actuales

La provisión de descripción de datos de las tablas en los sistemas de información se han desarrollado recientemente representa un gran avance hacia la meta de independencia de datos [5, 6, 7]. Tales tablas de facilitar la sustitución ciertas características de la representación de los datos almacenados en un banco de datos. Sin embargo, la variedad de características de representación de datos que puede ser cambiado sin perjudicar lógicamente algunos programas de aplicación es todavía bastante limitada. Además, el modelo de datos con los que interactúan los usuarios todavía está lleno de propiedades de representación, en particular en lo que se refiere a la representación de las colecciones de datos (en contraste a los elementos individuales). Tres de los principales tipos de dependencias de datos que todavía necesitan ser removidos son: la dependencia de pedido, la dependencia de indexación, y la dependencia del camino de acceso. En algunos sistemas estas dependencias no son claramente separables unos de otros.

1.2.1. La dependencia de pedido

Los elementos de datos en un banco de datos pueden ser almacenados en una variedad de formas, algunas que no implica preocupación para el pedido, algunos permitiendo cada elemento para participar en un único pedido, otros permiten cada elemento para participar en varios ordenamientos. Consideremos los sistemas existentes que requieren o bien elementos de datos permiso para ser almacenado en al menos un orden total que está estrechamente asociado con el orden determinado por el cableado de direcciones. Por ejemplo, los registros de un archivo relativos a las partes podrían ser almacenados en orden ascendente por número de serie de la pieza. Tales sistemas normalmente permiten programas de aplicación para asumir que el orden de presentación de los registros de un archivo de este tipo es idéntica a (o es un subordering de) el ordenamiento almacenado. Esos programas de aplicaciones que aprovechan el orden almacenado de un archivo es probable que no funcione correctamente si por alguna razón se hace necesario sustituir dicho pedido por uno diferente. Observaciones similares son válidas para un pedido almacenado en práctica por medio de punteros.
Es innecesario señalar cualquier sistema como un ejemplo, porque todos los sistemas de información conocidos que se comercializan hoy en día no pueden hacer una clara distinción entre el orden de presentación, por un lado y el pedido almacenado en el otro. importantes problemas de ejecución deben ser resueltos para proporcionar este tipo de independencia.

1.2.2. La dependencia de indexación

En el contexto de datos formateados, un índice se suele considerar como un componente puramente orientado al rendimiento de la representación de datos. Tiende a mejorar la respuesta a las consultas y actualizaciones y, al mismo tiempo, reduzca la velocidad de respuesta a las inserciones y deleciones. Desde un punto de vista informativo, un índice es un componente redundante de la representación de datos. Si un sistema utiliza los índices en absoluto y si se trata de un buen desempeño en un entorno con cambios en los patrones de la actividad en el banco de datos, la capacidad de crear y destruir los índices de vez en cuando, probablemente será necesario. Surge entonces la pregunta: ¿Pueden los programas de aplicación y actividades del terminal permanecen invariables como índices van y vienen?
sistemas de datos formateados presentes toman ampliamente diferentes enfoques para la indexación. TDMS [7] incondicionalmente proporciona la indexación de todos los atributos. La versión actualmente liberada de IMS [5] proporciona al usuario una opción para cada archivo: una elección entre la no indexación en absoluto (la organización jerárquica secuencial) o la indexación en la clave principal solamente (la organización jerárquica secuencial indizado). En ninguno de los casos es la lógica de la aplicación del usuario depende de la existencia de los índices proporcionados incondicionalmente. IDS [8], sin embargo, permite a los diseñadores de archivos para seleccionar atributos para ser indexados e incorporar índices en la estructura de archivos por medio de cadenas adicionales. Los programas de aplicación que se aprovechan de la ventaja de rendimiento de estas cadenas de indexación deben hacer referencia a esas cadenas por su nombre. Tales programas no funcionan correctamente si se eliminan estas cadenas más tarde.

1.2.3. La dependencia del camino de acceso

Muchos de los sistemas de datos con formato existentes proporcionan a los usuarios con los archivos de estructura de árbol o modelos de red ligeramente más generales de los datos. Los programas de aplicación desarrollados para trabajar con estos sistemas tienden a verse afectada, lógicamente, si los árboles o redes se cambian en su estructura. Un ejemplo sencillo.
Supongamos que el banco de datos contiene información sobre piezas y proyectos. Para cada parte, el número de pieza, nombre de la pieza, descripción de la pieza, la cantidad-en-mano, y la cantidad-en-orden se registran. Para cada proyecto, el número de proyecto, nombre del proyecto, descripción del proyecto se registran. Cada vez que un proyecto hace uso de una cierta parte, la cantidad de la parte comprometida con el proyecto dado también se registra. Supongamos que el sistema requiere que el usuario o diseñador de archivo para declarar o definir los datos en términos de estructuras de árbol. Entonces, cualquiera de las estructuras jerárquicas que podrán adoptarse a la información mencionada anteriormente (véase Estructuras 1-5).
Ahora, consideremos el problema de imprimir el número de pieza, nombre de la pieza, y la cantidad comprometida por cada parte que se utiliza en el proyecto que tiene como nombre del proyecto es "alfa". Las siguientes observaciones se pueden hacer independientemente del sistema de información orientada al árbol disponibles se selecciona para hacer frente a este problema. Si se desarrolla un programa de P para este problema suponiendo una de las cinco estructuras aboveÑthat es decir, P no hace ninguna prueba para determinar que la estructura es, en efecto, - a continuación, P fallará en al menos tres de las estructuras restantes. Más específicamente, si P tiene éxito con la estructura 5, se producirá un error con todos los demás; si P tiene éxito con la estructura 3 o 4, se producirá un error con al menos 1, 2 y 5; si P tiene éxito con 1 ó 2, para que no falle con al menos 3, 4 y 5. La razón es simple en cada caso. En ausencia de una prueba para determinar que la estructura es, en efecto, P falla porque se hace un intento para ejecutar una referencia a un archivo inexistente (sistemas disponibles tratan esto como un error) o no se hace ningún intento de ejecutar una referencia a un archivo que contiene la información necesaria. El lector que no estén convencidos de ello el desarrollo de programas de ejemplo de este sencillo problema.
Dado que, en general, no es práctico para desarrollar programas de aplicación que prueba para toda la estructuración del árbol permitida por el sistema, estos programas fallan cuando se hace necesario un cambio en la estructura.
Sistemas que proporcionan a los usuarios un modelo de red de los datos topan con dificultades similares. En ambos casos los árboles y de la red, se requiere que el usuario (o su programa) para explotar una colección de rutas de acceso de los usuarios a los datos. No importa si estos caminos están en estrecha correspondencia con el puntero - (rutas definidas en la representación almacenada -. En IDS la correspondencia es extremadamente simple, en TDMS es todo lo contrario La consecuencia, independientemente de la representación almacenada, es que el terminal actividades y programas se vuelven dependientes de la existencia continua de las vías de acceso de usuario.
Una solución a esto es adoptar la política que una vez que se define no se hará obsoleta hasta que todos los programas de aplicación que utilizan ese camino han quedado obsoletos una ruta de acceso de los usuarios. Tal política no es práctico, porque el número de vías de acceso en el modelo total para la comunidad de usuarios de un banco de datos se convertiría excesivamente grande.

...