¿Puede una clave foránea ser NULL y / o duplicada?

1 - Sí, desde al menos SQL Server 2000.

2 - Sí, siempre y cuando no sea una restricción UNIQUE o esté vinculada a un índice único.

De la boca del caballo:

Las claves foráneas permiten valores de clave que son todos NULL, incluso si no hay coincidencia de claves PRIMARIAS o ÚNICAS

Sin Restricciones en la Clave foránea

Cuando no se definen otras restricciones en la clave foránea, cualquier número de filas en la tabla secundaria puede hacer referencia al mismo valor de clave principal. Este modelo permite valores nulos en la clave foránea. ...

Restricción NOT NULL en la Clave Foránea

Cuando no se permiten nulos en una clave foránea, cada fila de la tabla secundaria debe hacer referencia valor en la clave padre porque los valores nulos no están permitidos en el clave.

Cualquier número de filas en la tabla secundaria puede hacer referencia al mismo padre valor clave, por lo que este modelo establece una relación de uno a muchos entre las claves padre y foránea. Sin embargo, cada fila en el niño table must have a reference to a parent key value; the absence of a valor (un null) en el no se permite la llave foránea. El mismo ejemplo en la sección anterior se puede utilizar para ilustrar tal relación. Sin embargo, en este caso, los empleados deben tener una referencia a un Departamento.

Restricción ÚNICA en la Clave Foránea

Cuando una restricción ÚNICA es definido en la clave foránea, solo una fila en la tabla secundaria puede haga referencia a un valor de clave padre dado. Este modelo permite nulos en el clave foránea.

Este modelo establece una relación uno-a-uno entre el padre y claves foráneas que permiten valores indeterminados (nulos) en el clave foránea. Por ejemplo, supongamos que la tabla de empleados tiene una columna MEMERNO, refiriéndose a un número de membresía de empleado en el plan de seguro de la compañía. Además, una tabla llamada SEGURO tiene una primaria clave llamada MEMERNO, y otras columnas de la tabla mantienen respectivamente información relativa a una póliza de seguro de empleados. El MIEMBRO en la mesa del empleado debe ser a la vez un clave foránea y una clave única:

• Para hacer cumplir las reglas de integridad referencial entre el EMP_TAB y Tablas DE SEGUROS (la restricción de CLAVE EXTERNA)

• Para garantizar que cada empleado tiene un número de membresía único (el Restricción de clave ÚNICA)

Restricciones ÚNICAS y NO NULAS en la Clave Foránea

Cuando ambos son ÚNICOS y las restricciones NO NULAS se definen en la clave foránea, solo una fila en la tabla del niño puede hacer referencia a un valor de clave padre dado, y porque No se permiten valores NULOS en la clave foránea, cada fila en el hijo la tabla debe hacer referencia explícita a un valor en la clave principal.

Vea esto:

Oracle 11g link

Sí la clave externa puede ser nula como se ha dicho anteriormente por programadores senior... Yo añadiría otro escenario donde la clave foránea será requerida para ser null.... supongamos que tenemos tablas 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 Claves Foráneas PicturesId, y VideosId junto con la clave principal CommentId. Por lo tanto, cuando comente un video, solo se requerirá VideosId y pictureId sería nulo... y si usted comenta sobre un picture only PictureId sería requerido y VideosId sería nulo...

Depende de qué papel juega este foreign key en su relación.

1. si este foreign key es también un key attribute en su relación, entonces no puede ser NULL
2. si este foreign key es un atributo normal en su relación, entonces puede ser NULL.

Aquí hay un ejemplo usando la sintaxis de Oracle:
Primero vamos a crear 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 ) ;

Crear la provincia de la tabla

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

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

Por defecto no hay restricciones en la clave foránea, la clave foránea puede ser null y duplicada.

Al crear una tabla / alterar la tabla, si agrega cualquier restricción de unicidad o no null, entonces solo no permitirá los valores null/ duplicados.

En pocas palabras, las relaciones "no identificativas" entre Entidades forman parte de ER-Model y están disponibles en Microsoft Visio al diseñar ER-Diagram. Esto es necesario para hacer cumplir la cardinalidad entre Entidades de tipo "cero o más que cero", o "cero o uno". Nota 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 registro / objeto en una entidad - Un "puede" o " puede no " tener un valor como referencia a los registros en otra Entidad-B.

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

En el Paradigma Orientado a Objetos (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á vagamente acoplada con la Clase-A tal que la Clase-A puede "Contener" (Contención) un objeto de Clase-A, en contraposición al concepto de objeto de Clase-B debe tener (Composición) un objeto de Clase-A, para su creación (objeto de clase-B).

Desde el punto de vista de la consulta SQL, puede consultar todos los registros en entity-B que son "not null" para foreign-key reservada para Entity-B. Esto traerá todos registros que tienen cierto valor correspondiente para las filas en Entity-A alternativamente, todos los registros con valor nulo serán los registros que no tienen ningún registro en Entity - A en Entity-B.

Creo que es mejor considerar la posible cardinalidad que tenemos en las tablas. Podemos tener una posible cardinalidad mínima cero. Cuando es opcional, la participación mínima de las tuplas de la tabla relacionada podría ser cero, ahora se enfrenta a la necesidad de que los valores de clave foránea se permitan null.

Pero la respuesta es que todo depende del Negocio.

Creo que la clave externa de una tabla también es la clave primaria de algún otro table.So no permite nulls.So no se trata de tener un valor nulo en la clave foránea.