Modelo relacional

El modelo relacional (RM) es un enfoque para la gestión de datos que utiliza una estructura y un lenguaje consistentes con la lógica de predicados de primer orden, descrito por primera vez en 1969 por un científico informático inglés. Edgar F. Codd, 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 quieren de ella, y dejan que el software del sistema de administración de la base de datos se encargue de describir las estructuras de datos. para el almacenamiento de los datos y los procedimientos de recuperación para responder 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 como 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 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 en contra de las desviaciones que comprometen los principios originales.

Resumen

La idea central de un modelo relacional es describir una base de datos como una colección de predicados sobre un conjunto finito de variables predicadas, describiendo restricciones sobre los posibles valores y combinaciones de valores. El contenido de la base de datos en un momento dado es un modelo finito (lógico) de la base de datos, es decir, un conjunto de relaciones, una por variable de predicado, de modo que se satisfacen todos los predicados. Una solicitud de información de la base de datos (una consulta de la base de datos) también es un predicado.

Conceptos de modelo relacional.

Alternativas

Otros modelos incluyen el modelo jerárquico y el modelo de red. Algunos sistemas que usan estas arquitecturas más antiguas todavía se usan en centros de datos con necesidades de alto volumen de datos, o donde los sistemas existentes son tan complejos y abstractos que sería prohibitivo migrar a sistemas que emplean el modelo relacional. También cabe destacar las bases de datos orientadas a objetos más nuevas.

Implementación

Se han hecho varios intentos para producir una verdadera implementación del modelo de base de datos relacional como lo definió originalmente Codd y lo explicaron Date, Darwen y otros, pero ninguno ha tenido éxito popular hasta el momento. A partir de octubre de 2015, Rel es uno de los intentos más recientes de hacer esto.

El modelo relacional fue el primer modelo de base de datos que se describió en términos matemáticos formales. Las bases de datos jerárquicas y de red existían antes que las bases de datos relacionales, pero sus especificaciones eran relativamente informales. Después de que se definió el modelo relacional, hubo muchos intentos de comparar y contrastar los diferentes modelos, y esto condujo al surgimiento de descripciones más rigurosas de los modelos anteriores; aunque la naturaleza procesal de las interfaces de manipulación de datos para bases de datos jerárquicas y de red limitó el alcance de la formalización.

Los análisis de bases de datos estructurales que emplean protocolos de modalidad relacional emplean con frecuencia diferenciales de secuencia de datos para mantener designaciones de arquitectura jerárquica con la incorporación de nueva entrada. Estos sistemas son funcionalmente similares en concepto a los algoritmos de retransmisión alternativos, que forman la base de la infraestructura de la base de datos en la nube.

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 El Tercer Manifiesto de 1995, Date y Darwen intentan demostrar cómo el modelo relacional puede acomodar ciertos "deseados" características orientadas a objetos.

Extensiones

Algunos años después de la publicación de su modelo de 1970, Codd propuso una versión de lógica de tres valores (Verdadero, Falso, Faltante/NULL) para lidiar con la información faltante, y en su El modelo relacional para la versión de administración de bases de datos 2 (1990) fue un paso más allá con una versión de lógica de cuatro valores (Verdadero, Falso, Falta pero aplicable, Falta pero no aplicable). Estos nunca se han implementado, presumiblemente debido a su complejidad inherente. La construcción NULL de SQL estaba destinada a ser parte de un sistema lógico de tres valores, pero no lo logró debido a errores lógicos en el estándar y en sus implementaciones.

Temas

La suposición fundamental detrás de un modelo relacional es que todos los datos se representan como relaciones matemáticas n-arias, siendo una relación n-aria un subconjunto del producto cartesiano de n dominios. En el modelo matemático, el razonamiento sobre tales datos se realiza en lógica de predicados de dos valores, lo que significa que hay dos posibles evaluaciones para cada proposición: verdadero o falso (y en particular ningún tercer valor como desconocido o no aplicable, cualquiera de los cuales se asocia a menudo con el concepto de NULL). Los datos son operados por medio de un cálculo relacional o álgebra relacional, siendo estos equivalentes en poder expresivo.

