Table des faits clés étrangères null?

Je suis nouveau dans la conception de Data Mart et j'ai besoin de clarifier quelques concepts.

J'ai lu un peu sur la modélisation des dimensions où je vois que les tables de faits stockent des références de clés étrangères aux tables de dimensions.

Supposons maintenant que j'ai une table de dimension phonenumber et une table de dimension phone_extension. (Ces tableaux ont des détails différents à cause desquels je ne peux pas les combiner)

Si je comprends bien, ces deux tables de dimension auront des clés primaires entières pour de meilleures performances, et la table de faits aura sa propre clé primaire entière et stockera également des références de clé étrangère à ces tables de dimension.

Mais supposons que j'ai une situation où tous les numéros de téléphone n'ont pas d'extension téléphonique associée. (certains numéros de téléphone n'ont pas besoin d'une extension)

Pour les numéros de téléphone qui ont une extension, la table de faits aurait des références de clé étrangère aux deux tables de dimension, mais comment puis-je capturer la situation où il n'y a que des numéros de téléphone et aucune extension (et vice versa, c'est-à-dire une extension sans numéro de téléphone) ?

Dois-je capturer de telles informations avec le numéro de téléphone FK dans la table de faits ayant une valeur et une clé étrangère phone_extension null ?? Ou ces objets non liés ne sont-ils pas enregistrés dans des tableaux de faits?

J'ai également besoin de générer un rapport sur ce magasin de données. Alors, dois-je commencer par interroger la table de faits et récupérer les valeurs de clé de dimension ou générer un rapport directement à partir de la table de dimension?

Merci pour votre temps en lisant ceci !!
Appréciez toute aide !!

Vous pouvez laisser le FK à certaines tables de dimensions comme NULL si ces dimensions ne sont pas connues ou ne s'appliquent pas. Vous devez simplement vous rappeler d'utiliser les jointures externes lorsque vous effectuez votre requête de création de rapports.

Alternativement, certaines personnes créent un enregistrement de dimension "aucun" et / ou "n / a" pour les dimensions du magasin de données, puis remplissent les FK de la table de faits pour les pointer plutôt que d'utiliser des valeurs NULL. Les gens qui font cela aiment cette approche parce qu'ils ont une aversion pour les jointures externes.

Les personnes qui utilisent des NULL FK en fait des tables ont généralement une aversion pour les personnes qui ont une version pour les jointures externes. ;) (en d'autres termes, c'est un problème stylistique qui peut générer des guerres de religion)

Je dis faire ce que vous préférez, mais choisissez une approche et respectez-la avec ferveur.

Ne mettez pas de null dans l'entrepôt ou dans les marts.

L'entrepôt doit être bien normalisé (au moins BCNF) et doit donc exclure les null. Les valeurs nulles peuvent être conservées dans les tables intermédiaires si elles existent dans les sources de données, mais elles ne devraient pas être nécessaires dans l'entrepôt lui-même.

Les marts doivent être conçus pour prendre en charge les outils de présentation et les requêtes des utilisateurs. Les valeurs nulles gênent simplement ces choses car elles ne sont jamais affichées et elles rendent les requêtes des utilisateurs plus complexes et sujettes aux erreurs, en particulier dans les colonnes de clés étrangères qui sont souvent soumises à des jointures.

les clés de dimension dans les faits ne doivent pas être nulles et avoir des fk aux dimensions pour éliminer le besoin de jointures externes gauche par les utilisateurs finaux, les rapports, etc. Toutes les charges de faits doivent faire une jointure externe gauche à la dimension et par défaut une clé 0 ou pas de clé du tout et échouer. Mieux vaut échouer que faire une jointure à la dimension et ne pas avoir idée que vous avez manqué des lignes dans votre fait, jusqu'à ce que certains utilisateurs le trouvent enfin (si cela arrive)

créez un enregistrement "n / a" dans la dimension phone_extension et liez-le.

ma règle de themb est la seule valeur nullable dans un datamart dwh end est le fait lui-même, de sorte que les fonctions d'agrégation comme avg fonctionnent toujours.