Modelo relacional

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

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 dato (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 cualquier 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}

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 restricciones de una base de datos la dejara en un estado inconsistente, ese cambio es ilegal y no debe tener éxito. ^{[ 7 ] : 91}

En general, las restricciones se expresan mediante operadores de comparación relacional, de los cuales solo uno, "es subconjunto de" (⊆), es teóricamente suficiente. ^{[ 8 ]}

Dos casos especiales de restricciones se expresan como claves y claves foráneas :

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

A menudo, los datos de varias tablas se combinan en una sola mediante una operación de unión (join ). Conceptualmente, esto se realiza tomando todas las combinaciones posibles de filas (el producto cartesiano ) y luego filtrando todo excepto la respuesta. ^{[ 2 ]}

Además de la operación de unión (join), existen varias operaciones relacionales. Estas incluyen la proyección (que elimina algunas columnas), la restricción (que elimina algunas filas), la unión (que combina dos tablas con estructuras similares), la diferencia (que muestra las filas de una tabla que no se encuentran en la otra), la intersección (que muestra las filas presentes en ambas tablas) y el producto (como se mencionó anteriormente, que combina cada fila de una tabla con cada fila de la otra). Según las fuentes consultadas, existen otros operadores  , muchos de los cuales se pueden definir en función de los mencionados. Estos incluyen la semiunión, operadores externos como la unión externa y la unión externa, y diversas formas de división. También existen operadores para renombrar columnas, operadores de resumen o agregación, y si se permiten valores de relación como atributos (atributos con valor de relación), operadores como agrupar y desagrupar. ^{[ 2 ]}

La flexibilidad de las bases de datos relacionales permite a los programadores escribir consultas que no fueron previstas por los diseñadores. Como resultado, las bases de datos relacionales pueden ser utilizadas por múltiples aplicaciones de maneras que los diseñadores originales no anticiparon, lo cual es especialmente importante para bases de datos que podrían usarse durante mucho tiempo (quizás varias décadas). ^{[ 2 ]} Esto ha hecho que la idea e implementación de bases de datos relacionales sean muy populares en las empresas. ^{[ 9 ]}

Las relaciones se clasifican según los tipos de anomalías a las que son vulnerables. Una base de datos en primera forma normal es vulnerable a todo tipo de anomalías, mientras que una base de datos en forma normal de dominio/clave no presenta anomalías de modificación. Las formas normales son jerárquicas. 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 antes haber cumplido todos los requisitos de las formas normales inferiores. ^{[ 10 ]}

Si una relación de Empleados contiene los atributos ⁠${\displaystyle \{Name,ID\}}$⁠ , entonces la tupla ⁠${\displaystyle \{Alice,1\}}$⁠ representa la proposición: "Existe una empleada llamada 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 dicha empleada). Si esta tupla no está en el cuerpo de la relación, la proposición es falsa (no existe dicha empleada). ^{[ 7 ] : 96–97}

Además, si${\displaystyle \{ID\}}$Si es una clave, entonces una relación que contiene las tuplas .${\displaystyle \{Alice,1\}}$y​​${\displaystyle \{Bob,1\}}$Esto representaría la siguiente contradicción :

1. Existe una empleada con el nombre Alice y la ID 1 .
2. Existe un empleado con el nombre Bob y la identificación 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 evitar esto. ^{[ 7 ] : 104}

Un ejemplo idealizado y muy simple de la descripción de algunas variables de relación ( relavars) y sus atributos:

• Cliente ( ID de cliente , Nombre)
• Pedido ( ID del pedido , ID del cliente , ID de la factura , Fecha)
• Factura ( ID de factura , ID de cliente , ID de pedido , Estado)

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

Normalmente, se elige una clave candidata que se denomina clave primaria y se utiliza con preferencia sobre las demás claves candidatas, que luego se denominan claves alternativas .

Una clave candidata es un identificador único que garantiza que ninguna tupla se duplique; esto convertiría la relación en algo distinto, concretamente una bolsa , al violar la definición básica de un conjunto . Tanto las claves foráneas 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 tabla que representa la relación de nuestro ejemplo Cliente relvar; una relación puede considerarse como un valor que se puede atribuir a un relvar.

Si intentáramos insertar un nuevo cliente con el ID 123 , esto violaría el diseño de la tabla, ya que el ID de cliente es una clave primaria y ya tenemos un cliente con ese ID . El sistema de gestión de bases de datos (DBMS) debe rechazar una transacción de este tipo, ya que provocaría inconsistencias en la base de datos al violar una restricción de integridad . Sin embargo, es posible insertar otro cliente llamado Alice , siempre y cuando este nuevo cliente tenga un ID único, dado que el campo Nombre no forma parte de la clave primaria.

