Factorisation des entités

**Kropernic** · 20/04/2015, 14h36

Bonjour,

Je viens vers vous afin d'ouvrir un débat qui vient d'éclore, sur le forum VB.NET suite à la question d'un membre, entre mactwist69 et moi-même. Pour les curieux, voici la discussion en question.

Nous avons continué la discussion en privé histoire de ne pas polluer la discussion autour de la question du membre et nous avons décidé de porter la question à votre attention car nous sommes sincèrement persuadé d'avoir raison l'un comme l'autre.

L'exemple qui nous chagrine est le suivant :

Disons que nous avons un CLIENT et que ce client possède une ADRESSE.

De mon point de vue, je pars du principe que CLIENT et ADRESSE sont deux entités-types distinctes. Je pose la règle de gestion qu'un client possède au moins une adresse et qu'une adresse est possédé par un (et un seul) client.

Le MCD qui en découle me semble évident et au final (ie. au MPD), on arrive avec une table contenant et une table contenant les adresses avec une référence vers la table client pour savoir à quel client appartient l'adresse.

Pour mactwist69, qui part du principe qu'un client n'a qu'une seule adresse, les entités-types peuvent être fusionnées. Par conséquent, les tables du MPD le seront, elles aussi. Et à la question "comment gérer le fait qu'un client peut posséder une 2e adresse le jour où le cas se présente ?", il répond qu' "il suffit d'ajouter le nombre de colonnes nécessaires à la table".*
*je résume mais pas tant que ça.

Se pose aussi la question de la performance. Je ne suis pas assez calé dans la gestion des pages en mémoire, ni du nombre de lectures qui sera nécessaire de faire dans un index alors je ne peux répondre.

Mais je sais que certains ici sont plus que qualifié pour éclaircir cette situation. C'est pourquoi je viens vers vous (avec l'accord de mactwist69 bien sûr!).

Merci d'avance pour les futures réponses.

**mactwist69** · 20/04/2015, 14h45

Je rectifie un peu le sujet :

Le sujet de base était : Il n'y a Qu'UNE adresse !

Et dans ce cas là, oui je le mets dans la table client.

(Après il s'est posé la question de si on devait ajouter une adresse... Mais gardons ce sujets différents pour plus tard).

Donc pour recentrer le sujet : c'est plutôt qu'on part du principe qu'il n'y a qu'une adresse :

Y'a t il une utilité à séparé ces données ?

Sachant que donc dans notre exemple, pour une ligne client, il n'y aura qu'une ligne d'autres infos (important, sinon on comprends pas le thème)...
En poussant le sujet un peu plus loin, en appliquant l'une ou l'autre méthode à tout un modèle, on peut avoir une deux types de schémas :

1) Une table avec 30 colonnes (info client / adresse / info perso / etc...)
2) 15 tables contenant les mêmes colonnes que au dessus mais séparées : client / adresse / info perso

Et là on peut se poser la question des jointures multiples et/ou sous requêtes qu'on devra faire si on choisi la solution des 15 tables...

J'ajoute qu'un autre point positif de la première solution, c'est qu'on est sur de ne pas perdre des petits (accident de mise à jour etc...)

**Kropernic** · 20/04/2015, 14h48

Envoyé par mactwist69

Je rectifie un peu le sujet :

Le sujet de base était : Il n'y a Qu'UNE adresse !

Méa culpa.

**mactwist69** · 20/04/2015, 14h49

C'est qu'on arrive facilement à déclencher 3 conversations en même temps avec un post, lol
Mais la question de base est intéressante.

