En la teoría de bases de datos relacionales, se llama una tabla. Teoría de bases de datos relacionales: normalización, relaciones y uniones. Claves de relación

El álgebra relacional se basa en la teoría de conjuntos y es la base de la lógica de la base de datos.
Cuando apenas estaba aprendiendo sobre bases de datos y SQL, una introducción preliminar al álgebra relacional realmente ayudó a que mis conocimientos encajaran correctamente en mi cabeza, e intentaré que este artículo tenga un efecto similar.

Entonces, si va a comenzar sus estudios en esta área o simplemente se interesó, por favor, en cat.

Base de datos relacional

Para empezar, introducimos el concepto de una base de datos relacional en la que realizaremos todas las acciones.

Una base de datos relacional es un conjunto de relaciones que contiene toda la información que debe almacenarse en la base de datos. En esta definición nos interesa el término relación, pero por ahora lo dejaremos sin una definición rigurosa.
Mejor imagina una tabla de productos.

tabla de PRODUCTOS

IDENTIFICACIÓN	NOMBRE	EMPRESA	PRECIO
123	galletas	OOO "Lado oscuro"	190
156	Té	OOO "Lado oscuro"	60
235	piñas	JSC ”Frutas”	100
623	Tomates	OOO ”Verduras”	130

La tabla consta de 4 filas, una fila en la tabla es una tupla en la teoría relacional. Un conjunto de tuplas ordenadas se llama relación.
Antes de definir una relación, introduzcamos un término más: dominio. Los dominios en relación con la tabla son columnas.

Para mayor claridad, ahora presentamos una definición estricta de una relación.

Sean dados N conjuntos D1, D2, …. Dn (dominios), la relación R sobre estos conjuntos es el conjunto de N-tuplas ordenadas de la forma , donde d1 pertenece a D1, y así sucesivamente. Los conjuntos D1,D2,..Dn se denominan dominios de la relación R.
Cada elemento de la tupla es el valor de uno de los atributos correspondientes a uno de los dominios.

Claves de relación

El requisito de relación es que todas las tuplas deben ser distintas. Para identificar de forma única una tupla, hay una clave principal. Una clave principal es un atributo o conjunto del número mínimo de atributos que identifica de forma única una tupla en particular y no contiene atributos adicionales.
Se da a entender que todos los atributos de la clave principal deben ser necesarios y suficientes para identificar una tupla en particular, y la omisión de cualquiera de los atributos de una clave la haría insuficiente para la identificación.
Por ejemplo, en una tabla de este tipo, la clave será una combinación de atributos de la primera y la segunda columna.

tabla de CONDUCTORES

Se puede ver que puede haber varios conductores en una organización, y para identificar de forma única a un conductor, se requieren tanto el valor de la columna "Nombre de la organización" como el de la columna "Nombre del conductor". Tal clave se llama clave compuesta.

En una base de datos relacional, las tablas están interconectadas y correlacionadas entre sí como maestras y esclavas. La relación entre las tablas principal y subordinada se realiza a través de la llave primaria (primary key) de la tabla principal y la llave foránea (foreign key) de la tabla subordinada.
Una clave externa es un atributo o conjunto de atributos que es la clave principal en la tabla principal.

Esta teoría preparatoria será suficiente para introducirte a las operaciones básicas del álgebra relacional.

Operaciones de álgebra relacional

Las ocho operaciones principales del álgebra relacional fueron propuestas por E. Codd.

Una asociación
intersección
Sustracción
producto cartesiano
Muestra
Proyección
Compuesto
División

La primera mitad de las operaciones son similares a las mismas operaciones en conjuntos. Algunas operaciones pueden expresarse en términos de otras operaciones. Considere la mayoría de las operaciones con ejemplos.

Para entender, es importante recordar que el resultado de cualquier operación de álgebra sobre relaciones es otra relación, que luego también puede usarse en otras operaciones.
Vamos a crear otra tabla que nos será útil en los ejemplos.

mesa VENDEDORES

IDENTIFICACIÓN	VENDEDOR
123	OOO "dardo"
156	OJSC ”Vedro”
235	CJSC “Baza Vegetal”
623	JSC ”Firma”

Supongamos que en esta tabla, ID es una clave externa asociada con la clave principal de la tabla PRODUCTOS.

Comencemos con la operación más simple: el nombre de la relación. Su resultado será la misma relación, es decir, al realizar la operación PRODUCTOS obtendremos una copia de la relación PRODUCTOS.

Proyección

