2009-06-19 9 views
0

Dans mon tout nouvel entrepôt de données construit (bien sûr) à partir de la base de données OLTP, j'ai supprimé toutes les colonnes IDENTITY et les ai remplacées par des colonnes INT.Clés et contraintes primaires

Quelles sont les meilleures pratiques en ce qui concerne ce qui suit d'autant plus que l'entrepôt est dénormalisé:

  1. clé primaire
    -> cela peut maintenant être une clé composite car plusieurs tables sont réunis
    -> faire i besoin de suivre la structure clé de OLTP?

  2. Contraintes
    -> il y a des contraintes (NOT NULL) avec des valeurs par défaut (0) pour les colonnes de bits

Répondre

1

Pour votre clé primaire, envisagez d'utiliser un substitut ou alternative; vous devrez adapter les dimensions qui changent lentement, par ex. Si vous faites un rapport sur les ventes moyennes par vendeur marié/non marié au cours des 5 dernières années, vous devez enregistrer le fait que quelqu'un était célibataire pendant 2 ans, puis marié pour les 3 dernières années. Cela signifie que votre entrepôt de données avoir deux rangées de tables de dimension pour la même personne. Suivre la structure OLTP pour cela sera difficile :)

Les contraintes sont moins un problème; Les fichiers DW sont massivement optimisés pour les lectures (en supposant que vous remplissez en tant que lot), et les contraintes ne prennent pas vraiment en compte les opérations de lecture. Vous pouvez généralement contourner tous les problèmes de contraintes avec votre travail de remplissage DW et traiter les valeurs nulles, etc., au niveau de l'outil de génération de rapports si nécessaire. Il est beaucoup plus important de s'assurer que les valeurs par défaut correspondent à votre modèle de données conceptuel, et n'introduisez pas de problèmes dans les outils client DW.

+0

@ Jeremy- Donc, si mon OLTP a une table de personne et une recherche MaritalStatus et une table PersonsMaritalStatus, puis je dénormaliser, ce serait alors une table dans l'entrepôt appelé personne avec une clé composite de personID et MaritalStatusId . Cela expliquerait le changement d'état matrimonial tel que vous le décrivez.
Mes questions sont donc:
-je utiliser la clé composite ou créer une nouvelle colonne (comme je le fais dans OLTP
Dois-je utiliser même perdre mon un index ordonné en clusters sur cette touche ou puis-je enregistrer pour quelque chose d'important? –

+0

Eh bien la difficulté est que vous auriez à faire la même chose pour Zipcode ou PhoneNumber ou tout autre champ ou combinaison de champs qui changeraient rarement, que vous auriez besoin de faire un rapport sur Voilà pourquoi la plupart des solutions qui traitent lentement changement les dimensions vont implémenter une clé alternative :) –

0

Je dirais environ 2 .: colonnes de bits -> travail bool Col. -> seulement 1/0 (vrai/faux) a permis -> ok Constraint

1

Pour dimension tables:

  • Conserver le PK de substitution automatique (identité), sauf pour la dimension de date (voir ci-dessous).
  • S'assure que vous avez une autre "touche naturelle" pour permettre des changements de dimensions lent (type 2).
  • Pas nulls autorisés dans les tables de dimension, les remplacer par verbose "n/a, ne sont pas saisis, inconnu .."
  • Si possible, changer les drapeaux booléens (1/0) verbose "Oui, Non", pour faire il rapport/affaires convivial.
  • Débarrassez-vous des champs calculés et remplacez-les par des valeurs, ou au moins persistez le champ calculé - dépend d'un db.
  • Implémentez le schéma en étoile si vous le pouvez, échangez de l'espace pour la vitesse. Flocon de neige seulement si vous devez.
  • Vérifiez vos requêtes, s'il existe une fonction dans la clause WHERE, ajoutez une colonne à la table de dimension et précalculez les valeurs.
  • Il est facile à la dimension de la date de partition si le PK ressemble 20090619.
  • Débarrassez-vous des contraintes de contrôle et par défaut, déplacez que la phase conforme processus ETL. Les vérifications et les valeurs par défaut ralentissent le chargement et, une fois le chargement terminé, elles ne jouent aucun rôle.

Pour fait tables:

  • Envisager d'avoir une auto-incrément de substitution (identité) PK pour permettre le partitionnement facile, si vous utilisez PK composite, vous pouvez faire un composite unique, non groupés au lieu. Avoir des scripts pour vos clés étrangères dans un endroit sûr, c'est une pratique courante de laisser tomber les clés avant de charger les tables de faits afin d'accélérer le chargement. Certaines personnes exécutent DW avec des clés étrangères étant "logique seulement", elles utilisent des requêtes "look-for-orphelines" après le chargement.

ETL

  • la conception de votre processus PEPE (ETL) à toutes les étapes: extrait, propre, conforme, livrer.
  • Si possible, conservez les résultats intermédiaires (fichiers) après chaque étape à des fins d'audit et de débogage.
  • Documentez l'ETL. Si vous utilisez des scripts, utilisez un contrôle de version pour pouvoir faire correspondre les versions de script avec les fichiers archivés (intermédiaires). Ayez un tableau de lignage de données, Excel est mieux que rien. Gardez les versions aussi.
+0

Bien écrit. J'aurais aimé pouvoir l'emporter plus d'une fois. –

Questions connexes