Datawarehouse - Comment lier les dimensions

Question

Je viens juste d'entrer dans le datawarehousing et j'ai besoin de votre aide pour clarifier une confusion. Disons que j'ai la dimension d'employé et la dimension de département. Si j'ai un rapport qui me demande de lister les champs de dimEmployee (Nom, Salaire, Position) et les champs du département (DeptNo, Desc, Manager), comment puis-je faire cela. Est-ce que je crée une table de faits (sans faits) qui sera une table de jointure entre ces deux dimensions? Ou dois-je concevoir ces deux tables différemment. Tout le monde parle de faits et de dimensions, mais envisage-t-on même de lier des tables de dimension?

Merci pour vos idées.

RK

Answer 1

Quand vous parlez de tables Dimension et fait vous se réfèrent généralement à des données agrégées. vous pouvez écrire un rapport qui parle du nombre d'employés par département.

Il semble que vous ayez affaire à des listes de données. Cela peut être mieux réalisé en utilisant SQL direct. donc quelque chose comme

SELECT person.Name, person.Salary, Person.Position, 
Department.DeptNo, Department.Desc, Department.Manager 
From person 
    join Department on person.DeptId = Department.Id 

Answer 2

Il devrait y avoir une relation entre employé et département. Cela est généralement effectué en ajoutant une colonne DepartmentId à la table Employee.

Answer 3

Les dimensions typiques d'un problème incluent le temps (toujours), la géographie (par exemple, département, territoire, état, etc.), etc. Dans votre cas, il semble que les échelles salariales d'une entreprise, etc. pertinent.

Les tables de faits contiennent généralement des éléments qui sont additifs (par exemple, le nombre d'individus dans une plage salariale donnée, une position, etc.). Je ne suis pas sûr que l'employé serait considéré comme une dimension; ressemble plus à un fait pour moi.

Answer 4

Merci à tous pour vos réponses. Donc, s'il est nécessaire de trouver des employés au total dans un département dans une certaine gamme de salaire et aussi une exigence à la liste des employés dans un département., La conception peut ressembler à ceci

dimEmployee
EMPID
Dept
Nom
etc ...

dimDept
deptID
Desc
Directeur
etc ....

fctEmpDept
EMPID
deptID
Salaire

Quand je lis à propos de datawarehouse, je ne vois que les dimensions et les tables de faits. J'étais vraiment confus au sujet de la façon dont les tableaux seront structurés s'il y a des exigences pour montrer des listes à des fins de rapports normaux. Apparemment, il pourrait y avoir des dimensions qui peuvent être liées à des clés étrangères.

Answer 5

Si vous gardez vos dimensions indépendantes l'une de l'autre, aucune référence de département dans la dimension Personne, aucune référence de personne dans la dimension Département, une table de faits d'affectation peut servir de pont entre les deux.

Par exemple

Person Table 
------------ 

PersonID 
Forename 
Surname 
EffectiveFromDate 
EffectiveToDate 


Department Table 
---------------- 

DepartmentID 
DepartmentName 

etc 


AssignmentFact Table 
-------------------- 

AssignmentID (primary key) 
PersonID (foreign key to person table) 
ManagerID (foreign key to person table) 
DepartmentID (foreign key to department table) 
Salary 
CostCentre 
EffectiveFromDate 
EffectiveToDate. 

donc un changement à une cession de personnes comme un changement de gestionnaire de ligne ou une promotion ne nécessite aucune modification des dimensions, mais seulement à la table de ce qui fournira un simple et agréable dossier historique des changements. Lorsque vous avez plusieurs tables de faits partageant ces dimensions, les garder simples vous rapportera des dividendes. Essayez une implémentation simple des deux et essayez-les. Je suis sûr que vous trouverez cela plus naturel.

Answer 6

Option A: Si chaque employé peut appartenir à un et un seul département. J'ajouterais le départementID à la table de faits.

Option B: Si un employé peut appartenir à plusieurs départements, j'irais avec une troisième alternative, installer des tables de métriques (ou des tables de faits agrégées). Vous effectuerez ensuite l'agrégation de votre employé par département et stockerez le nombre agrégé dans ce nouveau tableau.

Option C: Vous pouvez ajouter l'ID de service à la table des employés et effectuer le travail, mais vous devez alors définir une hiérarchie. Vous pouvez le faire, mais vos jointures deviennent difficiles et moins efficaces au fur et à mesure de la croissance de votre jeu de données.

J'irais avec l'une des 2 premières options, en fonction de votre relation employé/département.

Je vais admettre qu'il existe d'autres solutions disponibles, mais ce serait votre meilleur pari.