Si una tabla con una clave sustituta tiene una columna conocida por tener valores únicos no nulos (por ejemplo, SSN), ¿viola 3NF?

Según tengo entendido, la tercera forma normal (3NF) básicamente significa que debe haber exactamente una clave.

Si una tabla con, digamos, una idcolumna de incremento automático también tiene una columna que se sabe que es única y no nula, por ejemplo, el número de seguro social, esta otra columna podría usarse como clave.

Ignorando problemas prácticos / comerciales (por ejemplo, riesgo de seguridad / privacidad al pasar SSN como clave / FK), desde un aspecto estrictamente de diseño de esquema, ¿tal tabla no estaría en 3NF porque efectivamente hay 2 claves?

¿La respuesta variará sobre si había una clave única en la otra columna? Si es así, ¿por qué?

Una relación R está en tercera forma normal si cada atributo no primo de R no depende transitivamente de cada clave candidata de R

EFCodd, 1971, Normalización adicional del modelo relacional de base de datos

Está implícito en la definición de una relación que una relación debe tener al menos una clave. Nada sobre 3NF o cualquier otra forma normal requiere que una relación solo tenga una clave.

Desafortunadamente, los libros sobre diseño de bases de datos y normalización tienen abundantes ejemplos de relaciones con una sola clave y menos ejemplos con más de una clave. Esto me parece extraño dado que las claves múltiples parecen ser una práctica muy común en estos días. La escasez de ejemplos prácticos en la literatura no académica parece ser una causa de confusión sobre el papel de las claves en el diseño de bases de datos. Otra causa de confusión es el mnemónico popular "nada más que la clave". Esa frase generalmente se atribuye a Bill Kent, pero no es una definición precisa de 3NF.

Dado que la pregunta se basa en una interpretación de una regla, primero debemos mirar esa información vinculada, que es (énfasis mío):

2. Todos los atributos de una tabla están determinados solo por las claves candidatas de esa tabla y no por ningún atributo no primo.

Creo que la confusión es el resultado de malinterpretar el término "claves candidatas". Puede haber múltiples claves candidatas en una tabla. Es por eso que tenemos términos modificadores para especificar más entre este grupo: Primario y Alternativo. Si las tablas pudieran tener una, y solo una, clave, entonces el término Clave "Primaria" sería engañoso y debería haberse llamado de otra manera (tal vez "Principal" u "Origen" o "Identificando", etc.). Pero "Primario" implica que puede haber claves "secundarias", y esas se llaman claves "Alternas".

Las claves alternativas se indican en modelos físicos a través de una restricción única o índice único. También debe tenerse en cuenta que ambos tipos de claves candidatas (primaria y alternativa) pueden ser referenciadas por claves externas (¡aunque en general uno no debería / no debería hacer tal cosa sin una muy buena razón!).

¿La respuesta variará sobre si había una clave única en la otra columna? Si es así, ¿por qué?

No, porque es una cuestión de modelado físico versus lógico. Puede tener una tabla que tenga un IDENTITYcampo pero que no tenga definida una Clave primaria. La tabla y sus datos pueden estar fácilmente en 3NF, incluso si el modelo físico no lo impone. Esta distinción es similar a si se definen o no claves externas. Seguramente puede UNIRSE a tablas y no tener registros huérfanos, independientemente de si se han definido PK / FK. Y los datos pueden ser 100% correctos sin esas construcciones. Pero tener las PK y FK definidas es la diferencia entre la integridad referencial (lógica) y la integridad referencial declarativa (física). Tener las restricciones en el modelo físico simplemente ayuda a hacer cumplir las reglas del modelo lógico.

Con respecto al SSN (" Número de Seguro Social " para aquellos que no están familiarizados con ese acrónimo), y al ser una Clave Alternativa y tener un Índice / Restricción Único:

Recomendaría no considerar un SSN como una clave alternativa y ponerle una restricción o índice único, incluso si es común hacerlo (el SSN a menudo se considera una clave "natural", una que existe en el mundo real) . Hay dos razones principales:

1. Precisión: la mayoría de las veces, estos valores son ingresados ​​en un sistema por alguien que completa un formulario, ya sea en papel o en línea. Las personas cometen errores mientras ingresan datos todo el tiempo, especialmente si la fuente era un formulario en papel que está siendo ingresado por alguien que lee la escritura descuidada de otra persona (como la mía, que es apenas legible).

   Incluso si los datos provienen de otro sistema, ¿puede estar seguro de que el sistema fuente validó la información? ¿Puede estar seguro de que no hubo un error en su exportación de datos? ¿Qué pasa si hay un error en la importación de datos?

