Modelo relacional

Modelo de base de datos

El modelo relacional ( MR ) es un enfoque para gestionar datos utilizando una estructura y un lenguaje coherentes con la lógica de predicados de primer orden , descrita por primera vez en 1969 por el informático inglés Edgar F. Codd , ^{[1] [2]} donde todos los datos se representan en términos de tuplas , agrupadas en relaciones . Una base de datos organizada en términos del modelo relacional es una base de datos relacional .

El propósito del modelo relacional es proporcionar un método declarativo para especificar datos y consultas: los usuarios indican directamente qué información contiene la base de datos y qué información desean de ella, y dejan que el software del sistema de gestión de bases de datos se encargue de describir las estructuras de datos para almacenar los datos y los procedimientos de recuperación para responder a las consultas.

La mayoría de las bases de datos relacionales utilizan el lenguaje de consulta y definición de datos SQL ; estos sistemas implementan lo que puede considerarse una aproximación de ingeniería al modelo relacional. Una tabla en un esquema de base de datos SQL corresponde a una variable de predicado; el contenido de una tabla a una relación; las restricciones clave, otras restricciones y las consultas SQL corresponden a predicados. Sin embargo, las bases de datos SQL se desvían del modelo relacional en muchos detalles, y Codd argumentó ferozmente contra las desviaciones que comprometen los principios originales. ^[3]

Historia

El modelo relacional fue desarrollado por Edgar F. Codd como un modelo general de datos y posteriormente promovido por Chris Date y Hugh Darwen, entre otros. En su libro de 1995 El tercer manifiesto , Date y Darwen intentan demostrar cómo el modelo relacional puede dar cabida a ciertas características "deseadas" de la orientación a objetos . ^[4]

Extensiones

Algunos años después de la publicación de su modelo de 1970, Codd propuso una versión lógica de tres valores (Verdadero, Falso, Faltante/ NULL ) para lidiar con la información faltante, y en su The Relational Model for Database Management Version 2 (1990) fue un paso más allá con una versión lógica de cuatro valores (Verdadero, Falso, Faltante pero Aplicable, Faltante pero Inaplicable). ^[5]

Conceptualización

Conceptos básicos

Una relación con 5 atributos (su grado) y 4 tuplas (su cardinalidad) se puede visualizar como una tabla con 5 columnas y 4 filas. Sin embargo, a diferencia de las filas y columnas de una tabla, los atributos y las tuplas de una relación no están ordenados.

Una relación consta de un encabezado y un cuerpo . El encabezado define un conjunto de atributos , cada uno con un nombre y un tipo de datos (a veces llamado dominio ). El número de atributos en este conjunto es el grado o aridad de la relación . El cuerpo es un conjunto de tuplas . Una tupla es una colección de n valores , donde n es el grado de la relación y cada valor en la tupla corresponde a un atributo único. ^{[6] El número de tuplas en este conjunto es la} cardinalidad de la relación . ^{[7] : 17–22}

Las relaciones se representan mediante variables relacionales o relvars , que pueden reasignarse. ^{[7] : 22–24} Una base de datos es una colección de relvars. ^{[7] : 112–113}

En este modelo, las bases de datos siguen el principio de información : en un momento dado, toda la información en la base de datos está representada únicamente por valores dentro de tuplas, correspondientes a atributos, en relaciones identificadas por relvars. ^{[7] : 111}

Restricciones

Una base de datos puede definir expresiones booleanas arbitrarias como restricciones . Si todas las restricciones se evalúan como verdaderas , la base de datos es consistente ; de ​​lo contrario, es inconsistente . Si un cambio en las variables rel de una base de datos dejara la base de datos en un estado inconsistente, ese cambio es ilegal y no debe tener éxito. ^{[7] : 91}

En general, las restricciones se expresan utilizando operadores de comparación relacional, de los cuales sólo uno, "es subconjunto de" (⊆), es teóricamente suficiente. ^{[ cita requerida ]}

Dos casos especiales de restricciones se expresan como claves y claves externas :

Llaves

