MS SQL Server
  1. MS SQL Server
  3. Star Schema Design / bonne pratique
Intereting Posts
données plates Ordre hiérarchique Comment vérifier si une string est un identifiant unique? Pourquoi ne puis-je pas exprimer cette sous-requête? Y a-t-il une alternative? login SMTP SSIS Rétablir la connection après chaque boucle Foreach Méthodes de connection SQL et meilleures pratiques Apache 2.4.7 sur Ubuntu 14.04 ne se connectera pas à MSSQL via PHP 5.5 la conversion de la valeur nvarchar a débordé une colonne int pour l'insertion à partir du file Comment séparer datatables dans différentes colonnes sql? Sql Profiler Scan Commencé pour exécuter une procédure stockée Comment créer une table temporaire pour une requête dynamic afin que je puisse BCP la sortie Comment convertir hh: mm: ss en secondes dans SQL Server avec plus de 24 heures La connection n'a pas été fermée, l'état actuel de Connection est une erreur ouverte dans la boucle foreach Plus de précision nécessaire à partir du type de données SQL Server Money Serveur sql: MERGE a des résultats inattendus COUNT (1) + COUNT (DISTINCT ()) beaucoup plus lent, puis 2 requêtes séparément

Star Schema Design / bonne pratique

Je travaille avec un système qui possède 4 bases de données:

  • Compte (Stockage des counts bancaires, transactions, etc.)
  • Client (informations relatives au client)
  • Crédit (obtention des tarifs du système tiers)
  • Qualité (Calcul interne supplémentaire)

Je veux créer 4 tables de faits, une table de faits pour chaque database … par exemple, j'aurai une table de faits de count avec ClientAccount, transaction, fournisseur comme table de dimension. Je vais avoir 3 tables de faits similaires pour d'autres bases de données.

Ma question est la suivante: est-il logique d'inclure chaque table de faits correspondante dans cette database? c.-à-d. Créer des tables de faits et de dimensions comptables dans la database du count? Ou est-il préférable de créer une nouvelle database pour l'set de notre schéma en écanvas, et d'inclure toutes les tables de dimension et de faits dans leur propre database?

À less que votre volume de données soit très faible, votre entrepôt de données doit être hébergé dans une database distincte des données transactionnelles. Un DW a un model d'utilisation différent (OLTP vs OLAP) et aura généralement une window de maintenance différente.

Je recommand de créer tous vos Dims et Faits dans une seule database DW dédiée. Je ne vois aucun avantage à les séparer et cela réduirait votre surcharge de DBA en ne disposant pas de bases de données supplémentaires pour gérer / sécuriser / auditer / documenter.

Comme pour Dimensions vs Faits, datatables de la table Compte OLTP seraient utilisées pour créer un Dim et un Fait. DimAccount à tout le less serait une dimension dégénérée contenant juste le numéro de count. Vous devez examiner vos données pour déterminer si l'un des autres loggings est un atsortingbut générique du count. FactAccount contiendrait des references aux autres dimensions (DimAccountType, DimCustomer, DimLocation, etc.)

Considérez les dimensions comme les valeurs des tables de search / lists déroulantes, qui existent avant tout événement. Par exemple, une banque peut offrir des counts Checking & Savings, même s'ils n'ont pas encore de count.

Les faits documentent un événement. Lorsqu'un count est créé, l'logging de faits fait reference à toutes les dimensions qui décrivent l'événement et enregistre les valeurs mesurables associées à l'événement, le cas échéant.

Sans trop en savoir plus sur le système, je dirais que ce sont des arrays de dimensions plutôt que des arrays de faits. Une table de dimension représente une entité ou un object que vous pouvez utiliser pour build un fait. Les counts et les clients semblent être une bonne solution pour cela. Je ne suis pas sûr de ce que sont le crédit et la qualité, mais ils peuvent aussi être des dimensions.

Votre table de faits devrait représenter des loggings de type transaction. Cela peut être des ventes, des transactions, des appels téléphoniques ou tout ce que votre entrepôt de données rapporte. Cette table de faits aurait alors des foreign keys pour chacune des tables de dimension.

En ce qui concerne une ou plusieurs bases de données: je suggère de le stocker dans une database unique . C'est plus facile à utiliser de cette façon, et vous n'avez pas à vous soucier des liens de bases de données lorsque vous interrogez vos données. Votre process ETL pour remplir ces tables de faits et de dimensions peut extraire datatables de ces quatre bases de données et les charger dans une database, et à partir de là, vous pouvez build les cubes dans une database unique.