Par exemple, le fait qu’il existe des tables de faits sans faits …
C’est un peu comme si on avait des moules sans frites, une bière sans mousse, un avion sans ailes, un film de Tim Burton sans Johnny Deep ou une version de BO sans bug …

Je n’invente rien, tout est expliqué là, in french :
Cours de modélisation décisionnelle

En résumé il s’agit tout simplement de tables de faits sans mesures ( ou sans indicateurs ).
On trouvera ce type de table pour représenter surtout l’absence d’événements ( produits qui ne se sont pas vendus lors d’une promotion par exemple ). On répertorie ces tables en tables de suivi d’événements ou tables de couverture, c’est beau à dire et ça fait cultivé mais bon je m’éloigne là …

Alors pour moi un fait est un événement, par exemple une vente.
Un fait par homonymisme c’est « ce qui a été fait », ou « sera fait » …
Une table de faits correspond à une table d’événements, ces événéments correspondant au croisement des dimensions dans l’espace temps. Par exemple on aurait les ventes au mois par vendeur et par produit.
Mais on a toujours des faits dans une table, même si on n’a pas forcément d’indicateurs / de mesures.
Par exemple si on prend les absences d’élèves, on aurait une table de faits sans mesures, mais pourtant on a bien des faits dans la table – l’absence est un fait, on est sur le fait qu’un élève est absent tel jour de la semaine …

Mais voilà on a des tables de faits sans faits.
On aurait pu dire « tables de faits sans indicateurs » ou « tables de faits sans mesures », mais non pourquoi faire simple, autant semer le doute dans les esprits … On notera que les tables de dimension sans dimensions n’existent pas, mais les tables de faits sans faits si !

Evidemment les puristes diront que dans sa définition originale un fait est une mesure, alors qu’une table de faits n’est pas qu’une table de mesures … Du coup les esprits les plus alertes pourraient se dire, c’est une erreur de traduction, mais non pas du tout. On trouve des factless fact tables de l’autre côté de notre planète.

Moi j’aurais tendance à dire que le mal est fait …

Merci Ralphy

Par exemple nous avons une table VENTES et la table calendrier TEMPS.
La table TEMPS est au jour, la PK est JOUR de type date – sans heure
La table VENTES a plusieurs dates, dont la date de vente ( colonne DATE_VENTE ) qui est aussi de type date, mais avec l’heure.
On a tendance à lier directement les tables sur les 2 colonnes, mais cela ne ramène aucune donnée car d’un côté on a l’heure, de l’autre on ne l’a pas …

Pire, une requête sur la table calendrier avec la date d’aujourd’hui ( sysdate ) semble légitime pour un utilisateur, mais la requête suivante ne renvoie rien !

Il faut « enlever » l’heure avec la fonction trunc() pour avoir un résultat :
SELECT * FROM TEMPS WHERE JOUR=trunc(SYSDATE)

Généralement quand je n’ai pas la main sur le modèle je mets des trunc() un peu partout pour blinder les choses, mais c’est mieux quand en amont la conception et les normes sont bien faites et bien pensées, et que les noms des colonnes permettent de distinguer les dates avec heure et les dates sans.

Par exemple on peut nommer les colonnes avec heure en préfixant par
DATE_HEURE_ et les dates sans heure par DATE_ uniquement …
( ou DATE_ et DATH_ ou … cela dépend des normes of course … )
Idem pour l’univers BO, il est utile de préciser dans le nom des colonnes si on a affaire à une date avec heure ou sans.

Ainsi on sait tout de suite s’il faut rajouter un trunc() dans les jointures, et cela évite bien des erreurs …

Il reste le problème des dates qui contiennent des dates avec heure ET des dates sans heure, mais c’est une autre histoire …

Que faut-il choisir entre Un modèle en étoile ou un modèle en flocons ?

On se pose tous la même question quand on commence la conception, sans avoir d’éléments de réponse.
Je vais essayer ici de donner les différences entre les deux types de modélisation, et mon point de vue sur la question.

Mais avant quelques rappels :

Le schéma en étoile :
Les dimensions sont dénormalisées afin de concentrer toutes les informations en une seule table. Cela implique qu’on y retrouve certaines colonnes ayant plusieurs fois les mêmes valeurs.
Elles sont disposées autour d’une table de faits, à la manière d’une étoile.

Le schéma en flocons :
Seules les dimensions changent par rapport au modèle en étoile.
Dans le schéma en flocons, elles sont normalisées. Au lieu de tout concentrer en une seule table on a plusieurs tables liées en une arborescence, chaque niveau de la hiérarchie donnant lieu à une table.
>

Les différences :