(Et pour le cas où on aurait pu prévoir qu'un personne peut avoir n adresse, bien entendu je valide la table adresse)

**JPhi33** · 21/04/2015, 00h36

Bonsoir Kropernic et mactwist69,

Donc nous sommes dans l'hypothèse où un client a une et une seule adresse et à une adresse on ne trouve qu'un seul client.

En premier lieu, il faut souligner qu'il s'agit d'un cas particulier qui prive le système de sa capacité à gérer tous les autres cas. En effet :

Il sous-entend qu'aucun client ne peut avoir plusieurs adresses. Souvent dans les applications de gestion un client a une adresse de livraison et une adresse de facturation qui peuvent être différentes (et d'autres types d'adresses sont possibles).
Il sous-entend qu'une adresse n'est affectée qu'à un client. Dans les applications de vente par correspondance, par exemple, il n'est pas rare que plusieurs membres d'une même famille, donc résidant à la même adresse, aient chacun un compte, et soient donc considérés comme des clients différents.
Enfin, il sous-entend aussi que tout client a obligatoirement une adresse. Donc, en toute rigueur, on ne peut pas enregistrer un client dans le système s'il n'a pas d'adresse.

Mais soit, partons de cette hypothèse. La tentation est grande de "fusionner" ces deux concepts différents dans une même entité (donc au final dans une même table). On a donc l'égalité CLIENT = ADRESSE.
Mon avis est qu'il ne faut pas céder à la tentation pour deux raisons.

On bloque toute évolutivité du système vis-à-vis du rapport qu'il y a entre les deux concepts. On ne saura jamais gérer aucun des 3 cas ci-dessus. Et il y a fort à parier qu'un jour, l'un de ces cas se produira.

On élimine le concept d'Adresse en le faisant disparaître dans celui de Client. Sauf s'il s'agit d'une application "maison" (par soi-même, pour soi-même), on ne travaille jamais seul. Si ce concept Adresse est apparu au cours du recueil d'informations auprès de l'utilisateur du système, c'est que ce concept a une importance pour son métier. Il n'est donc pas judicieux de l'éliminer.

**Kropernic** · 21/04/2015, 07h52

Envoyé par JPhi33

Bonsoir Kropernic et mactwist69,

Donc nous sommes dans l'hypothèse où un client a une et une seule adresse et à une adresse on ne trouve qu'un seul client.

En premier lieu, il faut souligner qu'il s'agit d'un cas particulier qui prive le système de sa capacité à gérer tous les autres cas. En effet :

Il sous-entend qu'aucun client ne peut avoir plusieurs adresses. Souvent dans les applications de gestion un client a une adresse de livraison et une adresse de facturation qui peuvent être différentes (et d'autres types d'adresses sont possibles).
Il sous-entend qu'une adresse n'est affectée qu'à un client. Dans les applications de vente par correspondance, par exemple, il n'est pas rare que plusieurs membres d'une même famille, donc résidant à la même adresse, aient chacun un compte, et soient donc considérés comme des clients différents.
Enfin, il sous-entend aussi que tout client a obligatoirement une adresse. Donc, en toute rigueur, on ne peut pas enregistrer un client dans le système s'il n'a pas d'adresse.

Mais soit, partons de cette hypothèse. La tentation est grande de "fusionner" ces deux concepts différents dans une même entité (donc au final dans une même table). On a donc l'égalité CLIENT = ADRESSE.
Mon avis est qu'il ne faut pas céder à la tentation pour deux raisons.

On bloque toute évolutivité du système vis-à-vis du rapport qu'il y a entre les deux concepts. On ne saura jamais gérer aucun des 3 cas ci-dessus. Et il y a fort à parier qu'un jour, l'un de ces cas se produira.

On élimine le concept d'Adresse en le faisant disparaître dans celui de Client. Sauf s'il s'agit d'une application "maison" (par soi-même, pour soi-même), on ne travaille jamais seul. Si ce concept Adresse est apparu au cours du recueil d'informations auprès de l'utilisateur du système, c'est que ce concept a une importance pour son métier. Il n'est donc pas judicieux de l'éliminer.

My point exactly (ou presque) !

**mactwist69** · 21/04/2015, 08h51

My point too !!! lol

Nan mais concrètement, on est d'accord, ce que vous dites c'est : "Oui, mais au cas où".

On a pris l'exemple de l'adresse, et par déformation professionnelle (et expérience), on se dit "oui mais l'adresse, il en faudra plusieurs" etc...

Mais la réponse qui dit : 1 client = 1 adresse, donc on factorise, c'est juste.
Donc quelque part, avoir une table client qui aurait 30 colonnes, n'est, en soit, pas un problème à part entière.

Il faut forcement avoir différentes tables quand on a un rapport 1-n, mais je "milite" plus pour le cas inverse, où on aurait tendance à avoir des dizaines de table qui ont un rapport 1-1, qui pour moi complique les choses inutilement, ajoute des possibilités d'avoir des orphelins ou des doublons...

**Kropernic** · 21/04/2015, 09h00

(haha, j'espérais bien te faire réagir ^^)

Si les contraintes nécessaires sont correctement mises en place, tu n'auras jamais d'orphelin ou de doublons, même avec une chiée de tables. Par contre, pas question de créer des tables juste pour créer des tables. Il faut que ce soit cohérent avec le domaine traiter.

**mactwist69** · 21/04/2015, 09h10

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Si les contraintes nécessaires sont correctement mises en place

Si tu parles d'utiliser vraiment les tables relationnelles avec de VRAI clés étrangères dans MS SQL SERVER, et toutes les options qui vont avec...

Sache que ça fait 10 ans que je travail, dans plus de 6 entreprises (certaines assez grosses), aucune d'elle n'utilise ça !
Les clés étrangère se font à la main... ^^'

Ca n'a jamais été de mon ressort, et surement que les chefs de projets qui ont montés les projets (plus développeur que DBA) préféraient gérer du code plutôt que les bases de données... En tout cas, ça m'a fait prendre des réflexes de conceptions de modèle pour protéger au maximum les données.

Il y a toujours la théorie et la pratique...

**Kropernic** · 21/04/2015, 09h39

Envoyé par mactwist69

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Si les contraintes nécessaires sont correctement mises en place

Si tu parles d'utiliser vraiment les tables relationnelles avec de VRAI clés étrangères dans MS SQL SERVER, et toutes les options qui vont avec...

Sache que ça fait 10 ans que je travail, dans plus de 6 entreprises (certaines assez grosses), aucune d'elle n'utilise ça !
Les clés étrangère se font à la main... ^^'

Ca n'a jamais été de mon ressort, et surement que les chefs de projets qui ont montés les projets (plus développeur que DBA) préféraient gérer du code plutôt que les bases de données... En tout cas, ça m'a fait prendre des réflexes de conceptions de modèle pour protéger au maximum les données.

Il y a toujours la théorie et la pratique...

Aaaaaaaaaaah mais quelle horreur ! Oui effectivement, je parle d'utiliser le SGDB(R) correctement.

Ici, la société dans laquelle je travaille, c'est moi qui fait tout. Enfin... Je devrais dire c'est nous qui faisons tout car j'ai un collègue mais il est en maladie depuis un bout de temps et ne reviendra probablement pas

. Et quand je dis tout, c'est tout. Y compris tirer les vers du nez des gens qui demandent un développement pour savoir ce dont ils ont vraiment besoin.

[Hors-sujet perso]
Du coup, effectivement, j'utilise le SGDB(R) correctement (ou du moins, du mieux que je peux) et je mets des clefs étrangères, des clefs alternatives, des contraintes check et j'en passe. Je blinde la DB au maximum. Alors bien sûr, je fais aussi pas mal de vérif du côté applicatif mais le jour où j'oublie de coder un test, la DB me gueule dessus et mes données ne sont pas corrompues avec obligation de restaurer un backup...

Ca c'est pour moi. Pour mon malchanceux collègue, ce n'est pas la même histoire. Comme ceux qui t'emploient, il est de la vieille école. Il a connu et appris les DB avec les DB de type Advantage Database Server qui sont des DB de types fichiers dans lesquelles, sauf erreur de ma part, les clefs étrangères n'existent pas. Alors quand je dois intervenir sur un de ces projets, c'est l'angoisse. Pas plus tard qu'hier, j'ai un call comme quoi un pdf qu'un de ces applicatifs génère est vide alors qu'il devrait contenir quelque chose. Vu que j'ai pas les sources

, je prie pour que le problème se situe en DB. Heureusement, c'étiat le cas. Par contre, pas de clefs étrangères, des colonnes mal typées, des noms colonnes ambigus ou pas forcément bien choisi. Je suis finalement parvenu à résoudre le problème en écrivant une requête qui me générait une autre requête pour chaque colonne pouvant contenir du texte dans chaque table avec comme critère un texte que je savais qu'il devait être présent dans le pdf. J'ai finalement trouvé mon bonheur et j'ai pu alors modifier la procédure stockée défectueuse pour corriger le problème et que son applicatif génère à nouveau des pdfs avec du contenu
[/Hors-sujet perso]

Maintenant, effectivement si tu es obligé de bosser avec des DB crades, c'est pas de bol. N'empêche, de là à conseiller ce genre de technique aux débutants du forum, il y a un pas que je ne franchirai pas.

Mais tu as raison, il y a une différence entre théorie et pratique. Sûrement que cette différence varie d'un individu à l'autre mais, dans mon cas, cette différence se limite à autoriser les attributs 'description' et 'remarque' à NULL dans une table plutôt que de créer une table supplémentaire juste pour chaque colonne là où dans mon MCD, je fais bien la distinction. Je ne procède à cette légère dénormalisation que dans de rare cas et uniquement au MPD pour ne pas polluer la logique du MCD pour les futures modifications qui seront demandées.

**mactwist69** · 21/04/2015, 09h59

Ah mais je suis bien d'accord avec toi...

J'ai TOUJOURS travaillé avec des Base de données pourris, parce que les chefs de projets informaticien s'en foutent un peu.
Du coup, même aujourd'hui, 30% des colonnes n'ont pas le bon type, le nommage est pourri et je parle pas des contraintes qui n'existe pas.

Mais attention, ne me fais pas dire ce que je n'ai pas dit (au débutant)...
Je fais la distinction entre les bidouilles que je dois utiliser pour protéger les données, et "ce qu'il faut faire" au niveau du modèle idéalement.

Donc je remets dans le contexte, le débutant voulait faire ces deux tables :

"JOUER" table de relation avec comme attribut(id_jouer, id_equipe_ext, id_equipe_dom, id_resultat)
"RESULTAT" (id_resultat, score_equipe_ext, score_equipe_dom)

-> C'est à partir de là, que le débat a commencé...
Et clairement ici, oui je conseil de fusionner les deux tables...

**Kropernic** · 21/04/2015, 10h17

Si ça s'arrêtait là oui. Mais il nous a parlé des buts. Du coup, on va avoir une table entité but en relation avec la relation jouer (que je convertis en entité match) qui listera les buts et donc le résultat du match sera calculable.

Bref, on va attendre de voir s'il lit la lecture que je lui ai filé et s'il revient vers nous avec des règles de gestion et un mcd sur base desquels travailler ^^.

Je pense qu'en fait on est d'accord mais qu'on ne regarde pas les choses du même angles ^^. Du coup, tu dis que c'est une droite et moi je dis que c'est un plan alors qu'en fait...

**mactwist69** · 21/04/2015, 10h21

Tout à fait.

En plus sur les buts j'étais d'accord, mais il à l'air vraiment débutant (notamment en SQL), il semblait difficile de lui expliquer directement que tout est calculable en SQL si il a les buts...

Mais on est d'accord.

**JPhi33** · 21/04/2015, 23h54

Bonsoir à tous,

Envoyé par mactwist69

Nan mais concrètement, on est d'accord, ce que vous dites c'est : "Oui, mais au cas où".

Pas seulement.
Tu oublies un peu vite la 2e raison ; celle qui dit que la disparition du concept Adresse risque d'être inacceptable aux yeux du métier. Elle est tout aussi importante que la 1e, si ce n'est pas plus...

**mactwist69** · 22/04/2015, 08h50

"Oui mais" tout dépend du contexte...

Si l'adresse est un concept totalement mineur dans le métier justement...

J'ai un exemple, ou une "personne" EST le concept avec son adresse, et ce n'est absolument pas le cœur du métier.

**SQLpro** · 28/04/2015, 12h42

Envoyé par Kropernic

[...]
Pour mactwist69, qui part du principe qu'un client n'a qu'une seule adresse, les entités-types peuvent être fusionnées. Par conséquent, les tables du MPD le seront, elles aussi. Et à la question "comment gérer le fait qu'un client peut posséder une 2e adresse le jour où le cas se présente ?", il répond qu' "il suffit d'ajouter le nombre de colonnes nécessaires à la table".*

Ceci viole un principe fondamental de modélisation :
Pas de NULL !
Or en ajoutant un jour les n colonnes pour une seconde adresse dans la table des clients, tous les clients déjà présent auront des NULLs dans les nouvelles colonnes.
L'autre solution serait donc de rajouter une table pour les adresses secondaires, mais là, la recherche d'une personne par son adresse impose immédiatement deux problématique :
1) la réécriture de la requête initiale de recherche d'une personne par son adresse pour tenir compte de l'adresse secondaire
2) les mauvaises performances du fait de la lecture de deux tables au lieu d'une !