Una clave candidata , o simplemente una clave , es el subconjunto más pequeño de atributos que se garantiza que diferencian de forma única cada tupla de una relación. Dado que cada tupla de una relación debe ser única, cada relación tiene necesariamente una clave, que puede ser su conjunto completo de atributos. Una relación puede tener múltiples claves, ya que puede haber múltiples formas de diferenciar de forma única cada tupla. ^{[7] : 31–33}

Un atributo puede ser único entre tuplas sin ser una clave. Por ejemplo, una relación que describe a los empleados de una empresa puede tener dos atributos: ID y Nombre. Incluso si ningún empleado comparte actualmente un nombre, si es posible contratar eventualmente a un nuevo empleado con el mismo nombre que un empleado actual, el subconjunto de atributos {Nombre} no es una clave. Por el contrario, si el subconjunto {ID} es una clave, esto significa no solo que ningún empleado comparte actualmente un ID, sino que ningún empleado compartirá nunca un ID. ^{[7] : 31–33}

Claves externas

Una clave externa es un subconjunto de atributos {A} en una relación R ₁ que corresponde con una clave de otra relación R ₂ , con la propiedad de que la proyección de R ₁ sobre {A} es un subconjunto de la proyección de R ₂ sobre {A} . En otras palabras, si una tupla en R ₁ contiene valores para una clave externa, debe haber una tupla correspondiente en R ₂ que contenga los mismos valores para la clave correspondiente. ^{[7] : 34}

Operaciones relacionales

Los usuarios (o programas) solicitan datos de una base de datos relacional enviándole una consulta . En respuesta a la consulta, la base de datos devuelve un conjunto de resultados.

A menudo, los datos de varias tablas se combinan en una sola mediante una operación de unión . En teoría, esto se hace tomando todas las combinaciones posibles de filas (el producto cartesiano ) y luego filtrando todo excepto la respuesta.

Existen varias operaciones relacionales además de la operación join. Entre ellas se encuentran project (el proceso de eliminar algunas de las columnas), restrict (el proceso de eliminar algunas de las filas), union (una forma de combinar dos tablas con estructuras similares), difference (que enumera las filas de una tabla que no se encuentran en la otra), intersect (que enumera las filas que se encuentran en ambas tablas) y product (mencionada anteriormente, que combina cada fila de una tabla con cada fila de la otra). Según las fuentes que consulte, existen otros operadores, muchos de los cuales se pueden definir en términos de los que se enumeran anteriormente. Entre ellos se incluyen semijoin, operadores externos como external join y external union, y varias formas de división. También hay operadores para cambiar el nombre de las columnas, operadores de resumen o agregación y, si permite valores de relación como atributos (atributo con valor de relación), operadores como group y ungroup.

La flexibilidad de las bases de datos relacionales permite a los programadores escribir consultas que no habían previsto los diseñadores de bases de datos. Como resultado, las bases de datos relacionales pueden ser utilizadas por múltiples aplicaciones de maneras que los diseñadores originales no previeron, lo que es especialmente importante para bases de datos que podrían usarse durante mucho tiempo (quizás varias décadas). Esto ha hecho que la idea y la implementación de bases de datos relacionales sean muy populares entre las empresas.

Normalización de bases de datos

Las relaciones se clasifican en función de los tipos de anomalías a las que son vulnerables. Una base de datos que se encuentra en la primera forma normal es vulnerable a todos los tipos de anomalías, mientras que una base de datos que se encuentra en la forma normal de dominio/clave no tiene anomalías de modificación. Las formas normales son jerárquicas por naturaleza. Es decir, el nivel más bajo es la primera forma normal y la base de datos no puede cumplir los requisitos de las formas normales de nivel superior sin haber cumplido primero todos los requisitos de las formas normales menores. ^[8]

Interpretación lógica

El modelo relacional es un sistema formal . Los atributos de una relación definen un conjunto de proposiciones lógicas . Cada proposición puede expresarse como una tupla. El cuerpo de una relación es un subconjunto de estas tuplas, que representan qué proposiciones son verdaderas. Las restricciones representan proposiciones adicionales que también deben ser verdaderas. El álgebra relacional es un conjunto de reglas lógicas que pueden inferir conclusiones válidas a partir de estas proposiciones. ^{[7] : 95–101}

