Verdadero o falso: un buen diseño requiere que cada tabla tenga una clave principal, si no otra cosa, un entero en ejecución

Question

Considere un escenario de tienda de comestibles (lo estoy inventando) donde tiene registros FACT que representan una transacción de venta, donde las columnas de la tabla de hechos incluyen

SaleItemFact Table 
------------------ 
CustomerID 
ProductID 
Price 
DistributorID 
DateOfSale 
Etc 
Etc 
Etc 

Incluso si hay duplicados en la tabla si tenemos en cuenta todas las llaves, yo sostendría que un sustituto corriendo tecla numérica (es decir, la columna de identidad) debe estar compuesta, por ejemplo, , TransactionNumber de tipo Entero.

puedo ver a alguien argumentando que una tabla de hechos que no tenga una clave única (aunque me gustaría inventar uno y los residuos de los 4 bytes, pero ¿qué hay de una tabla de dimensiones?

Answer 1

La primera forma normal requiere una clave principal en cada tabla. Entonces este es el mínimo requerido para un buen diseño de la base de datos. Lo que elijas para la clave primaria está abierto a mucho debate. Pero la primera forma normal para el diseño de la base de datos no lo es.

Answer 2

Una de las razones, entre muchos, a tener una clave única por fila (construida a partir de los datos, o de otro modo) es facilitar las actualizaciones o eliminaciones de esa fila específica.

En cualquier caso, esta pregunta es un poco tonta, porque realmente no hay una negociación de ingeniería -off en juego. No hay ningún beneficio real propuesto para no tener la clave, entonces, ¿cuál es el punto? Verdad/sí, las filas deben tener identificadores únicos.

Answer 3

Para los almacenes de datos, las tablas de hechos a menudo tienen una clave primaria compuesta, por lo general la combinación de todas las claves externas a sus tablas de dimensiones.

Es bastante común que no tenga ninguna clave primaria en sus tablas de hechos, ya que a menudo no tienen otra finalidad que perder espacio, y para grandes datawarehouses el espacio puede ser bastante grande. Sin embargo, sus tablas de dimensiones tendrán claves primarias.

Si habla de la parte OLTP de su tienda de comestibles, normalmente seguiría el diseño de la base de datos OLTP normal, normalizaría sus tablas y proporcionaría una clave principal.

Answer 4

Es cierto. Pensar conceptualmente, todo es único, incluso si no está definido por datos únicos. Entonces, si ingresas datos en una tabla y tienen exactamente la misma información, siguen siendo únicos ya que se ingresaron dos veces.

Dejando eso, usted obtiene el beneficio de poder seleccionar, actualizar, eliminar fácilmente en base a la identificación a un costo relativamente bajo (4 bytes). Lo que podría decirse, cuanto más grande es la tabla, más útil es la identificación. Así que los 4 bytes se vuelve menos y menos de un punto, el más grande de la mesa :-)

Answer 5

Debido a su pregunta es bajo Datawarehousing:

• Las tablas de dimensiones deben tener un sustituto (sin sentido) clave primaria, generalmente un entero de incremento automático; y una clave comercial que identifica de forma única un objeto que la fila de la tabla describe, como una dirección de correo electrónico, nombre completo o similar.

• Las tablas de hechos en su mayoría (casi siempre) tienen una clave principal que es la combinación de dos o más claves foráneas.

No debe haber duplicados en las tablas de hecho cuando se combinan claves externas en la clave principal. Para probar esto, simplemente intente cargar la misma transacción dos veces; debería fallar.Una clave primaria generada automáticamente no evitará esto, porque no existe fuera del almacén. El problema generalmente puede resolverse incluyendo la marca de tiempo en la clave principal.

veces una tabla de hechos se utiliza como una dimensión, o en una vista que puede actuar como una dimensión. En este caso, es conveniente tener una (gran) número entero como clave principal, en lugar de varios campos FK - sin embargo, la combinación original de FKs y sello de tiempo (s) aún debe identificar de forma exclusiva la fila hecho.