UNA VISION RELACIONAL DE DATOS
Patrichs Inocente Valle1 ,Kevin Paima Mijahuanca2
1,2 Universidad Nacional de Ingenieria. Facultad de Ciencias, Ciencia de la computación.
1. Parte 1
La totalidad de los datos en una base de datos
puede verse como una colección de relaciones que
varían con el tiempo. Estas relaciones son de di-
versos grados. A medida que pasa el tiempo, cada
relación n-aria puede estar sujeta a la inserción de
n-tuplas adicionales, la eliminación de las existen-
tes y la alteración de los componentes de cualquie-
ra de sus n-tuplas existentes.
Sin embargo, en muchos bancos de datos co-
merciales, gubernamentales y científicos, algunas
de las relaciones son de un grado bastante alto
(un grado de 30 no es nada raro). Los usuarios
normalmente no deben cargar con recordar el do-
minio pedido de cualquier relación (por ejemplo, el
proveedor de pedidos, luego parte, luego proyecto,
luego cantidad en la relación de suministro).
En consecuencia, proponemos que los usuarios
traten, no con relaciones que están ordenadas por
dominio, sino con relaciones que son sus contra-
partes desordenadas de dominio.2 Para lograr es-
to, los atributos deben ser identificables de forma
única, al menos dentro de cualquier relación dada,
sin usar la posición. Por lo tanto, cuando hay dos
o más atributos idénticos, requerimos en cada ca-
Figura 1: Una relación con dos atributos idénticos
1
so que el nombre de dominio sea calificado por un
nombre de función distintivo, que sirve para iden-
tificar el papel desempeñado por ese dominio en la
relación dada. Por ejemplo, en el componente de
relación de la Figura 1, la primera parte del do-
minio podría estar calificada por el nombre de rol
sub, y la segunda por super, de modo que los usua-
rios pudieran tratar con el componente de relación
y sus atributos-sub.part super.part cantidad, in-
dependientemente de cualquier pedido entre estos
atributos.
2. Parte 2
En resumen, se propone que la mayoría de los
usuarios interactúen con un modelo relacional de
los datos que consiste en una colección de rela-
ciones que varían en el tiempo (en lugar de rela-
ciones). Cada usuario no necesita saber más sobre
ninguna relación que su nombre junto con los nom-
bres de sus atributos (rol calificado siempre que
sea necesario): incluso esta información podría ser
ofrecido en estilo de menú por el sistema (sujeto a
seguridad y restricciones de privacidad) a petición
del usuario.
 Por lo general, existen muchas formas alter- .
nativas de establecer un modelo relacional para
un banco de datos. En para discutir una forma
preferida (o forma normal), nosotros primero de-
be introducir algunos conceptos adicionales (acti-
vo dominio, clave primaria, clave externa, domi-
nio no simple) y establecer algunos enlaces con la
terminología actualmente en uso en programación
de sistemas de información. En el resto de este
documento, no nos molestaremos en distinguir en-
tre relaciones y relaciones, excepto cuando parezca
ventajoso ser explícito.
Considere un ejemplo de un banco de datos que
incluye relaciones relacionadas con piezas, proyec-
tos y proveedores. Una relación llamada parte se
define en los siguientes atributos:

número de pieza

nombre de parte

parte de color

peso de la parte

cantidad disponible

cantidad en orden

Y posiblemente otros atributos también. Cada

uno de estos atributos es, en efecto, un conjun-
to de valores, algunos de los cuales pueden estar
representados en el banco de datos en cualquier
momento. Si bien es concebible que, en algún mo-
mento, todos los colores de las partes estén presen-
tes, es poco probable que lo estén todos los pesos,
nombres y números de partes posibles. Llamare-
mos al conjunto de valores representados en algún
momento el dominio activo en ese instante.