La definición de una tupla permite una tupla vacía única sin valores, correspondiente al conjunto vacío de atributos. Si una relación tiene un grado de 0 (es decir, su encabezado no contiene atributos), puede tener una cardinalidad de 0 (un cuerpo que no contiene tuplas) o una cardinalidad de 1 (un cuerpo que contiene la única tupla vacía). Estas relaciones representan valores de verdad booleanos . La relación con grado 0 y cardinalidad 0 es False , mientras que la relación con grado 0 y cardinalidad 1 es True . ^{[7] : 221–223}

Ejemplo

Si una relación de Empleados contiene los atributos {Nombre, ID} , entonces la tupla {Alice, 1} representa la proposición: "Existe un empleado llamado Alice con ID 1 ". Esta proposición puede ser verdadera o falsa. Si esta tupla existe en el cuerpo de la relación, la proposición es verdadera (existe dicho empleado). Si esta tupla no está en el cuerpo de la relación, la proposición es falsa (no existe dicho empleado). ^{[7] : 96–97}

Además, si {ID} es una clave, entonces una relación que contenga las tuplas {Alice, 1} y {Bob, 1} representaría la siguiente contradicción :

1. Existe un empleado con el nombre Alice y el ID 1 .
2. Existe un empleado con el nombre Bob y el ID 1 .
3. No existen varios empleados con el mismo ID.

Según el principio de explosión , esta contradicción permitiría al sistema demostrar que cualquier proposición arbitraria es verdadera. La base de datos debe aplicar la restricción de clave para evitarlo. ^{[7] : 104}

Ejemplos

Base de datos

Un ejemplo idealizado, muy simple, de una descripción de algunas relvars ( variables de relación ) y sus atributos:

• Cliente ( ID de cliente , nombre)
• Pedido ( ID de pedido , ID de cliente , ID de factura , Fecha)
• Factura ( ID de factura , ID de cliente , ID de pedido , Estado)

En este diseño tenemos tres variables rel: Cliente, Pedido y Factura. Los atributos en negrita y subrayados son claves candidatas . Los atributos que no están en negrita y subrayados son claves externas .

Generalmente se elige una clave candidata para llamarla clave principal y se la utiliza con preferencia sobre las otras claves candidatas, que luego se denominan claves alternativas .

Una clave candidata es un identificador único que obliga a que no se duplique ninguna tupla ; esto convertiría la relación en otra cosa, es decir, en un conjunto , al violar la definición básica de un conjunto . Tanto las claves externas como las superclaves (que incluyen las claves candidatas) pueden ser compuestas, es decir, pueden estar formadas por varios atributos. A continuación se muestra una representación tabular de una relación de nuestro ejemplo de relvar Cliente; una relación puede considerarse como un valor que puede atribuirse a un relvar.

Relación con el cliente

Si intentáramos insertar un nuevo cliente con el ID 123 , esto violaría el diseño de la variable relvar ya que el ID del cliente es una clave principal y ya tenemos un cliente 123. El DBMS debe rechazar una transacción como esta que haría que la base de datos fuera inconsistente por una violación de una restricción de integridad . Sin embargo, es posible insertar otro cliente llamado Alice , siempre que este nuevo cliente tenga un ID único, ya que el campo Nombre no es parte de la clave principal.

Las claves externas son restricciones de integridad que imponen que el valor del conjunto de atributos se extraiga de una clave candidata en otra relación . Por ejemplo, en la relación Pedido, el atributo ID de cliente es una clave externa. Una unión es la operación que extrae información de varias relaciones a la vez. Al unir relvars del ejemplo anterior, podríamos consultar la base de datos para todos los Clientes, Pedidos y Facturas. Si solo quisiéramos las tuplas para un cliente específico, lo especificaríamos usando una condición de restricción. Si quisiéramos recuperar todos los Pedidos para el Cliente 123 , podríamos consultar la base de datos para devolver cada fila en la tabla Pedido con ID de cliente 123 .