El modelo relacional de datos permite al diseñador de la base de datos crear una representación lógica y coherente de la información. La consistencia se logra mediante la inclusión de restricciones declaradas en el diseño de la base de datos, que generalmente se denomina esquema lógico. La teoría incluye un proceso de normalización de bases de datos mediante el cual se puede seleccionar un diseño con ciertas propiedades deseables de un conjunto de alternativas lógicamente equivalentes. Los planes de acceso y otros detalles de implementación y operación son manejados por el motor DBMS y no se reflejan en el modelo lógico. Esto contrasta con la práctica común de los DBMS de SQL en los que el ajuste del rendimiento a menudo requiere cambios en el modelo lógico.

El bloque de construcción relacional básico es el dominio o tipo de datos, generalmente abreviado hoy en día como tipo. Una tupla es un conjunto desordenado de valores de atributos. Un atributo es un par desordenado de nombre de atributo y nombre de tipo. Un valor de atributo es un valor válido específico para el tipo de atributo. Puede ser un valor escalar o un tipo más complejo.

Una relación consta de un encabezado y un cuerpo. Un encabezado es un conjunto de atributos. Un cuerpo (de una relación n-aria) es un conjunto de tuplas n. El encabezamiento de la relación es también el encabezamiento de cada una de sus tuplas.

Una relación se define como un conjunto de n-tuplas. Tanto en las matemáticas como en el modelo de base de datos relacional, un conjunto es una colección desordenada de elementos únicos y no duplicados, aunque algunos DBMS imponen un orden a sus datos. En matemáticas, una tupla tiene un orden y permite la duplicación. E. F. Codd originalmente definió las tuplas usando esta definición matemática. Más tarde, una de las grandes intuiciones de E. F. Codd fue que usar nombres de atributos en lugar de un orden sería más conveniente (en general) en un lenguaje informático basado en relaciones. Esta idea todavía se utiliza hoy en día. Aunque el concepto ha cambiado, el nombre "tuple" no tiene Una consecuencia inmediata e importante de esta característica distintiva es que en el modelo relacional el producto cartesiano se vuelve conmutativo.

Una tabla es una representación visual aceptada de una relación; una tupla es similar al concepto de una fila.

Un relvar es una variable nombrada de algún tipo de relación específico, a la que en todo momento se le asigna alguna relación de ese tipo, aunque la relación pueda contener cero tuplas.

El principio básico del modelo relacional es el Principio de Información: toda la información está representada por valores de datos en relaciones. De acuerdo con este Principio, una base de datos relacional es un conjunto de varrels y el resultado de cada consulta se presenta como una relación.

La coherencia de una base de datos relacional se impone, no mediante reglas integradas en las aplicaciones que la utilizan, sino mediante restricciones, declaradas como parte del esquema lógico y aplicadas por el DBMS para todas las aplicaciones.. En general, las restricciones se expresan mediante operadores de comparación relacional, de los cuales solo uno, "es un subconjunto de" (⊆), es teóricamente suficiente. En la práctica, se espera que estén disponibles varias abreviaturas útiles, de las cuales las más importantes son las restricciones de clave candidata (realmente, superclave) y clave externa.

Interpretación

Para apreciar completamente el modelo relacional de datos, es esencial comprender la interpretación prevista de una relación.

El cuerpo de una relación a veces se llama su extensión. Esto se debe a que debe interpretarse como una representación de la extensión de algún predicado, siendo este el conjunto de proposiciones verdaderas que se pueden formar reemplazando cada variable libre en ese predicado por un nombre (un término que designa algo).

Existe una correspondencia biunívoca entre las variables libres del predicado y los nombres de los atributos del encabezado de la relación. Cada tupla del cuerpo de la relación proporciona valores de atributo para instanciar el predicado sustituyendo cada una de sus variables libres. El resultado es una proposición que, debido a la aparición de la tupla en el cuerpo de la relación, se considera verdadera. Por el contrario, toda tupla cuyo encabezamiento se ajuste al de la relación, pero que no aparezca en el cuerpo, se reputará falsa. Esta suposición se conoce como la suposición del mundo cerrado: a menudo se viola en las bases de datos prácticas, donde la ausencia de una tupla podría significar que se desconoce la verdad de la proposición correspondiente. Por ejemplo, la ausencia de la tupla ('John', 'Español') de una tabla de habilidades lingüísticas no necesariamente puede tomarse como evidencia de que John no habla español.

