Tema 35 Boe 13 02 1996

1.-Introducción

En este tema se va a exponer la definición de datos desde el punto de vista de los sistemas gestores de bases de datos. Primero hablaré del concepto de definición de datos, veremos después los diferentes niveles de descripción tanto a nivel de SGBD como a nivel de modelado de datos, y expondremos los lenguajes de definición de cada uno de los modelos.

Hablaremos de los modelos relacionales, jerárquico, en red y orientado a objetos, aunque en la práctica didáctica es más adecuado centrarse únicamente en el modelo relacional ya que los modelos jerárquico y en red están en desuso y el orientado a objetos no ha sido implementado. Se puede utilizar, sin embargo, el concepto de modelo jerárquico para introducir conceptos de XML, y el modelo orientado a objetos como base para explicar los modelos de mapeo para la persistencia de objetos.

2.-Definición de datos

El objetivo de la definición de datos es especificar la estructura de una base de datos que soporte un modelo conceptual concreto. Esto se hace detallando una serie de componentes:

  • Los elementos que integran la base de datos
  • Su estructura
  • Las relaciones entre los elementos
  • Reglas de integridad
  • Controles de acceso
  • Características físicas
  • Vistas de los usuarios

Esta definición se puede realizar en base a un modelo de datos. Los principales modelos de datos en uso son:

2.1.-Modelo jerárquico

Compuesto por una serie de registros básicos (segmentos) que se relacionan con otros segmentos, formando una estructura de árbol. El conjunto de los árboles de diferentes tipos definidos en el sistema forma la base de datos:

35_1.png

2.2.-Modelo de red

Compuesto por una serie de registros de datos. Los registros se almacenan en ficheros, por tipos. Conjuntos o sets, que relacionan 1:1 o 1:N los registros.

2.3.-Modelo relacional

Formado por dos estructuras: tupla y relación. Las tuplas se relacionan en conjuntos llamados relaciones. Una tupla puede estar en una única relación. Las relaciones pueden representarse en forma de tabla, en la que cada fila representa una tupla:

Departamento Profesor
Matemáticas Antonio Pérez
Matemáticas Juan Marzal
Filosofía Michael Focault

Es el modelo más utilizado hoy en día, casi de forma única.

2.4.-Modelo de objetos

El modelo de objetos encapsula datos y objetos en una única unidad, llamada objeto, que se agrupan en clases. Un objeto puede contener enlaces a otros objetos o estar compuesto por ellos. En una base de datos puramente orientada a objetos, pueden accederse a través de un sistema gestor y almacenarse en disco directamente.

Una vez elegido el modelo, La definición de datos se realiza a diferentes niveles, que veremos a continuación.

3.-Niveles de descripción

Uno de los objetivos de un sistema de BD es evitar a los usuarios los detalles a cómo se almacenan los datos. Para ello, los administradores describen la estructura de esos datos en una serie de niveles, y desde dos puntos de vista: arquitectura de la base de datos, y modelado de datos. Se verán a continuación.

3.1.-Niveles de arquitectura

La arquitectura más estandarizada para la definición de niveles es la ANSI/X3/SPARC, que divide el SGBD en tres niveles:

Nivel interno

Nivel más bajo de abstracción. Se describe como se almacenarán físicamente los datos: tamaño de los bloques, posición de los registros, unidades físicas de almacenamiento, índices, técnicas de compresión…

Nivel conceptual

Siguiente nivel de abstracción. Se definen cuales son los datos reales que están almacenados (nombre, tamaño, tipo, etc.) así como las relaciones entre ellos (limitaciones de integridad, relaciones entre registros, etc.) En el nivel conceptual se incluyen todos los datos que contendrá el SGBD.

Nivel externo

Nivel de más alto nivel de abstracción: dado que no todos los usuarios tienen por qué preocuparse de toda la información almacenada, se define para cada uno un subesquema de la base de datos, llamado subesquema externo. Se trata de los datos vistos desde el punto de vista del usuario.

La ventaja de la división en niveles es que pueden realizarse cambios en un nivel sin afectar a otro (se podría ampliar el disco o utilizar almacenamiento en red sin afectar al esquema conceptual) Los cambios suelen ser transparentes de izquierda a derecha, más difícil de derecha a izquierda pues se pierde rendimiento.

