Modelos de BD

Aunque no es una característica esencial del modelo, las bases de datos en red implementan sus relaciones mediante punteros directos al disco. Esto da una velocidad de recuperación excelente, pero penaliza las operaciones de carga y reorganización. 

Entre los SGBD más populares que tienen arquitectura en red se encuentran Total e IDMS. IDMS logró una importante base de usuarios; en 1980 adoptó el modelo relacional y SQL, manteniendo además sus herramientas y lenguajes originales. 

La mayoría de bases de datos orientadas a objetos (introducidas en 1990) usan el concepto de navegación para proporcionar acceso rápido entre objetos en una red. Objectivity/DB, por ejemplo, implementa 1:1, 1:N, N:1 y N:N entre distintas bases de datos. Muchas bases de datos orientadas a objetos también soportan SQL, combinando así la potencia de ambos modelos. 

Modelo de fichero invertido 

En un fichero invertido o de índice invertido, los datos contenidos se usan como claves en una tabla de consulta (lookup table), y los valores en la tabla se utilizan como punteros a la localización de cada instancia. Esta es también la estructura lógica de los índices de bases de datos modernas, los cuales introducen sólo el contenido de algunas columnas en esa tabla de consulta. El modelo de fichero invertido puede poner los índices en ficheros planos para acceder a sus registros de manera eficiente. 

Implementaciones notables de este modelo de datos la realizó Adabas de Software AG, aparecida en 1970. Adabas logró una importante base de usuarios y está soportada aún hoy. En la década de 1980 adoptó el modelo relacional y SQL, manteniendo sus propias herramientas y lenguajes. 

Modelo relacional 

Artículo principal: Modelo relacional 

 El modelo relacional fue introducido por E.F. Codd en 19701con el objetivo de querer hacer los SGBD más independientes de las aplicaciones. Es un modelo matemático definido en términos de lógica de predicados y teoría de conjuntos, y se han implementado con él SGBDs para mainframe, ordenadores medios y microordenadores. 

Los productos referidos como base de datos relacional de hecho implementan un modelo que es sólo una aproximación al modelo matemático definido por Codd. Existen tres términos usados con profusión en el modelo relacional de bases de datos: relaciones, atributos y dominios. Una relación equivale a una tabla con filas y columnas. Las columnas de una relación se llaman con rigor atributos, y el dominio es el conjunto de valores que cada atributo puede tomar. 

La estructura básica de datos del modelo relacional es la relación (tabla), donde la información acerca de una determinada entidad (p.e. "empleado") se almacena en tuplas (filas), cada una con un conjunto de atributos (columnas). Las columnas de cada tabla enumeran los distintos atributos de la entidad (el nombre del "empleado", dirección y número de teléfono, p.e.), de modo que cada tupla de la relación "empleado" representa un empleado específico guardando los datos de ese empleado concreto. 

Todas las relaciones (es decir, tablas) en una base de datos relacional han de seguir unas mínimas reglas: 

Una base de datos puede contener varias tablas, cada una similar al modelo plano. Una de las fortalezas del modelo relacional es que un valor de atributo coincidente en dos registros (filas) -en la misma o diferente tabla- implica una relación entre esos dos registros. Es posible también designar uno o un conjunto de atributos como "clave", que permitirá identificar de manera única una fila en una tabla. 

Dicha clave que permite identificar de manera unívoca una fila en una tabla se denomina "clave primaria". Las claves son habitualmente utilizadas para para combinar datos de dos o más tablas. Por ejemplo una tabla de empleados puede contener una columna denominada "departamento"", cuyo valor coincida con la clave de una tabla denominada "departamentos". Las claves son esenciales a la hora de crear índices, que facilitan la recuperación rápidas de datos de tablas grandes. Una clave puede estar formada por cualquier columna o por una combinación de varias columnas, denominándose clave compuesta. No es necesario definir todas las claves por adelantado; una columna puede usarse como clave incluso si no estaba previsto en origen. 

Una clave que tenga un significado en el mundo físico (tal como un nombre de persona, el ISBN de un libro o el número de serie de un coche) a veces se denomina clave "natural". Si no existe una clave natural viable, se puede asignar un sucedáneo arbitrario (como dar a una persona un número de empleado). En la práctica la mayor parte de las bases de datos tienen a la vez claves sucedáneas y naturales, dado que las claves sucedáneas pueden usarse internamente para crear enlaces íntegros entre filas, mientras que las claves naturales tienen un uso menos fiable a la hora de buscar o enlazar con otras bases de datos. 

