II MODELOS DE DATOS

Antes de entrar a la descripción del modelo relacional, objetivo central de la

asignatura, debemos definir lo que es un modelo de dato en general.

La calidad del análisis y diseño de un sistema de información que

pretendemos mecanizar dependerá de los modelos de datos que utilicemos

para cada una de las fases de desarrollo. Además, disponer de herramientas

software basadas en modelos de datos adecuados a nuestra tarea nos hará

más fácil y rentable el diseño y el mantenimiento.

Podemos decir que, en líneas generales, el diseño de un sistema de

información, en lo que atañe a las bases de datos, tiene tres fases:

• Diseño conceptual: en la que se formalizan las estructuras que

se observan en el mundo real produciendo lo que se denomina

Esquema Conceptual.

• Diseño Lógico: en la que se estructura el conjunto de

información de la fase anterior teniendo en cuenta el SGBD que

se vaya a utilizar. En esta fase obtendremos el Esquema Lógico.

• Diseño Físico: en la que se estructuran los datos en términos de

almacenamiento en los dispositivos del ordenador. Es lo que se

conoce como Esquema Interno.

Para definir esas representaciones, es decir, los distintos esquemas,

utilizaremos uno o varios modelo de datos, un formalismo o un lenguaje que

nos permite representar una realidad con una mayor o menor riqueza de

detalle.

Podemos considerar que los Modelos de Datos se utilizan, entre otras

aplicaciones, para:

• Como herramienta de especificación, para definir tipos de datos y

la organización de los datos de una BD específica.

• Como soporte para el desarrollo de una metodología de diseño

de BD.

• Como formalismo para el desarrollo de familias de lenguaje de

muy alto nivel, para la resolución de requerimientos y

manipulación de datos.

• Como modelo soporte de la arquitectura de los SGBD.

• Como vehículo para investigar el comportamiento de diversas

alternativas en la organización de los datos.

En una primera aproximación, un modelo de datos es un conjunto de

conceptos y unas reglas de composición de esos conceptos que, combinados

de alguna forma, son capaces de representar un sistema de información,

tanto en su parte estática como dinámica.

Pero, hablando de bases de datos, ¿qué es antes: el modelo de datos o el

SGBD? En realidad, el concepto de modelo de datos es totalmente

independiente de las técnicas de BD. Es una herramienta que permite

describir un determinado concepto o sistema. Los SGBD se apoyan en un

determinado modelo de datos para poder estructurar la información a

almacenar y gestionarla rentablemente. Esto implica unas ciertas reglas que

el diseñador de la BD debe seguir para “informar” al SGBD de cómo se van a

introducir los datos y que límites, restricciones o evolución pueden o deben

tener esos datos.

No olvidemos, pues, que el modelo de datos es una “forma de hablar”, un

lenguaje de representación que podemos utilizar independientemente de que

se vaya a utilizar un ordenador o no, y que nos sirve para definir las

propiedades esenciales de un sistema de información y, al mismo tiempo,

poder comunicarnos con otras personas para explicarles esas propiedades.

El siguiente punto pretende ser el marco de partida para introducir los

modelos de datos, herramientas que se utilizan para describir, mejor o peor,

una realidad concreta. El concepto a desarrollar es el Sistema de información,

la realidad que queremos modelar y convertir (seguramente) en un sistema de

información mecanizado por ordenador.

II1. Sistemas de información

Uno de los pilares de cualquier organización es la información que necesita para su funcionamiento. Asimismo, el tratamiento de dicha información es una

de sus ocupaciones básicas. Podemos decir que la Organización dispone en

un primer momento de una cantidad de datos desordenados e inconexos

sobre el entorno en el que se desarrolla y la actividad o actividades a las que

se dedica. Es primordial, pues, ordenar e interrelacionar esos datos y obtener

conclusiones de ellos, es decir, obtener información elaborada que permita

tomar decisiones o conocer el estado de la Organización.

El tratamiento de la información (sea manual o electrónico) tiene como

objetivo proporcionar esa información elaborada, de tal forma que sea

correcta, se obtenga en el momento y lugar adecuado, para la persona

autorizada y con el mínimo coste.