3.2.-Niveles de análisis

Para poder definir los datos que va a almacenar un SGBD es necesario saber primero qué se tiene que almacenar. Es el objetivo del modelado de datos. También se realiza en niveles, pero de abstracción lógica, no de arquitectura de base de datos. Son los siguiente:

Nivel conceptual

No hay que confundir con el nivel conceptual de la arquitectura de BD. De lo que trata este nivel es de definir las reglas del sistema que se esta estudiando, así como los datos que se han de modelar para conseguir la funcionalidad requerida. Se utilizan herramientas como el esquema Entidad / Relación, que no hace mención a un modelo concreto.

Nivel lógico

Se trata de expresar las reglas del modelo conceptual utilizando herramientas concretas que se ajustan a uno de los modelos de bases de datos estudiados: por ejemplo, modelo lógico relacional si se ha elegido un SGBD relacional

Nivel físico

Es en este nivel donde se definirían los datos según los tres niveles de arquitectura de una SGBD concreta. Se adaptaría el modelo lógico a las características del sistema que lo va a soportar.

4.-Lenguajes

Dado que existen diferentes niveles de definición para los datos, tanto desde el punto de vista físico como del estructural, se necesitan diferentes lenguajes para especificar los datos desde cada uno de los niveles.

Desde el punto de vista estructural la división debería ser:

  • Nivel Interno y conceptual: Todos los SGBD deben poseer, por necesidad, un lenguaje para la definición física de los datos. El problema es que no existe una separación entre el nivel interno y el nivel conceptual: el administrador de los datos especifica En SGBD relacionales, SQL tiene un subconjunto de instrucciones para ello. En
  • Nivel externo: El nivel externo si que tiene un lenguaje específico: BCP (Bloque de especificación de programa) en el sistema jerárquico, subesquemas en el modelo en Red, definición de vistas y tablespaces en SQL.

Desde el punto de vista conceptual, los lenguajes que se utilizan son:

  • Nivel conceptual: Se especifica mediante el modelo entidad-relación
  • Nivel lógico: Aquí, existe una separación clara en el caso de sistemas relacionales, para el que existe el esquema lógico relacional, el diagrama de estructura de datos para el modelo en red, y el diagrama de Bachman para el modelo jer

árquico:

Un diagrama de estructura de datos tiene la siguiente forma:

Un diagrama de Bachman es el que hemos utilizado para representar el ejemplo de sistema jerárquico (también puede utilizarse para el sistema en red):

  • Nivel físico: cada modelo tiene un lenguaje propio: SQL para relacionales, NDL para red, etc…

Veamos una pincelada de cómo se realiza la definición de datos en los diferentes sistemas:

4.1.-SQL

El lenguaje de definición de datos se ve con detalle en el tema 39, de manera que sólo veremos aquí como se definen sus elementos principales a un nivel superficial.

Elementos que la integran y estructura

Los elementos que integran una BD relacional son tuplas y relaciones. En SQL se denominan tablas: en una tabla se define la relación y los campos de las tuplas que la componen. Se realiza mediante:

CREATE TABLE NombreRelación (definicion CampoTupla1, definicion CampoTupla2)

Reglas de integridad y relaciones entre los elementos

Para la integridad y definición de relaciones se dispone de las siguientes herramientas: claves ajenas, claves primarias, y disparadores. Las claves ajenas y primarias se incluyen como definición de las tablas:

PRIMARY KEY Campos
FOREIGN KEY NombreClave REFERENCE Tabla

La definición de disparadores es compleja y no va a tratarse aquí. Básicamente, consiste en la verificación de una serie de condiciones o ejecución de ciertas acciones en respuesta a eventos de la base de datos. Para definir los disparadores se utiliza el lenguaje de manipulación de datos o DML.

Controles de acceso

SQL posee un sublenguaje específico para controlar el acceso: DCL. Permite asignar uno o varios permisos (inserción, borrado,modificación) a ciertos recursos (tablas, columnas..). Su sintaxis básica es:

GRANT Permiso ON recurso TO usuarios [WHITH GRANT OPTION]

Vistas de los usuarios

Las posibilidades de definición de esquemas externos en SGBDR es muy limitada. Su herramienta principal son las vistas, que sólo se pueden utlizar para consultar datos y manipular en casos muy restringidos. Se crean de la siguiente forma:

CREATE VIEW nombreVista AS ConsultaSelección

Algunos SGBD permiten la creación de TABLESPACES o espacios de usuario para la definición de esquemas externos.

4.2.-Jerárquico

El sistema jerárquico se ve con detalle en el tema 37, de modo que lo mencionaremos de forma superficial:

Los elementos de un sistema jerárquico son los segmentos, correspondientes a una tupla del modelo relacional, y los árboles, que definen la relación entre segmentos. Se definen de forma conjunta, en la definición de los árboles. Por ejemplo, la definición del ejemplo anterior sería esta:

DBNAME = GestionColegios
SEG NAME = Colegio, BYTES=58
    FIELD NAME=Codigo,BYTES 8, START 1
    FIELD NAME=Nombre,BYTES 50, START 
SEG NAME = Departamento, PARENT=Colegio, BYTES 50
    FIELD NAME=Nombre, BYTES 50, START 1
SEG NAME = Profesor, PARENT=Departamento, BYTES 50
    FIELD NAME=Nombre, BYTES 50, START 1
SEG NAME = Alumno, PARENT=Colegio, BYTES 50
    FIELD NAME=Nombre, BYTES 50, START 1

Los controles de acceso se realizan autorizando o denegando a los usuarios el acceso a árboles concretos.

4.3-XSD

XSD es el lenguaje de definición de datos de XML. XML es un sistema jerárquico, y aunque no está soportado por un SGBD (no es su propósito) si se utiliza ampliamente hoy en día, sobre todo en el intercambio de datos entre aplicaciones.

XSD permite definir estructuras complejas de datos utilizando XML. Es muy complejo, de modo que sólo veremos un ejemplo:

<xs:schema> 
    <xs:element name="Colegio"> 
        <xs:complexType> 
            <xs:sequence> 
                <xs:element name="Departamento" minOccurs="0" maxOccurs="unbounded"> 
                    <xs:complexType> 
                        <xs:all minOccurs="0"> 
                            <xs:element name="Profesor"> 
                                <xs:complexType> 
                                    <xs:attribute name="Nombre"/> 
                                </xs:complexType> 
                            </xs:element> 
                        </xs:all> 
                        <xs:attribute name="Nombre"/> 
                    </xs:complexType> 
                </xs:element> 
                <xs:element name="Alumno" minOccurs="0" maxOccurs="unbounded"> 
                    <xs:complexType> 
                        <xs:attribute name="Nombre"/> 
                    </xs:complexType> 
                </xs:element> 
            </xs:sequence> 
            <xs:attribute name="Codigo"/> 
            <xs:attribute name="Nombre"/> 
        </xs:complexType> 
    </xs:element> 
</xs:schema>

4.4.-Red

El sistema en Red se ve con detalle en el tema 37, así que sólo veremos por encima. Su lenguaje de definición de datos es el NDL (Network database Languaje) definido por ANSI. Los elementos del sistema en Red son el registro (similar a la tupla SQL), el fichero (conjunto de registros) y el Set (que relaciona registros).

En el ejemplo anterior, la forma de definirlo sería (se ha simplificado para que sea más legible):

SCHEMA Name=GestionColegios
RECORD NAME is Colegio; 
    DUPLICATES NOT ALLOWED FOR codigo IN Colegio.
    codigo TYPE IS CHARACTER 8;
    nombre TYPE IS CHARACTER 50.
RECORD NAME IS Departamento;
    nombre TYPE IS CHARACTER 50.
RECORD NAME IS Profesor
    nombre TYPE IS CHARACTER 50.
RECODR NAME IS Alumno;
    nombre TYPE IS CHARACTER 50.

SET NAME IS Colegio_Departamento;
    OWNER IS Colegio
    MEMBER IS Departamento
SET NAME IS Colegio_Alumno;
    OWNER IS Colegio
    MEMBER IS Alumno