Una proyección es una operación en la que solo se extraen de la relación los atributos de los dominios especificados, es decir, solo se seleccionan de la tabla las columnas necesarias, y si se obtienen varias tuplas idénticas, solo queda una instancia de dicha tupla en la relación resultante.
Por ejemplo, hagamos una proyección en la tabla PRODUCTOS seleccionando ID y PRECIO de ella.

Sintaxis de la operación:
π (ID, PRECIO) PRODUCTOS

En la condición de selección, podemos usar cualquier expresión lógica. Hagamos otra selección con un precio superior a 90 y un ID de producto inferior a 300:

σ (PRECIO>90 ^ DNI<300) PRODUCTS

Multiplicación

La multiplicación o producto cartesiano es una operación que se realiza sobre dos relaciones, por lo que a partir de las dos relaciones iniciales obtenemos una relación con todos los dominios. Las tuplas en estos dominios serán todas las combinaciones posibles de tuplas de las relaciones iniciales. Un ejemplo lo hará más claro.

Obtengamos el producto cartesiano de las tablas PRODUCTOS y VENDEDORES.
Sintaxis de la operación:

PRODUCTOS × VENDEDORES
Puede ver que estas dos tablas tienen el mismo ID de dominio. En tal situación, los dominios con el mismo nombre tienen el prefijo del nombre de la relación correspondiente, como se muestra a continuación.
Por brevedad, no multiplicamos las proporciones completas, sino las muestras con el ID de condición<235

(las mismas tuplas están resaltadas en color)

ID DE PRODUCTOS	NOMBRE	EMPRESA	PRECIO	IDENTIFICACIÓN DEL VENDEDOR	VENDEDOR
123	galletas	OOO "Lado oscuro"	190	123	OOO "dardo"
156	Té	OOO "Lado oscuro"	60	156	OJSC ”Vedro”
123	galletas	OOO "Lado oscuro"	190	156	OJSC ”Vedro”
156	Té	OOO "Lado oscuro"	60	123	OOO "dardo"

Para ver un ejemplo del uso de esta operación, imagine la necesidad de seleccionar vendedores con precios inferiores a 90. Sin el producto, primero necesitaría obtener los ID de producto de la primera tabla, luego usar estos ID de la segunda tabla para obtener la información necesaria. VENDEDOR nombres, y utilizando el producto, la siguiente consulta sería:

π (VENDEDOR) σ (PRODUCTOS.ID=VENDEDORES.ID ^ PRECIO<90) PRODUCTS × SELLERS

Como resultado de esta operación, obtenemos la relación:

VENDEDOR

OJSC ”Vedro”

Conexión y conexión natural

La operación de unión es lo opuesto a la operación de proyección y crea una nueva relación a partir de dos existentes. Se obtiene una nueva relación concatenando las tuplas de la primera y la segunda relación, mientras se concatenan las relaciones en las que coinciden los valores de los atributos dados. En particular, si une las relaciones PRODUCTOS y VENDEDORES, estos atributos serán los atributos de los dominios ID.

Además, para mayor claridad, puede representar la conexión como el resultado de dos operaciones. Primero se toma el producto de las tablas fuente, y luego de la relación resultante hacemos una selección con la condición de igualdad de atributos de los mismos dominios. En este caso, la condición es la igualdad de PRODUCTS.ID y SELLERS.ID.

Intentemos conectar la relación PRODUCTOS y VENDEDORES y obtener la relación.

ID DE PRODUCTOS	NOMBRE	EMPRESA	PRECIO	IDENTIFICACIÓN DEL VENDEDOR	VENDEDOR
123	galletas	OOO "Lado oscuro"	190	123	OOO "dardo"
156	Té	OOO "Lado oscuro"	60	156	OJSC ”Vedro”
235	piñas	JSC ”Frutas”	100	235	CJSC “Baza Vegetal”
623	Tomates	OOO ”Verduras”	130	623	JSC ”Firma”

Una unión natural obtiene una relación similar, pero si tenemos un esquema correctamente configurado en la base de datos (en este caso, la clave principal de la tabla de ID de PRODUCTOS está vinculada a la clave externa de la tabla de ID de VENDEDORES), entonces hay una ID dominio en la relación resultante.

Sintaxis de la operación:
PRODUCTOS ⋈ VENDEDORES;

Obtienes esta relación:

ID DE PRODUCTOS	NOMBRE	EMPRESA	PRECIO	VENDEDOR
123	galletas	OOO "Lado oscuro"	190	OOO "dardo"
156	Té	OOO "Lado oscuro"	60	OJSC ”Vedro”
235	piñas	JSC ”Frutas”	100	CJSC “Baza Vegetal”
623	Tomates	OOO ”Verduras”	130	JSC ”Firma”

Intersección y resta.

El resultado de la operación de intersección será una relación formada por tuplas totalmente incluidas en ambas relaciones.
El resultado de la resta será una relación formada por tuplas que son tuplas de la primera relación y no son tuplas de la segunda relación.
Estas operaciones son similares a las mismas operaciones en conjuntos, por lo que creo que no hay necesidad de describirlas en detalle.

Fuentes de información

Fundamentos del uso y diseño de bases de datos - V. M. Ilyushechkin
curso de conferencias Introducción a las bases de datos - Jennifer Widom, Universidad de Stanford

Agradecería comentarios razonados.

Una base de datos (DB) es una colección organizada de datos. La organización de los datos suele tener por objeto reflejar la relación real de los datos almacenados de forma que se facilite el tratamiento de esta información.

DBMS - sistemas de gestión de bases de datos - es un software especializado diseñado, como era de esperar, para gestionar bases de datos. Esto se logra mediante la interacción con el usuario por un lado y con la propia base de datos por el otro.

Un DBMS de propósito general debe permitir definir, crear, modificar, administrar y consultar la base de datos.

Los ejemplos de DBMS incluyen paquetes tan conocidos como

mysql
postgresql
Servidor SQL de Microsoft
Oráculo
ibmdb2
acceso Microsoft
SQLite

Las bases de datos generalmente no son portátiles entre diferentes DBMS, pero la interoperabilidad entre DBMS (y con el software del usuario) es posible utilizando varios estándares como SQL, ODBC o JDBC.

Los RDBMS a menudo se clasifican según el modelo de datos que admiten. Desde la década de 1980, casi todos los DBMS populares han admitido el modelo de datos relacionales representado por el estándar del lenguaje de consulta SQL (aunque NoSQL ha ganado popularidad en los últimos años).

Entonces, las principales tareas realizadas por el DBMS incluyen

Definición del esquema de datos Creación, modificación y eliminación de estructuras que definen la organización de todos los demás datos en la base de datos Modificación de datos Adición, modificación y eliminación de los propios datos Recuperación de datos Suministro de información en un formato que otras aplicaciones pueden utilizar directamente. Administración de bases de datos Registro y gestión de usuarios, seguridad de datos, mantenimiento de integridad, recuperación de información, control de concurrencia, monitoreo de desempeño, etc.

Los DBMS son ampliamente utilizados en banca, empresas de transporte, instituciones educativas, telecomunicaciones, gestión de información financiera y recursos humanos. Pues no olvides que la mayoría de los backends de la Web utilizan uno u otro DBMS.

Una de las principales características del desarrollo de bases de datos es el hecho de que no existen soluciones ni algoritmos listos para usar. Cada base de datos es específica para la tarea para la que está diseñada. Esto distingue el desarrollo de bases de datos del desarrollo de aplicaciones típicas para las que se han desarrollado algoritmos y patrones de diseño durante mucho tiempo y no hay necesidad de inventar nada especial. Aunque, por supuesto, las técnicas de diseño de bases de datos son comunes a todas las aplicaciones.

Modelos de base de datos

Como se mencionó anteriormente, el modelo de datos más utilizado es el modelo relacional. Sin embargo, la aparición del modelo relacional estuvo precedida por otros, en particular

Modelo jerárquico o de navegación
modelo de red

El modelo jerárquico fue ampliamente utilizado en el DBMS suministrado por IBM en la década de 1960. La idea principal es que un registro en dicha base de datos puede tener varios "hijos" y un "padre". En general, se parece sospechosamente a un sistema de archivos jerárquico. Para obtener un registro en una base de datos de este tipo, a menudo es necesario recorrer todo el árbol.

El modelo de red es una versión más flexible del mismo enfoque. Le permite tener múltiples entradas "principales". Este modelo, que apareció a principios de la década de 1970, no fue muy utilizado y pronto fue reemplazado por el modelo relacional.

En la década de 1970, Edgar Codd (empleado de IBM) propuso un modelo relacional que facilitaba mucho la tarea de buscar información en una base de datos. Puede pensar en el modelo relacional como "tablas" donde las "filas" son los registros en la base de datos. Los registros en una base de datos relacional también se denominan tuplas y los grupos de registros ("tablas") se denominan relaciones. El modelo relacional es capaz de expresar las relaciones de los modelos jerárquico y de red, y ha añadido sus propias relaciones correspondientes al modelo tabular.