Hay una falla en el diseño de nuestra base de datos anterior. La variable relvar Factura contiene un atributo ID de pedido. Por lo tanto, cada tupla en la variable relvar Factura tendrá un ID de pedido, lo que implica que hay exactamente un pedido para cada factura. Pero en realidad, se puede crear una factura para muchos pedidos, o incluso para ningún pedido en particular. Además, la variable relvar Pedido contiene un atributo ID de factura, lo que implica que cada pedido tiene una factura correspondiente. Pero nuevamente, esto no siempre es cierto en el mundo real. Un pedido a veces se paga a través de varias facturas y, a veces, se paga sin factura. En otras palabras, puede haber muchas facturas por pedido y muchos pedidos por factura. Esta es una relación de muchos a muchos entre Pedido y Factura (también llamada relación no específica ). Para representar esta relación en la base de datos, se debe introducir una nueva variable relvar cuya función sea especificar la correspondencia entre pedidos y facturas:

Factura de pedido ( ID de pedido , ID de factura )

Ahora, la variable rel de pedido tiene una relación de uno a muchos con la tabla OrderInvoice, al igual que la variable rel de factura. Si queremos recuperar cada factura de un pedido en particular, podemos consultar todos los pedidos en los que el ID de pedido en la relación de pedido sea igual al ID de pedido en OrderInvoice, y en los que el ID de factura en OrderInvoice sea igual al ID de factura en Invoice.

Aplicación a bases de datos relacionales

Un tipo de datos en una base de datos relacional puede ser el conjunto de números enteros, el conjunto de cadenas de caracteres, el conjunto de fechas, etc. El modelo relacional no dicta qué tipos se deben admitir.

Los atributos se representan comúnmente como columnas , las tuplas como filas y las relaciones como tablas . Una tabla se especifica como una lista de definiciones de columnas, cada una de las cuales especifica un nombre de columna único y el tipo de valores permitidos para esa columna. Un valor de atributo es la entrada en una columna y fila específicas.

Una variable de relación ( relvar ) de una base de datos se conoce comúnmente como tabla base . El encabezado de su valor asignado en cualquier momento es el especificado en la declaración de la tabla y su cuerpo es el que le haya sido asignado más recientemente por un operador de actualización (normalmente, INSERT, UPDATE o DELETE). El encabezado y el cuerpo de la tabla resultante de la evaluación de una consulta están determinados por las definiciones de los operadores utilizados en esa consulta.

SQL y el modelo relacional

SQL, que en un principio se promovió como el lenguaje estándar para bases de datos relacionales , se desvía del modelo relacional en varios puntos. El estándar SQL ISO actual no menciona el modelo relacional ni utiliza términos o conceptos relacionales. ^{[ cita requerida ]}

Según el modelo relacional, los atributos y tuplas de una relación son conjuntos matemáticos , lo que significa que no están ordenados y son únicos. En una tabla SQL, ni las filas ni las columnas son conjuntos propios. Una tabla puede contener filas y columnas duplicadas, y las columnas de una tabla están ordenadas explícitamente. SQL utiliza un valor Nulo para indicar datos faltantes, que no tiene análogo en el modelo relacional. Debido a que una fila puede representar información desconocida, SQL no se adhiere al Principio de información del modelo relacional . ^{[7] : 153–155, 162}

Formulación de teoría de conjuntos

Los conceptos básicos del modelo relacional son los nombres de las relaciones y los nombres de los atributos . Los representaremos como cadenas como "Persona" y "nombre" y normalmente utilizaremos las variables y para abarcarlas. Otro concepto básico es el conjunto de valores atómicos que contiene valores como números y cadenas. ${\displaystyle r,s,t,\ldots }$ ${\displaystyle a,b,c}$

Nuestra primera definición se refiere a la noción de tupla , que formaliza la noción de fila o registro en una tabla:

Tupla

Una tupla es una función parcial desde nombres de atributos hasta valores atómicos.

Encabezamiento

Un encabezado es un conjunto finito de nombres de atributos.

Proyección

La proyección de una tupla sobre un conjunto finito de atributos es . ${\displaystyle t}$ ${\displaystyle A}$ ${\displaystyle t[A]=\{(a,v):(a,v)\in t,a\in A\}}$

La siguiente definición define la relación que formaliza el contenido de una tabla tal como se define en el modelo relacional.

Relación

Una relación es una tupla con , el encabezado, y , el cuerpo, un conjunto de tuplas que tienen todas el dominio . ${\displaystyle (H,B)}$ ${\displaystyle H}$ ${\displaystyle B}$ ${\displaystyle H}$