El lenguaje de interrogación más común utilizado con las bases de datos relacionales es el Structured Query Language(SQL). 

Modelo Dimensional 

El modelo dimensional es una adaptación especializada del modelo relacional usada para almacenar datos en depósitos de datos, de modo que los datos fácilmente puedan ser extraídos usando consultas OLAP. En el modelo dimensional, una base de datos consiste en una sola tabla grande de datos que son descritos usando dimensiones y medidas. Una dimensión proporciona el contexto de un hecho (como quien participó, cuando y donde pasó, y su tipo). Las dimensiones se toman en cuenta en la formulación de las consultas para agrupar hechos que están relacionados. Las dimensiones tienden a ser discretas y son a menudo jerárquicas; por ejemplo, la ubicación podría incluir el edificio, el estado y el país. Una medida es una cantidad que describe el dato, tal como los ingresos. Es importante que las medidas puedan ser agregados significativamente -por ejemplo, los ingresos provenientes de diferentes lugares puedan sumarse. 

En una consulta (OLAP), las dimensiones y los hechos son agrupados y añadidos juntos para crear un informe. El modelo dimensional a menudo es puesto en práctica sobre el modelo relacional usando un esquema de estrella, consistiendo en una tabla que contiene los datos y tablas circundantes que contienen las dimensiones. Dimensiones complicadas podrían ser representadas usando múltiples tablas, usando un esquema de copo de nieve. 

Un almacén de datos (data warehouse) puede contener múltiples esquemas de estrella que comparten tablas de dimensión, permitiéndoles ser usadas juntas. El establecimiento de un conjunto de dimensiones estándar es una parte importante del modelado dimensional. 

Modelos post-relacionales 

Los productos que ofrecen un modelo de datos más general que el relacional se denominan a veces post-relational.2 Como términos alternativos se oyen incluyen "bases de datos híbridas", "bases de datos relacionales potenciadas con objectos" entre otros. El modelo de datos de esos productos incorpora relaciones pero no limitadas por las restricciones del principio de información de E.F. Codd, que requiere que toda información en la base de datos debe ser modelada en términos de valores en relaciones nada más 

Algunas de estas extensiones al modelo relacional integran conceptos de tecnologías que preceden el modelo relacional. Por ejemplo permiten representar un grafo dirigido con árboles en los nodos. La compañía sones implementa este concepto en su GraphDB. 

Algunos productos post-relacionales anplían los sistemas relacionales con caracteristicas no relacionales. Otros han llegado al mismo punto añadiendo características relaciones a modelos pre-relacionales. Paradójicamente esto ha permitido a productos históricamente pre-relacionales, como por ejemplo PICK y MUMPS, razonar su esencia post-relactional. 

El Resource Space Model es un modelo de datos no relacional basado en clasificación multi-dimensional. 

Modelo de grafo[editar] 

Las bases de datos de grafos permiten incluso una estructura más general que una base de datos en red, cualquier nodo puede estar conectado a cualquier otro. 

Modelo multivaluados 

Artículo principal: MultiValue 

Las bases de datos multivaluadas contienen datos arracimados, en el sentido de que pueden almacenar los datos del mismo modo que las bases de datos relacionales, pero además permiten un nivel de profundidad al que las relacionales sólo se pueden aproximar utilizando subtablas. Esto es prácticamente igual al modo en que XML representa los datos, donde un campo/atributo dado puede contener múltiples valores a la vez. El multivalor se puede considerar una forma de XML comprimida. 

Un ejemplo puede ser una factura, la que puede ser vista como: 

En el modelo multivaluado tenemos la opción de almacenar los datos como una sola tabla (1), con tablas imbuidas representando el detalle. 

Tiene la ventaja que la correspondencia entre la factura conceptual y la de la factura como representación de datos es biunívoca. Esto redunda en menor número de lecturas, menos problemas de integridad referencial y una fuerte disminución del hardware necesario para soportar un volumen de transacciones dado. 

Modelo orientado a objetos