¿Puede una key externa ser NULL y / o duplicarse?

Por favor, aclara dos cosas para mí:

  1. ¿Puede una key externa ser NULL?
  2. ¿Se puede duplicar una key externa?

Por justo que yo sepa, NULL no debe usarse en keys externas, pero en algunas aplicaciones mías puedo ingresar NULL tanto en Oracle como en SQL Server, y no sé por qué.

Respuesta corta: Sí, puede ser NULO o duplicado.

Quiero explicar por qué una key externa podría ser nula o necesitar ser única o no única. Primero recuerde que una key Extranjera 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 database que almacena propuestas de venta. Supongamos además que cada propuesta solo tiene una persona de ventas asignada y un cliente. Por lo tanto, su tabla de propuesta tendría dos keys externas, una con la ID del cliente y otra con la ID del representante de ventas. Sin embargo, en el momento en que se crea el logging, un representante de ventas no siempre se asigna (porque nadie es libre de trabajar en él todavía), por lo que la ID del cliente está completa pero la ID del representante de ventas puede ser nula. En otras palabras, generalmente necesita la capacidad de tener un FK nulo cuando no puede conocer 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 está separado de la idea de que sea un FK.

Si es único o no único se relaciona con si la tabla tiene una relación de uno a uno o uno a muchos con la tabla padre. Ahora bien, si tiene una relación de uno a uno, es posible que pueda tener todos los datos en una sola tabla, pero si la tabla es demasiado amplia o si los datos están en un tema diferente (el empleado – ejemplo de seguro @tbone dio por ejemplo), entonces quieres tablas separadas con un FK. Entonces querrías hacer de este FK también el PK (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 obtienes de un FK sin agregar una restricción adicional en el campo. Entonces, tiene una tabla de pedidos y la tabla de detalles de la order, por ejemplo. Si el cliente ordera diez artículos a la vez, tiene un order y diez loggings de detalles de pedido que contienen el mismo ID de pedido que el FK.

1 – Sí, desde al less SQL Server 2000.

2 – Sí, siempre que no sea una restricción UNIQUE o esté vinculado a un índice único.

De la boca del caballo:

Las keys externas permiten valores key que son todos NULL, incluso si no hay keys PRIMARY o UNIQUE coincidentes

Sin restricciones en la key externa

Cuando no se definen otras restricciones en la key externa, cualquier número de filas en la tabla secundaria puede hacer reference al mismo valor de key padre. Este model permite nulos en la key externa. …

NO NULO Restricción en la key externa

Cuando no se permiten valores nulos en una key externa, cada fila en la tabla secundaria debe hacer reference explícitamente a un valor en la key primaria porque no se permiten nulos en la key externa.

Cualquier número de filas en la tabla secundaria puede hacer reference al mismo valor de key padre, por lo que este model establece una relación de uno a muchos entre las keys padre y extranjeras. Sin embargo, cada fila en la tabla secundaria debe tener una reference al valor key principal; la ausencia de un valor (nulo) en la key externa no está permitido. El mismo ejemplo en la sección anterior puede usarse para ilustrar tal relación. Sin embargo, en este caso, los empleados deben tener una reference a un departamento específico.

Restricción ÚNICA en la Clave Extranjera

Cuando se define una restricción ÚNICA en la key externa, solo una fila en la tabla secundaria puede hacer reference a un valor de key principal dado. Este model permite nulos en la key externa.

Este model establece una relación de uno a uno entre las keys padre y extranjeras que permite valores indeterminados (nulos) en la key externa. Por ejemplo, suponga que la tabla de empleados tenía una columna llamada MEMBERNO, que hace reference al número de membresía de un empleado en el plan de seguro de la compañía. Además, una tabla llamada SEGURO tiene una key principal llamada MEMBERNO, y otras columnas de la tabla mantienen la información respectiva relacionada con una póliza de seguro del empleado. El MEMBERNO en la tabla de empleados debe ser una key externa y una key única:

  • Para imponer reglas de integridad referencel entre las tablas EMP_TAB y ASEGURADOR (la restricción FOREIGN KEY)

  • Para garantizar que cada empleado tenga un número de membresía único (la restricción de key ÚNICA)

Restricciones ÚNICAS y NO NULAS en la key externa

Cuando se definen las restricciones ÚNICA y NO NULA en la key externa, solo una fila en la tabla secundaria puede hacer reference a un valor key principal dado, y dado que los valores NULOS no están permitidos en la key externa, cada fila en la tabla secundaria debe hacer reference explícita un valor en la key principal.

Mira esto:

Enlace Oracle 11g

Sí, la key externa puede ser nula como lo indicaron anteriormente los progtwigdores senior … Añadiría otro escenario en el que la key foránea fuera 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 PicturesId de Foreign Keys y VideosId junto con el ID de comentario key principal. Entonces, cuando comentas un video, solo se requiere VideosId y pictureId sería nulo … y si comentas en una image solo se requeriría PictureId y VideosId sería nulo …

Aquí hay un ejemplo usando la syntax de Oracle:
Primero, creemos una tabla COUNTRY

 CREATE TABLE TBL_COUNTRY ( COUNTRY_ID VARCHAR2 (50) NOT NULL ) ; ALTER TABLE TBL_COUNTRY ADD CONSTRAINT COUNTRY_PK PRIMARY KEY ( COUNTRY_ID ) ; 

Crea la tabla PROVINCE

 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 key externa COUNTRY_ID en la segunda tabla no tiene "NOT NULL".

Ahora, para insert una fila en la tabla PROVINCE, es suficiente especificar solo PROVINCE_ID. Sin embargo, si elige especificar un COUNTRY_ID también, debe existir ya en la tabla COUNTRY.

En pocas palabras, las relaciones "no identificables" entre entidades forma parte del model de ER y está disponible en Microsoft Visio cuando se diseña ER-Diagram. Esto es necesario para imponer la cardinalidad entre Entidades del tipo "cero o más que cero", o "cero o uno". Tenga en count este "cero" en cardinalidad en lugar de "uno" en "uno a muchos".

Ahora, un ejemplo de relación no identificable donde la cardinalidad puede ser "cero" (no identificable) es cuando decimos un logging / object en una entidad: "puede" o "puede no" tener un valor como reference al logging / s en otra Entidad-B.

Como, existe la posibilidad de que un logging de la entidad A se identifique en los loggings de otra Entidad B, por lo tanto, debe haber una columna en la Entidad B para tener el valor de identidad del logging de la Entidad-B. Esta columna puede ser "Nula" si ningún logging en la Entidad-A identifica los loggings / s (o, object / s) en la Entidad-B.

En Paradigma orientado a objects (mundo real), hay situaciones en las que un object de Clase B no depende necesariamente (fuertemente acoplado) del object de class A para su existencia, lo que significa que la Clase B está débilmente asociada con Clase A tal que la Clase-A puede contener (Contención) un object de Clase-A, en oposition al concepto de object de Clase-B debe tener (Composition) un object de Clase-A, para su (object de class- B) creación

Desde el punto de vista de Consulta SQL, puede consultar todos los loggings en la entidad B que son "no nulos" para la key externa reservada para la Entidad-B. Esto traerá todos los loggings que tengan cierto valor correspondiente para las filas en la Entidad-A, alternativamente, todos los loggings con valor Nulo serán los loggings que no tengan ningún logging en la Entidad-A en la Entidad-B.

Creo que la key externa de una tabla también es la key principal de alguna otra tabla. Por lo tanto, no permitirá valores nulos. Por lo tanto, no se trata de tener valor nulo en la key externa.