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 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 aplicación, que incluyen tasa de transacción (velocidad), confiabilidad, mantenibilidad, escalabilidad y costo. La mayoría de los sistemas de gestión de bases de datos se basan en un modelo de datos particular, aunque es posible que los productos ofrezcan soporte para más de un modelo.
Varios modelos de datos físicos pueden implementar cualquier modelo lógico determinado. 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 elecciones que se realizan tienen un efecto significativo en el rendimiento.
Un modelo no es sólo 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 seleccionar ( proyecto ) y unirse . Aunque estas operaciones pueden no ser explícitas en un lenguaje de consulta en particular , proporcionan la base sobre la cual se construye un lenguaje de consulta.
El modelo plano (o de tabla) consta de una única matriz bidimensional de elementos de datos , donde se supone que todos los miembros de una columna determinada son valores similares y que todos los miembros de una fila están relacionados entre sí. Por ejemplo, columnas para nombre y 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 suelen tener un tipo asociado, definiéndolas 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 y heredados . 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 único padre para cada registro. Un campo de clasificació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 eficaz para describir muchas relaciones en el mundo real; recetas, índice, ordenación de párrafos/versos, cualquier información anidada y ordenada.
Esta jerarquía se utiliza como el orden físico de los registros almacenados. 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 bases de datos cuando no se incluye una ruta completa (a diferencia del vínculo ascendente y el campo de clasificació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 básica.
El modelo de red amplía la estructura jerárquica, permitiendo relaciones de muchos a muchos en una estructura similar a un árbol que permite múltiples padres. Era 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 de cualquier número de conjuntos y miembro de cualquier número de conjuntos.
Un conjunto consta de listas circulares enlazadas donde un tipo de registro, el propietario del conjunto o principal, aparece una vez en cada círculo, y un segundo tipo de registro, el subordinado o secundario, puede aparecer varias veces en cada círculo. De esta manera se puede establecer una jerarquía entre dos tipos de registros cualesquiera, por ejemplo, el tipo A es el propietario de B. Al mismo tiempo se puede definir otro conjunto donde B es el propietario de A. Así, todos los conjuntos comprenden un gráfico dirigido general . (la propiedad define una dirección) o construcción de red . El acceso a los registros es secuencial (normalmente en cada tipo de registro) o mediante navegación en listas circulares enlazadas.
El modelo de red puede 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 ancestro 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 localizar proporcionando valores clave.
Aunque no es una característica esencial del modelo, las bases de datos en red generalmente implementan las relaciones establecidas mediante punteros que abordan directamente la ubicación de un registro en el disco. Esto proporciona un rendimiento de recuperación excelente, a expensas de operaciones como la carga y reorganización de la base de datos.
Los productos DBMS populares que lo utilizaron fueron Total de Cincom Systems y 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. Objetividad/DB , por ejemplo, implementa relaciones con nombre uno a uno, uno a muchos, muchos a uno y muchos a muchos que pueden cruzar bases de datos. Muchas bases de datos de objetos también admiten SQL , combinando los puntos fuertes 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áneas , que pueden usar solo el contenido de una columna particular en la tabla de búsqueda. El modelo de datos de archivos invertidos puede colocar índices en un conjunto de archivos junto a archivos de bases de datos planos existentes, para acceder de manera directa y eficiente a los registros necesarios en estos archivos.
Destaca por el uso de este modelo de datos el ADABAS DBMS de Software AG , introducido en 1970. ADABAS ha ganado una considerable base de clientes y existe y cuenta con soporte hasta el día de hoy. En la década de 1980 adoptó el modelo relacional y SQL además de sus herramientas y lenguajes originales.
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 sean 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 microcomputadores.
Los productos que generalmente se denominan bases de datos relacionales implementan de hecho un modelo que es sólo una aproximación al modelo matemático definido por Codd. Tres términos clave se utilizan ampliamente en los modelos de bases de datos relacionales: relaciones , atributos y dominios . Una relación es una tabla con columnas y filas. Las columnas nombradas de la relación se llaman atributos y el dominio es el conjunto de valores que los atributos pueden tomar.
La estructura de datos básica del modelo relacional es la tabla, donde la información sobre una entidad particular (por ejemplo, un empleado) se representa en filas (también llamadas tuplas ) y columnas. Así, 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 diversos 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 único empleado.
Todas las relaciones (y, por tanto, las tablas) en una base de datos relacional deben cumplir algunas reglas básicas para calificar como 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 tercero, 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 fortalezas del modelo relacional es que, en principio, cualquier valor que ocurra en dos registros diferentes (pertenecientes a la misma tabla o a tablas diferentes), implica una relación entre esos dos registros. Sin embargo, para imponer restricciones de integridad explícitas , las relaciones entre registros en tablas también se pueden definir explícitamente, identificando o no 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 puede usarse para identificar de forma única cada tupla en la tabla.
Una clave que se puede utilizar para identificar de forma única una fila en una tabla se denomina clave primaria. Las claves se utilizan comúnmente para unir o combinar datos de dos o más tablas. Por ejemplo, una tabla de Empleados puede contener una columna denominada Ubicación que contiene un valor que coincide con la clave de una tabla de Ubicación . 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 originalmente no estaba destinada a serlo.
Una clave que tiene un significado externo en el mundo 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 ninguna clave natural es adecuada (piense en las muchas personas llamadas Brown ), se puede asignar una clave arbitraria o sustituta (por ejemplo, dando números de identificación a los empleados). En la práctica, la mayoría de las bases de datos tienen claves tanto generadas como 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 integración con otras bases de datos. (Por ejemplo, los registros de dos bases de datos desarrolladas de forma independiente podrían cotejarse 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 utilizado para representar datos en almacenes de datos de manera que los datos se puedan resumir fácilmente mediante 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 ocurrió, 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 podría 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 manera significativa; por ejemplo, se pueden sumar los ingresos de diferentes ubicaciones.
En una consulta OLAP, se eligen dimensiones y los hechos se agrupan y agregan para crear un resumen.
El modelo dimensional a menudo se implementa sobre el modelo relacional utilizando 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 las jerarquías de varios niveles dentro de una dimensión en varias tablas.
Un almacén de datos puede contener múltiples esquemas dimensionales que comparten tablas de dimensiones, lo que permite su uso conjunto. Elaborar 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] Los términos alternativos incluyen "base de datos híbrida", "RDBMS mejorado por objetos" y otros. El modelo de datos en tales productos incorpora relaciones pero no está restringido 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 postrelacionales amplían los sistemas relacionales con características no relacionales. Otros llegaron prácticamente al mismo lugar añadiendo características relacionales a sistemas pre-relacionales. Paradójicamente, esto permite que productos que son históricamente pre-relacionales, como PICK y MUMPS , hagan una afirmación plausible de ser post-relacionales.
El modelo de espacio de recursos (RSM) es un modelo de datos no relacional basado en una clasificación multidimensional. [5]
Las bases de datos de gráficos 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 "grumosos", ya que pueden almacenarse exactamente de la misma manera que las bases de datos relacionales, pero también permiten un nivel de profundidad que el modelo relacional sólo puede aproximar utilizando subtablas. Esto es casi idéntico a la forma en que XML expresa datos, donde un campo/atributo determinado puede tener múltiples respuestas correctas al mismo tiempo. Se puede considerar el valor múltiple como una forma comprimida de XML.
Un ejemplo es una factura, que en datos multivalor o relacionales 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 multivalor, tenemos la opción de almacenar los datos como en una tabla, con una tabla integrada para representar el detalle: (A) Tabla de facturas: 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) es uno a uno. Esto también da como resultado menos lecturas, menos problemas de integridad referencial y una disminució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 la discrepancia entre la impedancia relacional y el objeto : 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). Aún más, 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 [ ¿por quién? ] para almacenar objetos en una base de datos. Algunos [ ¿cuáles? ] Los productos han abordado el problema desde el punto de vista de la programación de aplicaciones, haciendo persistentes los objetos manipulados por el programa . Por lo general, esto 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 atacado el problema desde el extremo 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 base de datos que permite capacidades de programación completas, así como funciones de consulta tradicionales.
Las bases de datos de objetos sufrieron debido a la falta de estandarización: aunque ODMG definió los 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: normalmente aplicaciones especializadas, como bases de datos de ingeniería o bases de datos de biología molecular, en lugar del procesamiento de datos comerciales convencional. Sin embargo, los proveedores relacionales retomaron las ideas de bases de datos de objetos 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 relacional de objetos (ORM).