Bref, cette position est indéfendable, anti performante, peu évolutive... bref, stupide !

A +

**SQLpro** · 28/04/2015, 12h57

Envoyé par mactwist69

Les clés étrangère se font à la main... ^^'

C'est très, très con... En effet, les bons SGBDR comme Oracle ou SQL Server dispose d'un optimiseur sémantique en sus de l'optimiseur statistique qui tire partie notamment des contraintes... pour simplifier les plans de requête...
De ce fait, les performances seront systématiquement moins bonnes !
Je passe mon temps en audit à inviter les gens à rectifier ce genre de pratiques hérétiques afin de booster les performances de leurs applications qui sont poussive par leur faute !

De plus il est strictement impossible de simuler à la main (côté applicatif) la moindre contrainte de SGBDR au niveau table. En effet, du fait de la concurrence, un utilisateur A peut supprimer une ligne que l'utilisateur B bien de "checker" pour valider son intégrité référentielle ! Démonstration :

Conditions de départ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Soit les tables :
- T_CLIENT (CLI_ID primary key, ...)
- T_FACTURE (FAC_ID primary key, CLI_ID ...) 
sans contrainte FK

Le client 33 existe dans T_CLIENT mais n'a pas de facture relative...

Les requêtes lancées en même temps côté applicatif :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Temps     user A                          user B
--------  ------------------------------  ---------------------------------------
t0        IF NOT EXISTS                   IF EXISTS
            (SELECT *                        (SELECT *
             FROM   T_FACTURE                 FROM   T_CLIENT 
             WHERE  CLI_ID = 33)              WHERE  CLI_ID = 33)
          DELETE T_CLIENT                 INSERT T_FACTURE (FAC_ID, CLI_ID ...)
          WHERE  CLI_ID = 33;             VALUES (999, 33...);

Vont toutes les deux réussir et la facture 999 sera orpheline !

IL EST STRICTEMENT IMPOSSIBLE DE GARANTIR L'INTÉGRITÉ D'UNE BASE CÔTÉ APPLICATIF

Dans tous les audit que j'ai rendu, sans exception, il existait des lignes orphelines lorsque l'IR n'était pas mise en œuvre via les contraintes FK !

A +

**mactwist69** · 28/04/2015, 16h41

Je suis d'accord avec vous et je ne soutient pas le contraire.

Moi j'explique juste ce qu'il se passe en entreprise.

Factorisation des entités [MCD]

Schéma

Discussions similaires

Partager

Partager