Esta relación se corresponde estrechamente con lo que se suele llamar la extensión de un predicado en la lógica de primer orden, excepto que aquí identificamos los lugares en el predicado con nombres de atributos. Por lo general, en el modelo relacional, se dice que un esquema de base de datos consta de un conjunto de nombres de relaciones, los encabezados que están asociados con estos nombres y las restricciones que deben cumplirse para cada instancia del esquema de base de datos.

Universo de relaciones

Un universo de relaciones sobre un encabezado es un conjunto no vacío de relaciones con encabezado . ${\displaystyle U}$ ${\displaystyle H}$ ${\displaystyle H}$

Esquema de relación

Un esquema de relación consta de un encabezado y un predicado que se define para todas las relaciones con encabezado . Una relación satisface un esquema de relación si tiene encabezado y satisface . ${\displaystyle (H,C)}$ ${\displaystyle H}$ ${\displaystyle C(R)}$ ${\displaystyle R}$ ${\displaystyle H}$ ${\displaystyle (H,C)}$ ${\displaystyle H}$ ${\displaystyle C}$

Restricciones clave y dependencias funcionales

Uno de los tipos de restricciones de relación más simples e importantes es la restricción de clave . Nos dice que en cada instancia de un determinado esquema relacional las tuplas pueden identificarse por sus valores para determinados atributos.

Superclave

Una superclave es un conjunto de encabezados de columnas para los cuales los valores de esas columnas concatenados son únicos en todas las filas. Formalmente:

Una superclave se escribe como un conjunto finito de nombres de atributos.

Una superclave se cumple en una relación si: ${\displaystyle K}$ ${\displaystyle (H,B)}$

• ${\displaystyle K\subseteq H}$y
• no existen dos tuplas distintas tales que . ${\displaystyle t_{1},t_{2}\in B}$ ${\displaystyle t_{1}[K]=t_{2}[K]}$

Una superclave se cumple en un universo de relaciones si se cumple en todas las relaciones en . ${\displaystyle U}$ ${\displaystyle U}$

Teorema: Una superclave se cumple en una relación universo sobre si y sólo si y se cumple en . ${\displaystyle K}$ ${\displaystyle U}$ ${\displaystyle H}$ ${\displaystyle K\subseteq H}$ ${\displaystyle K\rightarrow H}$ ${\displaystyle U}$

Clave de candidato

Una clave candidata es una superclave que no puede subdividirse aún más para formar otra superclave.

Una superclave se cumple como clave candidata para un universo de relaciones si se cumple como superclave para y no existe un subconjunto adecuado de ella que también se cumpla como superclave para . ${\displaystyle K}$ ${\displaystyle U}$ ${\displaystyle U}$ ${\displaystyle K}$ ${\displaystyle U}$

Dependencia funcional

La dependencia funcional es la propiedad de que un valor de una tupla puede derivarse de otro valor de esa tupla.

Una dependencia funcional (FD, por sus siglas en inglés) se escribe para conjuntos finitos de nombres de atributos. ${\displaystyle X\rightarrow Y}$ ${\displaystyle X,Y}$

Una dependencia funcional se cumple en una relación si: ${\displaystyle X\rightarrow Y}$ ${\displaystyle (H,B)}$

• ${\displaystyle X,Y\subseteq H}$y
• ${\displaystyle \forall }$tuplas , ${\displaystyle t_{1},t_{2}\in B}$ ${\displaystyle t_{1}[X]=t_{2}[X]~\Rightarrow ~t_{1}[Y]=t_{2}[Y]}$

Una dependencia funcional se cumple en un universo de relaciones si se cumple en todas las relaciones en . ${\displaystyle X\rightarrow Y}$ ${\displaystyle U}$ ${\displaystyle U}$

Dependencia funcional trivial

Una dependencia funcional es trivial bajo un encabezado si se cumple en todos los universos de relación sobre . ${\displaystyle H}$ ${\displaystyle H}$

Teorema: Un FD es trivial bajo un encabezado si y solo si . ${\displaystyle X\rightarrow Y}$ ${\displaystyle H}$ ${\displaystyle Y\subseteq X\subseteq H}$

Cierre