Para una exposición formal de estas ideas, consulte la sección Formulación de la teoría de conjuntos, a continuación.

Aplicación a bases de datos

Un tipo de datos como se usa en una base de datos relacional típica podría ser el conjunto de números enteros, el conjunto de cadenas de caracteres, el conjunto de fechas o los dos valores booleanos verdadero y falso, y así sucesivamente. Los nombres de tipo correspondientes para estos tipos pueden ser las cadenas "int", "char", "date", "boolean& #34;, etc. Es importante entender, sin embargo, que la teoría relacional no dicta qué tipos se deben admitir; de hecho, hoy en día se espera que haya disposiciones disponibles para los tipos definidos por el usuario además de los integrados proporcionados por el sistema.

Atributo es el término utilizado en la teoría para lo que comúnmente se conoce como una columna. De manera similar, tabla se usa comúnmente en lugar del término teórico relación (aunque en SQL el término no es sinónimo de relación). Una estructura de datos de tabla se especifica como una lista de definiciones de columna, cada una de las cuales especifica un nombre de columna único y el tipo de valores permitidos para esa columna. Un atributo valor es la entrada en una columna y fila específicas, como "John Doe" o "35".

Una tupla es básicamente lo mismo que una fila, excepto en un DBMS SQL, donde se ordenan los valores de columna en una fila. (Las tuplas no están ordenadas; en cambio, cada valor de atributo se identifica únicamente por el nombre del atributo y nunca por su posición ordinal dentro de la tupla). Un nombre de atributo podría ser "nombre" o "edad".

Una relación es una definición de estructura de tabla (un conjunto de definiciones de columna) junto con los datos que aparecen en esa estructura. La definición de la estructura es el título y los datos que aparecen en él son el cuerpo, un conjunto de filas. Una base de datos relvar (variable de relación) se conoce comúnmente como una 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 se le asignó más recientemente al invocar algún operador de actualización (normalmente, INSERTAR, ACTUALIZAR o ELIMINAR). El encabezado y el cuerpo de la tabla resultante de la evaluación de alguna consulta están determinados por las definiciones de los operadores utilizados en la expresión de esa consulta. (Tenga en cuenta que en SQL el encabezado no siempre es un conjunto de definiciones de columna como se describe anteriormente, porque es posible que una columna no tenga nombre y también que dos o más columnas tengan el mismo nombre. Además, el cuerpo no siempre es un conjunto de filas porque en SQL es posible que la misma fila aparezca más de una vez en el mismo cuerpo).

SQL y el modelo relacional

SQL, inicialmente impulsado como lenguaje estándar para bases de datos relacionales, se desvía del modelo relacional en varios lugares. El estándar ISO SQL actual no menciona el modelo relacional ni utiliza términos o conceptos relacionales. Sin embargo, es posible crear una base de datos conforme al modelo relacional usando SQL si no se usan ciertas características de SQL.

Las siguientes desviaciones del modelo relacional se han observado en SQL. Tenga en cuenta que pocos servidores de bases de datos implementan todo el estándar SQL y, en particular, no permiten algunas de estas desviaciones. Mientras que NULL es omnipresente, por ejemplo, permitir nombres de columna duplicados dentro de una tabla o columnas anónimas es poco común.

Ruedas duplicadas

La misma fila puede aparecer más de una vez en una tabla SQL. El mismo tuple no puede aparecer más de una vez en una relación.

Columnas anónimas

Una columna en una tabla SQL puede ser nombrada y por lo tanto incapaz de ser referenciada en expresiones. El modelo relacional requiere que cada atributo sea nombrado y referenciable.

Nombres de columna duplicados

Dos o más columnas de la misma tabla SQL pueden tener el mismo nombre y por lo tanto no pueden ser referenciadas, debido a la ambigüedad obvia. El modelo relacional requiere que cada atributo sea referenciable.

Significado del orden de columna

El orden de las columnas en una tabla SQL es definido y significativo, una consecuencia es que las implementaciones de SQL del producto cartesiano y la unión no son recíprocas. El modelo relacional requiere que no haya importancia para cualquier orden de los atributos de una relación.

Vistas sin CHECK OPTION

