foreign - eliminar llave foranea sql
¿Puede una clave externa ser nula y/o duplicada? (10)
Por favor aclaren dos cosas para mi:
- ¿Puede una clave externa ser nula?
- ¿Se puede duplicar una clave externa?
Tan justo como lo sé, NULL
no debería usarse en claves externas, pero en alguna de mis aplicaciones puedo ingresar NULL
tanto en Oracle como en SQL Server, y no sé por qué.
1 - Sí, desde al menos SQL Server 2000.
2 - Sí, siempre que no sea una restricción UNIQUE
o que esté vinculada a un índice único.
Aquí hay un ejemplo usando la sintaxis de Oracle:
Primero vamos a crear una tabla PAÍS
CREATE TABLE TBL_COUNTRY ( COUNTRY_ID VARCHAR2 (50) NOT NULL ) ;
ALTER TABLE TBL_COUNTRY ADD CONSTRAINT COUNTRY_PK PRIMARY KEY ( COUNTRY_ID ) ;
Crear la tabla PROVINCIA
CREATE TABLE TBL_PROVINCE(
PROVINCE_ID VARCHAR2 (50) NOT NULL ,
COUNTRY_ID VARCHAR2 (50)
);
ALTER TABLE TBL_PROVINCE ADD CONSTRAINT PROVINCE_PK PRIMARY KEY ( PROVINCE_ID ) ;
ALTER TABLE TBL_PROVINCE ADD CONSTRAINT PROVINCE_COUNTRY_FK FOREIGN KEY ( COUNTRY_ID ) REFERENCES TBL_COUNTRY ( COUNTRY_ID ) ;
Esto funciona perfectamente bien en Oracle. Observe que la clave foránea COUNTRY_ID en la segunda tabla no tiene "NOT NULL".
Ahora, para insertar una fila en la tabla PROVINCE, es suficiente solo para especificar el PROVINCE_ID. Sin embargo, si elige especificar también un COUNTRY_ID, debe existir ya en la tabla COUNTRY.
Creo que es mejor considerar la posible cardinalidad que tenemos en las tablas. Podemos tener una cardinalidad mínima posible de cero. Cuando es opcional, la participación mínima de tuplas de la tabla relacionada podría ser cero. Ahora se enfrenta a la necesidad de que se permitan valores de clave externa nulos.
Pero la respuesta es que todo depende del negocio.
Creo que la clave externa de una tabla también es la clave principal de otra tabla. Por lo tanto, no permite nulos. Por lo tanto, no se trata de tener valor nulo en la clave externa.
De forma predeterminada, no hay restricciones en la clave externa, la clave externa puede ser nula y duplicada.
al crear una tabla / alterar la tabla, si agrega alguna restricción de unicidad o no nula, solo esto no permitirá los valores nulos / duplicados.
De la boca del caballo:
Las claves externas permiten valores de clave que son todos NULL, incluso si no hay claves PRIMARIA o ÚNICA coincidentes
No hay restricciones en la clave externa
Cuando no se definen otras restricciones en la clave externa, cualquier número de filas en la tabla secundaria puede hacer referencia al mismo valor de clave principal. Este modelo permite nulos en la clave externa. ...
Restricción NO NULA en la clave externa
Cuando no se permiten valores nulos en una clave externa, cada fila en la tabla secundaria debe hacer referencia explícitamente a un valor en la clave principal porque no se permiten valores nulos en la clave externa.
Cualquier número de filas en la tabla secundaria puede hacer referencia al mismo valor de clave principal, por lo que este modelo establece una relación de uno a varios entre la clave principal y la clave externa. Sin embargo, cada fila en la tabla secundaria debe tener una referencia a un valor de clave principal; la ausencia de un valor (un nulo) en la clave externa no está permitida. El mismo ejemplo en la sección anterior se puede utilizar para ilustrar una relación de este tipo. Sin embargo, en este caso, los empleados deben tener una referencia a un departamento específico.
Restricción ÚNICA en la clave externa
Cuando se define una restricción ÚNICA en la clave externa, solo una fila en la tabla secundaria puede hacer referencia a un valor de clave principal dado. Este modelo permite nulos en la clave externa.
Este modelo establece una relación de uno a uno entre las claves primarias y externas que permite valores indeterminados (nulos) en la clave externa. Por ejemplo, suponga que la tabla de empleados tenía una columna llamada MEMBERNO, que se refiere al número de miembro del empleado en el plan de seguro de la compañía. Además, una tabla llamada INSURANCE tiene una clave principal llamada MEMBERNO, y otras columnas de la tabla mantienen la información respectiva relacionada con la póliza de seguro de un empleado. El MEMBERNO en la tabla de empleados debe ser tanto una clave externa como una clave única:
Para imponer reglas de integridad referencial entre las tablas EMP_TAB y INSURANCE (la restricción FOREIGN KEY)
Para garantizar que cada empleado tenga un número de membresía único (la restricción de clave ÚNICA)
Restricciones ÚNICAS y NO NULAS en la clave externa
Cuando se definen las restricciones UNIQUE y NOT NULL en la clave externa, solo una fila en la tabla secundaria puede hacer referencia a un valor de clave principal dado, y como no se permiten valores NULL en la clave externa, cada fila en la tabla secundaria debe hacer referencia explícita un valor en la clave padre.
Mira esto:
Depende del papel que juegue esta foreign key
en su relación.
- Si esta
foreign key
también es unkey attribute
en su relación, entonces no puede ser NULL - Si esta
foreign key
es un atributo normal en su relación, entonces puede ser NULL.
En pocas palabras, las relaciones "no identificables" entre entidades son parte de ER-Model y están disponibles en Microsoft Visio cuando se diseña ER-Diagram. Esto es necesario para imponer la cardinalidad entre Entidades de tipo "cero o más que cero", o "cero o uno". Tenga en cuenta este "cero" en la cardinalidad en lugar de "uno" en "uno a muchos".
Ahora, el ejemplo de relación no identificable donde la cardinalidad puede ser "cero" (no identificable) es cuando decimos que un registro / objeto en una entidad-A "puede" o "puede no" tener un valor como referencia al registro / s en otra Entidad-B.
Como, existe la posibilidad de que un registro de la entidad A se identifique con los registros de otra Entidad B, por lo tanto, debe haber una columna en la Entidad B que tenga el valor de identidad del registro de la Entidad B. Esta columna puede ser "Nula" si ningún registro en la Entidad-A identifica el registro / s (o, objeto / s) en la Entidad-B.
En el Paradigma Orientado a Objetos (del mundo real), hay situaciones en las que un objeto de Clase B no necesariamente depende (fuertemente acoplado) del objeto de Clase A para su existencia, lo que significa que la Clase B está acoplada libremente con la Clase A A tal que la Clase A pueda "contener" (Contención) un objeto de la Clase A, en oposición al concepto de objeto de la Clase B debe tener (Composición) un objeto de la Clase A, por su (objeto de la clase- B) la creación.
Desde el punto de vista de la Consulta SQL, puede consultar todos los registros en la entidad B que "no son nulos" para la clave externa reservada para la Entidad-B. Esto traerá todos los registros que tengan cierto valor correspondiente para las filas en la Entidad A, alternativamente, todos los registros con valor Nulo serán los registros que no tienen ningún registro en la Entidad A en la Entidad B.
Respuesta corta: Sí, puede ser NULL o duplicado.
Quiero explicar por qué una clave externa debe ser nula o puede ser única o no única. Primero recuerde que una clave externa simplemente requiere que el valor en ese campo debe existir primero en una tabla diferente (la tabla principal). Eso es todo un FK es por definición. Nulo por definición no es un valor. Nulo significa que aún no sabemos cuál es el valor.
Déjame darte un ejemplo de la vida real. Supongamos que tiene una base de datos que almacena propuestas de ventas. Supongamos además que cada propuesta solo tiene una persona de ventas asignada y un cliente. Por lo tanto, su tabla de propuestas tendría dos claves externas, una con la identificación del cliente y otra con la identificación del representante de ventas. Sin embargo, en el momento en que se crea el registro, no siempre se asigna un representante de ventas (ya que nadie tiene libertad para trabajar en él todavía), por lo que la identificación del cliente se completa pero la identificación del representante de ventas puede ser nula. En otras palabras, generalmente necesita la capacidad de tener un FK nulo cuando es posible que no sepa su valor en el momento en que se ingresan los datos, pero sí conoce otros valores en la tabla que deben ingresarse. Para permitir nulos en un FK, generalmente, todo lo que tiene que hacer es permitir nulos en el campo que tiene el FK. El valor nulo es independiente de la idea de que es un FK.
Si es único o no, se relaciona con si la tabla tiene una relación de uno a uno o varios a la tabla principal. Ahora, si tiene una relación de uno a uno, es posible que pueda tener todos los datos en una tabla, pero si la tabla se está volviendo demasiado amplia o si los datos están sobre un tema diferente (el empleado - ejemplo de seguro @tbone dio por ejemplo), entonces usted quiere tablas separadas con un FK. Entonces querrá hacer que este FK sea también el PK (lo que garantiza la singularidad) o ponerle una restricción única.
La mayoría de los FK son para una relación de uno a muchos y eso es lo que se obtiene de un FK sin agregar una restricción adicional en el campo. Así que tienes una tabla de orden y la tabla de detalles de orden, por ejemplo. Si el cliente solicita diez artículos a la vez, tiene un pedido y diez registros de detalles de pedidos que contienen el mismo ID de pedido que el FK.
Sí, la clave externa puede ser nula, tal como lo indicaron los programadores superiores ... Agregaría otro escenario en el que la clave externa deba ser nula ... supongamos que tenemos tablas de comentarios, imágenes y videos en una aplicación que permite comentarios sobre imágenes y videos En la tabla de comentarios, podemos tener dos Id. De clave foránea, y Id. De videos junto con el Id. De clave principal. Por lo tanto, cuando comente en un video, solo se requerirá VideosId y pictureId sería nulo ... y si comenta en una foto, solo se requerirá PictureId y VideosId sería nulo ...