2. Unicidad: incluso si la Administración de Seguridad Social principal nunca ha emitido una identificación duplicada, eso no significa que no se haya producido una duplicación. Fuera de los problemas de robo de identidad, recuerdo haber escuchado a alguien hace años que trabajaba como DBA para el Departamento de Ingresos del estado (creo) y que tuvo que lidiar con los beneficios del Seguro Social, cómo estaban teniendo "problemas" relacionados con lo que era un práctica anterior de reasignar el SSN de una persona fallecida al cónyuge sobreviviente (generalmente la viuda) para que sea más fácil para el cónyuge sobreviviente continuar cobrando los pagos de beneficios. Estoy seguro de que esta práctica terminó hace un tiempo, pero los datos "duplicados" todavía estaban en el sistema.

Según tengo entendido, la tercera forma normal (3NF) básicamente significa que debe haber exactamente una clave.

No. 2NF, 3NF y Boyce Codd Normal Form (BCNF) se ocupan de dependencias funcionales . Una tabla en 2NF significa que no hay dependencias parciales de claves en las que una columna sin clave depende de algún subconjunto adecuado de una clave de varias columnas. Las tablas como la de nuestro ejemplo ya están en 2NF ya que cada clave candidata es una sola columna. Una tabla en 3NF significa que cada columna no clave es también no funcionalmente dependiente de alguna otra columna no clave, y creando así una dependencia transitiva. No importa si hay una o cien claves candidatas. En realidad, es BCNF, no 3NF, que es la forma normal "final" con respecto a las dependencias funcionales. Esto se debe a que una tabla puede estar en 3NF pero no estar en BCNF ya que podría haber múltiples claves candidatas que se superponen. Por lo tanto, cuando usamos el término 3NF para significar "totalmente normalizado" con respecto a las dependencias funcionales, lo que realmente queremos decir es BCNF.

Si una tabla con, por ejemplo, una columna de identificación de incremento automático también tiene una columna que se sabe que es única y no nula, por ejemplo, el número de seguro social, esta otra columna podría usarse como clave.

¡No solo podría serlo, debe serlo si queremos asegurarnos de que los datos almacenados en la base de datos permanezcan consistentes con las reglas que hemos identificado en el mundo real!

Ignorando problemas prácticos / comerciales (por ejemplo, riesgo de seguridad / privacidad al pasar SSN como clave / FK), desde un aspecto estrictamente de diseño de esquema, ¿tal tabla no estaría en 3NF porque efectivamente hay 2 claves?

Como se explicó anteriormente, si la tabla está o no en 3NF (o más importante, BCNF) es ortogonal a la cantidad de claves candidatas que contiene.

¿La respuesta variará sobre si había una clave única en la otra columna? Si es así, ¿por qué?

No, simplemente porque determinar si la tabla está o no en 3NF no tiene nada que ver con cuántas claves candidatas tiene. En cambio, tiene todo que ver con garantizar que todas las columnas sin clave dependan completamente de las claves candidatas.

Pero esto hace que aparezca un punto interesante. Tenga en cuenta que una clave única cuando se define como una restricción en un DBMS no es lo mismo que un identificador único definido como una regla de negocio en un modelo de negocio conceptual. Quizás en nuestro mundo siempre conocemos el SSN de la persona y, por lo tanto, sirve como clave candidata para una persona, y quizás también introducimos una clave sustituta en el esquema lógico que llamamos Id . De persona . Nuestro modelo de negocio incluye la regla que establece que el SSN es un identificador único para una persona en nuestro mundo. Esto implica una dependencia funcionalde todos los atributos descriptivos en este atributo de identidad. Esta regla no cambia solo porque olvidamos o decidimos no informar al DBMS. Esta es precisamente la razón por la cual es vital declarar la restricción, para que el DBMS pueda garantizar que los datos almacenados sean consistentes con las reglas del modelo de negocio. Si no creamos esa restricción única en el SSN, ahora podemos crear inadvertidamente más de una fila para la misma persona con el mismo SSN; ¡cada fila tiene una identificación de persona diferente!

Una excelente introducción sobre estos temas es la Serie práctica de la base de datos práctica de Fabian Pascal y la Teoría relacional y de diseño de bases de datos de Chris Date , de donde se deriva esta respuesta. Si bien cada documento de Fabian es una lectura obligada, el documento n. ° 1 (que define claramente la diferencia entre los niveles conceptual, lógico y físico) y el documento n. ° 4 (que define claramente los diversos tipos de claves) abordan específicamente esta pregunta. Del mismo modo, el libro completo de Chris es una lectura obligada, mientras que la Parte II es la sección dedicada a la normalización con respecto a la dependencia funcional.