Basado en las propuestas de Codd, System R DBMS se desarrolló a mediados de la década de 1970 y, al final, tenía soporte para el lenguaje de consulta SQL estandarizado.

En la década de 1980, con el advenimiento de la programación orientada a objetos, se hizo cada vez más difícil traducir los objetos a un modelo relacional. Al final, esto condujo a la aparición de los enfoques NoSQL y NewSQL, que actualmente solo se están desarrollando. Ejemplos de la implementación del enfoque NoSQL pueden ser los llamados. bases de datos orientadas a documentos construidas sobre la base de XML. La principal ventaja de NoSQL es su alta escalabilidad horizontal, es decir, la capacidad de aumentar el rendimiento agregando servidores. Con la llegada de la computación en la nube, NoSQL se ha vuelto especialmente demandado.

Sin embargo, el modelo relacional sigue siendo el más común, por lo que nos detendremos en él con más detalle.

modelo relacional

El modelo relacional opera en términos de registros, atributos y relaciones. La relación se puede considerar como una tabla bidimensional, luego los atributos son las columnas de la tabla (más precisamente, los nombres de las columnas) y los registros son las filas de la tabla.

El modelo relacional requiere una definición estricta de la estructura de datos almacenada en la base de datos, es decir, las relaciones y los atributos de esta base de datos son fijos.

Introduzcamos algunas definiciones.

Dominio Un conjunto que contiene el conjunto completo de todos los valores posibles para alguna variable. Los dominios a menudo se denominan tipo de datos. Atributo de par ordenado nombres de atributos y dominio \(D_j\) . Tupla Conjunto ordenado finito \((d_1, d_2, \ldots, d_n)\) Tupla de encabezado de relación (esquema) \((A_1, A_2, \ldots, A_n)\) , donde \(A_j\) son atributos. Valor de atributo Un valor específico que pertenece al dominio del atributo. Cuerpo de relación Un conjunto de tuplas, donde \(d^i_j \in D_j\) , \(D_j\) son dominios. Grabar tupla \((d^i_1, d^i_2, \ldots, d^i_n)\) para \(i\) fijo. Relación La combinación del encabezado de la relación y el cuerpo de la relación. Esquema de base de datos El conjunto de esquemas para todas las relaciones incluidas en la base de datos.

Puede representar la relación en forma de tabla. Entonces el cuerpo de la relación es el cuerpo de la tabla, el encabezado de la relación es el encabezado de la tabla, los atributos son los nombres de las columnas, los registros son las filas y los valores de los atributos están en las celdas:

\(A_1\)	\(A_2\)	\(\ldots\)	\(Un\)	← Título
\(d^1_1\)	\(d^1_2\)	\(\ldots\)	\(d^1_n\)	← Grabación
\(d^2_1\)	\(d^2_2\)	\(\ldots\)	\(d^2_n\)	← Grabación
\(\ldots\)	\(\ldots\)	\(\ldots\)	\(\ldots\)	← Grabación
\(d^m_1\)	\(d^m_2\)	\(\ldots\)	\(d^m_n\)	← Grabación

El modelo relacional impone los siguientes requisitos adicionales a las relaciones:

Está claro que los atributos (más precisamente, sus valores) de alguna manera dependen unos de otros; de lo contrario, la relación resulta ser solo un conjunto de datos no estructurados. Para determinar las dependencias entre atributos se utiliza el concepto dependencia funcional.

Dependencia funcional Un conjunto de atributos \(B\) depende funcionalmente de un conjunto de atributos \(A\) (escrito \(A\rightarrow B\) ) si para cualquiera de los dos registros que tienen el mismo valor \(A\) , su los valores \( B\) coinciden. De lo contrario, cada valor \(A\) corresponde a un solo valor \(B\) (no necesariamente único, solo único).

En otras palabras, si algún conjunto de atributos \(A\) determina de forma única (dentro de la relación dada) los valores de los atributos \(B\), entonces \(B\) depende funcionalmente de \(A\) .

Como un ejemplo más familiar de dependencia funcional, podemos citar la definición matemática de una función. Para una función, cada valor de argumento corresponde a un solo valor de función. Lo contrario generalmente no es cierto, por ejemplo, para la función \(y = sin(x)\) cualquier valor \(y\) del dominio \(1\geq y \geq -1\) corresponde a un conjunto infinito de valores \(x\ ) , pero para cada valor \(x\) hay exactamente un valor \(y\) , entonces \(x \a y\) . Tenga en cuenta que el concepto de dependencia funcional también es aplicable a funciones de muchas variables. Para ellos, el valor de la función depende funcionalmente de todos los argumentos al mismo tiempo. Digamos que para la función \(z = f(x,y)\) se cumple la FZ \((x,y)\to z\) , o \(xy\to z\) para abreviar.

