Des clés primaires de substitution sont-elles nécessaires sur une table de faits dans un entrepôt de données ?

Question

Lorsque j'ai demandé à nos concepteurs de base de données pourquoi notre table de faits n'avait pas de PK, on ​​m'a répondu qu'il n'y avait aucun ensemble de colonnes dans la table qui identifierait de manière unique un enregistrement, même si toutes les colonnes étaient sélectionnées.Lorsque j'ai suggéré de créer une colonne d'identité dans ce cas, on m'a dit que "je perdrais simplement de l'espace et que ce n'était pas nécessaire".

Mon sentiment est que chaque table du système source devrait avoir un PK, même s'il s'agit d'une colonne d'identité.Étant donné que l'entrepôt de données (DW) est un destinataire de données provenant d'un autre système, comment pourrais-je autrement garantir que les données du DW reflètent avec précision ce qui se trouve dans le système source s'il n'y a aucun moyen de lier des enregistrements individuels ?Si vous disposez d'un programme de chargement incontrôlable qui bousille les données et s'exécute pendant une semaine, comment réconcilieriez-vous les différences avec un système source de transactions en direct sans une sorte de contrainte unique à comparer ?

Answer 1

La table de base de données sans clé primaire semble être un mauvais choix de conception et laisse beaucoup de place à différents types d'anomalies, c'est-à-direcomment supprimeriez-vous ou mettriez-vous à jour un seul enregistrement dans une telle table ?

Answer 2

Un entrepôt de données n'est pas nécessairement un magasin de données relationnelles, même si vous pouvez choisir d'en faire un, de sorte que les définitions relationnelles ne s'appliquent pas nécessairement.

Une clé primaire n'est requise que si vous souhaitez faire quelque chose avec les données qui nécessite un identifiant unique (comme les retracer jusqu'à une source, mais ce n'est pas toujours requis, nécessaire ou même possible de toute façon) ;et les données d'un entrepôt de données peuvent souvent être utilisées d'une manière qui ne nécessite pas de clés primaires.Plus précisément, vous n’aurez peut-être pas besoin de distinguer les lignes les unes des autres.Le plus souvent pour construire des valeurs globales.

Le temps n'est pas une dimension requise dans la construction de tables d'entrepôt de données.

Cela peut être psychologiquement inconfortable et la perte d'espace est un problème trivial, mais votre collègue a raison : les PK ne sont pas nécessaires.

Answer 3

Une colonne de type d'identité est une clé « de substitution » qui remplace l'une de vos clés « candidates » (en termes simples).L'ajout d'une clé de substitution aux colonnes n'ajoute rien si vous ne pouvez pas identifier une ligne sans elle.Ce qui nécessite une clé candidat.

Answer 4

Vous devez au moins disposer d'une clé naturelle sur la table de faits afin de pouvoir identifier les lignes et les rapprocher de la source ou suivre les modifications lorsque cela est nécessaire.

Sur SQL Server, une colonne d'identité vous donne une clé de substitution gratuitement et sur d'autres systèmes utilisant des séquences (par ex.Oracle), il peut être ajouté assez facilement.Les clés de table de faits de substitution peuvent être utiles pour diverses raisons.Certaines applications possibles sont :

• Certains outils aiment avoir des touches numériques sur les tableaux de faits, de préférence des touches à croissance monotone.Un exemple de ceci est MS SQL Server Analysis Services, qui aime vraiment avoir une clé numérique croissante de façon monotone pour les tables de faits utilisées pour remplir les groupes de mesures.Ceci est particulièrement nécessaire pour les charges incrémentielles.

• Si vous avez des relations entre les tableaux de faits (par exemple une répartition des primes écrites et gagnées pour ceux qui sont familiers avec l'assurance), une clé synthétique est utile ici.

• Si vous avez des dimensions vivant dans une relation M:M avec une table de faits (par ex.codes ICD), puis une touche numérique sur la table de faits simplifie cela.

• Si vous avez des exigences d'auto-adhésion pour les transactions (par ex.certaines transactions étant des corrections d'autres) alors une clé synthétique simplifiera le travail avec celles-ci.

• Si vous effectuez des opérations de contre-retraitement au sein de votre entrepôt de données (c.-à-d.gérer les modifications apportées aux données transactionnelles en générant des inversions et en reformulant la ligne), vous pouvez alors avoir plusieurs lignes de table de faits pour la même clé naturelle.

