Los modelos de datos.

En el proceso de abstracción que conduce a la creación de una base de datos desempeña una función prioritaria el modelo de datos. El modelo de datos, como abstracción del universo de discurso, es el enfoque utilizado para la representación de las entidades y sus características dentro de la base de datos, y puede ser dividido en tres grandes tipos (KORTH y SILBERSCHATZ, 1993: 6-11):

1. Modelos lógicos basados en objetos: los dos más extendidos son el modelo entidad-relación y el orientado a objetos. El modelo entidad-relación (E-R) se basa en una percepción del mundo compuesta por objetos, llamados entidades, y relaciones entre ellos. Las entidades se diferencian unas de otras a través de atributos. El orientado a objetos también se basa en objetos, los cuales contienen valores y métodos, entendidos como órdenes que actúan sobre los valores, en niveles de anidamiento. Los objetos se agrupan en clases, relacionándose mediante el envío de mensajes. Algunos autores definen estos modelos como "modelos semánticos".
2. Modelos lógicos basados en registros: el más extendido es el relacional, mientras que los otros dos existentes, jerárquico y de red, se encuentran en retroceso. Estos modelos se usan para especificar la estructura lógica global de la base de datos, estructurada en registros de formato fijo de varios tipos. El modelo relacional representa los datos y sus relaciones mediante tablas bidimensionales, que contienen datos tomados de los dominios correspondientes. El modelo de red está formado por colecciones de registros, relacionados mediante punteros o ligas en grafos arbitrarios. el modelo jerárquico es similar al de red, pero los registros se organizan como colecciones de árboles. Algunos autores definen estos modelos como "modelos de datos clásicos".
3. Modelos físicos de datos: muy poco usados, son el modelo unificador y el de memoria de elementos. Algunos autores definen estos modelos como "modelos de datos primitivos".

De lo anterior se deduce que el punto clave en la construcción de la base de datos será el modelo de datos. Se denomina modelo:

"...al instrumento que se aplica a una parcela del mundo real (universo del discurso) para obtener una estructura de datos a la que denominamos esquema. Esta distinción entre el modelo (instrumento) y el esquema (resultado de aplicar el instrumento) es importante... Es importante también distinguir entre mundo real y universo del discurso, ya que este último es la visión que del mundo real tiene el diseñador... podemos definir un modelo de datos como un conjunto de conceptos, reglas y convenciones que nos permiten describir los datos del universo del discurso." (MIGUEL y PIATTINI, 1993: 162)

Los objetivos del modelo de datos son dos:

1. Formalización: definir formalmente las estructuras permitidas y las restricciones a fin de representar los datos de un SI.
2. Diseño: el modelo resultante es un elemento básico para el desarrollo de la metodología de diseño de la base de datos.

Los diferentes modelos de datos comparten, aunque con diferentes nombres y notaciones, unos elementos comunes, componentes básicos de la representación de la realidad que realizan. Estos componentes se identifican gracias a la clasificación, y pueden identificarse conceptos estáticos y conceptos dinámicos. Los conceptos estáticos corresponden a:

1. Objeto: cualquier entidad con existencia independiente sobre el que almacenan datos. Puede ser simples o compuestos.
2. Relación: asociación entre objetos.
3. Restricción estática: propiedad estática del mundo real que no puede expresarse con los anteriores, ya que sólo se da en la base de datos; suele corresponder a valores u ocurrencias, y puede ser sobre atributos, entidades y relaciones.
4. Objeto compuesto: definidos como nuevos objetos dentro de la base de datos, tomando como punto de partida otros existentes, mediante mecanismos de agregación y asociación.
5. Generalización: se trata de relaciones de subclase entre objetos, es decir, parte de las características de diferentes entidades pueden resultar comunes entre ellas.

Por su parte, los conceptos dinámicos responden a:

1. Operación: acción básica sobre objetos o relaciones (crear, modificar, eliminar...).
2. Transacción: conjunto de operaciones que deben ejecutarse en su conjunto obligatoriamente.
3. Restricción dinámica: propiedades del mundo real que restringen la evolución en el tiempo de la base de datos.

El modelo jerárquico. Estructura. Relaciones padre-hijo. Propiedades del esquema. Arboles. Estructura de almacenamiento. Tipos de acceso. Integridad y seguridad del modelo. Definición completa de una base de datos jerárquica.