Si un sistema es un conjunto de “cosas” que, ordenadamente relacionadas

entre sí, contribuyen a cumplir unos determinados objetivos, un sistema de

información es un conjunto de elementos (en este caso datos),

ordenadamente relacionados entre sí siguiendo unas ciertas reglas, que

aporta al sistema objeto (la organización a la que sirve y que le marca las

directrices de funcionamiento) la información necesaria para el cumplimiento

de sus fines, para lo cual tendrá que recoger, procesar y almacenar los datos,

facilitando la recuperación, elaboración y presentación de los mismos.

Dicho de otra forma, un sistema (y un sistema de información en particular) es

un conjunto de componentes conectados de forma organizada. Dependiendo

de cómo estén conectados el sistema se comporta o contribuye a sus fines de

una manera concreta; si cambiamos esas interrelaciones, su comportamiento

cambiará, al igual que si eliminamos o agregamos componentes.

Esos componentes del sistema de información, datos en nuestro caso, se

representarán mediante papeles que se archivan o cualquier otro tipo de almacén de información (¿una base de datos?). Así, si deseamos controlar el

inventario de un almacén, el sistema físico que queremos representar es el

local donde se almacenan y se retiran ciertas mercancías.

En realidad, el encargado podría pasarse todos los días por el lugar y

comprobar si se ve el suelo del almacén, y decidir entonces que es necesario

reponer existencias. Otra forma de organizar el almacén es construir un

sistema de información en el que las entradas y salidas no sean bienes

materiales sino notas de pedido, albaranes, etc., es decir, papeles que van de

un archivador a otro. Sería la representación mediante la circulación de

información del sistema físico almacén. En la Figura 2.1 podemos ver este

ejemplo del almacén visto desde el punto de vista físico y desde el punto de

vista del sistema de información.

Figura 2.1. Diferencias entre un sistema físico y un sistema de información.

Una decisión a posteriori sería la de mecanizar este sistema de información o

no. Es perfectamente posible que se dé el caso en el que la incorporación de

un ordenador no reporte ningún beneficio en cuanto a eficiencia y

rendimiento, e incluso que fuera perjudicial para una buena gestión.

Un sistema de información mecanizado (SIM) será aquel soportado por un

ordenador. Si nos circunscribimos a este supuesto, podemos particularizar los

componentes básicos de un sistema de información:

- contenido: los datos y su descripción.

- equipo físico: el ordenador soporte de la información.

- equipo lógico: sistema de gestión de bases de datos, sistema de

comunicaciones, etc.

- administrador: la persona o equipo de personas responsables de

asegurar la calidad y disponibilidad de los datos.

- usuarios.

Resumiendo, los SIM están compuestos de máquinas, programas que se

ejecutan en esas máquinas, un responsable o responsables de su buen

funcionamiento experto en temas de análisis, diseño e implementación de

sistemas informáticos y, por supuesto, los usuarios finales que son los que

indican cuales son las necesidades de la organización.

Los sistemas de información soportados por un ordenador han sufrido una

rápida evolución. Desde el punto de vista de su funcionalidad podemos hacer

una somera distinción de estos:

- SIM de procesos de transacción.

- SIM de ayuda a la toma de decisiones.

Los primeros tienen como objetivo el tratamiento de los datos necesarios para

llevar a cabo las tareas rutinarias de la organización: nóminas, contabilidad,

etc.; eran sistemas de información para la gestión.

Pero el desarrollo técnico en el campo de los ordenadores ha permitido exigir

cada vez más prestaciones a los sistemas de información, que pasan a

proporcionar una información más elaborada de ayuda a la toma de

decisiones: son los sistemas de información para la ayuda a la toma de

decisiones. Pensemos en una sistema de información de diseño asistido por

ordenador (CAD); la máquina será la encargada de simular el comportamiento

de un determinado objeto (el diseño de un avión, por ejemplo) en distintas

condiciones ambientales, información ésta que nos dará una base para

decidir si es factible su fabricación o si, por el contrario, no debemos seguir

adelante con el proyecto. Los almacenes de datos (más conocidos como Data

Warehouses y las aplicaciones OLAP constituyen hoy en día el núcleo de

estos sistemas de apoyo a la toma de decisiones). Estos sistemas son la

