C'est pour répondre à la partie:
J'essayais de comprendre si les tables de dimension peuvent également être des tables de faits ou non?
La réponse courte (INMO) est non, car les 2 types de tableaux sont créés pour des raisons différentes. Cependant, du point de vue de la conception de base de données, une table de dimension peut avoir une table parent comme le cas avec la table de faits qui a toujours une table de dimension (ou plus) comme parent. De plus, les tables de faits peuvent être agrégées, tandis que les tables de dimensions ne le sont pas. Une autre raison est que les tables de faits ne sont pas censées être mises à jour sur place alors que les tables de dimension peuvent être mises à jour sur place dans certains cas.
Plus de détails:
Les tableaux de faits et de dimensions apparaissent dans ce que l'on appelle communément un schéma en étoile. Un des principaux objectifs du schéma en étoile est de simplifier un ensemble normalisé complexe de tables et de consolider les données (éventuellement provenant de différents systèmes) dans une structure de base de données qui peut être interrogée de manière très efficace.
Dans sa forme la plus simple, il contient une table de faits (exemple: StoreSales) et une ou plusieurs tables de dimension. Chaque entrée de dimension est associée à 0,1 ou plus de tables de faits (exemple de tables de dimension: géographie, article, fournisseur, client, temps, etc.). Il serait également valable pour la dimension d'avoir un parent, auquel cas le modèle est de type "Snow Flake". Cependant, les concepteurs tentent d'éviter ce type de conception car il entraîne davantage de jointures que la lenteur des performances. Dans l'exemple de StoreSales, la dimension Geography pourrait être composée des colonnes (GeoID, ContenentName, CountryName, StateProvName, CityName, StartDate, EndDate)
Dans un modèle Snow Flakes, vous pouvez avoir 2 tables normalisées pour les informations géographiques, à savoir: Table de contenu, Table de pays.
Vous pouvez trouver de nombreux exemples sur Star Schema. Vérifiez également ceci pour voir une vue alternative sur le modèle de schéma en étoile Inmon vs Kimball . Kimbal a un bon forum que vous voudrez peut-être aussi consulter ici: Kimball Forum .
Edit: Pour répondre aux commentaires sur les exemples pour 4NF:
- Exemple pour une table de faits violant 4NF:
Facture de vente (ID, BranchID, SalesPersonID, ItemID, Amount, TimeID)
- Exemple de table de faits ne violant pas 4NF:
AggregatedSales (BranchID, TotalAmount)
Ici la relation est en 4NF
Le dernier exemple est plutôt rare.