El modelo de red. Estructura. Registros. Campos y datos. Tipos y ocurrencias de sets. Limitantes de membresía (de inserción, retención y ordenamiento). Representaciones de ocurrencias. Set singular. Set de miembros múltiples. Set recursivo.

El modelo relacional. Conceptos básicos. Dominios, atributos, tuplas, relaciones, atributos llave, llaves foráneas. Algebra relacional. Operaciones. Cálculo relacional, Vistas. Esquema de base de datos relacional. Regla de unicidad. Regla de integridad referencial. Normalización.

Modelo entidad-relación. Atributos y entidades. Valores y dominios de los atributos. Tipos de entidades. Atributos llave. Tipos de relación. Instancias de rela-ciones. Restricciones estructurales. Entidad débil. Representación del modelo mediante diagramas. Generalización y especialización. Agregación. Conversión de los diagramas en tablas.

Diseño relacional. Requerimientos y análisis. Diseño conceptual. Esquema conceptual. Diseño lógico. Diseño físico e implantación. Problemas de redundancia. Valores nulos. Dependencias funcionales. Reglas de inferencia. Formas normales: primera, segunda, tercera, interpretación de la tercera forma normal, forma normal de Boyce-Codd. Proceso de normalización. Algoritmos de descomposición. Otros tipos de dependencias y formas normales. Dependencias multivaluadas.

Modelos alternativos. Modelo orientado a objetos: tipos abstractos de datos, herencia, identidad de objetos, modelado de datos y estrategias de diseño, persistencia, métodos especiales de acceso, consideraciones de seguridad. Bases de datos heterogéneas: tecnología para interoperabilidad, esquemas, renombramiento, consultas, resolución de conflictos, optimización de consultas globales.

CONCEPTOS BASICOS

    Una base de datos jerárquica consiste en una colección de registros que se conectan entre si por medio de ligas. Los registros y las ligas son similares a los del modelo de red, pero en el modelo jerárquico se organiza en forma de árbol con raíz (donde la raíz es nodo ficticio); de tal manera que una base de datos jerárquica es una colección de arboles de este tipo, formando un bosque.

A cada árbol con raíz con raíz se le denomina árbol de base de datos.

    En este modelo un registro puede tener que repetirse en varios sitios que puede ocasionarlos siguientes problemas:

• Riesgos de la inconsistencia al llevar a cabo actualizaciones.

• Inevitable desperdicio de espacio en el medio de almacenamiento secundario.

DIAGRAMAS DE ESTRUCTURAS DE ÁRBOL

    Un diagrama de estructura de árbol es el esquema de una base de datos jerárquica. Tiene dos componentes básicos:

REGISTROS y LIGAS

    Estos diagramas son similares a los de estructura de datos en el modelo de red. La diferencia radica en que en el modelo de red los registros se organizan en forma de un grafo arbitrario mientras que en el modelo jerárquico se organiza en forma de un árbol con raíz.

1.-No hay ciclos
2.-De padre a hijos son

Las reglas para la formación del árbol son: validas las relaciones de uno a uno a uno a muchos.    El esquema de una base de datos jerárquica se representa como una colección de diagramas de estructuras de árbol. Para cada diagrama existe una única instancia del árbol de base de datos. La raíz de este árbol es un nodo ficticio. Los hijos de ese nodo son instancias del tipo de registros adecuado.

 Ejemplo:

 

CASOS PARTICULARES

REGISTROS VIRTUALES.

    Dado que en las relaciones muchos a muchos existe demasiada repetición de datos, se maneja el concepto de registro virtual. Un registro virtual es aquel que no se escribe físicamente en el medio, sino que es una referencia (liga) a un registro existente en forma previa su representación es :

    La razón de utilizar registros virtuales es evitar la repetición de los datos, lo cual traería consigo los siguientes inconvenientes:

-Redundancia, en consecuencia desperdicio de espacio de almacenamiento.

-Alto riesgo de inconsistencia durante las actualizaciones.

Modelos de Datos De Red

	Mediados de los Sesentas	Setentas a mediados de los ochentas	Ochentas a principios de los noventas	Futuro