Las relaciones en este contexto pueden ser vistas como tabular o funciones discretas.

Trabajando con la Ley Federal

Hay ciertas reglas formales para trabajar con relaciones FZ.

Las reglas formales están íntimamente relacionadas con los conceptos cierres y ley federal irreductible.

axiomas de armstrong

Existen reglas para la derivación de nuevas leyes federales a partir de las existentes, denominadas axiomas de armstrong.

axiomas de armstrong

Regla de reflexividad: si \(B \subset A\) , entonces \(A\rightarrow B\)
Regla del complemento: si \(A\rightarrow B\) entonces \(AC\rightarrow BC\)
Regla de transitividad: si \(A\rightarrow B\) y \(B\rightarrow C\), entonces \(A\rightarrow C\)

De estos axiomas también se pueden derivar las siguientes reglas adicionales:

Regla de autodeterminación: \(A\rightarrow A\)
Regla de descomposición: Si \(A\rightarrow BC\) , entonces \(A\rightarrow B\) y \(A\rightarrow C\)
Regla de unión: si \(A\rightarrow B\) y \(A\rightarrow C\) entonces \(A\rightarrow BC\)
Regla de composición: si \(A\rightarrow B\) y \(C\rightarrow D\), entonces \(AC\rightarrow BD\)

Puede verse que, debido a la regla de reflexividad, cualquier conjunto de atributos \(A\) implica un FD de la forma \(A\to A\) . Estos FD, así como los siguientes, no tienen interés y se denominan triviales.

Dependencia funcional trivial de la FZ \(A \to B\) tal que \(B \subset A\) .

En principio, estas reglas son suficientes para encontrar todos los FD que se derivan de los datos. En este sentido, se introduce el concepto de cierre de un conjunto de DF.

Cierre de un conjunto de FD Un cierre de un conjunto de FD es un conjunto de FD que incluye todos los FD del conjunto original, así como todos los FD implicados por ellos. En otras palabras, para una relación \(R\) que tiene dependencias funcionales \(S\) , el cierre \(S^+\) es el conjunto de todos los FD posibles para \(R\) , basados en \(S \) .

Como regla general, se requiere establecer si un cierto PF \(X\rightarrow Y\) se seguirá de un conjunto dado de PF \(S\) . Resulta que esto es posible si y solo si el conjunto de atributos \(Y\) es un subconjunto del cierre de atributos \(X^+\) en \(S\) .

Cierre de atributos El cierre \(X^+\) de atributos \(X\) con respecto al conjunto de FDs \(S\) es el conjunto de todos los atributos que dependen funcionalmente de algún subconjunto \(X\) .

Para calcular el cierre del conjunto de atributos \(X^+\) con respecto al conjunto FD \(S\), existe la siguiente regla: para cada FD \(A\rightarrow B\) en \(S\) , si \(A \subset X^ +\) , entonces también lo es \(B \subset X^+\) , y es suficiente comenzar con la suposición de que \(X^+ = X\) .

Cabe señalar que para cualquier cierre \(X^+\) , hay FD de la forma \(X \to B\) , donde \(B \subset X^+\) , por lo tanto, los cierres de toda relación los atributos por su FD describen el cierre de la ZF de esta relación.

Esta regla se utiliza para calcular un conjunto irreducible de FDs equivalente al dado (en el sentido de la equivalencia de sus cierres). Reducir el número de FD manteniendo el cierre (y, por lo tanto, la lógica interna descrita por el FD) es un paso importante en el diseño de la base de datos.

Un conjunto de FD se llama irreducible si:

El lado derecho de cada FL contiene solo un elemento
Ninguno de los atributos de cualquier parte izquierda de la ZF del conjunto puede eliminarse sin cambiar el cierre
Ninguno de los FD configurados se puede quitar sin cambiar el cierre.

Para cualquier conjunto de FD, existe al menos un conjunto irreducible equivalente. Tal conjunto se llama cobertura mínima.

