1

Modelo de datos, esquema e instancias

Los modelos datos son el principal instrumento para ofrecer cierto nivel de abstracción
de los datos, ocultando detalles de almacenamiento que la mayoría de los usuarios no
necesitan conocer.

Un modelo de base de datos es un conjunto de conceptos que pueden servir para

describir la estructura de una base de datos. En ocasiones se utiliza la palabra modelo
para denotar una descripción o esquema de una base de datos en particular, por ejemplo
“el modelo de datos de comercialización”.

Con estructura de una base de datos o diseño de una base de datos nos referimos a los
tipos de datos, las relaciones y restricciones que deben cumplirse para esos datos.

Categoría de los modelos de datos.

Una clasificación posible de los modelos de datos se realiza de acuerdo al nivel de
abstracción que ofrecen para describir la estructura de la base de datos. Existen en este
sentido tres categorías:

 Conceptuales.
 Lógicos.
 Físicos.

Los conceptuales disponen de conceptos muy cercanos a la forma en que la mayoría de

los usuarios percibe los datos, mientras que los físicos proporcionan conceptos que
describen los detalles de cómo se almacenan los datos en la computadora. Entre dos
extremos están los Lógicos, cuyos conceptos pueden ser entendidos por los usuarios
finales sin estar demasiado alejados de la forma en que los datos se organizan dentro de
la computadora.
 2

Un ejemplo conocido de modelo conceptual es el MER (Modelo Entidad Relación).

Los modelos lógicos, entre los que se encuentra el modelo relacional son los más
utilizados en los DBMS comerciales.

Esquema e instancias
En cualquier modelo de datos es importante distinguir entre la descripción de la base de
datos y la base de datos propiamente dicha. La descripción se conoce como esquema de
la base de datos (o metadatos). Este esquema se especifica durante el diseño, por lo que
también le llamaremos diseño de la base de datos.

En la mayoría de los modelos de datos se utilizan ciertas convenciones para representar

los esquemas en forma de diagramas.

En la siguiente figura se muestra un diagrama esquemático de la base de datos vista

anteriormente; el diagrama presenta la estructura de todos los tipos de registros, pero no
los ejemplares o instancias reales de los registros. A cada uno de los objetos del
esquema –como CLIENTES o PRODUCTOS- se llama elemento del esquema.

CLIENTES

CódCliente Nombre Dirección

PRODUCTOS

CódProd Descripción PrecioProd

FACTURAS

NúmFactura Fecha CódCliente Total

LINEAS_FACT

NúmFactura CódProd CantidadLlevada ImporteLínea

Los diagramas solo ilustran algunos aspectos del diseño, como los nombres de los tipos
de registros y de los elementos de información, y algunas clases de restricciones como
veremos más adelante.

Los datos reales de la base de datos pueden cambiar con mucha frecuencia; por ejemplo,
la base de datos de ejemplo cambiará cada vez que agreguemos un nuevo cliente. Los
datos que la base de datos contiene en un determinado momento se denominan estado
de la base de datos (o conjunto de instancias). En un estado dado de la base de datos,
cada elemento del esquema tiene su propio conjunto actual de instancias; por ejemplo,
el elemento CLIENTES contendrá como instancias el conjunto de entidades clientes
individuales (registros). Es posible construir muchos estados de la base de datos que
correspondan a un diseño determinado. Cada vez que insertamos o eliminamos un
 3

registro, o que modificamos el valor de un elemento de información, transformamos un

estado de la base de datos en otro.

Cuando definimos una nueva base de datos, solo especificamos su diseño al DBMS.

En ese momento, el estado correspondiente a la base de datos es el “estado vacío”, sin

datos. Cuando cargamos estos por primera vez, la base de datos pasa al “estado inicial”.
De ahí en adelante, cada vez que se aplique una operación de actualización a la base de
datos sean estados válidos, en el sentido de que satisfagan la estructura y las
restricciones especificadas en el diseño. El DBMS almacena el diseño en su catálogo, de
modo que el software pueda consultarlo siempre que lo necesite

Publicado 29th April 2011 por Diego Gonzalez