Modelo de datos	De red Jerárquico	Relacional	Semántico Orientado a objetos	Fusión de los modelos de datos y la representación de conocimientos. Modelos híbridos Configuración cliente-servidor
Hardware de bases de datos	Macrocomputadores	Macrocomputadores	Computadores personales más rápidos	Configuración cliente-servidor
Interfaz con el usuario	Ninguna	Minicomputadores Computadores Personales Lenguajes de consulta Formas	Estaciones de trabajo Máquinas de bases de datos Máquinas dorsales Gráficos Menús Consulta por formas	Procesamiento en paralelo Memorias ópticas   Multimedia Lenguajes naturales Entrada de voz Texto a mano libre Bases de datos y lenguajes de programación integrados.
Interfaz con programas	Por procedimientos	Lenguajes de consulta incorporados	SQL estandarizado Lenguajes de cuarta generación Programación lógica Gráficos de negocios Salida de imágenes.	Gestores de presentación generalizados Procesamiento de datos y conocimientos distribuidos y heterogéneos, con información de multimedia
Procesamiento	Procesamiento de datos	Procesamiento de información y transacciones	Procesamiento de transacciones Procesamiento de conocimientos	Gestión de bases de datos en paralelo

 

La tabla resume los pasos más destacados en la evolución de la tecnología de bases de datos durante las últimas tres décadas, aproximadamente. Las tres primeras columnas de la tabla corresponden aproximadamente a los tres periodos identificables. La última columna lista los avances que se esperan para el futuro. Analizaremos esta tabla fila por fila.

 

MODELOS DE DATOS

Los modelos de red y jerárquicos surgieron en la década de 1960. Desde su introducción en 1970, el modelo relacional ha provocado un interés creciente debido a sus propiedades deseables, como son su base formal, su homogeneidad, su conjunto bien definido de operaciones algebraicas y sus lenguajes basados en el cálculo. Las desventajas del modelo relacional en términos de su poder expresivo semántico hicieron surgir el interés por los modelos semánticos. Este interés ha crecido desde finales de los años setenta, sobre todo con la aparición de los modelos de entidad - relación (ER), de jerarquía semántica y de datos semántico. El interés por los modelos semánticos continuó en los años ochenta. Hoy día, cuando los horizontes de las aplicaciones de bases de datos se encuentran en una clara fase de expansión.

Una de las principales tendencias en los próximos años será hacia los modelos de datos orientados a objetos (BDOO) y los sistemas de gestión de bases de datos orientadas a objetos (SGBDOO). Los modelos de datos BDOO poseen un poder de expresión similar al de los modelos semánticos, pero los rebasan en el sentido de que modelan explícitamente el comportamiento. Se asegura que son más fáciles de implementar y usar cuando se trata de crear aplicaciones, debido a la modularidad integrada, el encapsulamiento y la reutilización de código.

Se ha propuesto la lógica como modelo de datos fundamental para los esquemas de representación relacionales y de otro tipo. El cálculo relacional se basa en una rama de lógica denominada cálculo de predicados de primer orden, de modo que ya tiene tiempo que la lógica se utiliza para caracterizar consultas relacionales. La base de datos lógica ofrece un formalismo para los lenguajes de consulta, el modelado de integridad, a evaluación de consultas, el tratamiento de valores nulos, el manejo de información incompleta, etc. La lógica nos lleva también a un entendimiento formal de la deducción en las bases de datos. Es probable que en el futuro proliferen más los SGBD orientados a objetos, se utilice mas la lógica para las bases de datos deductivas y se combinen la representación de conocimientos, los lenguajes de programación y los modelos de datos.

Otra tendencia clara en la creación de SGBD comerciales es la de producir sistemas unificados con modelos de datos "híbridos". N ejemplo de ello es el sistema UniSQL que maneja un modelo de datos completo orientado a objetos que es totalmente compatible con el modelo relacional. Los proveedores de productos de SGBD convencionales ya han comenzado a implementar una interfaz relacional basada en SQL que permitirá la creación concurrente de aplicaciones relacionales.

  El modelo CODASYL DBTG.

   En el modelo DBTG solamente pueden emplearse enlaces uno a uno y uno a muchos. En este modelo existen dos elementos principales que son el dueño y el miembro, donde solo puede existir un dueño y varios miembros, donde cada miembro depende solamente de un dueño.

    Empleando el ejemplo de la relación Alumno-cursa-Materia.

  Si la relación es uno a muchos  sin atributos descriptivos, entonces el diagrama de estructura
      de datos apropiado es:

  Si la relación tiene un atributo descriptivo, como el de calif, entonces el diagrama de estructura de datos apropiado es:

  Si la relación fuera de muchos a muchos el algoritmo de transformación seria como el siguiente considerando que la relación no tiene atributos descriptivos, entonces:

1. Crear los registros correspondientes de las entidades involucradas (alumno,materia).
2. Crear un nuevo tipo de registro ficticio, renlace que puede no tener campos o tener sólo uno que contenga un   identificador único definido externamente.
3. Crear los enlaces correspondientes muchos a uno.

  En el caso de  las relaciones generales (es decir, no binarias), el algoritmo de transformación es el mismo  empleado para el estructurado de los diagramas de los modelos de red donde intervienen más de 2 entidades.
     Por ejemplo consideremos la agregación de la entidad   maestro, entonces  para este caso resulta la  estructura siguiente:

Conjuntos DBTG

    Como se mencionó anteriormente en este modelo solo pueden utilizarse enlaces muchos a uno y uno a uno, así una  forma general de este modelo sería:

    En el modelo DBTG, esta estructura de denomina conjunto DBTG. El nombre que se le asigna al conjunto generalmente es el mismo que el de la relación que une a las entidades.

    En todo conjunto DBTG de este tipo, el tipo de registro A se denomina dueño (o padre) del conjunto, el tipo de registro B se le denomina miembro (o hijo) del conjunto.Cada  conjunto DBTG puede tener cualquier numero de ocurrencias del conjunto. Puesto que no se permiten enlaces del tipo muchos a muchos, cada ocurrencia del conjunto tiene exclusivamente un dueño y cero o más registros miembros. Además ningún registro puede participar en más de una ocurrencia del conjunto en ningún momento. Sin embargo, un registro miembro puede participar simultáneamente en varias ocurrencias de diferentes conjuntos.

Podemos ejemplificar las ocurrencias que se pueden presentar, como:

Para ilustrarlo, considérese el diagrama de estructura siguiente:

Existen dos conjuntos DBTG:

   
AluCal, cuyo dueño es Alumno y cuyo miembro es reenlace.
   
  MatCal, cuyo dueño es Materia y el miembro reenlace.

Declaración de conjuntos

El  conjunto AluCal se define:          y el conjunto MatCal:

        Set name is AluCal                Set name is MatCal       
             owner is Alumno                      owner is Materia
             member is reenlace                  member is reenlace

Una instancia de la base de datos podría ser:

            

5.4 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.

    La mayor parte de los comandos de manejo de datos en DBTG de CODASYL tienen dos pasos. En primer lugar, se emite un comando FIND para identificar el registro sobre el cual se va a actuar. El comando FIND no lee, procesa el registro indicado;sólo identifica un registro para que lo localice el DBMS. Una vez identificado el registro, un segundo comando DML puede emitirse para que se lleve a cabo una operación sobre él. Patrones típicos son FIND, GET, o bien, FIND, MODIFY; o bien FIND, ERASE.

    Cuando el programa emite un comando FIND, se localiza un registro y su identidad permanece almacenada en una variable especial llamada indicador de posición. Después, cuando se emite un comando GET, MODIFY, ERASE o bien otro, el DBMS hace referencia al indicador de posición para determinar cuál es el registro sobre el que ha de actuar. Los indicadores de posición también se utilizan como puntos de referencia para los comandos del procesamiento secuencial como son FIND NEXT o FIND PRIOR.

Las operaciones utilizadas para la recuperación de datos son :

   
Find: Que localiza a un registro en la base de datos y da valores a los punteros de actualidad correspondientes
   
Get: Copia el registro al que apunta el actual de unidad de ejecución de la base de datos ala plantilla adecuada en el área de trabajo de programa.

La orden FIND tiene varias formas, en este caso estudiaremos 2 ordenes find diferentes para localizar los registro individuales de la base de datos; La orden más sencilla es de la forma:

    find any < tipo de registro > using < campo de registro >

    Esta orden localiza un registro del tipo <tipo registro> cuyo valor de < campo de registro> es el mismo que el del valor de <campo de registro> en la plantilla del <tipo de registro> en el área de trabajo del programa. Una vez que se encuentra ese registro se modifican los siguientes punteros para que apunten a ese registro:

     
