Chapter 5 – Developing Computer-based Agents
5.1 RimSim: Response for Emergency Response Simulation
REFERENCIAS Y BIBLIOGRAFÍA
La mayoría de las siguientes referencias son aplicables a todos los aspectos del modelo relational, no sólo al aspecto estructural.
5.1 E. F. Codd: "A Relational Model of Data for Large Shared Data Banks", CACM 13, No. 6 (junio, 1970). Reeditado en Milestones of Research—-Selected Papers 1958-1982 (CACM 25th Anniversary
Issue), CACM 26, No. 1 (enero, 1983). Vea también la primera versión "Derivability, Redundancy,
and Consistency of Relations Stored in Large Data Banks", IBM Research Report RJ599 (agosto 19, 1969). Nota: Esa primera versión fue la primera publicación de Codd sobre el modelo relational.
El artículo que lo inició todo. Aunque con unos 30 años de antigüedad, asombrosamente se mantiene bien para su relectura. Desde luego, muchas de las ideas han sido redefinidas desde su primera pu- blicación pero (por mucho) los cambios han sido de naturaleza evolutiva, no revolucionaria. De hecho, hay algunas ideas cuyas implicaciones todavía no se han explorado por completo.
Hacemos una observación en un pequeño aspecto de la terminología. En su artículo, Codd em- plea el término "relaciones variables en el tiempo" en lugar del término que nosotros preferimos "variables de relación" (varrels). Aunque "relaciones variables en el tiempo" no es en realidad un muy buen término. Primero, las relaciones como tales, son valores y simplemente no "varían en el tiempo" (no hay ninguna notación matemática de una relación que tenga diferentes valores en mo- mentos distintos). Segundo, si decimos por ejemplo en algún lenguaje de programación
DECLARE N INTEGER ;
no llamamos a N un "entero variable en el tiempo", la llamamos variable entera. Por lo tanto, en este libro mantendremos nuestra terminología "variable de relación", no la terminología "variable en el tiempo"; sin embargo, usted por lo menos debe estar al tanto de la existencia de esta última terminología.
5.2 E. F. Codd: The Relational Model for Database Management Version 2. Reading, Mass.: Addi- son-Wesley (1990).
Codd dedicó varios años a revisar y ampliar su modelo (al cual ahora se refiere como "el Modelo Relacional Versión 1" o RM/V1) y este libro es el resultado. Describe "el Modelo Relational Ver- sión 2" (RM/V2). La diferencia esencial entre RM/V1 y RM/V2 es la siguiente: mientras que RM/V1 fue diseñado como un anteproyecto abstracto para un aspecto en particular del problema total de las bases de datos (en esencia el aspecto de la fundamentación), RM/V2 está diseñado como un plano abstracto para todo el sistema. De ahí que, mientras RM/V1 contenía sólo tres partes —es- tructura, integridad y manipulación— RM/V2 contenga 18; esas 18 partes, por supuesto, contienen no sólo a las tres originales, sino también partes que tienen que ver con el catálogo, la autorización, la asignación de nombres, las bases de datos distribuidas y muchos otros aspectos de la adminis- tración de bases de datos. Para fines de consulta, aquí tenemos una lista de las 18 partes:
A Autorización M Manipulación
B Operadores básicos N Asignación de nombres
C Catálogo P Protección
D
Principios de diseño de DBMS Q Calificadores E Comandos para el DBAs
EstructuraF Funciones T Tipos de datos
I Integridad V Vistas
J Indicadores X Base de datos distribuida
142 Parte II / El modelo relational
Sin embargo, las ideas que promulga este libro no son de ningún modo aceptadas en fon universal [5.7-5.8]. Comentamos aquí un aspecto específico. Como vimos en el capítulo, los do- minios limitan las comparaciones. Por ejemplo, en el caso de la base de datos de proveedores) partes, la comparación V.V# = VP.P# no es válida, debido a que los operandos son de tipos dife- rentes; por lo tanto, un intento de juntar números de proveedor y números de parte fracasará. Codd propone por lo tanto versiones de la "anulación de comprobación de dominio" (I de ciertas operaciones del álgebra relacional, la cual permite que las operaciones en cuestión se realicen aun cuando comprenden una comparación entre valores de diferentes tipos. Por ejem- plo, una versión DCO de la junta recién mencionada, ocasionará que la junta se haga aun cuando los atributos V.V# y VP.P# sean de tipos diferentes (la junta se hace presuntamente sobre la base de representaciones coincidentes en lugar de tipos coincidentes).
Pero, por supuesto, es ahí donde reside el problema. Toda la idea de DCO está basada en
una confusión entre los tipos y las representaciones. Reconocer los dominios por lo que son(
decir, tipos) —con todo lo que implica este reconocimiento— nos da la comprobación de do- minio que queremos, y también nos da algo como la posibilidad de DCO. Por ejemplo, la s guiente expresión constituye una comparación en el nivel de representación posible entre un número de proveedor y un número de parte:
THE_V# V# = THEP# P#
(aquí, ambos operandos son de tipo CHAR). Por lo tanto, afirmamos que la clase de mecanismo expuesta en la sección 5.2 nos da todas las facilidades que queremos, pero lo hace de una manera clara, sistemática (es decir, no ad hoc) y completamente ortogonal. En particular, ahora no hay necesidad de saturar el modelo relacional con nuevos operadores como "junta DCO" (etcétera).
5.3 Hugh Darwen: "The Duplicity of Duplicate Rows", en C. J. Date y Hugh Darwen, i
Database Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).
Este artículo fue escrito para dar mayor soporte a los argumentos presentados en la referencia [5.6] en apoyo a la prohibición de las filas duplicadas. El artículo no sólo ofrece versiones fresca gunos de esos mismos argumentos, sino que también se las arregla para presentar otros adicionales. En particular, enfatiza la idea fundamental de que, con el fin de exponer de alguna manera inteli¡ la cuestión de si dos objetos están duplicados, es esencial tener un criterio de
igualdad claro (de-nominado en el documento, criterio de identidad) para la clase de objetos bajo
consideración. I palabras, ¿qué significa que dos objetos "sean lo mismo", ya sean filas en una tabla u otra cosa?
5.4 Hugh Darwen: "Relation-Valued Attributes", en C. J. Date y Hugh Darwen, Relational
Database
Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).
5.5 Hugh Darwen: "The Nullologist in Relationland", en C. J. Date y Hugh Darwen, Relatit
base Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).
La nulología es, como lo dice Darwen, "el estudio de nada en absoluto"; o en otras \ estudio del conjunto vacío. En la teoría relacional los conjuntos son ubicuos y la cuestión de qué sucede si un conjunto es vacío dista mucho de ser trivial. De hecho, muy a menudo r que el caso del conjunto vacío es absolutamente fundamental.
En lo que respecta al presente capítulo, las partes aplicables de este artículo son la sección. 2 ("Tablas sin filas") y la sección 3 ("Tablas sin columnas"). También vea la respuesta al cicio 5.9.
5.6 C. J. Date: "Why Duplicate Rows Are Prohibited", en Relational Database Writings 1 Reading, Mass.: Addison-Wesley (1990).
Presenta una extensa serie de argumentos, con ejemplos, en apoyo a la prohibición de las filas duplicadas. En particular, el artículo muestra que las filas duplicadas constituyen un in
5.7 C. J. Date: "Notes Toward a Reconstituted Definition of the Relational Model Version 1 (RM/V1)", en C. J. Date y Hugh Darwen, Relational Database Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).
Resume y critica el "RM/V1" de Codd [5.2] y ofrece una definición alternativa. La suposición es que resulta de crucial importancia asimilar la "Versión 1", antes de pensar siquiera en pasar a alguna "Versión 2". Nota: La versión del modelo relacional que se describe en el presente libro se basa en la versión "reconstituida" que se bosqueja en este artículo (y se clarifica y describe más a fondo en la referencia [3.3]).
5.8 C. J. Date: "A Critical Review of the Relational Model Version 2 (RM/V2)", en C. J. Date y Hugh Darwen, Relational Database Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).
Resume y critica el "RM/V2" de Codd [5.2].
5.9 C. J. Date: "30 Years of Relational" (serie de doce artículos), Intelligent Enterprise 1 números 1 a 3 e Intelligent Enterprise 2 números 1 a 9 (octubre de 1998 en adelante). Nota: La mayoría de los fascículos, después del primero, están publicados en la versión en línea de la revista, en www.intelli-
gententerprise. com.
Estos artículos se ofrecen como una revisión y valoración retrospectivas, cuidadosas y sin desvia- ciones, de la contribución relacional de Codd como está documentada en sus publicaciones de los años setenta. Para ser específicos, examinan en detalle los siguientes documentos (y de paso, también aborda otros más):
■ Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks (la primera versión de la referencia [5.1]);
■ A Relational Model of Data for Large Shared Data Banks [5.1]; ■ Relational Completeness of Data Base Sublanguages [6.1];
■ A Data Base Sublanguage Founded on the Relational Calculus [7.1]; ■ Further Normalization of the Data Base Relational Model [10.4];
■ Extending the Relational Database Model to Capture More Meaning [13.6];
■ Interactive Support for Nonprogrammers: The Relational and Network Approaches [25.8]. 5.10 Mark A. Roth, Henry F. Korth y Abraham Silberschatz: "Extended Algebra and Calculus for Nested Relational Databases", ACM TODS 13, No. 4 (diciembre, 1988).
A través de los años, varios investigadores han propuesto lo que se denominan "Relaciones NF2", en donde NF2 = NFNF = "no primera forma normal". En realidad existe cierta confusión sobre
lo que significa exactamente el término NF2, pero la interpretación que parece tener más sentido
es ésta: Sea nr una "relación NF2" y sea el "atributo" A de nr del tipo T. Entonces, una determi-
nada "tupia" t de nr puede incluir cualquier cantidad de valores para el "atributo" A (¿incluso quizás ninguno?), y diferentes "tupias" pueden contener diferentes cantidades de dichos valores
A* (Por lo tanto, el atributo A es un atributo de grupo de repetición; vea las observaciones sobre
este tema en la edición anterior de este libro, citada en la sección 5.3 del presente capítulo.) Por lo tanto, observe cuidadosamente, que la "relación" nr definitivamente no es normalizada (no contiene exactamente un valor para cada atributo en cada tupia); de hecho, por lo que respecta al modelo relacional, no es en absoluto una relación. Sea como fuere, este artículo expone una versión de la idea del NF2. En particular, define un cálculo y un álgebra (vea los capítulos 6 y 7) para las "relaciones NF2" y demuestra su equivalencia. Además, proporciona referencias a un cuerpo considerable de otro trabajo sobre el tema.
* Algunos autores rechazarían esta definición y definirían una "relación NF2" para que fuera cualquier relación con al menos un atributo que tuviera el valor de una relación. Nosotros tenemos nuestras razones para argumentar que una relación así está, de hecho, en la primera forma normal.
144 Parte II / El modelo relational