Las actualizaciones a una vista definida sin la OPCIÓN CHECK pueden ser aceptadas, pero la actualización resultante a la base de datos no necesariamente tiene el efecto expresado en su objetivo. Por ejemplo, una invocación de INSERT puede ser aceptada pero las filas insertadas no pueden aparecer en la vista, o una invocación de UPDATE puede resultar en que las filas desaparezcan desde la vista. El modelo relacional requiere actualizaciones para tener el mismo efecto que si la vista fuera un relvar base.

Tablas sin columna no reconocidas

SQL requiere que cada tabla tenga al menos una columna, pero hay dos relaciones de grado cero (de cardenalidad uno y cero) y son necesarias para representar extensiones de predicados que no contienen variables libres.

NULL

Esta marca especial puede aparecer en lugar de un valor donde un valor pueda aparecer en SQL, en particular en lugar de un valor de columna en alguna fila. La desviación del modelo relacional surge del hecho de que la aplicación de este ad hoc concepto en SQL implica el uso de la lógica de tres valores, bajo la cual la comparación de NULL con sí mismo no produce verdadero pero en cambio da el tercer valor de la verdad, desconocida; similarmente la comparación NULL con algo distinto a sí mismo no produce falso pero en cambio cede desconocida. Es debido a este comportamiento en comparaciones que NULL se describe como una marca en lugar de un valor. El modelo relacional depende de la ley del centro excluido bajo la cual cualquier cosa que no sea verdadera es falsa y cualquier cosa que no sea falsa es verdadera; también requiere que cada tuple en un cuerpo de relación tenga un valor para cada atributo de esa relación. Esta desviación particular es disputada por algunos si sólo porque E.F. Codd finalmente defendió el uso de marcas especiales y una lógica de 4 valores, pero esto se basó en su observación de que hay dos razones distintas por las que uno podría querer utilizar una marca especial en lugar de un valor, lo que llevó a los opositores al uso de tales lógicas para descubrir razones más distintas y por lo menos hasta 19 han sido notados, lo que requeriría una lógica de 21 valor. SQL usa NULL para varios fines distintos a representar "valor desconocido". Por ejemplo, la suma del conjunto vacío es NULL, lo que significa cero, el promedio del conjunto vacío es NULL, lo que significa que no está definido, y NULL aparece en el resultado de un LEFT JOIN puede significar "ningun valor porque no hay fila coincidente en el operado derecho". Hay maneras de diseñar tablas para evitar la necesidad de NULL, por lo general lo que puede considerarse o parecer altos grados de normalización de la base de datos, pero muchos encuentran tan poco práctico. Puede ser un tema de debate caliente.

Operaciones relacionales

Los usuarios (o programas) solicitan datos de una base de datos relacional enviándole una consulta escrita en un lenguaje especial, generalmente un dialecto de SQL. Aunque SQL originalmente estaba destinado a los usuarios finales, es mucho más común que las consultas de SQL se incrusten en un software que proporciona una interfaz de usuario más sencilla. Muchos sitios web, como Wikipedia, realizan consultas SQL al generar páginas.

En respuesta a una consulta, la base de datos devuelve un conjunto de resultados, que es solo una lista de filas que contienen las respuestas. La consulta más simple es simplemente devolver todas las filas de una tabla, pero más a menudo, las filas se filtran de alguna manera para devolver solo la respuesta deseada.

A menudo, los datos de varias tablas se combinan en una sola mediante una unión. Conceptualmente, esto se hace tomando todas las combinaciones posibles de filas (el producto cartesiano) y luego filtrando todo excepto la respuesta. En la práctica, los sistemas de administración de bases de datos relacionales reescriben ("optimizan") las consultas para que funcionen más rápido, utilizando una variedad de técnicas.

Hay una serie de operaciones relacionales además de unirse. Estos incluyen proyecto (el proceso de eliminar algunas de las columnas), restringir (el proceso de eliminar algunas de las filas), unión (una forma de combinar dos tablas con estructuras similares), diferencia (que enumera las filas en una tabla que son no se encuentra en la otra), intersección (que enumera las filas que se encuentran en ambas tablas) y producto (mencionado anteriormente, que combina cada fila de una tabla con cada fila de la otra). Dependiendo de qué otras fuentes consulte, hay una serie de otros operadores, muchos de los cuales se pueden definir en términos de los enumerados anteriormente. Estos incluyen semi-unión, operadores externos como unión externa y unión externa, y varias formas de división. Luego están los operadores para cambiar el nombre de las columnas y los operadores de resumen o agregación, y si permite valores de relación como atributos (atributo de valor de relación), entonces operadores como agrupar y desagrupar. La declaración SELECT en SQL sirve para manejar todo esto excepto los operadores de grupo y desagrupación.

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