El puntero actual de unidad de ejecución
     
El puntero de actualidad de tipo de registro que corresponde a <tipo de registro>

     
Para cada conjunto en el que participe ese registro, el puntero de actualidad de conjunto apropiado.

    Para ilustrar lo anterior, construyamos una consulta en DBTG que nos muestre el número de control del alumno Luis A. (consideremos el modelo alumno-materia ).
               
         Alumno.nombre:="Luis A.";
           find any Alumno using NombreA;
           get Alumno:
           print("Alumno.control");

    Pueden existir varios registros con el valor especificado. La orden find localiza el primero de ellos en un orden previamente especificado. Para localizar otros registros de la base de datos que pudieran tener el mismo campo <campo de registro, utilizamos la orden

            find duplicate <tipo de registro> using <campo de registro>


    Que localiza al siguiente registro (según un orden que depende del sistema) que tiene el valor de <campo registro>.ejemplo:

              Alumno.NombreA:="Luis A.";
                find any Alumno using NombreA;
                while DB-Status = 0 do
                   begin
                    get Alumno;
                    print (Alumno.control);
                    find duplicate Alumno using NombreA;
                  end;

    Se ha encerrado parte de la consulta en un ciclo while ya que no sabemos por adelantado cuántos nombres Luis A. pueden existir. Salimos del bucle cuando DB-Status<>0, esto indica que la última operación find duplicate falló, lo que implica que ya hemos agotado todos los registros con esos datos.

Actualización en DBTG.

Creación de nuevos registros.

   La orden para crear un nuevo registro es:

         Store <tipo de registro>

Esta técnica nos permite crear y añadir solamente un registro a la vez.  

Para ejemplificar consideremos el caso siguiente: 

    Deseamos registrar a un nuevo alumno de nombre "Delia J. Siordia", la instrucción para esto es: 

    Alumno.NombreA:="Delia J. Siordia";
    Alumno.control:="94310128";
    Alumno.Esp:="LAE";
    Store Alumno;

Modificación de un registro existente. 

    Para realizar la modificación a los registro primero se debe encontrar ese registro en la base de datos, pasarlo a la memoria principal y efectuar las modificaciones deseadas, posteriormente actualizamos el puntero de actualidad hacia el registro a modificar y ejecutamos la orden Modify.

   Modify <tipo de registro>

 Para que el sistema se entere que se va a realizar una modificación se emplea la orden for update.

     Ejemplo: Deseamos cambiar la Especialidad del alumno de nombre Delia J. Siordia, por LI.

   Alumno.NombreA:="Delia J. Siordia";
   find for update any Alumno using nombreA;
  

get Alumno.Esp :="LI";
   modify Alumno;

     Las líneas de código antes descritas, primero requieren del dato por el cual se realizará la búsqueda del registro, la orden find for update any establecen el tipo de registro que se usara, using indica el campo por el cual debe buscar la coincidencia para la modificación, get se antepone la línea de modificaciones que se realizaran sobre el registro y finalmente ya que el registro fue modificado se ejecuta la instrucción modify para activar las actualizaciones ejecutadas.

 Eliminación de registros.

     Para efectuar la eliminación de los registros es necesario tener el puntero de actualidad apuntando al registro que deseamos borrar, después se ejecuta al orden:

   erase <tipo de registro>

Esta instrucción al igual que la orden modify, requiere de la declaración de las instrucciones for update en la orden find.

 Ejemplo:Consideremos que deseamos eliminar el alumno cuyo número de control es 94310166 que pertenece al alumno Luis A.

   Fin:=false;
   Alumno.NombreA:="Luis A.";
    find any Alumno using NombreA;
    while DB-Status=0 and not fin do
    begin
        get Alumno;
        if Alumno.control=94310166 then
        begin
            erase Alumno;
          fin:=true;
        end
        else
            find for update next alumno with Alren1(*Registro reenlace*)
    end;

    Es posible eliminar toda una secuencia de conjunto encontrando al dueño del mismo, para ello se ejecuta la orden:

    erase all <tipo de registro>

    Esto borrara al dueño del conjunto y a todos sus miembros, si un miembro de un conjunto dueño de otro conjunto, también se eliminaran los miembros de ese conjunto, esta operación es recursiva.

 Ejemplo: Consideremos que deseamos borrar al Alumno de nombre Luis A. y todas sus registros de materias, entonces:

   Alumno.NombreA :="Luis A.";
    find for update any Alumno using NombreA;
    erase all Alumno;

