schéma en étoile Conception/meilleures pratiques

Question

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

• compte (Stockage des comptes bancaires, transactions, etc.)
• (Informations relatives au client) Client
• crédit (obtenir des taux de système 3ème partie)
• qualité (plus de calcul interne)

Je veux créer 4 tables de faits, une table de fait pour chaque base de données ... par exemple, j'aurai une table Account Fact avec ClientAccount, Transaction, Provider 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 base de données? c'est-à-dire créer des tables de faits et de dimensions comptables dans la base de données du compte? Ou est-il préférable de créer une nouvelle base de données pour l'ensemble de notre schéma en étoile, et d'inclure toutes les tables de dimension et de faits dans leur propre base de données?

Answer 1

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

Je vous recommande de créer tous vos Dims et Facts dans une seule base de données 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. En ce qui concerne les dimensions et les faits, les données de la table de compte OLTP seraient utilisées pour créer un Dim et un Fait. DimAccount à tout le moins serait une dimension dégénérée contenant juste le numéro de compte. Vous devez examiner vos données pour déterminer si l'un des autres enregistrements est un attribut générique du compte. FactAccount contiendrait des références aux autres dimensions (DimAccountType, DimCustomer, DimLocation, etc.)

Considérez les dimensions comme les valeurs des tables de recherche/listes déroulantes, qui existent avant tout événement. Par exemple, une banque peut proposer des comptes d'épargne &, même s'ils n'ont pas encore de compte.

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

Answer 2

Sans en savoir trop sur le système, je suggérerais que ce sont dimension tables plutôt que des tables de faits. Une table de dimension représente une entité ou un objet que vous pouvez utiliser pour construire un fait. Les comptes 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 doit représenter des enregistrements 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 clés étrangères 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 seule base de données. 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 processus ETL pour remplir ces tables de faits et de dimensions peut extraire les données de ces quatre bases de données et les charger dans une base de données, et à partir de là, vous pouvez construire les cubes dans une base de données unique.