Word - Carreras de Sistemas - UARG

Título: Modelo de Red
Integrantes:
!
Alvarado, Belen
Atencio, Josefina
Farfán, Ricardo
Farfán, Silvia
Cátedra: Base de Datos
&
Profesor: Sofia, Osiris
Año: 2002
Índice
Modelo de Red .........................................................................3
Conceptos Básicos ....................................................................3
Diagrama de Estructura de Datos ..............................................3
El modelo CODASYL DBTG .....................................................6
!
Facilidad de recuperación de datos en DBTG .........................10
Facilidad de actualización en DBTG ........................................12
Facilidad de procesamiento de conjuntos en DBTG ................14
Asignación de redes a archivos ................................................16
Sistemas de red ........................................................................20
&
Bibliografía . ...............................................................................21
Modelo de Red
2
Modelo de Red
En el modelo de red, los datos se representan por medio de colecciones de registros y
las relaciones entre los datos mediante enlaces.
Conceptos básicos
Registro: Colección de campos (atributos), cada uno de los cuales contiene solamente
un valor de un dato.
Enlace: Asociación entre 2 registros exclusivamente.
Por ej. :
!
Un registro puede ser cliente y cuenta, éstos pueden definirse utilizando una notación
en Pascal como sigue:
Type cliente=record
Nombre: string;
Calle: string;
Ciudad:string
End;
Type cuenta=record
Numero: integer;
Saldo: integer
End;
Diagrama de Estructura de Datos
Es un esquema que representa el diseño de una base de datos de red, el cual consta
de:
&
Cajas, que corresponden a tipos de registros.
Líneas, que corresponden a enlaces.
Un diagrama de estructura de datos tiene el mismo propósito que uno de
entidad_relación; a saber, especifica la estructura lógica global de la base de datos.
Relación binaria
Considérese el diagrama Entidad_Relación de la fig. 1 que consta de dos conjuntos de
entidades, clientes y cuenta, relacionados por medio de una relación binaria, muchos a
muchos, clicta, sin atributos descriptivos. El diagrama de estructura de datos
correspondiente se ilustra en la fig. 2. El tipo de registro cliente corresponde al conjunto
de entidades cliente, incluye tres campos (nombre, calle y ciudad). De manera similar,
cuenta es el tipo de registro correspondiente al conjunto de entidades cuenta. Incluye
Modelo de Red
3
!
dos campos (número y saldo). Finalmente, la relación clicta se ha sustituido por el
enlace clicta.
La cardinalidad de asignación, que se utilizará en los diagramas de estructura de datos,
se representará de la misma manera que los diagramas Entidad_Relación.
Si una relación incluye atributos respectivos, la transformación de un diagrama
Entidad_Relación en un diagrama de estructura de datos es algo más complicada. Esto
se debe al hecho de que un enlace no puede contener valores de datos.
En este caso se necesita crear un nuevo tipo de registro y establecer los enlaces como
se indica a continuación:
1. Sustituir entidades por registros.
2. Crear un nuevo registro con solo un campo para representar el atributo de la
relación.
3. Crear los siguientes enlaces, muchos a uno:
&
Un enlace que vaya del nuevo registro clifecha al tipo de registro cliente
como se indica en el gráfico.
Ctafecha del tipo registro fecha al tipo registro cuenta.
Modelo de Red
4
!
Relaciones generales
Considerese el diagrama Entidad_Relación que consta de tres conjuntos de entidades
(cuenta, cliente y sucursal), relacionados entre sí por medio de una relación general
CCS sin atributos descriptivos. Puesto que un enlace puede conectar solamente a dos
tipos de registro diferentes, necesitamos conectar estos tres tipos de registro por
medio de un nuevo tipo de registro que se enlaza directamente a cada uno de estos
tres registros, como se describe a continuación:
&
1. Sustituir a todas las entidades por registros.
2. Crear un nuevo tipo de registro que puede no tener campos o tener solo uno que
contenga un identificador único, este identificador es proporcionado por el sistema.
Este nuevo registro es, a veces, denominado tipo registro ficticio.
3. Crear los siguientes enlaces, muchos a uno, que vayan de:
El registro ficticio al primer registro.
El registro ficticio al segundo registro.
El registro ficticio al tercer registro.
Esta técnica puede extenderse de una forma directa para tratar relaciones que
abarquen más de tres conjuntos de entidades. De la misma manera, si la relación
general contiene varios atributos descriptivos, necesitamos añadir un campo al tipo de
registro ficticio por cada atributo descriptivo.
Modelo de Red
5
!
El modelo CODASYL DBTG
La primera especificación estándar de una base de datos, llamada informe CODASYL
DBTG 1971, fue escrita a finales de la década de los sesenta por el grupo de trabajo
sobre Base de Datos. Desde entonces se han sugerido varios cambios a ese informe.
En 1981, se publicó una nueva propuesta que todavía no se ha adoptado oficialmente.
Hemos elegido esta proposición como la fuente principal para nuestro tratamiento del
modelo DBTG.
&
Restricción de enlaces
En el modelo DBTG solamente pueden emplearse enlaces mucho a uno. Los enlaces
muchos a muchos se prohiben para simplificar la implementación. Los enlaces uno a
uno se representan utilizando un enlace muchos a uno. Si el diagrama de base de
datos es uno a muchos, éste no sufre cambios.
Sin embargo, si el enlace es de muchos a muchos, el algoritmo de transformación debe
redefinirse como sigue. Si la relación no tiene atributos descriptivos entonces debe
emplearse el siguiente algoritmo:
1. Sustituir entidades por registros.
2. Crear un nuevo tipo de registro ficticio, que puede no tener campos o tener solo
uno, que contenga un identificador único definido exteriormente.
3. Crear los dos siguientes enlaces muchos a uno que van de:
Modelo de Red
6
Conjuntos DBTG
!
Registro ficticio al primer registro (cliente).
Registro ficticio al segundo registro (cuenta).
&
Dada que solamente puede utilizarse enlaces muchos a uno en el modelo DBTG, un
diagrama de estructura de datos que consta de dos tipos de registros enlazados entre
sí tiene la forma general de la figura:
Esta estructura se denomina conjunto DBTG, generalmente el conjunto recibe el
nombre del enlace.
En todo conjunto DBTG de este tipo, el tipo de registro A se denomina dueño (o padre)
del conjunto, y el tipo de registro B se denomina miembro (o hijo) del conjunto.
Cada conjunto DBTG puede tener cualquier número de ocurrencias del conjunto.
Además, ningún registro miembro puede participar en más de una ocurrencia del
conjunto en ningún momento. Sin embargo, el registro miembro puede participar
simultáneamente en varias ocurrencias de diferentes conjuntos.
Para ilustrar considere el siguiente gráfico:
Modelo de Red
7
Los conjuntos pueden definirse así:
Set name is succta
owner is sucursal
member is cuenta
!
Set name is clicta
Owner is cliente
Member is cuenta
&
El modelo DBTG permite estructuras de conjuntos más complicadas en las que existe
un solo tipo de dueño y varios tipos de miembros. Por ejemplo , Supóngase que
tenemos dos tipos de cuentas bancarias: de cheques y de ahorros. El diagrama de
estructura de datos será el siguiente:
Modelo de Red
8
!
El modelo DBTG también proporciona la definición de un conjunto especial,
denominado conjunto singular o del sistema. En un conjunto de este tipo, el dueño es
un tipo de registro único definido por el sistema, llamado system, que no tiene campos.
Este conjunto tiene una sola ocurrencia de conjunto. Este esquema es útil para buscar
registros de un tipo determinado.
Grupos repetidos
&
El modelo DBTG proporciona un mecanismo que permite a un campo tener un conjunto
de valores en vez de un solo valor.
La construcción de grupos repetidos es otra forma de representar el concepto de
entidades débiles en el modelo Entidad_Relación.
Para ilustrarla, dividamos el conjunto de entidades cliente en dos conjuntos:
Cliente, con el atributo descriptivo nombre.
Dirección, con los atributos descriptivos calle y ciudad.
El conjunto de entidades dirección es débil, ya que depende del conjunto de entidades
fuerte cliente.
Si no se uso la construcción de grupo repetida en el esquema, entonces el diagrama de
estructura de datos correspondiente es el de la figura. Por otro lado, si se utiliza la
construcción de grupo repetida entonces el diagrama de estructura de datos consta
simplemente de un solo tipo de registro cliente.
Modelo de Red
9
!
Facilidad de recuperación de datos en DBTG
El lenguaje de manipulación de datos de la propuesta DBTG consiste en un número de
órdenes que se incorporan en un lenguaje principal.
Área de trabajo de programa
&
Todo programa de aplicación que se ejecute en un sistema posee una secuencia de
sentencias: algunas son sentencias de Pascal y otras son órdenes DBTG. A este tipo
de programa se lo denomina unidad de ejecución. Las sentencias que este programa
posee acceden y manipulan todos los elementos de la base de datos como las
variables declaradas localmente.
El programa mencionado anteriormente mantiene un área de trabajo de programa
"Área de trabajo de usuario en el modelo DBTG", siendo ésta un área de
almacenamiento de registros intermedios, la cual contiene las siguientes variables:
Plantillas de registros: Un registro para cada tipo de registro, al que acceda al
programa principal.
Punteros de actualidad: Un conjunto de punteros a varios registros de la base de
datos más actuales.
Distintos tipos de punteros:
Actual de tipo de registro.
Actual de tipo conjunto.
Actual de unidad de ejecución.
Indicadores de estado: Es un conjunto de variables que utiliza el sistema para
comunicar al programa de aplicación, el resultado de la última operación aplicada a
la base de datos. La más utilizada es:
Modelo de Red
10
DB-status (la más usada).
DB-set-name.
DB-record-name.
DB-data-name.
Ejemplo:
Plantillas
Registro cliente.
Registro sucursal.
Registro cuenta.
!
Punteros de actualidad
&
Registro cliente, registro cuenta y registro sucursal.
Conjunto clicta y suc-cuenta.
Puntero actual de unidad de ejecución.
Órdenes find y get (las más usadas)
Modelo de Red
11
Find: Localiza a un registro en la base de datos y da valores a los punteros de
actualidad adecuados.
Get: Copia el registro al que apunta el actual, de unidad de ejecución de la base
de datos a la plantilla adecuada en el área de trabajo del programa.
Acceso a registros individuales
Existen dos órdenes find diferentes para localizar registros individuales en la base de
datos. Ésta es la más sencilla:
Find any <tipo de registro> using <campo de registro>
Acceso de registros dentro de un conjunto
!
Órdenes find que localizan registros en un conjunto DBTG particular, el conjunto en
cuestión es aquel al que apunte el puntero de actualidad <tipo conjunto>. Existen tres
tipos distintos de órdenes.
Está es la más básica. Busca el primer registro.
Find first <tipo de registro> within <tipo de conjunto>
Busca el siguiente elemento del conjunto.
Find next <tipo de registro> within <tipo de conjunto>
Localiza el dueño de un conjunto.
Find owner within <tipo de conjunto>
Predicados
&
Las sentencias find permiten comparar el valor de un campo en una de las plantillas de
registros con el campo correspondiente en los registros apropiados de la base de
datos.
Cuando existen muchas consultas en las que deben compararse el valor de un campo
con un rango de valores especificados, necesitamos pasar (get) los registros
apropiados a la memoria y examinar cada uno por separado, para determinar si es uno
de los que busca la sentencia find.
Facilidad de actualización en DBTG
La actualización en DBTG incluye la creación de registros nuevos, eliminación de
registros antiguos, como la modificación de registros existentes.
Creación de registros nuevos
Modelo de Red
12
Esta técnica nos permite crear y añadir solamente un registro cada vez.
Store <tipo de registro>
Cliente.nombre:=’’Juan’’;
Cliente.calle:=”Roca”;
Cliente.ciudad := ‘’Rio gallegos’’ ;
Store cliente ;
Eliminación de un registro
!
El puntero de actualidad de ese tipo debe apuntar al registro que se va a eliminar en la
base de datos, usando la siguiente sentencia:
Erase <tipo de registro>
&
Fin:=false;
Cliente.nombre:=”Juan”;
Find any cliente using nombre ;
Find for update first cuenta within CliCta;
While DB-status=0 and not fin do
Begin
Get cuenta;
If cuenta.número= 402 then
Begin
Erase cuenta;
Fin:=true;
End
Else find for update next cuenta within CliCta;
End
Modificación de un registro existente
Para modificar un registro existente del tipo <tipo-registro>, debemos encontrar el
registro en la base de datos, pasarlo a memoria principal y cambiar los campos
deseados en las plantillas de <tipo de registro>. Finalizado esto, reflejamos los cambios
en el registro al que apunta el puntero de actualidad de <tipo de registro>. La sentencia
es:
Modify <tipo de registro>
La sentencia find for update es la que se utiliza para buscar el registro que desea
actualizar.
Cliente.nombre:=’’Juan ’’;
Modelo de Red
13
Find for update any cliente using nombre;
Get cliente;
Cliente.ciudad:=’’Rio Gallegos’’;
Modif. Cliente;
Facilidad de procesamiento de conjuntos en DBTG
La sentencia (connect)
Pasos para la inserción de un registro nuevo:
!
1. Crear un registro nuevo del tipo <tipo de registro>. Esto asigna al puntero de
actualidad de <tipo de registro>, el valor apropiado.
2. Encontrar el dueño adecuado del conjunto <tipo de conjunto>, ésto hace que el
puntero de actualidad apunte automáticamente a la ocurrencia de <tipo de
conjunto>.
3. Se inserta el registro nuevo con la sentencia connect.
Cuenta.número:=267;
Cuenta.saldo:=0;
Store cuenta;
Cliente.nombre:=”Juan”;
Find any cliente using nombre;
Connect cuenta to CliCta;
La sentencia (disconnect)
&
Para eliminar un registro del tipo <tipo de registro>, de una ocurrencia del conjunto del
tipo <tipo de conjunto>, necesitamos hacer que los punteros de actualidad de <tipo de
registro> y <tipo de conjunto> apunten al registro y ocurrencia de conjunto apropiados.
Una vez que se ha hecho esto, el registro puede eliminarse del conjunto. La sentencia
es:
Disconnect <tipo de registro> from <tipo de conjunto>
Cuenta.número:=177;
Find for update any cuenta using número;
Get cuenta;
Find dueño within CliCta;
Disconnect cuenta from CliCta;
La sentencia (reconnect)
Modelo de Red
14
Para pasar un registro <tipo de registro> de una ocurrencia de un conjunto a otra
ocurrencia del conjunto de tipo <tipo de conjunto> se debe encontrar el registro
apropiado y el dueño de las ocurrencias de conjunto a las que se trasladará ese
registro. La sentencia es:
Reconnect <tipo de registro> to <tipo de conjunto>
!
Clienta.nombre:=”Juan”;
Find any cliente using nombre;
Find first cuenta within CliCta;
While DB-status=0 do
Begin
Find dueño within SucCta;
Get sucursal;
If sucursal.nombre :=”Hillside” then
Begin
Sucursal.nombre:=”Valleyview”;
Find any sucursal using nombre;
Reconnect cuenta to SucCta;
End
Find next cuenta eithin CliCta;
end
Inserción y retención en conjunto
Insertion is <modo de inserción>
Donde <modo de inserción> puede tomar una de las dos formas:
Manual:
&
Connect <tipo de registro> to <tipo de conjunto>
Automático:
Store <tipo de registro>
Cuenta.sucursal:= “Valleyview”;
Find any sucursal using nombre;
Cuenta.número:=535;
Cuenta.saldo=0;
Store cuenta;
Cliente.nombre:=”Juan”;
Find any cliente using nombre;
Connect cuenta to CliCta;
Modelo de Red
15
Retención en conjunto
Existen varias restricciones respecto a como y cuando un registro miembro puede
eliminarse de una ocurrencia de conjunto en la que se halla insertado anteriormente.
Retention is <modo de retención>
Donde modo de retención puede ser:
Fija: Esta forma impide sacar el registro miembro de una ocurrencia de un
conjunto. Para poder reconectar un registro, debemos borrarlo, volver a crearlo, y
luego insertarlo en la nueva ocurrencia del conjunto.
Obligatoria: No puede reconectarse ni desconectarse a un conjunto de otro tipo.
Opcional: No hay restricciones.
!
Asignación de redes a archivos
&
Una base de datos de red consta de registros y enlaces. Los enlaces se implementan
añadiendo campos de punteros a los registros que se asocian por medio de enlaces.
Cada registro debe tener un campo de puntero por cada enlace con el que esté
asociado. La figura a continuación ilustra el tema.
En un enlace muchos a muchos, cada registro puede estar asociado a un numero
arbitrario de registros. Así, no es posible limitar el número de campos de puntero de un
registro. Por tanto aunque el registro mismo sea de longitud fija, el registro real que se
utiliza en la implementación física es un registro de longitud variable.
Estas complicaciones llevaron a los arquitectos del modelo DBTG a restringir los
enlaces a que fueran bien uno a uno o bien uno a muchos.
Veremos que, bajo esta restricción es posible conservar registros de longitud fija y
reducir el número de punteros requeridos.
Un registro cuenta puede estar asociado solamente a un registro cliente. Por tanto,
únicamente necesitamos un puntero en el registro cuenta para representar la relación
Modelo de Red
16
CliCta. Sin embargo, un registro cliente puede estar asociado a muchos registros
cuenta. En vez de utilizar muchos punteros en el registro cliente, podemos usar una
estructura de anillo (lista circular) para representar la ocurrencia total del conjunto
DBTG CliCta.
&
!
Si representamos los conjuntos DBTG empleando la estructura anillo, un registro
contendrá exactamente un puntero por cada conjunto DBTG en el que participe, sin
importar que sea del tipo dueño o miembro. Así, los registros de longitud pueden
representarse dentro de una estructura de anillo sin la necesidad de recurrir a registros
de longitud variable. Para encontrar un registro miembro determinado de una
ocurrencia de conjunto, debe seguirse de manera secuencial la cadena de punteros
para llegar desde el registro dueño hasta el registro miembro deseado.
La estrategia de implementación de la estructura de anillo para el modelo DBTG
proporciona motivación para la facilidad de recuperación de información en DBTG. En
este caso son utilizadas las órdenes find first y find next estas se refieren a la
ordenación de los registros dada por los punteros.
La sentencia find owner del lenguaje de consulta DBTG está reflejada en una forma
modificada de la estructura de anillo en la que todos los registros de tipo miembro
contienen un segundo puntero, el cual apunta al registro dueño. Bajo esta estrategia de
implementación, un registro tiene un puntero por cada conjunto DBTG que sea del tipo
miembro. Bajo la estrategia anterior, es necesario recorrer la estructura de anillo hasta
encontrar el dueño.
Puesto que las sentencias find first, find next y find owner son las que se utilizan con
mayor frecuencia en una consulta en DBTG, es conveniente almacenar los registros de
una ocurrencia de conjunto DBTG unos cerca de otros físicamente en el disco. Para
especificar la estrategia que va a emplear el sistema para almacenar un conjunto
DBTG, se añade una cláusula placement a la definición del tipo de registro miembro.
Placement clustered via <nombre del conjunto>
Esta sentencia provocará que el sistema almacene los miembros de cada ocurrencia
de conjunto físicamente cerca unos de otros en el disco. Hasta donde sea posible, los
miembros de una ocurrencia de conjunto se almacenarán en el mismo bloque.
Modelo de Red
17
!
Si deseamos almacenar más de un tipo de registro en un archivo, podemos especificar
que los registros dueño y miembro se almacenan físicamente cerca unos de otros en el
disco. Hacemos esto añadiendo la cláusula near owner a la cláusula placement.
&
Placement clustered via <nombre del conjunto> near owner
Modelo de Red
18
Sistemas de red
El modelo de red es la base de la mayor parte de los sistemas antiguos de base de
datos y de algunos sistemas recientes. Los mas populares son Total e IDMS.
Total
IDMS
!
El sistema de base de datos Total data de finales de la década de los años sesenta.
Funciona en una variedad de máquinas que van desde microcomputadores hasta
computadores grandes.
El lenguaje de consulta Total difiere del estándar DBTG que se presento hasta ahora,
aunque tiene una función similar, utiliza una sintaxis diferente.
Todas las sentencias del lenguaje de manipulación de datos (data manipulation
language (DML)). Total deben incorporarse en un lenguaje principal (cobol, PL/I,
Fortran o RPG).
&
IDMS es un sistema de base de datos de red desarrollado por Cullinane Database
System, Inc. IDMS sigue de cerca el modelo DBTG que se presentó en las secciones
anteriores. Incluye un lenguaje de manipulación de datos detallado que permita al
diseñador de datos un alto grado de control sobre la organización física de la base de
datos.
El lenguaje de manipulación de datos incluye características idénticas al DBTG DML
que se describió en las secciones anteriores. Se incluyen características adicionales
para facilitar la labor del programador y para que los programadores experimentados
sean capaces de escribir consultas más eficientes.
Modelo de Red
19
Bibliografía
Fundamentos de bases de datos. Segunda edición / Henry F. Korth,
Abraham Silberschatz ; tr. María Angeles Vaquero Martín; Antonio Vaquero García;
revisión técnica María Amparo Vila Miranda. -- Madrid [ES] : McGraw-Hill, 1993. -xx,739 p. : il.
&
!
Diseño y uso de bases de datos relacionales / Irene Luque Ruiz, Miguel
Angel Gómez-Nieto. -- Madrid [ES] : Ra-Ma, 1997. -- xix,449 p. : il
Modelo de Red
20