J’ai un souci d’entité non obligatoire. Je viens d’hériter d’un modèle décisionnel (beaucoup trop dénormalisé à mon goût mais là n’est pas le problème) dont on s’est aperçu après coup que le client voulait absolument voir ses données même si certaines ne sont pas renseignées.
Soit l’exemple suivant:
Entité 1 : Ville
Entité 2 : Société
Entité 3 : Nom du responsable.
Entité 4 : Calendrier
L’association reliant ces 4 entités est le chiffre d’affaire par exemple.
Donc ça nous fait une table de fait FAIT_CA
dont la PK = id_ville, id_société, id_nom, id_date
et l’indicateur CA du jour
Donc le client nous demande que id_nom et id_date puissent être non renseignée[ul]
[li]pour pouvoir voir ces données provenant de la base transactionnelle [/li][li]pour pouvoir voir ces donnés en faisant un lien avec d’autres données sans la date renseignée par exemple.[/li][/ul]Pour l’instant je n’ai trouvé que 2 solutions pas propres que je ne souhaiterais pas mettre en place:[ul]
[li]enlever la clé primaire[/li][li]remplir par une valeur bidon id_date ou id_nom, pour que la clé primaire fonctionne, et indiquer avec un autre attribut que la donnée est bidon.[/li][/ul]Petit indication. Le modèle transactionnel dont proviennent les données est un modèle de données certes relationnelles mais qui simule un workflow.
Ville-> Ville, Société -> Ville, Société, nom du responsable -> Ville, Société, nom du responsable, date de validation
Dans la majeure partie des cas je suis pour bien normaliser et mettre des clés primaire mais ce n’est pas un argument pour les utilisateurs finaux évidemment.
Merci de votre aide B)
PS: exemple fictif mais je ne peux donner d’exemple reconnaissable
Houla ouais, c’est bien crado ce truc. Quand ils zappent la date ou bien le nom du responsable c’est pour un aggrégat (avec une petite vue adéquate, enfin 3 petites vues plutôt, on arrive à simule l’absence de date et/ou pti chef), ou bien, c’est qu’ils comptent mettre tout et n’importe quoi dans cette même table (auquel cas, des tables séparées feraient peut-être l’affaire, une union a posteriori si nécessaire permettant de tout réafficher) ? Ou alors j’ai pas compris ce que tu as écrit (très possible aussi vu la fièvre de cheval que je me tape B))…
si si tu as tout compris. Sauf un petit truc: il ne s’agit pas de simuler l’absence de date mais au contraire d’y palier. Ces données n’existent pas dans la base amont pour certaines lignes, c’est là tout mon problème.
Effectivement on pourrait faire une autre table sans la date, dans mon exemple. Comme le projet est avancé j’aimerais éviter. Mais comme ce n’est pas BO au dessus mais jasper, donc SQL statique et pas de problème de contexte et de boucle, ça serait peut être un idée de faire des UNION et plus facile pour alimenter séparément ces 2 tables. (Par contre les vues j’évite)
Je me freinais des 4 fers pour rajouter des tables sur un projet aussi avancée mais je n’avais pas pensé à l’UNION en face de la solution de faire plusieurs tables . Comme tu dis un UNION de la table de fait complète, PK comprise, avec une table de fait sur une PK ne portant que les 3 entités.
edit: Par contre si Nom n’est pas remplie non plus je peux faire une 3é table mais ça complique les choses. Peut être en jouant avec les clés uniques et faire une PK physique.
edit2: Il faut que je réfléchisse et soupèse avec l’autre éventualité de créer des valeurs pour les valeurs nulles avec une indication de cet état edit3: mais alim plus compliquée dans ce cas là.
Bon, le monde du décisionnel est un peu tout nouveau pour moi (changement de boite récent), mais de ce que j’en ai compris il n’y a pas à avoir de clé primaire dans les tables de fait. Les tables dimensions ont une clé primaire sur l’identifiant de leur entité, et les tables de faits ne contiennent que des clés étrangéres vers les tables de dimensions. Donc effectivement si tu viens (comme moi) d’un dév plus traditionnel, ce manque complet de normalisation surprend mais est tout à fait commun en décisionnel.
Je suis dans le monde du décisionnel depuis 8 ans et c’est la première fois que je lis cela, qu’une table de fait n’aurait pas de PK.
L’interêt de la PK n’est pas l’indexation mais surtout pour vérifier la contrainte d’unicité. De plus la PK permet de mettre à jour la table plus facilement pour pouvoir déterminer quelles lignes sont à mettreà jour et à ajouter.
[quote name=‘page 5’]Afin de permettre toutes les jointures, toutes les tables (faits, dimensionnelles) doivent obligatoirement être nommées et posséder un identifiant clé primaire.[/quote] d’autant plus que [quote name=‘page 3’]Les tables de faits représentent des associations dont l’existence d’une occurrence dépend de l’existence des occurrences correspondantes dans les tables dimensionnelles, c’est-à-dire la table de fait contient l’ensemble des mesures correspondant aux informations de l’activité à analyser.[/quote] c’est-à-dire qu’une association à partir de plusieurs entités, ne peut donner par merise (ou même UML), qu’une clé primaire.
Mais bon ça m’a permis de trouver cet excellent document en pdf.
PS: Tiens un autre lyonnais B)
edit: Bon après le monde réel nous oblige quelque fois à outrepasser la théorie mais cela doit être rare, sinon autant revenir aux bases de données d’après guerre et réinventer la roue. Donc j’aimerais vraiment ne pas enlever les PK qui me poserait des problèmes d’intégrité de données, de mise à jour, de temps de traitement etc.
edit2: On peut aussi dénormaliser, je suis assez reservé là dessus, mais enlever la PK n’a rien à voir avec la dénormalisation. En décisionnel il faut parfais dénormaliser mais pas à tout va ni systématiquement mais en fonction des besoins.
Bah je dois avouer que je trouve ça aussi étrange, mais c’est ce que l’architecte du coin m’a expliqué, et je suis allé voir le MPD d’un projet en cours et je n’y ait vu aucune PK dans les tables de fait. Après l’architecte d’ici peut avoir tout faux, je n’en sais rien B)
Question con : une clé primaire ne peut pas contenir de champ Nullable? Il me semble bien que si.
Dans ce cas, c’est tout simple, tu mets les champs de FK optionnels en nullable et c’est finit.
non une clé primaire ne peut pas contenir de champs nulls, contrairement à une clé unique.
Mais même avec une clé unique je ne pourrais avoir qu’une fois a, b, NULL.
Et sans clé unique je suis obliger d’alimenter entièrement la table de A à Z sinon je m’expose à des doublons pour les lignes normales sans NULL. Pour moi on devrait résoudre le problème par la modélisation
Sinon, pour ton souci, il y a aussi effectivement, la possibilité d’ajouter une colonne de statut supplémentaire qui te permet d’esquiver les NULL si tune veux pas de l’UNION. Suivant les cas, je passe par l’une ou l’autre (uniquement en fonction du contexte, trop particulier pour en tirer une conclusion). Dans tous les cas, la règle est immuable : modèle de merde => alim de merde… B)
PS: +1 pour les PK, à part pour certains aggégats précis recomposés à partir de tables de fait, j’ai pas souvenir d’avoir jamais zappé des PK, et surtout pas en généralisant à toutes les tables de fait.