Normalización de bases de datos

Las relaciones se clasifican según los tipos de anomalías a las que son vulnerables. Una base de datos que está en la primera forma normal es vulnerable a todo tipo de anomalías, mientras que una base de datos que está en la forma normal de dominio/clave no tiene anomalías de modificación. Las formas normales son de naturaleza jerárquica. Es decir, el nivel más bajo es la primera forma normal, y la base de datos no puede cumplir con los requisitos para las formas normales de nivel superior sin haber cumplido primero con todos los requisitos de las formas normales menores.

Ejemplos

Base de datos

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

• ClienteID de cliente, ID fiscal, nombre, dirección, ciudad, estado, postal, teléfono, correo electrónico, sexo)
• Orden (Orden)Orden No, ID de cliente, Factura No, Fecha Lugar, Fecha Prometida, Términos, Estado)
• Línea de orden (Orden No, Línea de orden No, Código de producto, Qty)
• Factura (Invocación)Factura No, ID de cliente, Orden No, Fecha, Estado)
• Línea de facturación (Factura No, Línea de facturación No, Código de producto, Qty Shipped)
• Producto (Código de producto, Descripción del producto)

En este diseño tenemos seis referencias: Cliente, Pedido, Línea de pedido, Factura, Línea de factura y Producto. Los atributos subrayados en negrita son claves candidatas. Los atributos subrayados que no están en negrita son claves foráneas.

Por lo general, una clave candidata se elige para llamarla clave principal y se usa con preferencia sobre las otras claves candidatas, que luego se denominan claves alternativas.

Una clave candidata es un identificador único que impone que no se duplicará ninguna tupla; esto convertiría la relación en otra cosa, a saber, 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 compuestas por varios atributos. A continuación se muestra una representación tabular de una relación de nuestro ejemplo Customer relvar; una relación se puede considerar como un valor que se puede atribuir a un relvar.

Relación con el cliente

Si intentáramos insertar un nuevo cliente con el ID 1234567890, esto violaría el diseño de la varrel ya que ID del cliente es una clave principal y ya tenemos un cliente 1234567890. 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.

Las claves foráneas son restricciones de integridad que obligan a 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. Un join es la operación que extrae información de varias relaciones a la vez. Al unir las variables reales 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, especificaríamos esto usando una condición de restricción.

Si quisiéramos recuperar todos los pedidos del cliente 1234567890, podríamos consultar la base de datos para obtener cada fila de la tabla de pedidos con ID de cliente 1234567890 y una la tabla Pedido a la tabla Línea de pedido según el Número de pedido.

Hay una falla en el diseño de nuestra base de datos anterior. La var. de factura contiene un atributo N.º de pedido. Entonces, cada tupla en la var. factura tendrá un No. de Pedido, lo que implica que hay precisamente un Pedido para cada Factura. Pero, en realidad, se puede crear una factura para muchos pedidos o, de hecho, para ningún pedido en particular. Además, la varrel de Pedido contiene un atributo Número de factura, lo que implica que cada Pedido tiene una Factura correspondiente. Pero, de nuevo, esto no siempre es cierto en el mundo real. A veces, un pedido se paga mediante varias facturas y, a veces, se paga sin factura. En otras palabras, puede haber muchas Facturas por Pedido y muchas Órdenes por Factura. Esta es una relación muchos a muchos entre el Pedido y la Factura (también denominada relación no específica). Para representar esta relación en la base de datos se debe introducir un nuevo relvar cuya función es especificar la correspondencia entre Pedidos y Facturas:

OrderInvoiceOrden No, Factura No)

Ahora, la var.rel del pedido tiene una relación de uno a varios con la tabla FacturaPedido, al igual que la var.rel de la factura. Si queremos recuperar todas las facturas de un pedido en particular, podemos consultar todos los pedidos en los que el número de pedido en la relación del pedido sea igual al número de pedido en OrderInvoice, y donde Factura No en OrderInvoice es igual al Factura No en Invoice.