parte central de la asignatura optativa Bases de Datos Multidimensionales.

II1.1. Desarrollo de un sistema de información

mecanizado.

Para construir un sistema de información se parte de una definición de los

posibles usuarios, sus necesidades y las fuentes de información, pasando a

dar respuesta a un conjunto de temas entre los que destacan los relativos a la

organización de los datos, que determinan en gran medida el rendimiento,

flexibilidad y fiabilidad de todo el sistema. Así, cualquier sistema de

información pretende, por medio de una abstracción del mundo real,

representar con un conjunto de datos estructurado toda la información

necesaria para el cumplimiento de los objetivos de una organización, para lo

que se deben seguir distintas fases apoyadas en métodos y reglas.

En primer lugar, habrá que aislar la parcela del mundo real objeto de estudio,

identificando objetos con sus propiedades, las relaciones entre ellos, así

como su semántica asociada.

A continuación y por medio de un proceso de abstracción, intentaremos

obtener una imagen (representación) de esta parcela del mundo real. Es lo

que se llama modelado, proponer un esquema bajo un determinado sistema

de representación que simule el comportamiento de la parte de la realidad en

estudio. Obtendremos así las estructuras que alberguen nuestros datos y los

procesos (operaciones) que las han de afectar para obtener la información

elaborada final.

Por último, habrá que organizar el conjunto de información definido en la

etapa anterior para almacenarla en un soporte informático, lo que exige el

conocimiento de técnicas cada vez más sofisticadas entre las que se

encuentran las técnicas de bases de datos.

En definitiva, siguiendo el ciclo de vida clásico del software podemos

diferenciar tres fases a la hora de desarrollar un sistema de información, en

nuestro caso mecanizado, a saber:

- Análisis: investigación y modelado

- Diseño: lógico y físico

- Implementación: programas, carga de datos, pruebas.

En la fase de análisis se realizan labores de recogida de requerimientos, y se

obtiene un modelo no influido por un sistema mecanizado concreto (modelo

conceptual), que representa, lo más fielmente posible, el conjunto de datos en

estudio y las interrelaciones que hubiere entre ellos, así como los procesos

que los afectan. En definitiva vamos a describir, mediante un formalismo

adecuado, nuestro sistema físico.

En la etapa de diseño trasladamos las ideas obtenidas en la fase anterior a un

modelo comprensible por el ordenador, el diseño lógico y el físico, que

representan sucesivos acercamientos al nivel más bajo de detalles de

almacenamiento.

Con la implementación introducimos en la máquina el resultado del diseño y

los datos necesarios para la inmediata explotación de los mismos, tras las

correspondientes pruebas de fiabilidad y rendimiento. En la Figura 2.2.

podemos ver un resumen del proceso de diseño de una base de datos desde

el punto de vista del ciclo de vida de evolución del software.

Figura 2.2. Diseño de una base de datos desde el punto de vista del ciclo de

vida de evolución del software

II2. Conceptos y definiciones

Propiedades de un sistema de información

En un sistema de información encontraremos propiedades estáticas,

dinámicas y restricciones de integridad.

􀂃 Las propiedades estáticas se refieren a los datos en si, qué información

es la que se maneja en el sistema, qué valores puede contener el

sistema, y cómo dependen unos de otros. Son propiedades que no

varían en el tiempo.

􀂃 Las dinámicas hacen referencia a la evolución de esos datos en el

tiempo, a las operaciones que se les aplican, más concretamente

transacciones (secuencias indivisibles de operaciones simples).

􀂃 Las restricciones de integridad son reglas utilizadas para definir las

propiedades estáticas y dinámicas. Dicho de otro modo, es el

mecanismo por el que establecemos cuales son los valores válidos de

los objetos de nuestro sistema en cada instante.

La mayoría de ellas se podrán expresar adecuadamente con los conceptos

que maneja el modelo de datos. Al estructurar la información de una cierta

manera y al especificar las transacciones ejecutables estamos estableciendo

ya unas reglas que cumplirá el sistema. No obstante, hay propiedades

imposibles de expresar con los mecanismos anteriores que necesitan una