Las claves foráneas son restricciones de integridad que garantizan 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 foránea. Una unión es la operación que extrae información de varias relaciones a la vez. Al unir las relaciones del ejemplo anterior, podríamos consultar la base de datos para obtener todos los Clientes, Pedidos y Facturas. Si solo quisiéramos las tuplas para un cliente específico, lo especificaríamos mediante 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 que devuelva todas las filas de la tabla Pedido con el ID de cliente 123 .

Existe un fallo en el diseño de nuestra base de datos . El relvar Factura contiene un atributo ID de pedido. Por lo tanto, cada tupla en el relvar Factura tendrá un ID de pedido, lo que implica que hay exactamente un pedido por cada factura. Pero en realidad, una factura puede crearse para muchos pedidos, o incluso para ninguno en particular. Además, el relvar Pedido contiene un atributo ID de factura, lo que implica que cada pedido tiene una factura correspondiente. Pero, de nuevo, esto no siempre es cierto en la práctica. Un pedido a veces se paga mediante 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 un nuevo relvar cuya función sea especificar la correspondencia entre Pedidos y Facturas.

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

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

SQL, inicialmente promovido como el lenguaje estándar para bases de datos relacionales , se desvía del modelo relacional en varios aspectos. El estándar ISO SQL actual no menciona el modelo relacional ni utiliza términos o conceptos relacionales.

Según el modelo relacional, los atributos y las tuplas de una relación son conjuntos matemáticos , lo que significa que no tienen un orden específico y son únicos. En una tabla SQL, ni las filas ni las columnas son conjuntos propiamente dichos. Una tabla puede contener filas y columnas duplicadas, y las columnas de una tabla tienen un orden explícito. SQL utiliza un valor nulo para indicar datos faltantes, lo cual no tiene equivalente en el modelo relacional. Dado que una fila puede representar información desconocida, SQL no se adhiere al principio de información del modelo relacional . ^{[ 7 ] : 153–155, 162}

Uno de los tipos más simples e importantes de restricciones relacionales es la restricción de clave . Esta nos indica que, en cada instancia de un esquema relacional determinado, las tuplas pueden identificarse por sus valores para ciertos atributos.

Superclave

Una superclave es un conjunto de encabezados de columna cuyos valores concatenados son únicos en todas las filas. Formalmente:

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

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

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

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

Teorema: Una superclave${\displaystyle K}$se mantiene en una relación universo${\displaystyle U}$encima${\displaystyle H}$si y solo si${\displaystyle K\subseteq H}$y${\displaystyle K\rightarrow H}$se sostiene en${\displaystyle U}$.

Clave del candidato

Una clave candidata es una superclave que no se puede subdividir para formar otra superclave.

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

Dependencia funcional

La dependencia funcional es la propiedad que permite que un valor en una tupla se derive de otro valor en esa misma tupla.

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

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

• ${\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${\displaystyle X\rightarrow Y}$se mantiene en una relación universo${\displaystyle U}$si se cumple en todas las relaciones en${\displaystyle U}$.

Dependencia funcional trivial

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

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

Cierre

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

• ${\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${\displaystyle H}$y un conjunto${\displaystyle S}$de FD que solo contienen subconjuntos de${\displaystyle H}$,${\displaystyle X\rightarrow Y\in S^{+}}$si y solo si${\displaystyle X\rightarrow Y}$se mantiene en todos los universos de relación sobre${\displaystyle H}$en el que todos los FD en${\displaystyle S}$mantener. ^{[ 11 ]}

Terminación

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

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

La completitud de un conjunto de atributos puede utilizarse para calcular si una determinada dependencia se encuentra en el cierre de un conjunto de dependencias funcionales.

Teorema: Dado un conjunto${\displaystyle S}$de FD,${\displaystyle X\rightarrow Y\in S^{+}}$si y solo si${\displaystyle Y\subseteq X^{+}}$.

Cubierta irreductible

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

• ${\displaystyle S^{+}=T^{+}}$
• no existe${\displaystyle U\subset T}$de tal manera que${\displaystyle S^{+}=U^{+}}$
• ${\displaystyle X\rightarrow Y\in T~\Rightarrow Y}$es un conjunto unitario y
• ${\displaystyle X\rightarrow Y\in T\land Z\subset X~\Rightarrow ~Z\rightarrow Y\notin S^{+}}$.

El algoritmo deriva claves candidatas a partir de dependencias funcionales. Entrada : un conjunto S de FD que contienen solo subconjuntos de un encabezado H. Salida: el conjunto C de superclaves que se mantienen como claves candidatas. todos los universos de relaciones sobre H en los que se cumplen todas las FD en SC := ∅ // claves candidatas encontradas Q := { H } // superclaves que contienen claves candidatas mientras Q <> ∅ hacer sea K algún elemento de Q Q := Q  – { K } minimal := verdadero para cada X->Y en S hacer K' := ( K  – Y ) ∪ X // derivar nueva superclave si K' ⊂ K entonces minimal := falso Q := Q ∪ { K' } fin si fin para si minimal 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