Sinon, si rien ne se joint à votre table de faits dans une relation 1: M, alors une clé synthétique ne sera probablement utilisée pour rien.

Answer 5

Je serais d'accord avec toi.

« On m’a dit qu’il n’y avait pas d’ensemble de colonnes dans la table qui identifierait de manière unique un enregistrement, même si toutes les colonnes étaient sélectionnées. » - cela semble casser quelque chose de fondamental à propos des bases de données relationnelles telles que je les comprends.

Un fait est constitué de valeurs additives et de clés étrangères de dimensions.Le temps est une dimension évidente qui est commune à tous les modèles dimensionnels que je connais.À tout le moins, une clé composite contenant un horodatage serait certainement suffisamment unique.

Je me demande si vos administrateurs de base de données ont beaucoup de connaissances en modélisation dimensionnelle.C'est une façon de penser différente du style relationnel et transactionnel normal.

Answer 6

Vous avez raison – en quelque sorte.Sans clé primaire, une table ne répond pas à la définition minimale d’être relationnelle.Il est fondamental pour être une relation de ne pas autoriser de lignes en double.Les tables dans une conception Data Warehouse doivent être relationnelles, même si elles ne sont pas strictement sous forme normale.

Il doit donc y avoir une colonne (ou un ensemble de colonnes) dans la ligne qui sert à identifier les lignes de manière unique.Mais il ne doit pas nécessairement s’agir d’une colonne d’identité pour une clé de substitution.

Si la table de faits ne comporte aucun ensemble de colonnes pouvant jouer ce rôle de clé candidate, alors davantage de tables de dimensions sont nécessaires dans ce DW et davantage de colonnes sont nécessaires dans la table de faits.

Cette nouvelle Dimension à elle seule n’est peut-être pas la clé primaire ;elle peut être combinée avec des colonnes existantes dans la table de faits pour créer une clé candidate.

Answer 7

Si la table de faits est au centre d’un schéma en étoile, alors il existe en réalité une clé candidate.Si vous regroupez toutes les clés étrangères de la table de faits, celles qui pointent vers des lignes dans les tables de dimensions, vous obtenez une clé candidate.

Cela ne servirait probablement pas à grand-chose de le déclarer comme clé primaire.La seule chose que cela ferait est de vous protéger contre un processus ETL malveillant.Les personnes qui gèrent l’entrepôt maîtrisent peut-être le traitement ETL.

En ce qui concerne l'indexation et la vitesse des requêtes, le problème est complètement différent avec les schémas en étoile et avec les bases de données orientées OLTP.Les personnes qui gèrent l’entrepôt l’ont peut-être également en main.

Lors de la conception d'une base de données pour une utilisation OLTP, il n'est pas judicieux d'avoir une table sans clé primaire.Les mêmes considérations ne s’appliquent pas aux entrepôts.

Answer 8

Je pense toujours qu'une table doit être classée en fonction de ses requêtes ou de ses indicateurs de performances les plus courants. Par conséquent, l'index clusterisé d'une table doit être conforme à la requête la plus difficile ou la plus courante.

La clé primaire ne doit pas nécessairement être un index clusterisé, donc je sais que vous vous demandez peut-être où je veux en venir, mais ma préoccupation concerne davantage l'index clusterisé que la clé primaire (et soyons honnêtes, ils se suivent normalement).

Donc, la question initiale pour moi n’est pas « dois-je avoir une clé primaire de substitution sur la table de faits ? », mais plutôt « dois-je avoir un index groupé sur la table de faits ? » Je pense que la réponse est oui, vous devriez en avoir un (et oui, il y a d’autres articles sur ce site couvrant cette question, mais je pense toujours qu’il vaut la peine d’être mentionné ici, juste au cas où c’est la question que les gens se posent vraiment, même si elle est mal formulée)

Il y a des moments où vous souhaitez une clé de substitution, mais je recommande vivement que la clé de substitution ne soit PAS l'index clusterisé de la table.Cela ordonnerait la table conformément à la clé de substitution dénuée de sens.(Souvent, les gens ajoutent une colonne d'identité de substitution à une table et en font la clé primaire ainsi que l'index clusterisé par défaut)

Alors, sur quelles colonnes créer l’index clusterisé ?Personnellement, j'aime la date pour les tableaux de faits et à cela, vous pouvez ajouter le FK d'une autre dimension pour l'unicité, mais cela augmentera la taille et n'apportera peut-être aucun avantage car pour que l'index soit utile, les dimensions pertinentes devraient être référencées (dans le ordre d'importance avec lequel la clé a été générée).