Anotación: Esta y las próximas dos conferencias están dedicadas a la teoría de las bases de datos relacionales. Dado que toda la dirección del enfoque relacional para la organización de bases de datos es puramente práctica, esta teoría es principalmente pragmática. El principal problema que la teoría de las bases de datos relacionales pretende resolver es descubrir las propiedades útiles de algunos esquemas de bases de datos y desarrollar formas de construir dichos esquemas. Es común llamar a este problema el problema de diseño de base de datos relacional para abreviar.

Introducción

A pesar de su orientación práctica, teoría de bases de datos relacionales es una dirección científica independiente en la que han trabajado (y continúan trabajando) muchos investigadores de renombre, cuyos nombres aparecerán en nuestras conferencias. No planeamos describir en detalle los principales resultados en el campo en este curso. Nuestro objetivo es proporcionar solo las definiciones y declaraciones necesarias para una comprensión general del proceso. diseño de base de datos relacional basado en la normalización.

Dado que las propiedades más importantes de las bases de datos relacionales desde un punto de vista práctico se basan en el concepto dependencia funcional, hemos seleccionado una breve discusión de los temas teóricos relevantes en una conferencia separada. Entre estas cuestiones, las más interesantes son los cierres y cubriendo conjuntos de dependencias funcionales, axiomas de armstrong y el teorema de la condición suficiente de Heath descomposición de relaciones sin pérdidas. Los conceptos y declaraciones de esta lección son realmente necesarios para dominar el material de la lección 7, pero también tratamos de demostrar a los lectores, usando ejemplos simples, lo que es teoría de bases de datos relacionales, cuál es el nivel de su complejidad y qué tan intuitivo es.

Tenga en cuenta que no destacamos material teórico relacionado con dependencias multivaluadas y dependencias de conexión. Esto se hizo por dos razones. Primero, estos tipos de dependencias son menos comunes en el modelado. área temática medios de base de datos. Por lo tanto, consideramos suficiente presentar en la Lección 8 solo los conceptos básicos del material teórico relevante. En segundo lugar, aunque la teoría dependencias multivaluadas y dependencias de conexión, de hecho, no es mucho más complicado que la teoría dependencias funcionales, sus definiciones y declaraciones son demasiado engorrosas para este curso.

Dependencias Funcionales

Lo más importante desde un punto de vista práctico. formas normales de relaciones se basan en los fundamentos teoría de bases de datos relacionales concepto dependencia funcional. Para una presentación más detallada, necesitamos varias definiciones y declaraciones (las explicaremos e ilustraremos en el transcurso de la presentación).

Definiciones generales

Dejar variable de relación r , y X e Y son subconjuntos arbitrarios del encabezado r (atributos "compuestos").

En significado variable de relación r el atributo Y depende funcionalmente del atributo X si y solo si cada valor de X corresponde exactamente a un valor de Y. En este caso, también decimos que el atributo X define funcionalmente atributo Y (X es el determinante de ( determinante) para Y , e Y depende de X ). Denotaremos esto como r.X->r.Y .

Por ejemplo, usaremos la relación SERVANT_PROJECTS (SERVICE_NOM, SERVICE_NAME, SERV_ZARP, PRO_NOM, PROJECT_HAND)(Figura 6.1). Obviamente, si SLO_NOM es la clave principal de la relación EMPLEADOS , entonces para esta relación dependencia funcional (DF) NOMBRE_SERVICIO->NOMBRE_SERVICIO .

De hecho, para el cuerpo de la relación SERVANT_PROJECTS en la forma en que se muestra en la Fig. 6.1, también se ejecutan los siguientes FD (1):

Arroz. 6.1.

SLU_NOM->SLU_NAME SLU_NOM->SLU_ZARP SLU_NOM->PRO_NOM SLU_NOM->PROJECT_HAND (SLU_NOM, SLU_NAME)->SLU_ZARP (SLU_NOM, SLU_NAME)->PRO_NOM (SLU_NOM, SLU_NAME)->(SLU_ZARP, PRO_NOM)->(SLU_ZARP, PRO_NOM) )->(SLU_ZARP, PRO_NOM) etc.

Dado que los nombres de todos los empleados son diferentes, también se ejecuta el siguiente FD (2):

NOMBRE_SERVICIO->NOM_SERVICIO NOMBRE_SERVICIO->NOMBRE_SERVICIO_ZARP NOMBRE_SERVICIO->NOM_PRO, etc.

Además, para el ejemplo de la Fig. 6.1 se cumple y FD (3):

SLU_ZARP->PRO_NOM