definición adicional mediante un formalismo de especificación de aserciones.

De una forma hasta cierto punto coloquial, habitualmente se habla de

restricciones de integridad refiriéndose únicamente a las segundas, ya que las

primeras no necesitan de esa especificación aparte.

Resumiendo, en el proceso de análisis y diseño de un sistema de información

obtendremos finalmente un conjunto estructurado de datos, un conjunto de

operaciones a realizar sobre ellos, y una serie de afirmaciones adicionales

sobre las combinaciones de valores que son posibles dentro de nuestro

sistema. Para reflejar todo ello necesitamos un formalismo, un “lenguaje” que

nos permita estructurar esa información y definir esas operaciones para

satisfacer las demandas de los usuarios finales. Este formalismo es el modelo

de datos.

Figura 2.3. Ejemplo del proceso de diseño de una base de datos

Modelo de datos

Definimos un modelo de datos como la herramienta intelectual que nos permite estructurar los datos de forma que se capte la semántica de los

mismos. Éste nos ofrecerá un conjunto de conceptos y reglas que nos

permitirán representar, con mayor o menor fidelidad, un conjunto de datos

interrelacionados y operaciones sobre los mismos, a los que afectan unas

restricciones que han de cumplir en todo momento. Cuanta más información

sobre los datos podamos representar dentro del mismo, más expresivo será

el modelo de datos (y por la tanto más deseable).

Esquema

La aplicación de un cierto modelo de datos a una realidad nos dará como

resultado un esquema, una representación de esa realidad que podrá ser de

tipo gráfico o lingüístico y que describirá un conjunto de objetos e

interrelaciones entre ellos, un conjunto de operaciones (combinaciones de

insertar, borrar, modificar y consultar) a aplicar sobre los primeros, y todas las

restricciones semánticas que afecten al sistema.

Lenguajes de definición y manipulación de datos

Para aplicar un modelo de datos deberíamos disponer de un lenguaje de

definición de datos (LDD) y de un lenguaje de manipulación de datos (LMD).

Con el LDD describiríamos las estructuras en las que se almacenarían los

datos, y con el LMD las transacciones a efectuar para obtener información

elaborada a partir de esos datos. Podemos decir, pues, que un modelo de

datos se compone de dos partes estrechamente relacionadas: las

estructuras de datos4, que representan las propiedades estáticas del

modelo, y la especificación de transacciones, que hace lo propio con las

dinámicas.

No todos los modelos tienen en cuenta los dos tipos de propiedades,

centrándose bien en uno o en otro. De hecho, los más implantados de forma

comercial se basan casi exclusivamente en la parte estática, seguramente por

ser la menos costosa de solucionar.

¿Quién es el encargado de proporcionar los lenguajes antes mencionados y

de gestionar los datos estructurados en función de un determinado modelo de

datos? El sistema de gestión de bases de datos es la herramienta software

que soporte a un modelo de datos o, dicho de otro modo, todo SGBD debe

tener un modelo de datos subyacente que permita describir los datos de una

forma concreta.

Disponemos, pues, de un conjunto de reglas, aplicables mediante el LDD,

para la generación de esquemas. El esquema de una base de datos,

resultado de la utilización del LDD, es la definición de las estructuras de

acuerdo a cada modelo. Se usa para representar las propiedades estáticas

según el modelo que se utilice. En algunos modelos se distinguen dos

subconjuntos de este conjunto de reglas: uno para la definición de estructuras

en sí, y otro para la definición de restricciones de integridad estáticas.

Los LMD pueden ser navegacionales o de especificación. Los primeros se

basan en la utilización interna de punteros, por lo que los operadores

seleccionan un único objeto por la posición lógica que ocupa, es decir, se

recupera la información partiendo del valor actual del puntero (del objeto al

que está apuntando). En otras palabras, debemos recorrer la estructura

desde el lugar en el que nos encontremos hasta llegar a la información que

precisamos.

Los LMD de especificación, sin embargo, recuperan los datos en función de

qué es lo que estamos buscando, indicando explícitamente qué datos

precisamos y qué condiciones han de cumplir, pero dejando al SGBD la tarea