Axiomas de Armstrong : El cierre de un conjunto de FD bajo un encabezado , escrito como , es el superconjunto más pequeño de tal que: ${\displaystyle S}$ ${\displaystyle H}$ ${\displaystyle S^{+}}$ ${\displaystyle S}$

• ${\displaystyle Y\subseteq X\subseteq H~\Rightarrow ~X\rightarrow Y\in S^{+}}$(reflexividad)
• ${\displaystyle X\rightarrow Y\in S^{+}\land Y\rightarrow Z\in S^{+}~\Rightarrow ~X\rightarrow Z\in S^{+}}$(transitividad) y
• ${\displaystyle X\rightarrow Y\in S^{+}\land Z\subseteq H~\Rightarrow ~(X\cup Z)\rightarrow (Y\cup Z)\in S^{+}}$(aumento)

Teorema: Los axiomas de Armstrong son sólidos y completos; dado un encabezado y un conjunto de FD que solo contienen subconjuntos de , si y solo si se cumple en todas las relaciones universos en los que se cumplen todos los FD en . ${\displaystyle H}$ ${\displaystyle S}$ ${\displaystyle H}$ ${\displaystyle X\rightarrow Y\in S^{+}}$ ${\displaystyle X\rightarrow Y}$ ${\displaystyle H}$ ${\displaystyle S}$

Terminación

La completitud de un conjunto finito de atributos bajo un conjunto finito de FD , escrito como , es el superconjunto más pequeño de tal que: ${\displaystyle X}$ ${\displaystyle S}$ ${\displaystyle X^{+}}$ ${\displaystyle X}$

• ${\displaystyle Y\rightarrow Z\in S\land Y\subseteq X^{+}~\Rightarrow ~Z\subseteq X^{+}}$

La finalización de un conjunto de atributos se puede utilizar para calcular si una determinada dependencia está en el cierre de un conjunto de FD.

Teorema: Dado un conjunto de funciones diferenciales, si y sólo si . ${\displaystyle S}$ ${\displaystyle X\rightarrow Y\in S^{+}}$ ${\displaystyle Y\subseteq X^{+}}$

Cobertura irreductible

Una cubierta irreducible de un conjunto de funciones diferenciales es un conjunto de funciones diferenciales tales que: ${\displaystyle S}$ ${\displaystyle T}$

• ${\displaystyle S^{+}=T^{+}}$
• No existe tal cosa ${\displaystyle U\subset T}$ ${\displaystyle S^{+}=U^{+}}$
• ${\displaystyle X\rightarrow Y\in T~\Rightarrow Y}$es un conjunto singleton y
• ${\displaystyle X\rightarrow Y\in T\land Z\subset X~\Rightarrow ~Z\rightarrow Y\notin S^{+}}$.

Algoritmo para derivar claves candidatas a partir de dependencias funcionales

El algoritmo deriva claves candidatas a partir de dependencias funcionales como  entrada: un conjunto S de FD que contienen solo subconjuntos de un encabezado H  como salida: el conjunto C de superclaves que se mantienen como claves candidatas en todos los universos de relación sobre H en los que se cumplen todos los FD en S C  := ∅ // encontró claves candidatas Q  := { H } // superclaves que contienen claves candidatas mientras  Q <> ∅ sea K algún elemento de Q  Q  := Q  – { K } mínimo  := verdadero  para cada  X->Y  en  S  hacer  K' := ( K  – Y ) ∪ X // derivar nueva superclave si  K' ⊂ K  entonces  mínimo  := falso  Q  := Q ∪ { K' } fin si  fin para  si es  mínimo  y no hay un subconjunto de K en C  entonces eliminar todos los superconjuntos de K de C  C  := C ∪ { K } fin si  fin mientras

Alternativas

Otros modelos incluyen el modelo jerárquico y el modelo de red . Algunos sistemas que utilizan estas arquitecturas antiguas todavía se utilizan hoy en día en centros de datos con necesidades de gran volumen de datos, o donde los sistemas existentes son tan complejos y abstractos que resultaría prohibitivo en términos de costos migrar a sistemas que emplean el modelo relacional. También cabe destacar las nuevas bases de datos orientadas a objetos ^[9] y Datalog ^[10] .

