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 :

Users (or programs) request data from a relational database by sending it a query. In response to a query, the database returns a result set.^[2]

Often, data from multiple tables are combined into one, by doing a join. Conceptually, this is done by taking all possible combinations of rows (the Cartesian product), and then filtering out everything except the answer.^[2]

There are a number of relational operations in addition to join. These include project (the process of eliminating some of the columns), restrict (the process of eliminating some of the rows), union (a way of combining two tables with similar structures), difference (that lists the rows in one table that are not found in the other), intersect (that lists the rows found in both tables), and product (mentioned above, which combines each row of one table with each row of the other). Depending on which other sources you consult, there are a number of other operators – many of which can be defined in terms of those listed above. These include semi-join, outer operators such as outer join and outer union, and various forms of division. Then there are operators to rename columns, and summarizing or aggregating operators, and if you permit relation values as attributes (relation-valued attribute), then operators such as group and ungroup.^[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.

If we attempted to insert a new customer with the ID 123, this would violate the design of the relvar since Customer ID is a primary key and we already have a customer 123. The DBMS must reject a transaction such as this that would render the database inconsistent by a violation of an integrity constraint. However, it is possible to insert another customer named Alice, as long as this new customer has a unique ID, since the Name field is not part of the primary key.

Foreign keys are integrity constraints enforcing that the value of the attribute set is drawn from a candidate key in another relation. For example, in the Order relation the attribute Customer ID is a foreign key. A join is the operation that draws on information from several relations at once. By joining relvars from the example above we could query the database for all of the Customers, Orders, and Invoices. If we only wanted the tuples for a specific customer, we would specify this using a restriction condition. If we wanted to retrieve all of the Orders for Customer 123, we could query the database to return every row in the Order table with Customer ID123 .

There is a flaw in our database design above. The Invoice relvar contains an Order ID attribute. So, each tuple in the Invoice relvar will have one Order ID, which implies that there is precisely one Order for each Invoice. But in reality an invoice can be created against many orders, or indeed for no particular order. Additionally the Order relvar contains an Invoice ID attribute, implying that each Order has a corresponding Invoice. But again this is not always true in the real world. An order is sometimes paid through several invoices, and sometimes paid without an invoice. In other words, there can be many Invoices per Order and many Orders per Invoice. This is a many-to-many relationship between Order and Invoice (also called a non-specific relationship). To represent this relationship in the database a new relvar should be introduced whose role is to specify the correspondence between Orders and Invoices:

OrderInvoice (Order ID, Invoice ID)

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