de cómo obtiene esa información.

Sistema de Gestión de Bases de Datos

Un Sistema de Gestión de Bases de Datos (SGBD) es el software que

implementa las herramientas asociadas a un modelo de datos.

Estados de la BD

Diremos que para un esquema de BD existen muchas ocurrencias de base

de datos, cada una de las cuales tiene las mismas estructuras y obedece a

las mismas restricciones de integridad. La estructura de la base de datos es

siempre la misma o sufre alteraciones cada bastante tiempo pero las

operaciones de manipulación de datos son constantes y, por tanto, los datos

contenidos en la base de datos cambian continuamente. Tradicionalmente,

los términos ocurrencia del esquema y base de datos se suelen utilizar

indistintamente.

Un estado de la base de datos está definido en un instante de tiempo por la

descripción de la misma y la información almacenada; generalmente se

entiende que el resultado de una transacción o una simple operación atómica

(insertar, borrar, ...) generan un nuevo estado de la BD (se ha modificado, de

alguna forma, la BD con respecto al estado inmediatamente anterior).

Evidentemente, las operaciones que provocan la transición de un estado de

BD a otro nunca varían la estructura de la BD (el esquema).

II3. Representación de un sistema de

información

Resumiendo de forma intuitiva todo lo expuesto en las secciones anteriores,

todo modelo de datos utiliza los siguientes mecanismos de abstracción para

la construcción de las clases de objetos apropiadas:

− Clasificación: definir un concepto como una clase de objetos

− Agregación: definir una nueva clase de objetos a partir de otras clases

− Generalización: definir subtipos de una clase

Igualmente, para expresar las restricciones aplicables a las clases de objetos

en particular, y al sistema en general, sean de tipo estático o dinámico se

utilizan las:

− restricciones de dominio: definen el conjunto de valores (escalares o

complejos) agrupados en una clase de objetos.

− restricciones de identificación: no hay dos objetos dentro de una clase de

objetos iguales.

− restricciones de correspondencia entre clases: restricciones de

cardinalidad, de dependencia de identificador, de existencia y de cobertura

de las generalizaciones.

Características dinámicas del sistema del información: restricciones

dinámicas.

La parte dinámica de un sistema hace referencia a la variación del contenido

del sistema de información (o incluso su evolución como esquema) a través

del tiempo. Visto de una forma simplista, su comportamiento frente a

inserciones, borrados, modificaciones y consultas de los datos en él

almacenados.

Tal y como estudiaremos en el tema 3 dedicado al modelo relacional, éste es

en concreto, un modelo que como todos los denominados clásicos y algunos

de los semánticos, únicamente es capaz de representar la parte estática de

un sistema de información. Posteriores extensiones o nuevos modelos de

datos más potentes han incorporado herramientas para representar el

comportamiento en el tiempo de los datos, esto es, las restricciones

dinámicas del sistema.

Es evidente que siendo un tema importante este último, tradicionalmente se

ha dejado de lado por su dificultad de definición e implementación, y no va a

ser tratado en más profundidad en esta asignatura.

II4. Cualidades de los modelos de

datos

A la hora de evaluar un modelo de datos debemos fijarnos en los siguientes

puntos:

• Expresividad: cuantos más mecanismos o conceptos de

representación tenga un modelo mayor será la cantidad de propiedades

del sistema de información que pueda captar, y menor el uso de

aserciones en forma de restricciones de integridad que no se pueden

reflejar directamente sobre el esquema.

• Simplicidad: también es deseable que el modelo sea simple para que

los esquemas sean fáciles de entender por terceras personas. Debe

llegarse, pues, a un equilibrio entre la potencia del modelo mencionada

en el punto anterior y esa simplicidad deseable.

• Minimalidad: cada concepto tiene un significado distinto de los demás

conceptos utilizados en el modelo de datos; no se puede expresar un

concepto en función de otros.

• Formalidad: todos los conceptos del modelo tienen una interpretación

única, precisa y bien definida. Puesto que el esquema pretende ser una

especificación formal del sistema de información a representar, esta

cualidad permitiría el tratamiento matemático de sus conceptos.

Si el modelo utiliza un lenguaje de definición gráfico, también tendremos en

