SE APLICA A: SQL Server (a partir de 2016)Azure SQL DatabaseAzure SQL Data WarehouseParallel Data Warehouse
Las claves primarias y externas son dos tipos de restricciones que se pueden usar para hacer cumplir la integridad de los datos en tablas SQL servidor. Estos son objetos importantes de la base de datos.
Este tema se describe en las siguientes secciones.
Restricciones de clave principal
Restricciones de clave externa
Tareas relacionadas
Normalmente, una tabla tiene una columna o combinación de columnas que contiene valores que identifican de forma única cada fila de la tabla. Esta columna, o columnas, se denomina clave principal (PK) de la tabla y proporciona la integridad de la entidad de la tabla. Las restricciones de clave principal a menudo se definen en una columna de identidad porque garantizan la unicidad de los datos.
Cuando establece una restricción de clave principal en una tabla, el Motor de base de datos garantiza la unicidad de los datos al creación automáticaíndice único en columnas de clave principal. Este índice también proporciona un acceso rápido a los datos cuando se utiliza la clave principal en las consultas. Si se define una restricción de clave principal en más de una columna, los valores se pueden duplicar dentro de la misma columna, pero cada combinación de valores de todas las columnas en la definición de restricción de clave principal debe ser única.
Como se muestra en la siguiente figura, las columnas ID del Producto Y Id. de proveedor en la mesa Compras.ProductVendor formar una restricción de clave primaria compuesta para la tabla dada. Esto asegura que cada fila en la tabla Proveedor de productos tiene una combinación única de valores ID del Producto Y Id. de proveedor. Esto evita la inserción de filas duplicadas.
Una tabla solo puede tener una restricción de clave principal.
La clave principal no puede tener más de 16 columnas y la longitud total de la clave no puede exceder los 900 bytes.
Un índice formado por una restricción de clave principal no puede hacer que la cantidad de índices en una tabla supere los 999 índices no agrupados y 1 índice agrupado.
Si la restricción de clave principal no especifica si el índice está agrupado o no agrupado, se crea un índice agrupado si no existe uno en la tabla.
Todas las columnas con una restricción de clave principal deben definirse como no anulables. Si no se especifica la posibilidad de nulos, todas las columnas con una restricción de clave principal se establecen como no anulables.
Si se define una clave principal en una columna de un tipo de datos definido por el usuario de CLR, la implementación del tipo debe admitir la clasificación binaria.
Una clave externa (FK) es una columna o combinación de columnas que se utiliza para forzar una relación entre los datos de dos tablas para controlar los datos que se pueden almacenar en la tabla de clave externa. Si se hace referencia a una o más columnas que contienen la clave principal de una tabla en una o más columnas de otra tabla, se crea una relación en la referencia de clave externa entre las dos tablas. Esta columna se convierte en una clave externa en la segunda tabla.
Por ejemplo tabla Ventas.SalesOrderHeader vinculado a la tabla Ventas.Vendedor utilizando una clave externa porque existe una relación lógica entre las órdenes de venta y los vendedores. Columna ID de vendedor en la mesa Ventas.SalesOrderHeader coincide con la columna de clave principal en la tabla persona de ventas. Columna ID de vendedor en la mesa Ventas.SalesOrderHeader es una clave foránea para la tabla persona de ventas. Al establecer esta relación por clave foránea, el valor para ID de vendedor no se puede insertar en la tabla Encabezado de pedido de ventas si no está actualmente en la tabla persona de ventas.
La cantidad máxima de tablas y columnas a las que una tabla puede hacer referencia como claves externas (enlaces salientes) es 253. SQL Server 2016 aumenta el límite en la cantidad de otras tablas y columnas que pueden hacer referencia a columnas en la misma tabla (enlaces entrantes) de 253 hasta 10 000. (Requiere un nivel de compatibilidad de al menos 130.) El aumento tiene las siguientes limitaciones:
Superar las 253 referencias de clave externa solo se admite para operaciones DML DELETE. Las operaciones UPDATE y MERGE no son compatibles.
Más de 253 referencias de clave externa no están disponibles actualmente para índices de almacén de columnas, tablas optimizadas para memoria, base de datos ampliada o tablas de clave externa particionada.
A diferencia de las restricciones de clave principal, la creación de una restricción de clave externa no crea automáticamente un índice correspondiente. Sin embargo, a menudo es necesario crear manualmente un índice en una clave externa por las siguientes razones:
Las columnas de clave externa a menudo se usan en criterios de combinación cuando se usan juntas en consultas de datos de tablas relacionadas. Lo hace asignando una columna o columnas en una restricción de clave externa en una tabla a una o más columnas de clave principal o única en otra tabla. Un índice permite que el Motor de base de datos encuentre rápidamente datos relacionados en una tabla de clave externa. Sin embargo, crear un índice es opcional. Los datos de dos tablas relacionadas se pueden combinar incluso si no hay restricciones de clave principal o clave externa definidas entre las tablas, pero una relación de clave externa entre dos tablas muestra que las dos tablas están optimizadas para usarse juntas en una consulta donde las claves son utilizado como criterio.
Las restricciones de clave externa en tablas relacionadas verifican los cambios en las restricciones de clave principal.
El objetivo principal de una restricción de clave externa es controlar los datos que se pueden almacenar en la tabla de clave externa, pero esta restricción también controla la modificación de los datos en la tabla de clave principal. Por ejemplo, al eliminar una fila para un gerente de ventas de una tabla Ventas.Vendedor cuyo ID se utiliza en los pedidos de venta de la tabla Ventas.SalesOrderHeader, se violará la integridad referencial de las dos tablas. Órdenes de venta del administrador remoto en una tabla Encabezado de pedido de ventas deja de ser válido sin un enlace a los datos de la tabla persona de ventas.
La restricción de clave externa evita que ocurra esta situación. Una restricción impone la integridad referencial de la siguiente manera: prohíbe la modificación de datos en la tabla de clave principal si dicha modificación invalidaría la referencia en la tabla de clave externa. Si al intentar eliminar una fila en la tabla de clave principal o cambiar el valor de esta clave, se encuentra que el valor eliminado o modificado de la clave principal corresponde a cierto valor en una restricción de clave externa en otra tabla, no se realizará ninguna acción. Para actualizar o eliminar correctamente una fila con una restricción de clave externa, primero debe eliminar los datos de clave externa en la tabla de clave externa o modificar los datos en la tabla de clave externa que vincula la clave externa con otros datos de clave principal.
Puede usar restricciones de integridad referencial en cascada para definir las acciones que el Motor de base de datos realizará cuando un usuario intente eliminar o actualizar una clave a la que aún apuntan claves externas. Se pueden definir las siguientes acciones en cascada.
SIN ACCIÓN
Motor de base de datos genera un error y luego se revierte la operación de eliminación o actualización en la fila de la tabla principal.
CASCADA
Las filas correspondientes se actualizan o eliminan de la tabla de referencia si cadena dada se actualiza o elimina de la tabla principal. No se puede especificar el valor CASCADE si la columna es de tipo marca de tiempo es parte de una clave foránea o de referencia. La acción ON DELETE CASCADE no se puede especificar en una tabla que tenga definido un activador INSTEAD OF DELETE. La cláusula ON UPDATE CASCADE no se puede utilizar en tablas que tienen disparadores INSTEAD OF UPDATE.
ESTABLECER NULO
Todos los valores que componen una clave externa se establecen en NULL cuando se actualiza o elimina la fila correspondiente en la tabla principal. Las columnas de clave externa deben admitir valores NULL para que se aplique esta restricción. No se puede configurar para tablas que tienen definidos activadores INSTEAD OF UPDATE.
ESTABLECER PREDETERMINADO
Todos los valores que componen una clave externa se establecen en su valor predeterminado cuando se elimina o actualiza la fila correspondiente en la tabla principal. Para cumplir con esta restricción, todas las columnas de clave externa deben tener definiciones predeterminadas. Si la columna admite valores NULL y no se define explícitamente ningún valor predeterminado, el valor predeterminado de la columna se convierte en NULL. No se puede configurar para tablas que tienen definidos activadores INSTEAD OF UPDATE.
Las palabras clave CASCADE, SET NULL, SET DEFAULT y NO ACTION se pueden combinar en tablas que tienen referencias mutuas. Si Motor de base de datos encuentra la palabra clave NO ACTION, detendrá y revertirá las operaciones asociadas CASCADE, SET NULL y SET DEFAULT. Si una instrucción DELETE contiene una combinación de las palabras clave CASCADE, SET NULL, SET DEFAULT y NO ACTION, todas las operaciones CASCADE, SET NULL y SET DEFAULT se ejecutan antes de que Motor de base de datos busque una operación NO ACTION.
Las acciones referenciales en cascada se activan DESPUÉS DE ACTUALIZAR o DESPUÉS DE ELIMINAR disparadores como este:
Todas las acciones referenciales en cascada causadas directamente por la instrucción DELETE o UPDATE original se ejecutan primero.
Si hay activadores DESPUÉS definidos en las tablas modificadas, esos activadores se activan después de que se hayan llevado a cabo todas las acciones en cascada. Estos disparadores se ejecutan en el orden inverso de las acciones en cascada. Si se definen varios disparadores para la misma tabla, se activan en orden aleatorio, a menos que se especifique un primer y último disparador de tabla dedicados. Este orden está determinado por el procedimiento.
Si las secuencias de acción en cascada se originan en una tabla que fue el destino inmediato de una acción ELIMINAR o ACTUALIZAR, el orden en que esas secuencias de acción activan los disparadores no está definido. Sin embargo, una secuencia de acción siempre activa todos sus disparadores antes de que lo haga la siguiente.
Un activador AFTER en una tabla que es el destino inmediato de una acción DELETE o UPDATE se activa independientemente de si se ha modificado alguna fila. En este caso, ninguna otra tabla se ve afectada por la cascada.
Si uno de los desencadenantes anteriores realiza operaciones de ELIMINACIÓN o ACTUALIZACIÓN en otras tablas, esas operaciones pueden desencadenar sus propias secuencias de acción en cascada. Estos flujos de trabajo secundarios se procesan para cada operación de ELIMINACIÓN o ACTUALIZACIÓN después de que se hayan ejecutado todos los activadores de los flujos de trabajo principales. Este proceso se puede repetir de forma recursiva para operaciones posteriores de ELIMINACIÓN o ACTUALIZACIÓN.
Ejecutar CREAR, ALTERAR, ELIMINAR u otras operaciones DDL dentro de los disparadores puede hacer que se activen los disparadores DDL. Esto puede dar lugar a más operaciones de ELIMINACIÓN o ACTUALIZACIÓN, que iniciarán secuencias en cascada adicionales y activarán sus propios disparadores.
Si ocurre un error en cualquier secuencia particular de acciones de referencia en cascada, no se activará ningún disparador AFTER en esa secuencia y se revertirán las operaciones DELETE o UPDATE generadas por esa secuencia.
Una tabla en la que se define un disparador INSTEAD OF también puede tener una cláusula REFERENCES que especifica una acción en cascada específica. Sin embargo, un activador DESPUÉS en la tabla de destino de la acción en cascada puede ejecutar una instrucción INSERTAR, ACTUALIZAR o ELIMINAR en otra tabla o vista, lo que activará un activador INSTEAD OF en ese objeto.
La siguiente tabla enumera las tareas comunes relacionadas con las restricciones de clave principal y clave externa.
Así es como abordamos imperceptiblemente un tema muy importante: claves primarias y externas. Si los primeros son utilizados por casi todo el mundo, los últimos se ignoran por alguna razón. Pero en vano. Las claves foráneas no son un problema, son una verdadera ayuda en la integridad de los datos.
Ya hemos hablado mucho sobre los campos clave, pero nunca los hemos usado. Lo más interesante es que todo funcionó. Esta es una ventaja, o tal vez una desventaja de la base. datos de microsoft Servidor SQL y MS Access. En las tablas de Paradox, este truco no funcionará y, sin la presencia de un campo clave, la tabla será de solo lectura.
Hasta cierto punto, las claves son restricciones, y podrían considerarse junto con la declaración CHECK, porque la declaración ocurre de manera similar e incluso se usa la declaración CONSTRAINT. Veamos este proceso con un ejemplo. Para ello, crearemos una tabla de dos campos "guid" y "vcName". En este caso, el campo "guid" se establece como clave principal:
CREAR TABLA Globally_Unique_Data (identificador único guid DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (Guid))
Lo más sabroso aquí es la línea CONSTRAINT. Como sabemos, después de eso palabra clave viene el nombre de la restricción, y la clave de declaración no es una excepción. Para nombrar una clave principal, recomiendo usar PK_name, donde nombre es el nombre del campo que debe convertirse en la clave maestra. La abreviatura PK proviene de Primary Key (clave primaria).
Después de eso, en lugar de la palabra clave CHECK, que usamos en las restricciones, hay una instrucción PRIMARY KEY, que indica que no necesitamos un control, sino una clave principal. Los corchetes indican uno o más campos que conformarán la clave.
Recuerde que dos filas no pueden tener el mismo valor en un campo clave, en este caso, la restricción de clave principal es idéntica a la restricción única. Esto significa que si hace que el campo para almacenar el apellido sea la clave principal, entonces no será posible escribir dos Ivanov con nombres diferentes en dicha tabla. Esto viola la restricción de clave principal. Esta es la razón por la que las claves son restricciones y se declaran igual que la restricción CHECK. Pero esto no es cierto solo para claves primarias y claves secundarias con unicidad.
EN este ejemplo, la clave principal es un campo de tipo identificador único (GUID). El valor predeterminado para este campo es el resultado de ejecutar el procedimiento del servidor NEWID.
Atención
Solo se puede crear una clave principal para una tabla
Para simplificar los ejemplos, es conveniente utilizar como clave un tipo numérico, y si la base de datos lo permite, será mejor que sea del tipo "autoincremental" (número que aumenta/disminuye automáticamente). En MS SQL Server, dicho campo es IDENTIDAD, y en MS Access es un campo del tipo "contador".
El siguiente ejemplo muestra cómo crear una tabla de productos con un campo entero de incremento automático como clave principal:
CREAR TABLA Productos (id int IDENTIDAD (1, 1), producto varchar (50), Precio monetario, Cantidad numérica (10, 2), RESTRICCIÓN PK_id CLAVE PRINCIPAL (id))
Es este tipo de clave el que usaremos más a menudo, porque los números que son fáciles de leer se almacenarán en el campo clave y es más fácil y visual trabajar con ellos.
La clave principal puede contener más de una columna. El siguiente ejemplo crea una tabla en la que los campos "id" y "Producto" forman la clave principal, lo que significa que se creará un índice único en ambos campos:
CREAR TABLA Productos1 (id int IDENTIDAD (1, 1), Producto varchar (50), Precio monetario, Cantidad numérica (10, 2), RESTRICCIÓN PK_id CLAVE PRINCIPAL (id, [Nombre del producto]))
Muy a menudo, los programadores crean una base de datos con un campo clave en forma de número entero, pero al mismo tiempo está claro en la tarea que ciertos campos deben ser únicos. Y por qué no crear inmediatamente una clave principal a partir de esos campos que deberían ser únicos y no será necesario crear soluciones separadas para este problema.
El único inconveniente de una clave principal de varias columnas es el problema de crear relaciones. Aquí tienes que salir por varios métodos, pero el problema aún tiene solución. Solo necesita ingresar un campo de tipo identificador único y hacer una conexión en él. Sí, en este caso, obtenemos una clave principal única y un campo de tipo identificador único, pero esta redundancia como resultado no será mayor que la misma tabla donde la clave principal es identificador único y se establecen restricciones de unicidad en campos que deberían ser único. ¿Qué elegir? Depende de tarea específica y lo que mejor te funcione.
Una clave externa también es una restricción CONSTRAINT y representa una relación entre dos tablas. Digamos que tienes dos tablas:
Una persona puede tener varios teléfonos, por lo que hemos separado el almacenamiento de datos en diferentes tablas. La figura 1.4 muestra visualmente la relación entre las dos tablas. Si ya ha trabajado con tablas vinculadas, esto será suficiente para usted. Si escucha acerca de las conexiones por primera vez, intentemos analizar el problema más de cerca.
Por ejemplo, tomemos una mesa de tres personas. La Tabla 1.3 muestra el contenido de la tabla "Nombres". Solo hay tres líneas, y cada una tiene su propia clave maestra única. Por singularidad, cuando creamos la tabla, haremos que la clave sea un campo que se incremente automáticamente.
Tabla 1.3 Contenido de la tabla Nombres
Tabla 1.4. El contenido de la tabla Teléfonos
La tabla 1.4 contiene cinco números de teléfono. El campo de clave maestra también tiene una clave maestra única, que también puede incrementarse automáticamente. La clave secundaria es una relación con la clave principal de la tabla Nombres. ¿Cómo funciona esta conexión? Petrov tiene como clave principal en la tabla Nombres el número 1. En la tabla Teléfonos, buscamos el número 1 en la clave secundaria y obtenemos los números de teléfono de Petrov. Lo mismo ocurre con el resto de las entradas. Visualmente, la conexión se puede ver en la Figura 1.5.
Tal almacenamiento de datos es muy conveniente. Si no fuera posible crear tablas vinculadas, en la tabla Nombres tendríamos que completar todos los números de teléfono en un campo. Esto es inconveniente en términos de uso, soporte y recuperación de datos.
Puede crear varios campos de Nombres en una tabla, pero la pregunta es cuántos. Una persona puede tener solo 1 teléfono y yo, por ejemplo, tengo 3, sin contar los trabajadores. Un gran número de campos conduce a la redundancia de datos.
Es posible que cada teléfono en la tabla Nombres tenga una línea separada con el apellido, pero esto es fácil solo para un ejemplo tan simple, cuando necesita ingresar solo el apellido y puede hacer fácilmente varias entradas para Petrov con varios números de teléfono. ¿Y si hay 10 o 20 campos? Así, la creación de dos tablas enlazadas por una clave foránea se puede ver en el listado 1.6.
Listado 1.6. Creación de tablas enlazadas por una clave foránea
CREATE TABLE Nombres (idName int IDENTITY(1,1), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName),) CREATE TABLE Phones (idPhone int IDENTITY(1,1), idName int, vcPhone varchar(10), RESTRICCIÓN PK_idPhone CLAVE PRINCIPAL (idPhone), RESTRICCIÓN FK_idName CLAVE EXTRANJERA (idName) REFERENCIAS Nombres (idName))
Lea atentamente el contenido de la lista. Es lo suficientemente interesante porque usa algunos de los operadores que ya hemos cubierto y ejemplo adicional no prevenir Para ambas tablas, se crea un campo clave que viene primero, es de tipo int y se incrementa automáticamente desde 1 en incrementos de uno. El campo clave se convierte en la clave maestra con una restricción CONSTRAINT.
En la descripción de la tabla Phones, la última línea contiene una nueva declaración para nosotros, es decir, una declaración de clave externa que utiliza el operador FOREIGN KEY. Como puede ver, esto también es una limitación, y verá por qué un poco más adelante. Los corchetes indican el campo de la tabla que debe vincularse a otra tabla. A esto le sigue la palabra clave REFERENCIAS (referencia), el nombre de la tabla con la que se debe relacionar (Nombres) y entre paréntesis el nombre del campo ("idName"). Por lo tanto, hemos establecido una conexión, que se muestra en la Figura 1.4.
¡Atención!
Una clave externa solo puede referirse a la clave principal de otra tabla o a una restricción única. Esto significa que la palabra clave REFERENCIAS debe ir seguida del nombre de la tabla, y solo se puede especificar entre paréntesis la clave principal o un campo con una restricción ÚNICA. No se pueden especificar otros campos.
Ahora, si puedes llenar las tablas con datos. Los siguientes tres comandos agregan los tres apellidos que vimos en la Tabla 1.3:
INSERTAR EN Nombres(vcName) VALORES("Petrov") INSERTAR EN Nombres(vcName) VALORES("Ivanov") INSERTAR EN Nombres(vcName) VALORES("Sidorov")
Si ya ha trabajado con SQL, también puede agregar entradas para la tabla de teléfonos. Omitiré estos comandos, pero puede verlos en el archivo Foreign_keys.sql en el directorio del Capítulo 1 del CD.
Nuestra tarea ahora es ver cuáles son las acciones restrictivas de una clave externa, vamos a resolverlo. Hemos indicado una relación explícita entre dos campos en diferentes tablas. Si intenta agregar un registro a la tabla de teléfonos con un identificador en el campo "idName" que no existe en el campo del mismo nombre (el nombre podría haberse hecho diferente) en la tabla con apellidos, ocurrirá un error . Esto romperá la relación entre las dos tablas, y la restricción de clave externa evitará que existan registros sin una relación.
La restricción también se aplica al cambiar o eliminar registros. Por ejemplo, si intenta eliminar la fila con el apellido Petrov, obtendrá un error de restricción de clave externa. No puede eliminar registros que tengan filas relacionadas externamente. Primero, debe eliminar todos los teléfonos para esta entrada, y solo después de eso será posible eliminar la línea con el nombre Petrov.
Durante la creación de la clave externa, se puede especificar ON DELETE CASCADE o ON UPDATE CASCADE. En este caso, si elimina el registro Petrov de la tabla Nombres o cambia el identificador, todos los registros de la tabla Teléfonos asociados con la fila Petrov se actualizarán automáticamente. Nunca. No, tienes que escribir letras mayúsculas R: NUNCA hagas esto. Todo debe ser eliminado o cambiado manualmente. Si el usuario elimina accidentalmente una entrada de la tabla Nombres, también se eliminarán los teléfonos correspondientes. ¡Entonces tiene sentido crear una clave externa si la mitad de su poder restrictivo desaparece! Todo debe hacerse solo manualmente, y no se recomienda cambiar los identificadores en absoluto.
La eliminación de las propias tablas también debe comenzar con la tabla secundaria, es decir, con Teléfonos, y solo entonces se puede eliminar la tabla principal de Nombres.
Finalmente, te mostraré cómo hacer coincidir bellamente nombres y números de teléfono de dos tablas:
SELECCIONE vcName, vcPhone FROM Nombres, Teléfonos DONDE Names.idName=Teléfonos.idName
Hablaremos más sobre este tipo de consultas en el Capítulo 2. Por ahora, he incluido un ejemplo solo para mostrarle el poder de las tablas vinculadas.
Una tabla puede contener hasta 253 claves externas, lo que es suficiente incluso para las bases de datos más complejas. En lo personal, tuve que trabajar con bases de datos donde el número de claves foráneas no superaba las 7 por tabla. Si es más, lo más probable es que la base de datos esté diseñada incorrectamente, aunque hay excepciones.
La tabla en sí también puede tener un máximo de 253 claves foráneas. Las claves foráneas en una tabla son menos comunes, en su mayoría no más de 3. La mayoría de las veces, una tabla puede tener muchos enlaces a otras tablas.
Una clave externa puede hacer referencia a la misma tabla en la que se crea. Por ejemplo, tiene una tabla de posiciones en una organización, como se muestra en la tabla 1.5. La tabla consta de tres campos: clave principal, clave externa y cargo. Puede haber muchos puestos en cualquier organización, pero sería bastante lógico mostrar sus nombres y estructura de subordinación en una tabla. Para ello se debe asociar la clave foránea con la clave primaria de la tabla de trabajos.
Tabla 1.5. Tabla con enlace interno
Como resultado, obtenemos que el CEO tiene una clave externa cero, es decir esta posición está a la cabeza de todas las demás. Para el director comercial y el director de asuntos generales, la clave externa apunta a la fila del director general. Esto significa que estas dos posiciones reportan directamente al CEO. Etcétera.
Veamos cómo podemos crear todo esto en forma de consulta SQL:
CREATE TABLE Positions (idPosition int IDENTITY(1,1), idParentPosition int, vcName varchar(30), CONSTRAINT PK_idPosition PRIMARY KEY (idPosition), CONSTRAINT FK_idParentPosition FOREIGN KEY (idParentPosition) REFERENCES Positions (idPosition))
Como puede ver, la clave externa simplemente se refiere a la misma tabla que estamos creando. En el CD, en el directorio Capítulo 1, puede ver en el archivo Foreign_keys_to_self.sql un ejemplo de cómo crear esta tabla, llenarla con datos y mostrar posiciones, teniendo en cuenta su subordinación. En el próximo capítulo, veremos la posibilidad de trabajar con tales tablas con más detalle.
Hasta ahora, hemos considerado la relación clásica, cuando una fila de la tabla de datos principal corresponde a una fila de la tabla asociada. Tal relación se llama uno a muchos. Pero hay otras relaciones, y ahora consideraremos otra: uno a uno, cuando un registro en la tabla principal está relacionado con un registro en otro. Para implementar esto, basta con vincular las claves primarias de ambas tablas. Dado que las claves principales no se pueden repetir, solo se puede relacionar una fila en ambas tablas.
El siguiente ejemplo crea dos tablas que tienen una relación entre claves primarias:
CREATE TABLE Nombres (idName identificador único DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName)) CREATE TABLE Teléfonos (idPhone identificador único DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINT PK_idPhone PRIMARY KEY (idPhone), RESTRICCIÓN FK_idPhone CLAVE EXTERNA (idPhone) REFERENCIAS Nombres (idName))
Solo una de las tablas necesita una clave externa. Dado que la relación es uno a uno, no importa en qué tabla crearla.
La relación más compleja es de muchos a muchos, donde muchos registros de una tabla coinciden con muchos registros de otra tabla. Para implementar esto, dos tablas no son suficientes, se necesitan tres tablas.
Primero, debe comprender cuándo se puede usar una relación de muchos a muchos. Supongamos que tiene dos tablas: una lista de residentes de la casa y una lista de números de teléfono. Puede haber más de un número en un apartamento, lo que significa que dos teléfonos pueden pertenecer al mismo apellido. Así que es una relación de uno a muchos. Por otro lado, puede haber dos familias en un apartamento (piso común o solo un inquilino que usa el teléfono del propietario), lo que significa que la relación entre el teléfono y el residente también es de uno a muchos. Y la opción más difícil es tener dos teléfonos en un piso común. En este caso, varios residentes del apartamento utilizan ambos números. Entonces resulta que "muchas" familias pueden usar "muchos" teléfonos (comunicación de muchos a muchos).
¿Cómo implementar una relación de muchos a muchos? A primera vista, esto es imposible en el modelo relacional. Hace 10 años estaba buscando diferentes variantes y, como resultado, acaba de crear una tabla que estaba repleta de redundancia de datos. Pero un día, recibí una tarea, gracias a la cual ya surgió una excelente solución de la condición: debe crear dos tablas de residentes de apartamentos y teléfonos e implementar solo la clave principal en ellos. Las claves foráneas no son necesarias en esta tabla. Y aquí la comunicación entre mesas tiene que ser a través de la tercera mesa de conexión. A primera vista, esto es difícil y no está claro, pero una vez que comprenda este método, verá todo el poder de esta solución.
Las tablas 1.6 y 1.7 muestran ejemplos de tablas de apellidos y teléfonos, respectivamente. Y la tabla 1.8 muestra una tabla de enlaces.
Tabla 1.6. Tabla de apellidos
Tabla 1.7. Mesa de telefono
Tabla 1.8. Mesa de telefono
Veamos ahora cuál será la lógica de búsqueda de datos en una relación de muchos a muchos. Digamos que necesitamos encontrar todos los teléfonos que pertenecen a Ivanov. Ivanov tiene una clave primaria igual a 1. Encontramos en la tabla de enlace todos los registros en los que el campo "Relación con el nombre" es igual a 1. Estos serán los registros 1 y 2. En estos registros, se encuentran los identificadores 1 y 2 en el campo "Relación con el teléfono", respectivamente, por lo que Ivanov posee los números de la tabla de teléfonos, que se encuentran en las filas 1 y 2.
Ahora resolvamos el problema inverso: determine quién tiene acceso al número de teléfono 567575677. Este número en la tabla de teléfonos tiene una clave de 3. Estamos buscando todos los registros en la tabla de enlaces, donde el campo "Conexión con teléfono" es igual al 3. Son registros con los números 4 y 5, que en el campo “Relación con el nombre” contienen los valores 2 y 3, respectivamente. Si mira ahora la tabla de apellidos, verá Petrov y Sidorov en los números 2 y 3. Entonces, son estos dos vecinos quienes utilizan el número de teléfono 567575677.
Revise las tres tablas y asegúrese de comprender qué números de teléfono pertenecen a qué residentes y viceversa. Si ve esta conexión, comprenderá que es tan simple como tres centavos y puede implementarla rápidamente en sus proyectos.
CREATE TABLE Nombres (idName identificador único DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName)) CREATE TABLE Teléfonos (idPhone identificador único DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINT PK_idPhone PRIMARY KEY (idPhone)) CREATE TABLE LinkTable (identificador único de idLinkTable DEFAULT NEWID(), identificador único de idName, identificador único de idPhone, RESTRICCIÓN PK_idLinkTable CLAVE PRIMARIA (idLinkTable), RESTRICCIÓN FK_idPhone CLAVE EXTRANJERA (idPhone) REFERENCIAS Teléfonos (idPhone), RESTRICCIÓN FK_idName CLAVE EXTRANJERA (idName) REFERENCIAS Nombres (idName) )
La tabla de unión tiene dos claves externas que se vinculan con las tablas de nombres y teléfonos, y una clave principal que hace que los registros sean únicos.
Elegí el campo GUID como clave principal porque es más conveniente para resolver esta tarea en particular. El asunto es que necesitamos interponer registros en dos tablas y en ambos casos es necesario especificar la misma clave. El valor GUID se puede generar y luego usar al insertar datos en ambas tablas.
También puede usar un campo de incremento automático como clave, pero en este caso el problema es un poco más difícil de resolver, más precisamente, es un inconveniente para resolver el problema. Por ejemplo, al agregar un número de teléfono, primero debe insertar la fila correspondiente en la tabla, luego buscarla, determinar la clave que se asignó a la fila y luego establecer una conexión.
En esta etapa, estamos limitados a crear tablas únicamente, y en la sección 2.8 volveremos a este tema y aprenderemos a trabajar con tablas relacionadas. Trabajar con relaciones de uno a uno y de uno a muchos no es muy diferente, porque solo dos tablas están involucradas en este esquema. La relación de muchos a muchos es un poco más complicada debido a la tabla de unión, por lo que la cubriremos por separado en la Sección 2.27.
La figura muestra una tabla (proporción de grado 5) que contiene información sobre los empleados de una empresa hipotética. Las filas de la tabla corresponden a tuplas. Cada línea es en realidad una descripción de un objeto del mundo real (en este caso, un empleado), cuyas características están contenidas en las columnas. Las relaciones relacionales corresponden a conjuntos de entidades, mientras que las tuplas corresponden a entidades. Las columnas de una tabla que representan una relación relacional se denominan atributos.
Cada atributo se define en un dominio, por lo que se puede pensar en el dominio como el conjunto de valores válidos para ese atributo. Varios atributos de la misma relación, e incluso atributos de diferentes relaciones, se pueden definir en el mismo dominio.
Un atributo cuyo valor identifica de forma única las tuplas se denomina llave (o simplemente llave). La clave es el atributo "Número de personal", ya que su valor es único para cada empleado de la empresa. Si las tuplas se identifican solo concatenando los valores de varios atributos, entonces se dice que la relación tiene una clave compuesta.
Clave primaria- en un modelo de datos relacional, una de las claves potenciales de la relación, elegida como clave principal (o clave por defecto).
Una relación puede contener varias claves. Siempre se declara una de las claves. primario, sus valores no se pueden actualizar. Todas las demás claves de relación se llaman claves posibles.
Desde el punto de vista de la teoría, todas las claves potenciales (posibles) de la relación son equivalentes, es decir, tienen las mismas propiedades de unicidad y minimalidad. Sin embargo, como principal, se suele elegir una de las claves potenciales, que es la más conveniente para ciertos fines prácticos, por ejemplo, para crear externo claves de otras maneras, o para crear un índice agrupado. Por lo tanto, por regla general, se elige como clave principal la que tiene el tamaño más pequeño ( almacenamiento físico) y/o incluye el menor número de atributos.
Si Clave primaria consta de un solo atributo, se llama llave sencilla.
Si Clave primaria consta de dos o más atributos, se llama clave compuesta. Por lo tanto, el nombre, el apellido, el patronímico, el número de pasaporte y la serie de pasaporte no pueden ser claves primarias por separado, ya que pueden ser las mismas para dos o más personas. Pero no existen dos documentos personales del mismo tipo con la misma serie y número. Por tanto, en una relación que contiene datos sobre personas, la clave primaria puede ser un subconjunto de atributos, formado por el tipo de documento personal, su serie y número.
A diferencia de los modelos de datos jerárquicos y de red, el relacional no tiene el concepto de relación de grupo. Para reflejar asociaciones entre tuplas de diferentes relaciones se utiliza la duplicación de sus claves.
Los atributos que son copias de las claves de otras relaciones se denominan llaves extranjeras.
Por ejemplo, la relación entre DEPARTAMENTO y EMPLEADO se crea copiando la clave principal "Departamento_Número" de la primera relación a la segunda. Por lo tanto, para obtener una lista de empleados de una subdivisión dada, es necesario: 1) Desde la tabla DEPARTAMENTO, configure el valor del atributo "Departamento_Número" El correspondiente al "Department_Name" dado. 2) seleccione todos los registros de la tabla EMPLEADO, valor del atributo "Departamento_Número" que es igual a la obtenida en el paso anterior. Para saber en qué departamento trabaja un empleado, debe realizar la operación inversa: 1) Determinar "Departamento_Número" de la tabla EMPLEADO. 2) En base al valor obtenido, encontramos una entrada en la tabla DEPARTAMENTO.
18. Normalización en bases de datos relacionales, el concepto de forma normal en el diseño de bases de datos.
forma normal - una propiedad de una relación en un modelo de datos relacionales que lo caracteriza en términos de redundancia, lo que puede conducir potencialmente a resultados lógicamente erróneos de muestreo o cambio de datos. La forma normal se define como el conjunto de requisitos que debe satisfacer una relación.
El proceso de convertir una base de datos a un formato de formulario normal se denomina normalización . La normalización tiene como objetivo llevar la estructura de la base de datos a una forma que proporcione una redundancia mínima, es decir, la normalización no tiene como objetivo reducir o aumentar el rendimiento, ni reducir o aumentar el tamaño de la base de datos. El objetivo final de la normalización es reducir la inconsistencia potencial de la información almacenada en la base de datos.
La redundancia generalmente se elimina al descomponer las relaciones de tal manera que solo se almacenan hechos primarios en cada relación (es decir, hechos que no se derivan de otros hechos almacenados).
dependencias funcionales.
Una base de datos relacional contiene información tanto estructural como semántica. La estructura de una base de datos está determinada por el número y tipo de relaciones incluidas en ella, y las relaciones de uno a muchos que existen entre las tuplas de esas relaciones. La parte semántica describe el conjunto de dependencias funcionales que existen entre los atributos de estas relaciones. Demos una definición de dependencia funcional.
19. 1NF: Definiciones básicas y reglas de transformación.
Para discutir la primera forma normal, se deben dar dos definiciones:
atributo simple - un atributo cuyos valores son atómicos (indivisibles).
Atributo complejo - se obtiene combinando varios atributos atómicos que se pueden definir en el mismo o diferentes dominios (también se le llama vector o agregado de datos).
Definición de primera forma normal:
una relación está en 1NF si los valores de todos sus atributos son atómicos. . De lo contrario, no es una tabla en absoluto y dichos atributos deben descomponerse.
Considere un ejemplo:
La base de datos de recursos humanos de la empresa necesita almacenar información sobre los empleados que puede tratar de representar en relación con
EMPLEADO(NÚMERO_EMPLEADO, NOMBRE, FECHA_NACIMIENTO, HISTORIAL_TRABAJO, HIJOS).
De un examen cuidadoso de esta relación, se sigue que los atributos "historial de trabajo" Y "niños" son complejos, además, el atributo "historial de trabajo" incluye otro atributo complejo "historia_salario".
Estas unidades se ven así:
HISTORIAL_TRABAJO (FECHA_RECEPCIÓN, NOMBRE, HISTORIA_SALARIO),
HISTORIAL_SALARIO (FECHA_CITA, SALARIO),
HIJOS (NIÑO_NOMBRE, NACIMIENTO_AÑO).
Su relación se muestra en la Fig. 3.3.
Figura 3.3. Relación inicial.
Para llevar la relación original EMPLEADO a la primera forma normal, es necesario descomponerla en cuatro relaciones, como se muestra en la siguiente figura: 
Figura 3.4. Conjunto normalizado de relaciones.
Aquí, la clave principal de cada relación está resaltada en azul y los nombres de las claves externas están en azul. Recuérdese que son las claves foráneas las que sirven para representar las dependencias funcionales que existen en la relación original. Estas dependencias funcionales se indican mediante líneas con flechas.
El algoritmo de normalización es descrito por EF Codd de la siguiente manera:
20. 2NF: Definiciones básicas y reglas de transformación.
Muy a menudo, la clave principal de una relación incluye varios atributos (en cuyo caso se denomina compuesto) - ver, por ejemplo, la relación NIÑOS mostrada en la fig. 3.4 pregunta 19. Esto introduce el concepto dependencia funcional total.
Definición:
Un atributo que no es clave depende funcionalmente de una clave compuesta si depende funcionalmente de la clave en su conjunto, pero no depende funcionalmente de ninguno de sus atributos constituyentes.
Ejemplo:
Sea una relación OFERTA (N_PROVEEDOR, PRODUCTO, PRECIO).
Un proveedor puede suministrar diferentes bienes y los mismos bienes pueden ser suministrados por diferentes proveedores. Entonces la clave de la relación es "N_proveedor + artículo". Que todos los proveedores suministren bienes al mismo precio. Entonces tenemos las siguientes dependencias funcionales:
La dependencia funcional incompleta del atributo "precio" en la clave conduce a la siguiente anomalía: cuando cambia el precio de un producto, se requiere una vista completa de la relación para cambiar todos los registros sobre sus proveedores. Esta anomalía es consecuencia del hecho de que dos hechos semánticos se combinan en una estructura de datos. La siguiente expansión da la relación en 2FN:
Así, uno puede dar
Definición de segunda forma normal: Una relación está en 2NF si está en 1NF y cada atributo que no es clave depende funcionalmente de la clave.
21. 3NF: Definiciones básicas y reglas de transformación.
Antes de discutir la tercera forma normal, es necesario introducir el concepto: dependencia funcional transitiva.
Definición:
Sean X, Y, Z tres atributos de alguna relación. En este caso, X --> Y e Y --> Z, pero no hay correspondencia inversa, es decir Z -/-> Y e Y -/-> X. Entonces Z depende transitivamente de X.
Sea una relación ALMACENAMIENTO ( FIRME, ALMACÉN, VOLUMEN), que contiene información sobre las empresas que reciben mercancías de los almacenes y los volúmenes de estos almacenes. Atributo clave - "firme". Si cada empresa puede recibir mercancías de un solo almacén, a este respecto existen las siguientes dependencias funcionales:
Esto crea anomalías:
Para eliminar estas anomalías, es necesario descomponer la relación original en dos:
Definición de tercera forma normal:
Una relación está en 3NF si está en 2FN y cada atributo que no es clave no depende transitivamente de la clave principal.
Anteriormente en este libro, señalamos ciertas relaciones que existen entre ciertos campos de tablas de muestra. El campo snum en la tabla Clientes, por ejemplo, corresponde al campo snum en la tabla Vendedores y la tabla Pedidos. El campo cnum de la tabla Clientes también corresponde al campo cnum de la tabla Pedidos. A este tipo de relación la hemos llamado integridad referencial; y durante la discusión, vio cómo se puede utilizar.
En este capítulo, explorará la integridad referencial con más detalle y conocerá todas las limitaciones que puede utilizar para respaldarla. También verá cómo se aplica esta limitación cuando utiliza comandos de modificación DML. Debido a que la integridad referencial implica vincular campos o grupos de campos, a menudo entre tablas, esta acción puede ser algo más compleja que otras restricciones. Por esta razón, es bueno estar completamente familiarizado con él, incluso si no planea crear tablas. Sus comandos de modificación se pueden hacer más eficientes con una restricción de integridad referencial (al igual que con otras restricciones, pero una restricción de integridad referencial puede afectar tablas distintas de aquellas en las que está definida), y ciertas funciones de consulta, como las uniones, se estructuran repetidamente en términos de relaciones de integridad referencial (como se destaca en el Capítulo 8).
Cuando un campo de una tabla hace referencia a otro, se denomina clave externa; y el campo al que se refiere se llama clave principal. Entonces, el campo snum en la tabla Clientes es la clave externa, y el campo snum al que se refiere en la tabla Vendedores es la clave principal.
Asimismo, los campos cnum y snum de la tabla Pedidos son claves externas que hacen referencia a sus claves principales nombradas en la tabla Clientes y la tabla Vendedores. Los nombres de la clave externa y la clave principal no tienen que ser iguales, es solo una convención que seguimos para que la combinación sea más comprensible.
Está claro que cada valor de la clave foránea debe representarse una vez, y sólo una vez, en la clave padre.
De hecho, un valor de clave foránea dado puede referirse a un solo valor de clave principal sin asumir que es posible lo contrario: es decir, cualquier número de claves foráneas puede referirse a un solo valor de clave principal. Puede ver esto en las tablas de muestra de nuestros ejemplos. Tanto Hoffman como Clemens están asignados a Peel, por lo que sus valores de clave externa coinciden con la misma clave principal, lo cual es excelente. Un valor de clave externa debe hacer referencia a un solo valor de clave principal, pero un valor de clave principal puede hacer referencia a cualquier cantidad de valores de clave externa. Como ilustración, los valores de clave externa de la tabla Clientes que coincidieron con su clave principal en la tabla Vendedores se muestran en la Figura 19.1. Por conveniencia, no tomamos en cuenta el género no relacionado con este ejemplo.
Como la mayoría de las restricciones, puede ser una restricción de tabla o columna, en forma de tabla que permite usar varios campos como una única clave externa.
* Deben tener el mismo número de columnas.
* En esta secuencia, la primera, segunda, tercera, etc. columnas de la lista de columnas de clave foránea deben tener los mismos tipos y tamaños de datos que la primera, segunda, tercera, etc. columnas de la lista de columnas de la clave principal. Las columnas de las listas de ambas columnas no deben tener el mismo nombre, aunque hemos utilizado este método en nuestros ejemplos para que la relación sea más clara.
Vamos a crear una tabla Clientes con el campo snum definido como una clave foránea que hace referencia a la tabla Vendedores: CREAR TABLA Clientes (cnum integer NOT NULL PRIMARY KEY cname char(10), city char(10), snum integer, FOREIGN KEY (snum) REFERENCIAS Vendedores (snum); tenga en cuenta que al usar ALTER TABLE en lugar de CREATE TABLE, para aplicar una restricción FOREIGN KEY, los valores que especifique en la clave externa y la clave principal deben estar en un estado de integridad referencial. De lo contrario, el comando será rechazado.Aunque ALTER TABLE es muy útil desde, por su conveniencia, primero deberá formar principios estructurales en su sistema, siempre que sea posible, como la integridad referencial.
Desde el punto de vista de la integridad de la base de datos, las interrupciones internas (o excepciones) son, por supuesto, indeseables. Si los permite y al mismo tiempo desea mantener la integridad de su base de datos, puede declarar los campos snum y cnum en la tabla Pedidos como claves externas independientes de esos campos en la tabla Ventas y la tabla Cliente, respectivamente. De hecho, usar el campo snum en la tabla Pedidos, como lo hicimos nosotros, es opcional, aunque fue útil hacerlo para variar. El campo cnum que vincula cada pedido de clientes en la tabla Clientes, en la tabla Pedidos y en la tabla Clientes, siempre debe compartirse para encontrar el campo snum correcto para ese pedido (sin permitir excepciones). Esto significa que escribimos una parte de la información, qué cliente está asignado a qué proveedor, dos veces, y será necesario hacer más trabajo para asegurarnos de que ambas versiones sean consistentes. Si no tenemos una restricción de clave externa como se mencionó anteriormente, esta situación será especialmente problemática porque cada pedido deberá verificarse manualmente (junto con la consulta) para asegurarse de que el vendedor correcto acreditó cada venta respectiva. Tener este tipo de redundancia de información en su base de datos se denomina desnormalización, lo cual no es deseable en una base de datos relacional ideal, aunque en la práctica se puede permitir. La desmoralización puede hacer que algunas consultas se ejecuten más rápido, ya que una consulta en una sola tabla siempre es significativamente más rápida que una consulta en una unión.
Dado que la cuestión de cambiar los valores de la clave principal está involucrada, la respuesta, según la definición ANSI, es aún más simple, pero quizás un poco más limitada: cualquier valor de una clave principal al que hace referencia un valor de clave externa no se puede eliminar ni cambiar. Esto significa, por ejemplo, que no puede eliminar un cliente de la tabla Clientes mientras todavía tenga pedidos en la tabla Pedidos. Dependiendo de cómo use estas tablas, esto puede ser deseable o problemático. Sin embargo, esto es ciertamente mejor que tener un sistema que le permita eliminar un cliente con pedidos actuales y dejar la tabla Pedidos que se refiere a clientes inexistentes. El objetivo de este sistema de restricciones es que el creador de la tabla Pedidos, utilizando la tabla Clientes y la tabla Vendedores como claves principales, puede imponer restricciones significativas a las acciones en estas tablas. Por esta razón, no podrá usar una tabla que no controle (es decir, no la creó y no es su propietario) a menos que el propietario (creador) de esa tabla le otorgue específicamente el derecho a hacerlo (como se explica en el Capítulo 22). Hay algunos otros acciones posibles Cambios en la clave principal que no forman parte de ANSI pero que se pueden encontrar en algunos programas comerciales. Si desea cambiar o eliminar el valor de referencia de la clave principal actual, existen básicamente tres posibilidades:
Incluso dentro de estas tres categorías, es posible que no desee procesar todos los comandos de modificación de esta forma. INSERT, por supuesto, es irrelevante. Pone los nuevos valores de la clave principal en la tabla para que ninguno de esos valores se pueda llamar en este momento. Sin embargo, es posible que desee permitir modificaciones en cascada sin eliminaciones, y viceversa. La mejor situación puede ser que le permita definir cualquiera de las tres categorías, independientemente de los comandos ACTUALIZAR y ELIMINAR. Por lo tanto, nos referiremos a los efectos de actualización y los efectos de eliminación, que determinan lo que sucede si ejecuta un comando ACTUALIZAR o ELIMINAR en la clave principal. Estos efectos de los que hablamos se llaman cambios RESTRINGIDOS, cambios en CASCADAS y cambios NULOS. Las capacidades reales de su sistema deben estar dentro del estricto estándar ANSI (efectos de modificación y eliminación, ambos limitados automáticamente) para la situación más ideal descrita anteriormente. A modo de ilustración, le mostraremos algunos ejemplos de lo que puede hacer con la gama completa de efectos de modificación y eliminación. Por supuesto, los efectos de modificación y eliminación, que son características no estándar, carecen de la sintaxis de estado estándar. La sintaxis que usamos aquí es simple de escribir y servirá para ilustrar la función de estos efectos.
Para completar el experimento, supongamos que tiene una razón para cambiar el campo snum de la tabla Vendedor en caso de que nuestra tabla Vendedor cambie de particiones. (Por lo general, cambiar las claves principales no es algo que recomendamos hacer en la práctica. Es solo otra razón por la que las claves principales existentes no hacen nada más que actuar como claves principales: no deberían cambiar). Cuando cambia el número de proveedor, desea mantener todos de sus clientes Sin embargo, si este vendedor deja su firma o empresa, es posible que no desee eliminar a sus clientes cuando lo elimine de la base de datos. En su lugar, querrá asegurarse de que los clientes estén asignados a otra persona. Para hacer esto, debe especificar ACTUALIZAR con un efecto Cascada y ELIMINAR con un efecto Limitado. CREAR TABLA Clientes (cnum integer NOT NULL PRIMARY KEY, cname char(10) NOT NULL, city char(10), rating integer, snum integer REFERENCIAS Vendedores, ACTUALIZACIÓN DE Vendedores EN CASCADAS, ELIMINACIÓN DE Vendedores RESTRINGIDOS); Si ahora intenta eliminar Peel de la tabla Proveedores, el comando no será válido hasta que cambie el valor de género snum de los clientes Hoffman y Clemens a otro proveedor asignado. Por otro lado, puede cambiar el campo snum de Peel a 1009, y Hoffman y Clemens también se cambiarán automáticamente.
El tercer efecto son los cambios NULL. Sucede que cuando los vendedores abandonan la empresa, sus pedidos actuales no se transfieren a otro vendedor. Por otro lado, desea cancelar automáticamente todos los pedidos de los clientes cuyas cuentas elimine. Al cambiar los números del vendedor o cliente, simplemente puede transferirlos a él. El siguiente ejemplo muestra cómo puede crear una tabla de pedidos usando estos efectos. CREATE TABLE Orders (onum entero NOT NULL PRIMARY KEY, amt decimal, odate date NOT NULL cnum integer NOT NULL REFERENCIAS Clientes snum entero REFERENCIAS Vendedores, ACTUALIZACIÓN DE CASCADAS de Clientes, ELIMINACIÓN DE CASCADAS de Clientes, ACTUALIZACIÓN DE CASCADAS de Vendedores, ELIMINACIÓN DE NULOS de Vendedores); Por supuesto, en un comando DELETE con un efecto de cambio NULL en la tabla Vendedores, la restricción NOT NULL debe eliminarse del campo snum.
2. Compliquemos el problema. Redefina la tabla Pedidos de la siguiente manera: agregue una nueva columna llamada anterior para que se identifique para cada pedido, el campo onum del pedido anterior para este cliente actual. Haga esto usando una clave externa que se refiera a la tabla de pedidos en sí. La clave foránea también debe hacer referencia al campo cnum del cliente, que proporciona alguna relación prescrita entre el pedido actual y el de referencia.
(Consulte el Apéndice A para obtener respuestas).
Si eres como el autor de este curso en el sentido de que te gusta buscar respuestas a una pregunta que te interesa de manera compleja, en diferentes obras de diferentes autores, entonces no podrás evitar notar cierta confusión en las definiciones. principal (maestro) -> subordinado (detalle) mesas. Recuerde que la tabla maestra a menudo se conoce como tabla principal y la tabla subordinada como tabla secundaria.
Esto probablemente se deba a cómo se interpretan estas definiciones en el DBMS local y del servidor SQL.
En DBMS local, la tabla principal es la que contiene los datos principales y la tabla subordinada es la adicional. Tomemos, por ejemplo, tres tablas relacionadas. El primero contiene datos de ventas, el segundo contiene datos de productos y el tercero contiene datos de clientes:
Arroz. 18.1.
Aquí, la información principal se almacena en la tabla de ventas, por lo tanto, es la principal (padre). La información adicional se almacena en las tablas de productos y clientes, lo que significa que son secundarios. Esto es comprensible: una hija no puede tener dos madres biológicas, pero una madre es bastante capaz de dar a luz a dos hijas.
Pero los servidores de bases de datos SQL tienen una definición diferente de relaciones: cuando un campo en una tabla se refiere a un campo en otra tabla, se le llama clave externa. Y el campo al que se refiere se llama padre o Clave primaria. Una tabla que tiene una clave foránea (un enlace a un registro en otra tabla) a menudo se denomina tabla secundaria y una tabla con clave principal- padre. Incluso en la definición de relaciones, dicen que un padre puede tener solo un registro único, que puede ser referenciado por varios registros. mesa infantil.
Entonces, en el ejemplo anterior, la tabla de ventas tiene dos claves externas: identificación del producto e identificación del cliente. Y ambas tablas en el lado derecho de la figura tienen clave principal"Identificador". Dado que un cliente o producto puede aparecer más de una vez en la tabla de ventas, resulta que ambas tablas del lado derecho de la figura son padres y la tabla de la izquierda es hija. Como ahora estamos estudiando InterBase-SQL servidor de base de datos, nos guiaremos por estas definiciones en lecciones posteriores. Para no confundirnos más con esta confusión, estaremos inmediatamente de acuerdo: mesa infantil tiene una clave foránea ( FOREIGN KEY ) a otra tabla.
CLAVE PRIMARIA- clave primaria, es uno de los principales tipos de restricciones en la base de datos. La clave principal está destinada a identificar de forma única un registro en una tabla y debe ser única. Las claves primarias PRIMARY KEY están en las tablas que se llaman parent (Parent). No confunda la clave principal con los índices principales de las bases de datos locales, la clave principal no es un índice, sino una restricción. Al crear una clave principal interbase automáticamente crea para él índice único. Sin embargo, si creamos índice único, esto no creará restricciones de clave primaria. Una tabla solo puede tener una CLAVE PRINCIPAL.
Supongamos que tenemos una tabla con una lista de empleados. El campo "Apellido" puede contener los mismos valores (nombres del mismo nombre), por lo que no se puede utilizar como clave principal. Rara vez, pero hay homónimos que, además, tienen los mismos nombres. Aún más raro, pero hay homónimos completos, por lo que incluso los tres campos "Apellido" + "Nombre" + "Patronímico" no pueden garantizar la unicidad del registro y no pueden ser la clave principal. En este caso, la salida, como antes, es agregar un campo - identificador, que contiene el número de serie de esta persona. Dichos campos generalmente se incrementan automáticamente (hablaremos sobre la organización de los campos de incremento automático en las próximas lecciones). Entonces,
Clave primaria - este es uno o más campos en la tabla, cuya combinación es única para cada registro.
Si la clave principal tiene una sola columna (como suele ser el caso), el especificador PRIMARY KEY se usa cuando definición de columna:
CREAR TABLA Prim_1 (Stolbec1 INT NO CLAVE PRIMARIA NULA, Stolbec2 VARCHAR (50))
Si la clave principal se basa en varias columnas, el especificador se coloca después de definir todos los campos:
CREAR TABLA Prim_2 (Stolbec1 INT NO NULO, Stolbec2 VARCHAR (50) NO NULO, CLAVE PRINCIPAL (Stolbec1, Stolbec2))
Como puede ver en los ejemplos, la clave principal necesariamente debe tener una restricción de columna(s) NOT NULL.
ÚNICO- llave unica. El especificador UNIQUE especifica que todos los valores campo dado debe ser único, por lo tanto dichos campos tampoco pueden contener valores NULO. Se puede decir que la clave ÚNICA es una alternativa a la clave principal, pero existen diferencias. La principal diferencia es que debe haber una sola clave principal, mientras que puede haber varias claves únicas. Además, una restricción ÚNICA no se puede construir en el mismo conjunto de columnas que se utilizó para una restricción PRIMARY KEY u otra restricción ÚNICA. Las claves únicas, como las claves primarias, se encuentran en tablas que son padres de otras tablas.
Una columna declarada con una restricción ÚNICA, como una clave principal, se puede usar para hacer cumplir la integridad referencial entre el padre y la mesas infantiles. Mientras que la clave foránea mesa infantil se referirá a ese(s) campo(s). Como en el caso de una clave principal, cuando se crea una clave única, automáticamente se creará una clave para ella. índice único. Pero no al revés. Un ejemplo de cómo crear una tabla con una clave primaria y dos únicas:
CREAR TABLA Prim_3 (Stolbec1 INT NOT NULL PRIMARY KEY, Stolbec2 VARCHAR (50) NOT NULL UNIQUE, Stolbec3 FLOAT NOT NULL UNIQUE)
CLAVE EXTERNA- llave externa . Esta es una herramienta muy poderosa para garantizar la integridad referencial entre tablas, lo que le permite no solo monitorear la presencia de enlaces correctos, sino también administrarlos automáticamente. Las claves foráneas están contenidas en tablas que son hijos ( Child ) de otras tablas. Integridad referencial es proporcionada precisamente por una clave foránea que se refiere a la primaria o
