Un modelo de base de datos es un tipo de modelo de datos que determina la estructura lógica de una base de datos . Determina fundamentalmente de qué manera se pueden almacenar, organizar y manipular los datos . El ejemplo más popular de un modelo de base de datos es el modelo relacional , que utiliza un formato basado en tablas.
Los modelos de datos lógicos comunes para bases de datos incluyen:
Una base de datos relacional de objetos combina las dos estructuras relacionadas.
Los modelos de datos físicos incluyen:
Otros modelos incluyen:
Un sistema de gestión de bases de datos determinado puede proporcionar uno o más modelos. La estructura óptima depende de la organización natural de los datos de la aplicación y de los requisitos de la misma, que incluyen la tasa de transacciones (velocidad), la fiabilidad, la capacidad de mantenimiento, la escalabilidad y el coste. La mayoría de los sistemas de gestión de bases de datos se basan en un modelo de datos concreto, aunque es posible que los productos ofrezcan compatibilidad con más de un modelo.
Varios modelos de datos físicos pueden implementar cualquier modelo lógico. La mayoría del software de bases de datos ofrecerá al usuario cierto nivel de control para ajustar la implementación física, ya que las decisiones que se toman tienen un efecto significativo en el rendimiento.
Un modelo no es solo una forma de estructurar datos: también define un conjunto de operaciones que se pueden realizar sobre los datos. [1] El modelo relacional, por ejemplo, define operaciones como select , project y join . Aunque estas operaciones pueden no ser explícitas en un lenguaje de consulta en particular , proporcionan la base sobre la que se construye un lenguaje de consulta.
El modelo plano (o de tabla) consiste en una matriz bidimensional única de elementos de datos , donde se supone que todos los miembros de una columna dada son valores similares y se supone que todos los miembros de una fila están relacionados entre sí. Por ejemplo, las columnas para el nombre y la contraseña que podrían usarse como parte de una base de datos de seguridad del sistema. Cada fila tendría la contraseña específica asociada con un usuario individual. Las columnas de la tabla a menudo tienen un tipo asociado con ellas, que las define como datos de caracteres, información de fecha u hora, números enteros o números de punto flotante. Este formato tabular es un precursor del modelo relacional.
Estos modelos fueron populares en las décadas de 1960 y 1970, pero hoy en día se pueden encontrar principalmente en sistemas antiguos . Se caracterizan principalmente por ser navegables con fuertes conexiones entre sus representaciones lógicas y físicas, y deficiencias en la independencia de los datos .
En un modelo jerárquico , los datos se organizan en una estructura similar a un árbol , lo que implica un solo padre para cada registro. Un campo de ordenación mantiene los registros hermanos en un orden particular. Las estructuras jerárquicas se utilizaron ampliamente en los primeros sistemas de gestión de bases de datos mainframe, como el Sistema de gestión de información (IMS) de IBM , y ahora describen la estructura de los documentos XML . Esta estructura permite una relación de uno a muchos entre dos tipos de datos. Esta estructura es muy eficiente para describir muchas relaciones en el mundo real; recetas, tabla de contenidos, ordenación de párrafos/versos, cualquier información anidada y ordenada.
Esta jerarquía se utiliza como orden físico de los registros en el almacenamiento. El acceso a los registros se realiza navegando hacia abajo a través de la estructura de datos utilizando punteros combinados con acceso secuencial. Debido a esto, la estructura jerárquica es ineficiente para ciertas operaciones de base de datos cuando no se incluye una ruta completa (a diferencia de un enlace ascendente y un campo de ordenación) para cada registro. Estas limitaciones se han compensado en versiones posteriores de IMS mediante jerarquías lógicas adicionales impuestas a la jerarquía física base.
El modelo de red amplía la estructura jerárquica y permite relaciones de muchos a muchos en una estructura similar a un árbol que admite varios padres. Era el modelo más popular antes de ser reemplazado por el modelo relacional y está definido por la especificación CODASYL .
El modelo de red organiza los datos utilizando dos conceptos fundamentales, llamados registros y conjuntos . Los registros contienen campos (que pueden estar organizados jerárquicamente, como en el lenguaje de programación COBOL ). Los conjuntos (que no deben confundirse con los conjuntos matemáticos) definen relaciones de uno a muchos entre registros: un propietario, muchos miembros. Un registro puede ser propietario en cualquier número de conjuntos y miembro en cualquier número de conjuntos.
Un conjunto consta de listas enlazadas circulares en las que un tipo de registro, el propietario o padre del conjunto, aparece una vez en cada círculo, y un segundo tipo de registro, el subordinado o hijo, puede aparecer varias veces en cada círculo. De esta manera, se puede establecer una jerarquía entre dos tipos de registro cualesquiera, por ejemplo, el tipo A es el propietario de B. Al mismo tiempo, se puede definir otro conjunto en el que B es el propietario de A. De este modo, todos los conjuntos comprenden un gráfico dirigido general (la propiedad define una dirección) o una construcción de red . El acceso a los registros es secuencial (normalmente en cada tipo de registro) o mediante navegación en las listas enlazadas circulares.
El modelo de red es capaz de representar la redundancia en los datos de manera más eficiente que el modelo jerárquico, y puede haber más de una ruta desde un nodo antecesor a un descendiente. Las operaciones del modelo de red son de estilo de navegación: un programa mantiene una posición actual y navega de un registro a otro siguiendo las relaciones en las que participa el registro. Los registros también se pueden ubicar proporcionando valores clave.
Aunque no es una característica esencial del modelo, las bases de datos en red generalmente implementan las relaciones de conjuntos mediante punteros que apuntan directamente a la ubicación de un registro en el disco. Esto brinda un excelente rendimiento de recuperación, a expensas de operaciones como la carga y la reorganización de la base de datos.
Los productos DBMS más populares que lo utilizaban eran Total de Cincom Systems e IDMS de Cullinet . IDMS ganó una base de clientes considerable; en la década de 1980, adoptó el modelo relacional y SQL además de sus herramientas y lenguajes originales.
La mayoría de las bases de datos de objetos (inventadas en la década de 1990) utilizan el concepto de navegación para proporcionar una navegación rápida a través de redes de objetos, generalmente utilizando identificadores de objetos como punteros "inteligentes" a objetos relacionados. Objectivity/DB , por ejemplo, implementa relaciones nombradas de uno a uno, de uno a muchos, de muchos a uno y de muchos a muchos que pueden cruzar bases de datos. Muchas bases de datos de objetos también admiten SQL , lo que combina las fortalezas de ambos modelos.
En un archivo invertido o índice invertido , el contenido de los datos se utiliza como claves en una tabla de búsqueda, y los valores de la tabla son punteros a la ubicación de cada instancia de un elemento de contenido determinado. Esta es también la estructura lógica de los índices de bases de datos contemporáneos , que podrían utilizar únicamente el contenido de una columna particular en la tabla de búsqueda. El modelo de datos de archivo invertido puede colocar índices en un conjunto de archivos junto a archivos de base de datos planos existentes, para acceder de manera eficiente y directa a los registros necesarios en estos archivos.
El sistema de gestión de bases de datos ADABAS de Software AG , introducido en 1970, es un modelo de datos que ha utilizado con éxito. ADABAS ha conseguido una base de clientes considerable y sigue existiendo y recibiendo asistencia técnica hasta el día de hoy. En la década de 1980, además de sus herramientas y lenguajes originales, adoptó el modelo relacional y SQL.
La base de datos orientada a documentos Clusterpoint utiliza un modelo de indexación invertida para proporcionar una búsqueda rápida de texto completo para objetos de datos XML o JSON , por ejemplo.
El modelo relacional fue introducido por EF Codd en 1970 [2] como una forma de hacer que los sistemas de gestión de bases de datos fueran más independientes de cualquier aplicación en particular. Es un modelo matemático definido en términos de lógica de predicados y teoría de conjuntos , y sus implementaciones han sido utilizadas por sistemas mainframe, de rango medio y de microcomputadoras.
Los productos que generalmente se denominan bases de datos relacionales implementan de hecho un modelo que es solo una aproximación al modelo matemático definido por Codd. En los modelos de bases de datos relacionales se utilizan ampliamente tres términos clave: relaciones , atributos y dominios . Una relación es una tabla con columnas y filas. Las columnas con nombre de la relación se denominan atributos y el dominio es el conjunto de valores que pueden tomar los atributos.
La estructura de datos básica del modelo relacional es la tabla, donde la información sobre una entidad en particular (por ejemplo, un empleado) se representa en filas (también llamadas tuplas ) y columnas. Por lo tanto, la " relación " en "base de datos relacional" se refiere a las distintas tablas de la base de datos; una relación es un conjunto de tuplas. Las columnas enumeran los distintos atributos de la entidad (el nombre, la dirección o el número de teléfono del empleado, por ejemplo), y una fila es una instancia real de la entidad (un empleado específico) que está representada por la relación. Como resultado, cada tupla de la tabla de empleados representa varios atributos de un solo empleado.
Todas las relaciones (y, por lo tanto, las tablas) de una base de datos relacional deben cumplir algunas reglas básicas para ser consideradas relaciones. En primer lugar, el orden de las columnas es irrelevante en una tabla. En segundo lugar, no puede haber tuplas o filas idénticas en una tabla. Y, en tercer lugar, cada tupla contendrá un único valor para cada uno de sus atributos.
Una base de datos relacional contiene varias tablas, cada una similar a la del modelo de base de datos "plana". Una de las ventajas del modelo relacional es que, en principio, cualquier valor que aparezca en dos registros diferentes (que pertenezcan a la misma tabla o a tablas diferentes) implica una relación entre esos dos registros. Sin embargo, para aplicar restricciones de integridad explícitas , las relaciones entre registros de las tablas también se pueden definir explícitamente, identificando o no las relaciones padre-hijo caracterizadas por la asignación de cardinalidad (1:1, (0)1:M, M:M). Las tablas también pueden tener un atributo único designado o un conjunto de atributos que pueden actuar como una "clave", que se puede utilizar para identificar de forma única cada tupla de la tabla.
Una clave que se puede utilizar para identificar de forma única una fila de una tabla se denomina clave principal. Las claves se utilizan habitualmente para unir o combinar datos de dos o más tablas. Por ejemplo, una tabla Employee puede contener una columna denominada Location que contiene un valor que coincide con la clave de una tabla Location . Las claves también son fundamentales en la creación de índices, que facilitan la recuperación rápida de datos de tablas grandes. Cualquier columna puede ser una clave, o se pueden agrupar varias columnas en una clave compuesta. No es necesario definir todas las claves de antemano; una columna se puede utilizar como clave incluso si no se pretendía originalmente que lo fuera.
Una clave que tiene un significado externo y real (como el nombre de una persona, el ISBN de un libro o el número de serie de un automóvil) a veces se denomina clave "natural". Si no hay una clave natural adecuada (pensemos en las muchas personas que se llaman Brown ), se puede asignar una clave arbitraria o sustituta (por ejemplo, dando a los empleados números de identificación). En la práctica, la mayoría de las bases de datos tienen claves generadas y naturales, porque las claves generadas se pueden usar internamente para crear vínculos entre filas que no se pueden romper, mientras que las claves naturales se pueden usar, de manera menos confiable, para búsquedas y para la integración con otras bases de datos. (Por ejemplo, los registros en dos bases de datos desarrolladas independientemente podrían coincidir por número de seguro social , excepto cuando los números de seguro social sean incorrectos, falten o hayan cambiado).
El lenguaje de consulta más común utilizado con el modelo relacional es el lenguaje de consulta estructurado ( SQL ).
El modelo dimensional es una adaptación especializada del modelo relacional que se utiliza para representar datos en almacenes de datos de forma que estos puedan resumirse fácilmente mediante el procesamiento analítico en línea o consultas OLAP . En el modelo dimensional, un esquema de base de datos consta de una única tabla grande de hechos que se describen mediante dimensiones y medidas. Una dimensión proporciona el contexto de un hecho (como quién participó, cuándo y dónde sucedió y su tipo) y se utiliza en consultas para agrupar hechos relacionados. Las dimensiones tienden a ser discretas y, a menudo, jerárquicas; por ejemplo, la ubicación puede incluir el edificio, el estado y el país. Una medida es una cantidad que describe el hecho, como los ingresos. Es importante que las medidas se puedan agregar de forma significativa; por ejemplo, se pueden sumar los ingresos de diferentes ubicaciones.
En una consulta OLAP, se eligen las dimensiones y los hechos se agrupan y agregan para crear un resumen.
El modelo dimensional suele implementarse sobre el modelo relacional mediante un esquema en estrella , que consta de una tabla altamente normalizada que contiene los hechos y tablas desnormalizadas circundantes que contienen cada dimensión. Una implementación física alternativa, denominada esquema de copo de nieve , normaliza jerarquías de varios niveles dentro de una dimensión en varias tablas.
Un almacén de datos puede contener varios esquemas dimensionales que comparten tablas de dimensiones, lo que permite utilizarlos en conjunto. Crear un conjunto estándar de dimensiones es una parte importante del modelado dimensional .
Su alto rendimiento ha convertido al modelo dimensional en la estructura de base de datos más popular para OLAP.
Los productos que ofrecen un modelo de datos más general que el modelo relacional a veces se clasifican como posrelacionales . [3] Otros términos incluyen "base de datos híbrida", "RDBMS mejorado por objetos" y otros. El modelo de datos en dichos productos incorpora relaciones pero no está limitado por el Principio de información de EF Codd , que requiere que
Toda la información en la base de datos debe expresarse explícitamente en términos de valores en relaciones y de ninguna otra manera.
— [4]
Algunas de estas extensiones del modelo relacional integran conceptos de tecnologías anteriores al modelo relacional. Por ejemplo, permiten la representación de un grafo dirigido con árboles en los nodos. La empresa alemana sones implementa este concepto en su GraphDB .
Algunos productos posrelacionales amplían los sistemas relacionales con características no relacionales. Otros llegaron a la misma situación al agregar características relacionales a los sistemas prerelacionales. Paradójicamente, esto permite que productos que históricamente son prerelacionales, como PICK y MUMPS , puedan afirmar de manera plausible que son posrelacionales.
El modelo de espacio de recursos (MSR) es un modelo de datos no relacional basado en una clasificación multidimensional. [5]
Las bases de datos gráficas permiten una estructura aún más general que una base de datos de red; cualquier nodo puede estar conectado a cualquier otro nodo.
Las bases de datos multivalor son datos "gruesos", en el sentido de que se pueden almacenar exactamente de la misma manera que las bases de datos relacionales, pero también permiten un nivel de profundidad al que el modelo relacional solo puede aproximarse utilizando subtablas. Esto es casi idéntico a la forma en que XML expresa los datos, donde un campo o atributo determinado puede tener varias respuestas correctas al mismo tiempo. Los datos multivalor se pueden considerar como una forma comprimida de XML.
Un ejemplo es una factura, que en datos relacionales o de múltiples valores podría verse como (A) Tabla de encabezado de factura: una entrada por factura, y (B) Tabla de detalles de factura: una entrada por artículo de línea. En el modelo de múltiples valores, tenemos la opción de almacenar los datos como una tabla, con una tabla incorporada para representar el detalle: (A) Tabla de factura: una entrada por factura, no se necesitan otras tablas.
La ventaja es que la atomicidad de la factura (conceptual) y la factura (representación de datos) son uno a uno. Esto también da como resultado menos lecturas, menos problemas de integridad referencial y una reducción drástica del hardware necesario para soportar un volumen de transacciones determinado.
En la década de 1990, el paradigma de programación orientada a objetos se aplicó a la tecnología de bases de datos, creando un nuevo modelo de base de datos conocido como bases de datos de objetos . Esto tiene como objetivo evitar el desajuste de impedancia objeto-relacional : la sobrecarga de convertir información entre su representación en la base de datos (por ejemplo, como filas en tablas) y su representación en el programa de aplicación (normalmente como objetos). Más aún, el sistema de tipos utilizado en una aplicación particular se puede definir directamente en la base de datos, lo que permite que la base de datos aplique las mismas invariantes de integridad de datos. Las bases de datos de objetos también introducen las ideas clave de la programación de objetos, como la encapsulación y el polimorfismo , en el mundo de las bases de datos.
Se han probado varias de estas formas de almacenar objetos en una base de datos. Algunos productos [¿ cuáles? ] han abordado el problema desde el punto de vista de la programación de aplicaciones, haciendo que los objetos manipulados por el programa sean persistentes . Esto normalmente requiere la adición de algún tipo de lenguaje de consulta, ya que los lenguajes de programación convencionales no tienen la capacidad de encontrar objetos en función de su contenido de información. Otros [ ¿cuáles? ] han abordado el problema desde el punto de vista de la base de datos, definiendo un modelo de datos orientado a objetos para la base de datos y definiendo un lenguaje de programación de bases de datos que permita capacidades de programación completas, así como facilidades de consulta tradicionales.
Las bases de datos de objetos sufrieron debido a la falta de estandarización: aunque ODMG definió estándares , nunca se implementaron lo suficientemente bien como para garantizar la interoperabilidad entre productos. Sin embargo, las bases de datos de objetos se han utilizado con éxito en muchas aplicaciones: generalmente aplicaciones especializadas, como bases de datos de ingeniería o bases de datos de biología molecular, en lugar de procesamiento de datos comerciales convencionales. Sin embargo, las ideas de las bases de datos de objetos fueron adoptadas por los proveedores relacionales e influyeron en las extensiones realizadas a estos productos y, de hecho, al lenguaje SQL .
Una alternativa a la traducción entre objetos y bases de datos relacionales es utilizar una biblioteca de mapeo objeto-relacional (ORM).