1/ Performances
Avantage : — étoile ? –
On dit souvent que le modèle en étoile est plus performant. Cela est dû au fait qu’il y a moins de jointures à faire que sur un modèle en flocons.
Je dirais que c’était vrai il y a quelques années, quand les SGBD étaient moins performants.
Mais actuellement la différence est minime, les SGBD gérant mieux les jointures multiples. De plus les jointures supplémentaires mettent en oeuvre généralement des tables à faible volumétrie. Cependant il suffit que les stats Oracle soient mal calculées pour obtenir des plans d’exécution erronés et plomber un modèle en flocons.

1bis/ Contre-performance :
Une table de dimension en jointure réflexive dans un modèle en flocons est à proscrire.
Par exemple si on a une table de hierarchie décrivant la structure de l’entreprise, une colonne « père » permettant de faire le lien sur la même table

Le SGBD va lire plusieurs fois la même table, les accès concurrents se faisant sur le même disque les performances seront très dégradées.
Il vaut mieux créer plusieurs tables différentes, chacune représentant un niveau de la hiérarchie.

2/ Volumétries
Avantage : — flocons –
Si la dimension a de nombreux attributs, on a une table qui prend plus d’espace pour le modèle en étoile.
Il vaut mieux choisir un modèle en étoile sur de grosses volumétries quand le ratio devient faible ( 1:50 ), sinon en aplatissant en une seule table les redondances seront trop nombreuses.

3/ Compréhension
Avantage : — flocons –
Certains disent que les modèles en étoile sont plus compréhensibles au premier abord car ils sont plus lisibles, aérés.
Pourtant les hiérarchies sont plus compréhensibles par les utilisateurs dans un modèle en flocons, puisqu’elles sont représentées par les jointures. Alors que dans un modèle en étoile on a plus de mal à voir quel attribut est avant l’autre …

4/ Modèles spécifiques
Avantage : — flocons –
Le modèle en flocons est plus adapté pour les relations n n.
Par exemple si on prend la dimension Compte/Client dans le secteur bancaire, 1 compte a 2 clients, et 1 client a plusieurs comptes …

5/ Tables agrégées
Avantage : — flocons –
Le modèle en flocons est adapté aux tables agrégées comme les vues matérialisées d’Oracle.
Prenons par exemple une table ventes à volumétrie importante.
Pour des raisons de performance on l’a agrégée suivant la semaine, le mois et l’année. Ainsi en fonction de la granularité utilisée, on utilisera la table à la plus faible volumétrie.
Avec le modèle en flocons, les jointures sur les dimensions se font simplement.
Par contre avec le modèle en étoile, avec une seule dimension calendrier ayant le jour en point d’entrée, il faudra :
– soit créer des vues sur la table calendrier au niveau semaine, mois et année et qui dédoublonneront les lignes ( avec un distinct ) pour ne pas multiplier les résultats.
– soit bricoler les jointures dans l’applicatif de restitution ( par exemple lier une table agrégée au mois sur le 1er jour du mois )

6/ Attributs partagés
Avantage : — flocons –
On a souvent des niveaux partagés entre plusieurs dimensions comme le pays dans notre exemple.
Dans un modèle en étoile ces niveaux sont dupliqués dans chaque table, ce qui implique de bons process pour synchroniser les données dans toutes les tables.
Dans un modèle en flocons on n’a pas ce problème car on n’a qu’une seule table.

5/ Applicatifs
Avantage : — aucun –
Certaines applications comme Microstrategy DSS nécessite un modèle en flocons … J’ai vu un modèle en étoile sur lequel on définissait des vues pour le transformer en flocons … c’est dommage non ?

6/ SCD
Avantage : — flocons –
On peut scinder une dimension en SCD dans un modèle en flocons, ce qui est idéal pour de grosses volumétries ou une dimension avec de nombreux attributs.

7/ Simplicité
Avantage : — étoiles –
Le modèle en étoile est plus un modèle « de fainéants » …
Les requêtes SQL sont + faciles à écrire, puisqu’il y a moins de jointures. De même la modélisation est plus simple et plus rapide.

Conclusion
Il est difficile de choisir entre les 2 types de modèles quand il n’y a pas d’applicatifs ou de fonctionnements spécifiques.
D’expérience on part souvent sur un modèle en étoile à la Kimball qui est réputé performant et pratque en décisionnel. Et puis on revient sur des parties de dimension qui sont partagées, et qu’on « dénormalise » en parties de modèle en étoiles.
A mon avis c’est surement la meilleure solution, un modèle hybride qui fait du flocon sur des parties spécifiques ( SCD, niveaux partagés ) et de l’étoile pour le reste …