Sin embargo, tenga en cuenta que la naturaleza del grupo FD (1) difiere de la naturaleza de los grupos FD (2) y (3). Es lógico suponer que los números de identificación de los empleados siempre deben ser diferentes y que cada proyecto tiene un solo líder. Por lo tanto, el grupo FD (1) debe ser verdadero para cualquier valor válido variable de relación SERVANT_PROJECTS y puede ser considerado como invariantes, o restricciones de integridad esta variable de relación.

Los FD de grupo (2) se basan en la suposición menos natural de que los nombres de todos los empleados son diferentes. Esto es cierto para el ejemplo de la Fig. 6.1, pero es posible que con el tiempo los grupos FD (2) no se ejecuten por algún valor variable de relación SERVANT_PROJECTS.

Finalmente, el grupo FD (3) se basa en la suposición poco natural de que no hay dos empleados en diferentes proyectos que reciban el mismo salario. De nuevo, esta suposición es cierta para el ejemplo de la Fig. 6.1, pero lo más probable es que esto sea una coincidencia.

En lo que sigue, sólo nos interesará dependencias funcionales, que debe cumplirse para todos los valores posibles variables de relación.

Tenga en cuenta que si el atributo A de la relación r es una clave posible, entonces para cualquier atributo B de esta relación,

Ciclo de vida de los sistemas de información

Un análisis de la situación (complejidad del desarrollo de SI, uso ineficiente de SI) realizado por científicos mostró que esta situación se debió al hecho de que no se observaron requisitos muy importantes en el desarrollo de software:

Falta de especificación completa de todos los requisitos;

· Falta de una metodología aceptable (sistema de métodos) para el desarrollo de la PI;

· Falta de división del proyecto global global en componentes separados que puedan ser controlados y gestionados de forma eficaz.

El ciclo de vida (LC) de los sistemas de información es un enfoque estructural para el desarrollo de software.

(algún esquema) para el 26/09/12

1. Planificación para el desarrollo de SI. Acciones preparatorias que permitan implementar las etapas del ciclo de vida de la PI con la máxima eficiencia. Tres componentes principales: evaluación del alcance del trabajo; evaluación de los recursos necesarios; estimación del costo total del proyecto.

2. Determinación de los requisitos del sistema. Definición del alcance y límites de la aplicación de la base de datos, funciones, composición de sus usuarios y áreas de aplicación.

3. Recopilación y análisis de requerimientos de los usuarios. Recopilación y análisis de información sobre esa parte de la organización, cuyo trabajo será respaldado por el IS creado, determinación de los requisitos del usuario para el sistema. Fuentes: encuesta y cuestionamiento; observación; estudio de documentos; experiencia previa.

4. Diseño de base de datos. Cree un proyecto de base de datos. Los dos enfoques principales para diseñar sistemas de bases de datos son: descendiendo" y " ascendente».

5. Selección del DBMS de destino. Seleccione el tipo apropiado de DBMS para admitir la aplicación de base de datos que está creando.

6. Desarrollo de aplicaciones. Diseñar la interfaz de usuario y los programas de aplicación diseñados para trabajar con la base de datos.

7. Creación de un prototipo. Cree un modelo de trabajo de la aplicación de base de datos.

8. Implementación. Implementación física de la base de datos y aplicaciones desarrolladas.

9. Conversión y carga de datos. Transferir datos existentes a una nueva base de datos, cargar y modificar aplicaciones existentes para organizar la colaboración con una nueva base de datos.

10. Pruebas. El proceso de ejecutar programas de aplicación para encontrar errores. Estrategias de prueba: prueba de arriba hacia abajo; prueba al alza; pruebas de flujo; pruebas intensivas.

11. Operación y mantenimiento. Supervisar el sistema y apoyar su funcionamiento normal: seguimiento del rendimiento; soporte y modernización de aplicaciones.

Teoría de la base de datos relacional

Terminología

En 1970, el modelo relacional fue propuesto por primera vez por E.F. Cod.

Un DBMS relacional asume que el usuario percibe la base de datos como un conjunto de tablas (y nada más).

Relaciones matemáticas.

La teoría de las bases de datos relacionales se basa en la teoría matemática de las relaciones.

Sean D1, D2, … Dn algunos conjuntos.

Producto cartesiano D1 D2 … Dn = ((X1,X2,…,Xn) | X1 D1, X2 D2, … Xn Dn)

Relación – subconjunto R D1*D2*…*Dn

Por ejemplo, n=2, D1=(2,4) y D2=(1,3,5), D1 * D2 = ((2,1),(2,3),(2,5),(4 , 1),(4,3),(4,5)), R=((2,1),(4,1))