SET NAME is Departamento_Profesor;
    OWNER IS Departamento
    MEMBER IS Profesor

4.5.-Mapeos objeto-relacionales

Las bases de datos orientadas a objetos no son de uso común: en su lugar, se utilizan capas de persistencia que realizan un mapeo de las definiciones de objetos para ser almacenadas en un modelo relacional. Los mapeos objeto-relacionales no son un modelo en sí, sino que se trata de técnicas para representar un modelo de objetos en un modelo relacional.

Los frameworks de persistencia más conocidos son:

Hibernate: Define, para cada tabla, en qué columnas se almacenará cada una de las propiedades del objeto. Incluye métodos propios para no acceder directamente a la base de datos.

iBatis: propuesto por Apache. Para cada clase a almacenar se define un mapeo mediante XML, donde se define cómo se realizarán las operaciones básicas para cada tipo de objeto (get, find, update..)

Algunos entornos n-tier, como Enterprise Java Beans o Rails, utilizan sus propios modelos de persistencia específicos sobre BD relacionales (como activeRecord en caso de Rails).

5.-Diccionario de datos

Para una base de datos existirá: un esquema interno, un esquema lógico y varios esquemas externos. Es el DBA quien define estos esquemas, y para ello, necesita una herramienta para almacenarlos y manejarlos. Esta herramienta es el diccionario de datos, y contiene

  • Descripción interna, conceptual y externas
  • Descripción de campos, registros y relaciones
  • Información de seguridad e integridad

Para los esquemas relacionales existen herramientas específicas. Sin embargo, en los sistemas relacionales el diccionario de datos es gestionado por el propio SGBD, almacenando la información como una serie de relaciones con las mismas características que el resto. La ventaja de este enfoque es que se puede consultar y manipular utilizando los mismos lenguajes que se utilizan para los datos, en este caso, SQL.

En su día se intentó definir un estándar de diccionario de datos relacional, pero debido a la variabilidad de los sistemas comerciales y a las presiones del mercado, cada fabricante implementa la propia versión

El diccionario de datos es uno de los elementos clave de gestión de un administrador. Debermos darle una especial relevancia a la hora de impartir módulos con contenidos de administración de BD: un dominio profundo del diccionario de datos implica que se conocen y se saben manejar las características de implementación de un sistema.

No debemos confundir el concepto de diccionario de datos de un SGBD con el concepto de diccionario de datos del proceso de análisis estructurado: el primero pertenece al dominio específico de la informática y de una implementación concreta, mientras que el segundo es la descripción conceptual de los datos del sistema a modelar.

6.-Conclusiones

A pesar de que en este tema se ha visto la definición de datos para diferentes modelos, en la práctica el modelo predominante, y casi único, es el modelo relacional. Sin embargo es interesante conocer el modelo jerárquico y en red ya que nos proporciona perspectiva sobre la evolución de los sistemas gestores de bases de datos, y a partir de ellos se entienden mejor las ventajas y la necesidad de un modelo como el relacional.

En la práctica, se pueden utilizar estos dos modelos para iniciar el estudio de los sistemas de bases de datos, ya que son conceptualmente más directos y los alumnos entienden mejor a partir de ellos la estructuración de la información.

En cuanto a los diferentes niveles de definición, aunque en la práctica no existe una separación clara, también es importante estudiarla: los alumnos, cuando tengan que administrar SGBD, deben saber distinguir entre lo que el usuario tiene que ver (esquema externo), lo que debe haber en la base de datos (esquema conceptual) y cómo se debe implementar para optimizar su rendimiento (esquema físico), aunque luego lo haga utilizando un mismo lenguaje y unas mismas herramientas.
Por último, y aunque aquí no se le ha tratado con mayor profundidad por cuestiones de tiempo, las capas de persistencia de objetos están tomando una relevancia extraordinaria: muchos frameworks de desarrollo, sobre todo los basados en MVC (Modelo-Controlador-Vista) los incorporan de forma nativa como parte de la gestión de modelos: deberían estudiarse, ya que los alumnos van a encontrarse con ellos cuando accedan al mercado laboral.

7.-Bibliografía

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License