Diagramas de estructura de datos.

    Un diagrama de estructura de datos es un esquema que representa el diseño de una base de datos de red. Este modelo se basa en representaciones entre registros por medio de ligas, existen relaciones en las que participan solo dos entidades(binarias ) y relaciones en las que participan más de dos entidades (generales) ya sea con o sin atributo descriptivo en la relación.

La forma de diagramado consta de dos componentes básicos:

   
Celdas: representan a los campos del registro.
   
Líneas: representan a los enlaces entre los registros. 

    Un diagrama de estructura de datos de red, especifica la estructura lógica global de la base de datos; su representación gráfica se basa en el acomodo de los campos de un  registro en un conjunto de celdas que se ligan con otro(s) registro(s), ejemplificaremos esto de la siguiente manera:

Consideremos  la relación alumno-cursa-materia donde la relación cursa no tiene atributos descriptivos :

Las estructuras de datos según la cardinalidad se representan en los siguientes casos:

Cuando el enlace no tiene atributos descriptivos

Caso 1. Cardinalidad Uno a Uno.

Caso 2. Cardinalidad Muchos a uno.

Caso 3. Cardinalidad Muchos a muchos.

Cuando el enlace tiene atributos descriptivos.

   Consideremos que a la relación cursa le agregamos el atributo Cal (calificación), nuestro modelo E-R quedaría de la siguiente manera:

 

    La forma de convertir a diagramas de estructura de datos consiste en realizar lo siguiente:

    1. Realizar la representación de los campos del registro agrupándolos
        en sus celdas correspondientes.
    2. Crear nuevo registro, denominado Calif, para este caso, con un
        solo campo, el de cal (calif).
    3. Crear los enlaces indicando la cardinalidad de :

       
AluCal, del registro Calif al registro Alumno.
       
MatCal, del registro Calif al registro Materia.

    AluCal y MatCal son solo los nombres que emplearemos para
identificar el enlace, pueden ser otros y no son empleados para
otra cosa.

Los diagramas de estructuras de datos según la cardinalidad
se transforman en:

Caso 1. Cardinalidad uno a uno.

Caso 2. Cardinalidad Uno a muchos.

Caso 3. Cardinalidad Muchos a muchos.

   

Diagramas de estructura de datos cuando intervienen
más de dos entidades y el enlace no tiene atributos descriptivos.

  

Consideremos que a la relación alumno-cursa-materia le agregamos la entidad maestro, quien es el que imparte dicha materia.

   

Nuestro diagrama E-R quedaría de la siguiente manera:

    La transformación a diagramas de estructura de datos se realiza mediante los siguientes pasos:

1.Crear los respectivos registros para cada una de las entidades que intervienen en el modelo.

2. Crear un nuevo tipo de registro que llamaremos Renlace, que puede no tener campos o tener solo uno que contenga un identificador único, el identificador lo proporcionará el sistema y no lo utiliza directamente el programa de  aplicación, a este registro se le denomina también como registro ficticio o de enlace o unión.
    Siguiendo los pasos anteriores nuestra estructura finalmente es: (Considerando una relación con cardinalidad Uno a Uno)

    Ahora si nuestro enlace tuviera atributos descriptivos, se crea el registro con los campos respectivos y se liga indicando el tipo de cardinalidad de que se trate.

    En este caso tomamos el ejemplo anterior con cardinalidad uno a uno y le agregamos a la relación el atributo calif. (calificación).

    Considerando el anterior diagrama de estructura de datos, una instancia de este seria:

La estructura quedaría:

    Este diagrama nos indica que los alumnos Luis A. Laura M. y Leticia L. cursaron la materia Base de datos 2 con La maestra Ing. Lourdes A. Campoy M obteniendo una calificación de 100,80,95 respectivamente.