Un subconjunto de m. dada una condición, por ejemplo:

R=((x1,x2) |x1 D1, x2 D2, X2=1), A1, A2, … An – nombres de atributos con dominios D1, D2, … Wtb entonces la relación se escribirá como:

R(A1:D1,A2:D2,…An:Dn)

Propiedades de relación:

· La relación tiene un nombre único;

· Cada atributo tiene un nombre único (en relación);

· Cada celda de la relación contiene sólo un valor atómico y no hay grupos repetidos (la relación está normalizada);

D1 - estudiantes
D2 - disciplinas: Matemáticas, Informática

· No importa el orden de los atributos;

· El orden de las tuplas es arbitrario;

· Cada tupla es única.

Claves relacionales

Las claves relacionales sirven para identificar de forma única una tupla que describe relaciones entre relaciones.

integridad relacional.

álgebra relacional

El resultado de una operación se puede utilizar como operando para otra operación, lo que le permite crear expresiones anidadas (PA de cierre).

El álgebra relacional es un lenguaje en el que todas las tuplas se procesan en un solo comando.

Cinco operaciones principales:

· Muestreo,

proyección,

Producto cartesiano,

· Una asociación,

· Diferencia.

En base a estas operaciones se pueden obtener otras:

conexiones,

・Intersecciones

divisiones

Los signos de las operaciones lógicas ^(And), v(Or), ~(not) se pueden utilizar en el predicado.

Ejemplo. Obtenga una lista de todos los empleados con un salario superior a 300.

Proyección.

Define una relación cuyos atributos son atr1, ..., atrn y contiene solo tuplas únicas.

producto cartesiano

El producto cartesiano rara vez se usa, el muestreo se aplica al resultado.

Una asociación

Diferencia

operaciones de conexión.

conexión theta

conexión natural

Unión exterior

Luego, con una combinación externa izquierda, se conserva toda la información original de la relación R. De manera similar, también se puede definir una combinación externa derecha.

semi unirse

La operación de semiunión se puede definir utilizando los operadores de proyección y unión.

intersección

Representación

Propósito de las vistas:

· Proporciona un mecanismo flexible para proteger la base de datos ocultando parte de ella a ciertos usuarios;

Permite a los usuarios organizar el acceso a los datos de la forma más conveniente para ellos;

· Te permite simplificar operaciones complejas con relaciones básicas.

Reglas a cumplir
SGBD relacional

Para determinar si un SMS es relacional, Codd (1985) propuso 13 reglas que deben cumplir.

№		regla
		Regla fundamental. Un DBMS relacional debe poder administrar bases de datos únicamente con la ayuda de sus funciones relacionales.
		Representación de la información. Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico de una sola manera: como valores en tablas. Incluyendo metadatos.
		Acceso garantizado. Para cada elemento de datos en una base de datos relacional, se debe garantizar el acceso lógico en función de una combinación de nombre de tabla, valor de clave principal y nombre de columna.
		Soporte para valores nulos. El DBMS admite valores nulos.
		Catálogo de sistemas relacionales. La descripción de la base de datos debe presentarse a nivel lógico de la misma forma que los datos ordinarios, lo que permite a los usuarios utilizar el mismo lenguaje relacional para acceder a ellos.
		Un sublenguaje de datos exhaustivo. Un DBMS relacional puede admitir varios idiomas. Sin embargo, debe existir al menos un lenguaje cuyos operadores permitan realizar las siguientes funciones: 1. Definición de datos; 2. Definición de representaciones; 3. Comandos de manipulación de datos; 4. Restricciones de integridad; 5. Autorización de usuarios; 6. Organización de las transacciones

		Operaciones de extracción, inserción, eliminación y actualización de alto nivel. La capacidad de un DBMS para realizar operaciones de recuperación de datos en los comandos de inserción, eliminación y actualización como una sola operación.
		Independencia física de los datos. Del método de almacenamiento
		Independencia lógica de los datos. Independencia de las aplicaciones de los cambios en las tablas subyacentes.
		Independencia de las restricciones de integridad. Las restricciones de integridad deben definirse en el sublenguaje de datos relacionales y almacenarse en el catálogo del sistema, no en los programas de aplicación.
		Independencia de la distribución de datos.
		Sin regla de desvío. Si el DBMS tiene un lenguaje de bajo nivel (con procesamiento secuencial línea por línea), no debería permitir eludir las reglas y restricciones de integridad descritas en un lenguaje relacional de alto nivel.