Pour contourner ce problème (et la raison pour laquelle je réponds ici), je pense que vous DEVRIEZ ajouter un substitut, puis créer l'index clusterisé sur la clé de date et suivi du substitut (dans cet ordre).Je fais cela parce que la date seule ne créera pas une ligne unique, mais l'ajout du testament de substitution.Cela conserve les données classées par date, ce qui aide tous les autres index non clusterisés et maintient également la taille de l'index cluster raisonnable.

De plus, à mesure que les données augmentent, vous souhaiterez peut-être les partitionner, auquel cas vous aurez besoin d'une clé de partition qui sera invariablement à jour.Construire l'index clusterisé avec la date comme partie principale de la clé rend cela plus facile.Avec le partitionnement, vous pouvez désormais utiliser la technique de la fenêtre coulissante pour archiver d'anciennes données ou en cours de chargement.

Answer 9

Ne pas avoir d’identifiant unique pour chaque ligne est encore pire qu’il n’y paraît à première vue.Bien sûr, c'est précaire et il est facile de supprimer certaines lignes par inadvertance.

Mais les performances sont également bien pires.Chaque fois que vous demandez à la base de données de vous fournir les lignes des employés avec EmployeeType = 'Manager' vous faites une comparaison de chaînes.Les identifiants sont tout simplement plus rapides et meilleurs.

De plus, le stockage est bon marché et dans ce cas, j'imagine que l'impact sur l'espace sera inférieur à un quart de point de pourcentage. si cela - en tant qu'entrepôt de données, vous concevez probablement des téraoctets de données.

Answer 10

http://www.ralphkimball.com/html/controversies.html

Fable:

La clé primaire d'une table de faits est constituée de toutes les clés étrangères de dimension référencées.

Fait:

Une table de faits comporte souvent 10 clés étrangères ou plus se joignant aux clés primaires des tables de dimensions.Cependant, seul un sous-ensemble des références de clé étrangère de la table de faits est généralement nécessaire pour l’unicité des lignes.La plupart des tables de faits ont une clé primaire constituée d'un sous-ensemble concaténé/composite de clés étrangères.

Answer 11

l'utilisation de la combinaison de clés de substitution de dimension comme clé primaire de la table de faits ne fonctionne pas dans tous les cas.Prenons le cas où il y a trois dimensions a, b et c.Dans la plupart des conceptions, nous avons généralement une ligne de dimension pour "l'inconnu", supposons que j'attribue toujours à cette ligne la clé de substitution de -1.Je pourrais facilement avoir deux lignes dans ma table de faits qui ont des clés a=n1, b=n2 et c=-1, c'est-à-dire des clés en double car les deux lignes n'ont pas de valeurs valides pour la dimension c et donc toutes deux se résolvent en ligne inconnue.

Answer 12

Vous confondez ici deux problèmes : identifier un enregistrement unique dans la table de faits et tracer les enregistrements du système source jusqu'à la table de faits.

Dans ce dernier cas, il est tout à fait possible qu'un seul enregistrement dans un système source contienne plusieurs enregistrements de table de faits.Imaginez un enregistrement du système source qui représente un transfert de fonds d'un compte à un autre.Il peut y avoir deux enregistrements de table de faits pour représenter cela, un pour le compte débité et un pour le compte crédité.En outre, il peut y avoir plusieurs enregistrements de faits pour représenter différents états des enregistrements du système source à différents moments de son cycle de vie.

Pour la question de la clé primaire sur la table de faits, il n’y a vraiment pas de réponse « correcte ».Vous pourriez souhaiter certaines caractéristiques souhaitables/essentielles (par exemple, pour que l'identité d'un seul enregistrement soit facilement communiquée entre les utilisateurs du système, ou pour qu'un seul enregistrement soit facilement supprimé ou mis à jour).Cependant, pour un système Oracle, un ROWID pourrait très bien faire l'affaire tant que cela n'a pas d'importance s'il change occasionnellement.

En réalité, la maintenance d'une seule clé synthétique entraîne si peu de frais généraux que vous pourriez tout aussi bien le faire de toute façon.Vous pouvez choisir de ne pas l'indexer, car l'index sera un consommateur de ressources beaucoup plus important que la colonne elle-même.