Formulación de teoría de conjuntos

Nociones básicas en el modelo relacional son nombres y nombres. Representaremos estos como cadenas como "Person" y "nombre" y por lo general usaremos las variables r,s,t,...... {displaystyle r,s,t,ldots } y a,b,c{displaystyle a,b,c}...para cubrirlos. Otra noción básica es el conjunto de valores atómicos que contiene valores como números y cadenas.

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

Tuple

Un tuple es una función parcial de nombres de atributos a valores atómicos.

Header

Un encabezado es un conjunto finito de nombres de atributos.

Proyección

La proyección de un tuple t{displaystyle t} en un conjunto finito de atributos A{displaystyle A} es t[A]={}()a,v):()a,v)▪ ▪ t,a▪ ▪ A}{displaystyle t[A]={(a,v):(a,v)in t,ain A}.

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

Relación

Una relación es un tuple ()H,B){displaystyle (H,B)} con H{displaystyle H., el encabezado, y B{displaystyle B}, el cuerpo, un conjunto de tuplas que todos tienen el dominio H{displaystyle H..

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

universo de la relación

Un universo de relación U{displaystyle U} sobre una cabecera H{displaystyle H. es un conjunto no vacío de relaciones con el encabezado H{displaystyle H..

esquema de la relación

Un esquema de relación ()H,C){displaystyle (H,C)} consiste en un encabezado H{displaystyle H. y un predicado C()R){displaystyle C(R)} que se define para todas las relaciones R{displaystyle R. con cabecera H{displaystyle H.. Una relación satisface un esquema de relación ()H,C){displaystyle (H,C)} si tiene cabecera H{displaystyle H. y satisfizos C{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 clave. Nos dice que en cada instancia de un cierto esquema relacional las tuplas pueden ser identificadas por sus valores para ciertos atributos.

Superkey

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

Un superkey está escrito como un conjunto finito de nombres de atributos.

Un superkey K{displaystyle K} mantiene en una relación ()H,B){displaystyle (H,B)} si:

• K⊆ ⊆ H{displaystyle Ksubseteq H. y
• no existen dos tuples distintos t1,t2▪ ▪ B{displaystyle t_{1},t_{2}in B. tales que t1[K]=t2[K]{displaystyle [K]=t_{2} [K].

Un superkey sostiene en un universo de relación U{displaystyle U} si se mantiene en todas las relaciones U{displaystyle U}.

Teorema: Un superkey K{displaystyle K} sostiene en un universo de relación U{displaystyle U} sobre H{displaystyle H. si K⊆ ⊆ H{displaystyle Ksubseteq H. y K→ → H{displaystyle Krightarrow H. en U{displaystyle U}.

Candidato clave

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

Un superkey K{displaystyle K} sostiene como una clave candidata para un universo de relación U{displaystyle U} si se mantiene como un superkey para U{displaystyle U} y no hay subconjunto adecuado K{displaystyle K} que también es un superkey para U{displaystyle U}.

Dependencia funcional

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

Una dependencia funcional (FD para abreviar) se escribe como X→ → Y{displaystyle Xderecho Sí. para X,Y{displaystyle X,Y} conjuntos finitos de nombres de atributos.

Una dependencia funcional X→ → Y{displaystyle Xderecho Sí. mantiene en una relación ()H,B){displaystyle (H,B)} si:

• X,Y⊆ ⊆ H{displaystyle X,Ysubseteq H. y
• О О {displaystyle forall } tuples t1,t2▪ ▪ B{displaystyle t_{1},t_{2}in B., t1[X]=t2[X]⇒ ⇒ t1[Y]=t2[Y]{displaystyle [X]=t_{2} [X]~Rightarrow ~t_{1}[Y]=t_{2}[Y]

Una dependencia funcional X→ → Y{displaystyle Xderecho Sí. sostiene en un universo de relación U{displaystyle U} si se mantiene en todas las relaciones U{displaystyle U}.

Dependencia funcional trivial

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

Teorema: Un FD X→ → Y{displaystyle Xderecho Sí. es trivial bajo un encabezado H{displaystyle H. si Y⊆ ⊆ X⊆ ⊆ H{displaystyle Ysubseteq Xsubseteq H}.

Clausura

Los axiomas de Armstrong: El cierre de un conjunto de FDs S{displaystyle S. bajo una cabecera H{displaystyle H., escrito como S+{displaystyle S^{+}, es el superset más pequeño S{displaystyle S. tal que:

• Y⊆ ⊆ X⊆ ⊆ H⇒ ⇒ X→ → Y▪ ▪ S+{displaystyle Ysubseteq Xsubseteq H~Rightarrow ~Xrightarrow Yin S^{+} (reflexividad)
• X→ → Y▪ ▪ S+∧ ∧ Y→ → Z▪ ▪ S+⇒ ⇒ X→ → Z▪ ▪ S+{displaystyle Xrightarrow Yin S^{+}land Yrightarrow Zin S^{+}~ Derecho ~Xrightarrow Zin S^{+} (transitividad) y
• X→ → Y▪ ▪ S+∧ ∧ Z⊆ ⊆ H⇒ ⇒ ()X∪ ∪ Z)→ → ()Y∪ ∪ Z)▪ ▪ S+{displaystyle Xrightarrow Yin S^{+}land Zsubseteq H~Rightarrow ~(Xcup Z)rightarrow (Ycup Z)in S^{+} (aumentación)

Teorema: Los axiomas de Armstrong son sanos y completos; dado un encabezado H{displaystyle H. y un set S{displaystyle S. de las FD que sólo contienen subconjuntos de H{displaystyle H., X→ → Y▪ ▪ S+{displaystyle Xrightarrow Yin S^{+} si X→ → Y{displaystyle Xderecho Sí. mantiene en todos los universos de relación sobre H{displaystyle H. en que todos los FD en S{displaystyle S. Espera.

Terminación

La terminación de un conjunto finito de atributos X{displaystyle X} bajo un conjunto finito de FDs S{displaystyle S., escrito como X+{displaystyle X^{+}, es el superset más pequeño X{displaystyle X} tal que:

• Y→ → Z▪ ▪ S∧ ∧ Y⊆ ⊆ X+⇒ ⇒ Z⊆ ⊆ X+{displaystyle Y'rightarrow Zin Sland Ysubseteq X^{+}~ Derecho -Zsubseteq X^{+}

La terminación de un conjunto de atributos se puede utilizar para calcular si una cierta dependencia está en el cierre de un conjunto de FDs.

Teorema: Dado un conjunto S{displaystyle S. de FDs, X→ → Y▪ ▪ S+{displaystyle Xrightarrow Yin S^{+} si Y⊆ ⊆ X+{displaystyle Y subseteq X^{+}.

Cubierta irreducible

Una cubierta irreducible de un conjunto S{displaystyle S. FDs es un conjunto T{displaystyle T} of FDs such that:

• S+=T+{displaystyle S^{+}=T^{+}
• no existe U⊂ ⊂ T{displaystyle Usubset T} tales que S+=U+{displaystyle S^{+}=U^{+}
• X→ → Y▪ ▪ T⇒ ⇒ Y{displaystyle Xrightarrow Yin T~Rightarrow Sí. es un conjunto de singleton y
• X→ → Y▪ ▪ T∧ ∧ Z⊂ ⊂ X⇒ ⇒ Z→ → Y∉ ∉ S+{displaystyle Xrightarrow Yin Tland Zsubset X~Rightarrow ~Zrightarrow Ynotin S^{+}.

Algoritmo para derivar claves candidatas a partir de dependencias funcionales

algoritmo derivar claves candidatas de las dependencias funcionales es entrada: un conjunto S de las FD que contienen sólo subconjuntos de un encabezado H Producto: el conjunto C de superkeys que sostienen como claves candidatas en
todos los universos de relación sobre H en que todos los FD en S Espera.

 C:= ∅ // encontrados
 Q# H } // superkeys que contienen las teclas candidatas
 mientras Q Identificado doDeja K ser un elemento de Q Q:= Q- K }
 mínimo:= verdadero para cada uno X-Consejo dentro S do K ' :=K– Y∪ X // derivar nuevo superkey
 si K ' ⊂ K entonces mínimo:= falso Q:= Q. K ' }
 terminar si final for si mínimo y no hay un subconjunto de K dentro C entonceseliminar todos los supersets de K desde C C:= C. K }
 terminar si terminar mientras