cuenta:

• Compleción gráfica: un modelo es gráficamente completo si todos sus

conceptos poseen representación gráfica.

• Facilidad de lectura: que los símbolos gráficos sean fácilmente

distinguibles unos de otros.

II5. Clasificación de modelos de datos

A medida que han ido evolucionando el software y el hardware, las

posibilidades y las demandas de los usuarios han ido creciendo;

paralelamente, los modelos de datos fueron enriqueciéndose y salvando

carencias de sus predecesores. Cronológicamente, podemos clasificarlos de

la siguiente forma:

- Primitivos: basados en sistemas de ficheros convencionales

- Clásicos

- Jerárquico (el más conocido, IMS: IBM)

- Red (CODASYL)

- Relacional (desarrollado por E. Codd)

- Semánticos5

- EER (Entidad-Relación Extendido: Chen)

- RM/T (Relational Model/Tasmania: Codd)

- Semántico General

- Orientado a Objetos

- Modelo Funcional

Se dice que tanto primitivos como clásicos están basados en registros,

mientras que los semánticos se apoyan en la filosofía Orientada a Objetos.

Los modelos de datos primitivos se usaron durante la década de los 70,

cuando aun no se utilizaban las técnicas de bases de datos. Los objetos se

representaban como registros organizados en ficheros, y las relaciones

mediante referencias explícitas a otros registros en algún campo del mismo.

Los lenguajes de manipulación dependen por entero de la organización física

de los datos, y las operaciones básicas son la lectura y la escritura.

Para garantizar, o al menos mejorar, la independencia de los aplicaciones

frente a los datos aparecen los primeros SGBD, basados en lo que ahora

llamamos modelos de datos clásicos. Los primeros en aparecer fueron el

jerárquico y el red de CODASYL, cuyos nombres muestran cual es la

estructura de datos subyacente en los modelos. Los objetos siguen siendo

representados por registros pero las relaciones entre objetos se expresan,

con ciertas limitaciones implícitas del modelo, mediante la estructura en que

se basan. Los lenguajes de manipulación de datos son navegacionales.

Sin embargo, y dentro todavía de esta generación, la aparición del Modelo

Relacional provocó la representación de los objetos como relaciones (tablas

en su denominación informal), cuyas tuplas (filas en su denominación

informal) identifican a ocurrencias del objeto patrón, y la vuelta a las

referencias explícitas (unos atributos que relacionan un objeto con un

segundo por comparación de valores iguales en uno y otro) para expresar las

interrelaciones. La estructura de datos más simple y la aparición de lenguajes

de especificación totalmente declarativos ha hecho de este modelo el más

ampliamente utilizado en los SGBD comerciales actuales.

Uno de los grandes problemas que plantean los SGBD comerciales actuales,

en general, es que no soportan modelos con la suficiente expresividad como

para dejar libre al diseñador de sistemas de información de molestas tareas

de administración de datos a bajo nivel. Es práctica habitual utilizar en la

confección del EC modelos de datos con un fuerte potencial semántico para

traducirlo después a modelos que si tienen un software comercial disponible,

pero muy probablemente más pobres semánticamente.

Por eso, la aparición de los modelos de datos semánticos está justificada por

la pretensión de aumentar la capacidad expresiva de los modelos clásicos

incorporando conceptos y mecanismos de abstracción no contemplados en

los anteriores. Se utilizan preferentemente para la confección del Esquema

Conceptual, y como modelo subyacente de algunos SGBD aun en

experimentación. Son los más potentes pero no tienen un reflejo comercial en

algún producto de amplia difusión; la representación del EC ha de traducirse a un Esquema Lógico, en general a un modelo clásico, para poder ser

explotado eficientemente en algún SGBD.

Así y todo, parece que el EER está teniendo alguna penetración sobre todo

en herramientas de análisis y diseño de Sistemas de Información, en forma de

módulo de ciertas herramientas CASE que se puede traducir de forma

automática al Modelo Relacional.

Otros modelos de datos, que denominaremos de propósito particular, se

desarrollaron sobre aplicaciones concretas: cartografía, CAD/CAM, hipertexto,

etc.