Datalog es un lenguaje de definición de bases de datos que combina una visión relacional de los datos, como en el modelo relacional, con una visión lógica, como en la programación lógica . Mientras que las bases de datos relacionales utilizan un cálculo relacional o álgebra relacional, con operaciones relacionales , como unión , intersección , diferencia de conjuntos y producto cartesiano para especificar consultas, Datalog utiliza conectores lógicos, como if , or , and y not para definir relaciones como parte de la base de datos en sí.

A diferencia del modelo relacional, que no puede expresar consultas recursivas sin introducir un operador de punto mínimo fijo, ^[11] las relaciones recursivas se pueden definir en Datalog, sin introducir ningún operador o conectivo lógico nuevo.

Véase también

• Cálculo relacional de dominios
• Lista de sistemas de gestión de bases de datos relacionales
• Lenguaje de consulta
  • Lenguaje de consulta de base de datos
  • Lenguaje de consulta para recuperación de información
• Relación
• Base de datos relacional
• Sistema de gestión de bases de datos relacionales
• Control de versiones de tuplas

Notas

Referencias

1. Codd, EF (1969), Derivabilidad, redundancia y consistencia de las relaciones almacenadas en grandes bancos de datos , Informe de investigación, IBM.
2. Codd, EF (1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM . Clásicos. 13 (6): 377–87. doi : 10.1145/362384.362685 . S2CID  207549016. Archivado desde el original el 12 de junio de 2007.
3. Codd, E. F (1990), El modelo relacional para la gestión de bases de datos , Addison-Wesley, págs. 371–388, ISBN 978-0-201-14192-4.
4. "¿El "Tercer Manifiesto" de Date y Darwen tuvo un impacto duradero?". Stack Exchange en Ciencias de la Computación . Consultado el 3 de agosto de 2024 .
5. Fecha, Christopher J. (2006). "18. Por qué la lógica de tres y cuatro valores no funciona". Fecha en la base de datos: Escritos 2000–2006 . Apress. págs. 329–41. ISBN 978-1-59059-746-0.
6. "Tupla en DBMS". GeeksforGeeks . 2023-02-12 . Consultado el 2024-08-03 .
7. Date, Chris J. (2013). Teoría relacional para profesionales de la informática: de qué se tratan realmente las bases de datos relacionales (1.ª ed.). Sebastopol, California: O'Reilly Media. ISBN 978-1-449-36943-9.
8. David M. Kroenke, Procesamiento de bases de datos: fundamentos, diseño e implementación (1997), Prentice-Hall, Inc., páginas 130-144
9. Atkinson, M., Dewitt, D., Maier, D., Bancilhon, F., Dittrich, K. y Zdonik, S., 1990. El manifiesto del sistema de base de datos orientado a objetos. En Bases de datos deductivas y orientadas a objetos (pp. 223-240). Holanda Septentrional.
10. Maier, D., Tekle, KT, Kifer, M. y Warren, DS, 2018. Datalog: conceptos, historia y perspectivas. En Programación lógica declarativa: teoría, sistemas y aplicaciones (pp. 3-100).
11. Aho, AV y Ullman, JD, 1979, enero. Universalidad de los lenguajes de recuperación de datos. En Actas del 6º simposio ACM SIGACT-SIGPLAN sobre Principios de los lenguajes de programación (pp. 110-119).

Lectura adicional

• Date, Christopher J. ; Darwen, Hugh (2000). Fundación para futuros sistemas de bases de datos: el tercer manifiesto; un estudio detallado del impacto de la teoría de tipos en el modelo relacional de datos, incluyendo un modelo integral de herencia de tipos (2.ª ed.). Reading, MA : Addison-Wesley. ISBN 978-0-201-70928-5.
• ——— (2007). Introducción a los sistemas de bases de datos (8.ª ed.). Boston: Pearson Education. ISBN 978-0-321-19784-9.

Enlaces externos

• Childs (1968), Viabilidad de una estructura de datos de teoría de conjuntos: una estructura general basada en una definición reconstituida de relación (investigación), Handle, hdl :2027.42/4164citado en el artículo de Codd de 1970.
• Darwen, Hugh, El Tercer Manifiesto (TTM).
• "Modelo relacional", C2.
• Relaciones binarias y tuplas comparadas con respecto a la web semántica ( World Wide Web log), Sun.