El Unisys Data Management System II (DMSII) es un sistema de base de datos creado originalmente por Burroughs Corporation en 1972. Estaba disponible en las líneas de productos Small (B1000), Medium (4000, V Series) y Large System (5000, 6000, 7000) de Burroughs (posteriormente Unisys ). Las líneas de productos posteriores, A Series, Clearpath y Libra lo admiten y en versiones recientes del software Unisys Clearpath se le ha cambiado el nombre a Enterprise Database Server para ClearPath MCP . El DMS II original utilizaba un modelo de red. [1]
Originalmente compitió con los productos IMS y CICS de IBM y fue anterior a la popularidad de las bases de datos relacionales.
DMSII proporcionó un modelo ISAM (método de acceso secuencial indexado) para el acceso a los datos, el aislamiento de transacciones y las capacidades de recuperación de la base de datos. El esquema de la base de datos se escribió en el lenguaje propietario Data and Structure Definition Language (DASDL). El código fuente de DASDL se compiló con una utilidad del sistema en un archivo que contenía los metadatos de la base de datos (conocido como archivo de descripción). Un programa de utilidad de base de datos utilizaría el archivo de descripción de la base de datos para crear los componentes restantes de la base de datos.
Los compiladores de lenguajes propietarios (como COBOL y ALGOL ) utilizaban el archivo de descripción de la base de datos para crear elementos relacionados con la base de datos en el código objeto del programa compilado. Estos compiladores utilizaban extensiones del lenguaje para proporcionar una interfaz más natural con la base de datos por parte del programador. El compilador insertaba una serie de funciones intrínsecas para garantizar que el programa y la base de datos utilizaran la misma definición de estructuras de base de datos.
Originalmente, DMSII mantenía un diccionario de datos al que el programador de aplicaciones hacía referencia en su código fuente. El código fuente de las estructuras de datos se mantenía en un archivo fuente CANDE común . Luego, ese código fuente se compilaba con el compilador DASDL, que creaba el diccionario (archivo de descripción) si no existía ninguno antes. Si existía un diccionario, el nuevo diseño indicado por el archivo fuente se incorporaba al diccionario; los programas para copiar los datos de las estructuras de archivo antiguas y escribir en las nuevas estructuras de archivo se generaban automáticamente (una tarea de reorganización de la base de datos). El programador de aplicaciones solo necesitaba volver a compilar el código fuente de su aplicación (normalmente COBOL) con el nuevo archivo de descripción y podía aprovechar los nuevos elementos de datos en las estructuras.
DMSII utilizó el concepto de "conjuntos" para el almacenamiento de datos. Un conjunto de datos contenía filas de datos y podía ser aleatorio u ordenado. Dado que DMSII admitía modelos jerárquicos y relacionales, un conjunto de datos podía estar disjunto o integrado. Los índices de tabla se implementaron en conjuntos de índices y podían ser conjuntos completos o subconjuntos del conjunto de datos de destino. Los subconjuntos podían designarse como subconjuntos automáticos (con reglas para seleccionar registros del conjunto de datos de destino para su inclusión) o subconjuntos manuales (que utilizaban interfaces programáticas para insertar y eliminar registros).
Los conjuntos de índices incluían estilos ISAM (que utilizaban claves de campo para hacer referencia a los registros) y conjuntos con vectores de bits (que utilizaban la representación booleana de la pertenencia al conjunto si el registro del conjunto de datos cumplía las condiciones definidas en el conjunto). Al igual que ISAM, utilizaba conjuntos (índices en los que se hacía referencia a todos los registros, como el índice de Microsoft Access ), subconjuntos (una lista parcial de registros que dependían de una condición definible, por ejemplo, mujeres para una base de datos con un campo de "sexo") y mapas de bits (un conjunto de registros que cumplían una determinada condición (verdadero/falso) en el conjunto de datos). Esas características conseguían un rendimiento considerablemente más rápido en el acceso a los datos, con la pequeña penalización de tiempo extra dedicado a la creación de un nuevo registro si se definían muchos subconjuntos.
Se afirmó que se podía crear una base de datos de tipo red utilizando la capacidad de crear subconjuntos manualmente. Esto era arriesgado, ya que dependía de que los programas de usuario añadieran y eliminaran registros en un subconjunto manual. Existe una diferencia sustancial entre DMSII y las bases de datos relacionales: en DMSII, un registro solo se puede recuperar a través de un índice si el índice se diseñó inicialmente (o después de una reorganización que genera un nuevo subconjunto a partir de todos los datos del conjunto). En el modelo relacional, se trata de una operación en tiempo de ejecución.
En 1988, Burroughs intentó crear una base de datos de modelos orientada a objetos conocida como Infoexec, que era una capa adicional sobre DMSII. Esa capa estaba programada en Pascal y seguía el enfoque de selección en tiempo de ejecución, como lo hace el modelo relacional. Diseñado por Mike Hammer y Dennis McLeod en el Instituto Tecnológico de Massachusetts, tuvo un rendimiento deficiente.