Paradigma | Imperativo , declarativo |
---|---|
Familia | Base de datos d |
Diseñado por | Arden Scott |
Revelador | Richard Moore |
Apareció por primera vez | 1971 ( 1971 ) |
Lenguaje de implementación | FORTRAN |
Plataforma | Hoja de datos de seguridad 940 |
Licencia | Propiedad |
Influenciado | |
dBASE , JPLDIS , RECALL, muchos otros |
RETRIEVE es un sistema de gestión de bases de datos (DBMS) que se ofrece en los sistemas de Tymshare desde agosto de 1971. Fue escrito en el propio SUPER FORTRAN de Tymshare en el SDS 940. Ofrecía una funcionalidad básica de base de datos no relacional de un solo archivo mediante un lenguaje de programación interactivo . Es uno de los primeros ejemplos de software como servicio (SaaS). [1]
RETRIEVE fue muy influyente y generó una serie de clones relativamente directos. El RECALL de Wang Laboratories sobre la minicomputadora Wang 2200 era casi idéntico a RETRIEVE, hasta el punto de que las diferencias se detallaban en una sola página. JPL hizo una versión conocida como JPLDIS para el UNIVAC 1108 en 1973 que también era muy similar.
Wayne Ratliff , contratista del JPL durante muchos años, se inspiró en JPLDIS para adaptarlo al IMSAI 8080 para gestionar su quiniela de fútbol , y más tarde lo lanzó comercialmente como Vulcan para CP/M en 1979. Ashton-Tate licenció Vulcan y lo relanzó como dBASE II en 1980, lo que impulsó el mercado de bases de datos para microcomputadoras . La mayor parte de la sintaxis original de RETRIEVE permanece inalterada en dBASE y en los numerosos clones de xBASE que sobreviven hasta el siglo XXI.
En 1969, Jim Ryan de Tymshare diseñó una versión ampliada de IBM System/360 H-level (258 kB) FORTRAN , añadiendo cadenas y otras características que aprovechaban sus sistemas SDS 940. Ryan contrató a Richard Moore y Franck Bracher para desarrollarlo como SUPER FORTRAN, y se puso en marcha en sus sistemas en 1970. [a] Poco después de que se lanzara SUPER FORTRAN, Arden Scott le pidió a Moore que utilizara SUPER FORTRAN para desarrollar su visión de un sistema de gestión de bases de datos (DBMS). La primera versión estuvo lista en unas pocas semanas, y de inmediato resultó muy popular entre los clientes de Tymshare. [1] [b]
Durante la década de 1970, Tymshare comenzó a trasladar sus sistemas de SDS a la plataforma PDP-10 , y finalmente a ejecutar TOPS-10 . Esto condujo a un esfuerzo por construir un motor de base de datos completamente nuevo para esta plataforma, conocido como MAGNUM. MAGNUM era un motor de base de datos relacional completo y en muchas referencias se afirma que fue el primer sistema de este tipo que se ofreció comercialmente cuando se puso en marcha en octubre de 1975. [3] Aunque la mayoría de los clientes de Tymshare y los usuarios internos cambiaron a MAGNUM, en ese momento RETRIEVE ya se había portado a varias plataformas y estas versiones siguieron siendo muy populares fuera de la empresa.
En 1970, el Laboratorio de Propulsión a Chorro (JPL) instaló tres máquinas UNIVAC 1108. Fred Thompson había estado utilizando RETRIEVE para gestionar una base de datos de calculadoras mecánicas en el JPL y decidió incorporar el sistema a la empresa cuando llegaron las 1108. En 1971, colaboró con el programador del JPL Jack Hatfield para producir JPLDIS. Hatfield dejó el JPL en 1974 y el proyecto fue asignado a otro programador del JPL, Jeb Long, quien agregó una serie de características. [4]
En 1973 se lanzó el Wang 2200 , un miniordenador de sobremesa con almacenamiento en cintas de casete . [5] RETRIEVE fue adaptado a esta plataforma con el nombre de RECALL. Un informe para el ejército de los EE. UU. detallaba las diferencias en una sola página y concluía que "las diferencias entre las dos implementaciones son muy menores". [6]
Mientras trabajaba en el JPL como contratista, Wayne Ratliff entró en la quiniela de fútbol de la oficina . No tenía ningún interés en el juego, pero sentía que podía ganar la quiniela procesando las estadísticas posteriores al juego que se encontraban en los periódicos. Para ello, empezó a buscar un sistema de base de datos y, por casualidad, se encontró con la documentación de JPLDIS. La utilizó como base para un puerto a PTDOS en su microordenador IMSAI 8080 construido en kit , y llamó al sistema resultante Vulcan (en honor al Sr. Spock en Star Trek ). Más tarde fue portado a CP/M cuando ese sistema se volvió casi universal en el mercado de buses S-100 . [7]
En 1980, George Tate vio un anuncio de Vulcan que se vendía por 49 dólares. [8] Arregló un acuerdo de licencia con Ratliff, lo renombró dBASE II para que sonara como la segunda versión y lo puso en el mercado por 695 dólares. El sistema fue un éxito y en 1981, IBM encargó un puerto para el aún no lanzado PC DOS . [9] Este fue un éxito arrollador, uno de los tres grandes paquetes, junto con Word Perfect y Lotus 1-2-3 que conformaban el equivalente a una suite ofimática en el mercado DOS inicial. [10]
RETRIEVE era una base de datos no relacional, concepto que no se introdujo hasta 1970. Las bases de datos RETRIEVE contenían una única tabla almacenada en un único archivo, que normalmente utilizaba una forma abreviada del nombre de la base de datos como nombre de archivo. La estructura de la tabla se define cuando se crea la base de datos, lo que permite campos de entrada de caracteres, números enteros o números de formato libre. [11] Una base de datos podía tener un máximo de 98 campos, con un máximo de 72 caracteres por campo, y el total de cualquier fila era de 768 caracteres, o 256 palabras. Los nombres de los campos tenían que empezar con una letra y podían incluir letras adicionales, dígitos, un punto y el carácter @, con un máximo de 31 caracteres en total. [12]
El sistema era interactivo y utilizaba un símbolo del sistema para la interacción del usuario. [13] Por ejemplo, para iniciar una nueva base de datos, el usuario escribiría CREATE
en el símbolo del sistema, que respondería pidiéndole que escriba el nombre de la base de datos y luego solicitaría las definiciones de los campos. Una línea vacía detiene este proceso y lo envía al modo de ingreso de datos, lo que permite ingresar filas. [14] Cualquier paso de esta operación podría eliminarse proporcionando los datos en el comando original; por ejemplo, si uno escribía CREATE EMPLOYEES
en lugar de CREATE
, el sistema ya no solicitaría el nombre del archivo. [15]
Había tres formatos de archivos de base de datos que se podían especificar durante CREATE
: el formato de caracteres normal SYMBOLIC
, BINARY
que guardaba los números en sus formatos internos basados en 24 bits, y SCRAMBLED
que cifraba el archivo con una contraseña proporcionada por el usuario. [16]
Las bases de datos existentes se cargaban utilizando LOAD
o BASE
(eran equivalentes). [17] Los datos se guardaban a medida que se modificaban, pero también había un SAVE
comando para escribir los datos (o selecciones de ellos) en archivos planos. [18] QUIT
salía del sistema y regresaba al sistema operativo subyacente. [17]
Una vez definida y completada la base de datos, o cargada una existente, los datos se podían visualizar utilizando LIST
. Sin ningún parámetro, imprimía todos los registros en el orden en que se habían introducido, su "RECNO", que se imprimía al principio de la línea. También se podía proporcionar una lista de campos para seleccionar y reordenar los campos en la impresión, como LIST EMP.NUM,NAME,SALARY
. La PRINT
instrucción funcionaba de forma casi idéntica, diferenciándose únicamente en que no imprimía el RECNO al principio de las líneas. [19] FAST
era similar a PRINT
, pero también suprimía los encabezados de campo. [18]
Los registros individuales podían seleccionarse utilizando el "sistema de direccionamiento de número de registro", que se anteponía a LIST
o PRINT
. Este era un formato flexible que permitía especificar RECNO individuales separados por comas o rangos con dos puntos; por ejemplo, 1,7:20,50 PRINT
imprimiría los registros 1, todos los del 7 al 20 y luego el 50. También incluía el pseudorregistro $
para representar el último registro, por lo que 100:$ LIST
imprimía todos los registros a partir del 100. [20]
Los registros también se pueden seleccionar por campos que cumplan ciertos criterios en función de su contenido, utilizando la FOR
sintaxis. Para listar a todos los empleados con un salario mayor a $40,000, se usaría PRINT FOR SALARY>40000
. La misma sintaxis se puede utilizar para seleccionar registros individuales en función de su contenido, no del RECNO, por ejemplo LIST FOR NAME="Bob Smith"
. [21] [c] RETRIEVE admitía todas las comparaciones básicas, =
, <
, >
, <=
, >=
y #
para los no iguales, que se encontraban en algunos BASIC contemporáneos . De manera inusual, RETRIEVE también incluía expansiones en inglés de las comparaciones tradicionales, por lo que se podía utilizar SALARY>40000
o SALARY GREATER THAN 40000
. Tales expresiones también podían incluir matemáticas básicas, incluyendo +
, -
, *
para la multiplicación, /
para la división y ↑
para la exponenciación. [22] Estas se podían combinar además con expresiones booleanas utilizando AND
, OR
y NOT
. [21]
Además, SUM
, COUNT
y AVERAGE
funcionaban de manera similar a LIST
o PRINT
, incluidos los mismos conceptos de selección de registros. Como su nombre lo indica, estos generan un único valor con sus valores asociados. Por ejemplo, COUNT FOR NAME='Bob Smith'
probablemente devolvería 1, mientras que AVERAGE SALARY FOR SALARY>40000
podría devolver 42500. [23]
Además de LIST
/ PRINT
/ FAST
, hay otra declaración de salida REPORT
que funciona de manera similar, pero tiene varias opciones para imprimir la salida de manera elegante. Puede invocarse sola o con calificadores como se indicó anteriormente, pero cuando se la utiliza, ingresa a un modo interactivo que formula varias preguntas sobre dónde enviar la salida (siendo T la terminal), si debe tener un espacio simple o doble, si debe incluir encabezados y totales, etc. [24]
Los registros se podían eliminar usando la DELETE
declaración , usando los mismos selectores de registros o expresiones de campo que antes. Los nuevos registros se insertaban usando APPEND
. APPEND FIELDS
ingresaba a un modo interactivo que permitía al usuario escribir registros adicionales campo por campo en lugar de ingresar valores separados por comas una fila a la vez. [25] APPEND FROM filename
leía datos de un archivo de texto delimitado por comas en la base de datos actual que ya estaba en la memoria. [26] MERGE
se usaba para actualizar registros existentes; funcionaba de manera similar a APPEND
, cargando en la base de datos actual desde otro archivo, pero en este caso incluía un calificador adicional ON
. Por ejemplo, MERGE ON NAME FROM ADDRESSES
leía datos del archivo ADDRESSES y buscaba en ese archivo una columna donde la primera entrada fuera "NAME". Luego procesaba el archivo fila por fila, buscando entradas en la base de datos con ese NAME y luego actualizaba el resto de los campos con los datos de esa fila en ADDRESS. [27]
RETRIEVE admitía dos métodos interactivos para actualizar registros existentes, CHANGE
y REPLACE
. REPLACE
funcionaba de manera similar al equivalente SQLUPDATE
moderno, , tomando una expresión de selector de algún tipo, uno o más campos y los nuevos valores. Por ejemplo, uno podría REPLACE SALARY=SALARY*1.05 WHERE YEARS.EMP>5
. [28] Si bien CHANGE
en última instancia hacía lo mismo, lo hacía utilizando un modo interactivo. Uno invocado CHANGE
sin el nuevo valor, por ejemplo, CHANGE FOR 'Bob Smith' IN NAME
. El sistema imprimía esa fila y luego permitía al usuario editar el registro. [29] Si hay más de un valor único, por ejemplo, CHANGE FOR YEARS.EMP>5
, cada valor se imprimía en una línea separada y los cambios se enviaban a todos los registros coincidentes. [30] MODIFY
era esencialmente idéntico a CHANGE
pero no imprimía primero los valores existentes. [31]
La ordenación no se realizó en el momento de la recuperación, sino que se implementó modificando la base de datos y reescribiendo su contenido en orden ordenado. Esto se logró con SORT BY
, seguido de hasta veinte nombres de campo. Los datos originales sin ordenar se escriben en un archivo de respaldo. [32]
El RESULTS TO
modificador se puede utilizar con cualquiera de las instrucciones de modificación de datos para redirigir los resultados a una nueva base de datos. Por ejemplo, APPEND FROM FEBSALES RESULTS TO CURSALES
se podrían añadir los datos del archivo FEBSALES a la base de datos actual y luego guardar los resultados en CURSALES sin actualizar la base de datos ya abierta. O se podría SORT BY NAME RESULTS TO SORTEMP
. [33]
Se incluyeron comandos de utilidad STRUCTURE
que imprimían el esquema de la base de datos y SIZE
que devolvían el número de registros. [34]
Aunque RETRIEVE se utilizaba a menudo de forma interactiva, el sistema también incluía la capacidad de guardar listas de comandos en archivos y luego reproducirlos. [35] Los archivos de comandos también podían incluir una serie de otras instrucciones "auxiliares", como TYPE 'a string'
la de generar cualquier cadena, HUSH
la de suprimir el símbolo del sistema (un punto), TALK
la de volver a activar el símbolo del sistema y ECHO ON
la ECHO OFF
de impedir que la reproducción aparezca en la terminal. [36]
Estos archivos de comandos se ejecutaban utilizando la DO filename
instrucción de la línea de comandos interna [37] o COMMAND filename
desde fuera de RETRIEVE, en EXECUTIVE. [38] Si el script tenía la intención de dejar al usuario en RETRIEVE al final, se podía poner un COMMAND T
al final, "ejecutando" la Terminal, que especificaba qué debería suceder a continuación. Los scripts se podían unir con COMMAND
para formar flujos de trabajo más complejos. [35]
Cuando se ejecutaban, los comandos dentro de los archivos funcionaban tal como lo harían si el usuario los escribiera. Esto significa que si se proporciona una declaración que normalmente requeriría una entrada adicional del usuario, por ejemplo, CHANGE
sin parámetros, se invocaría el modo interactivo de manera normal. Esto permitía que los archivos de comandos invocaran la entrada basada en el usuario y luego ejecutaran instrucciones adicionales. Uno podría, por ejemplo, usar REPLACE ALL WEEK.SAL=SALARY/52
para capturar cualquier cambio reciente en el salario, llamar CHANGE HOURS
para que el sistema presente el registro de cada empleado y solicite sus horas semanales, luego REPLACE ALL PAY=HOURS*WEEK.SAL
calcular el cheque de pago semanal para todos los usuarios y, finalmente, REPORT
enviarlo todo a una impresora. [39]
Aunque separados por casi una década, y habiendo pasado por cuatro plataformas en el proceso, dBASE en DOS siguió siendo muy similar a RETRIEVE. Ratliff afirmó que hubo una "especie de progresión de Retrieve a JPLDIS a mi programa, al que llamé Vulcan". [40] John Walker , más conocido por AutoCAD , también utilizó JPLDIS y declaró rotundamente que "DBase II, el sistema de base de datos Ashton-Tate, era una copia, una reimplementación de un paquete desarrollado en el Laboratorio de Propulsión a Chorro llamado JPLDIS". [41]
LOAD
/ BASE
se convirtió en USE
y los puntos en los nombres de campo fueron reemplazados por dos puntos, pero la mayoría de los demás comandos y funciones permanecieron sin cambios, salvo para admitir diferencias en las plataformas subyacentes, como los formatos numéricos. Por ejemplo, el Manual del usuario de dBASE original usa este ejemplo: [42]
utilizar personaslista
Que es idéntico a las instrucciones en RETRIEVE:
CARGAR genteLISTA
El funcionamiento general de las instrucciones es en gran medida idéntico entre los dos sistemas. Las principales diferencias de dBASE están relacionadas con la programabilidad; dBASE agregó variables, podía LIST
crear columnas compuestas de fórmulas como LIST SALARY*1.05
, y agregó una variedad mucho más amplia de funciones para manipular datos, incluidas funciones para devolver la longitud de una cadena o el tipo de datos de un campo determinado. [43]