Discussion :

[StringBuilder]

Bien sûr que non.

Je peux aussi très bien avoir :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
create table voiture
(
   v_id int not null primary key,
   ...
);
 
create table roue
(
   r_id int not null primary key,
   ...
);

Puis au choix :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
create table voiture_roue
(
   v_id int not null references voiture(v_id),
   r_id int not null references voiture(r_id),
   -- Pas de clé primaire, pas de contrainte d'unicité, rien n'oblige à en avoir une, même si c'est vraiment pas recommandé
   numserie char(30) -- potentiellement unique, ou pas, ça pourrait être un numéro de lot, donc plusieurs roues montées sur des voitures différentes appartenant au même lot
);
 
-- ou
 
create table voiture_roue
(
   vr_id int not null primary key,
   v_id int not null references voiture(v_id),
   r_id int not null references voiture(r_id),
   numserie char(30) -- potentiellement unique, ou pas, ça pourrait être un numéro de lot, donc plusieurs roues montées sur des voitures différentes appartenant au même lot
);

Bref, tout dépend de ce que tu gères.
Il n'y a pas de manière universelle et juste de stocker une donnée en base de données.
Tout dépend de ce qu'on en fait.
Si l'objectif c'est d'avoir une IHM permettant d'ajouter des "lignes" à la voiture qui peut être des roules, des sièges ou je ne sais quoi, on va préférer le modèle dont je te parle, puisqu'une ligne en base = une ligne à l'écran.
Si l'objectif c'est d'avoir un suivi de chaque pièce détachée, alors la table "roue" va évidement contenir le détail de chaque roue, avec son niveau d'usure, etc.
Si l'objectif c'est de facturer des accessoires optionnels sur la voiture, alors on n'aura qu'une ligne de roues par voiture avec un attribut "nombre" pour savoir combien on en facture.
Si l'objectif c'est de réserver un nombre de roues d'un lot en cours de fabrication, alors on n'aura même pas de lien entre la voiture et ses roues, mais simplement un lien entre la voiture et le numéro de lot de fabrication + quantité réservée.

Bref, y'a pas de "on part de loin" qui tient ici.²

[wulfram]

Oui, c'est le bon modèle.
En termes de performances, cela va se ressentir immédiatement (d'autant plus je le répère avec SQLite qui implique un moteur léger, de la mémoire partagée donc limitée, et potentiellement une machine déjà limitée : c'est pas un serveur, elle fait tourner d'autres choses, etc.)
En effet, passer de PK de 150 caractères (donc potentiellement 300 octets si ce sont des chaines unicode) à 3 x 32 ou 64 bits, y'a pas photo, vous compressez vos index de plus de 99% !

Ensuite, faires des requêtes à rallonge ne représente une perte de temps que pour le développeur qui les écrit. A l'exécution, elles seront plus rapide (moins de données à manipuler), et d'un point de vue maintenance/évolutivité vous vous y retrouverez à la première modification du programme.

N'oubliez pas que vous pouvez écrire des vues : rien ne vous empêche de créer une vue v_table2 qui expose les noms correspondant aux PK correspondant à votre table actuelle.
Je vous invite à consulter l'unique billet sur mon blog (cf mon profil à gauche) pour voir comment procéder.
=> Sauf que vu que vous avez la main sur le code, vous vous contenterez de faire une vue pour les lectures, vous enregistrerez directement dans les tables au bon format

Bonsoir,

Merci bien pour ces explications.

Je ne pense néanmoins pas suivre l'ensemble des recommandations, du fait de la matérialité : en lisant votre blog, et les commentaires suivant votre billet, je remarque que ce facteur est décisif dans le choix de la structure de la BDD.
Pour reprendre l'exemple de ma table de classification des dépenses sur trois niveaux, j'en suis à 136 entrées en reprenant le modèle INSEE, et cela en rajoutant systématiquement une entrée (Niveau1, Niveau1, Niveau1) pour chaque premier niveau unique, et de même pour chaque second niveau unique dans ces niveaux 1 (Niveau1, Niveau2, Niveau2). Je doute qu'un utilisateur, quand bien même il souhaiterait suivre de manière extrêmement détaillée ses dépenses, puisse dépasser les 500 entrées... J'envisage même plutôt que la grande partie des utilisateurs se contente d'un ou deux niveaux, et ai prévu une option en ce sens.
Cette approche me semble bien plus "lisible" que d'éclater la classification sur plusieurs tables, dans le cadre d'une évolution future et après n'avoir pas plongé le nez dans le code pendant une longue période. Probablement une impression de néophyte !

Je vais, par contre, créer une clé primaire numérique pour chaque entrée, en lieu et place de ma clé composite, afin de la stocker dans la table de suivi des flux : cette dernière pourrait devenir volumineuse avec une utilisation dans le temps, et le gain à ce niveau me semble donc non négligeable au regard du travail supplémentaire d'écriture des requêtes de lecture et algorithmes d'insertion/correction.
Je vais faire de même pour l'ensemble de mes tables servant à alimenter cette table de suivi, même celles n'ayant pas de clé composite.

[edit : je "travaille" à ce projet en dilettante parfait, en dehors de mon activité professionnelle, et n'envisage donc pas pour l'instant d'y consacrer des journées entières ! ]

[Waldar]

En tout cas, ce qui est sûr, c'est qu'Oracle gère un ROWID pour chaque ligne de chaque table, et c'est effectivement la réelle clé primaire "technique", et la PK telle que définie par les attributs "primary key" n'est techniquement qu'une clé alternative, au même titre que les autres contraintes d'unicité.

Le ROWID est le lien entre les données et leur stockage physique. C'est un bête pointeur. Ca n'a rien à voir avec une clef primaire puisqu'il n'est pas du tout constant (faites un alter table move, tous les rowids seront modifiés).
Si c'est une pseudo-colonne c'est justement car ça n'a rien à voir avec la modélisation, c'est le choix d'implémentation technologique retenu par Oracle DB.
Comme il se trouve que c'est la méthode la plus rapide pour aller lire quelque chose, effectivement les index référencent ce rowid.

Ensuite, dans le cas de la plupart des SGBD (SQL Server par exemple) les données vont être stockées dans l'ordre de la clé primaire explicitement déclarée comme telle.

Non, c'est le comportement par défaut de SQL-Server quand vous avez une clef primaire portée par l'index clustered.
Sur une table sans index clustered vous avez un rowid comme à la concurrence.
Et le comportement "classique" des SGBDR ce sont les tables HEAP où rien n'est trié, les données arrivent et sont enregistrées sans surcoût de tri.

[Paprick]

Bonsoir,

Alors plusieurs choses :
- Faire confiance au script généré par un outil est une erreur en soit (tout comme cliquer sur "enregistrer une macro" dans Excel et espérer avoir un code propre)
- L'outil, et on le voit ici, fait des "choix" et des "interprétations" qui produisent un résultat qui peut s'avérer faux
- Le boulot du DBA, ou à défaut de l'analyse programmeur, c'est justement de pondre un script mieux foutu que celui de l'outil

Je peux comprendre que le DBA aura à cœur d'optimiser certains aspects très proches du système pour optimiser certains accès ou mise à jour de la BD.
Néanmoins, affirmer que "le script généré par un outil est une erreur en soit" ou est "mal foutu", c'est avoir fort peu de considération pour l'outil en question...
Et pour tenter d'afficher aussi peu de considération, encore faudrait-il d'abord bien le connaître, et surtout maîtriser tous les aspects d'une modélisation conceptuelle pour en faire bon usage.

Il n'y a rien, dans les exemples que vous avez pris (je mettrais juste de côté le fait d'accepter, dans un schéma relationnel, des tables sans clé primaire... j'avoue que je n'y vois aucun intérêt), qui ne puisse être modélisé conceptuellement par un bon outil qui sera ensuite capable de générer le bon schéma relationnel correspondant parfaitement au MCD, sans que l'outil ait à faire des "choix" ou des "interprétations", et encore moins produire un résultat faux (dans la mesure, bien sûr, où le MCD est juste) : ces choix sont faits par le concepteur qui pourra les exprimer sans ambiguïté dans son MCD avant génération du MLD correspondant : l'outil produira alors un résultat qui ne sera faux que si le modèle est mauvais.

Quand Escartefigue donne son exemple d'association du type [E1]---0,n---(Asso)---0,n---[E2], je ne peux qu'aller dans son sens : tout concepteur de modèles E/A sait que cela se traduit au niveau MLD par une table d'association dont la clé primaire est composée des clé étrangères issues des classes d'entités associées. Ce n'est pas un choix ou une interprétation discutable : c'est la traduction précise et "non négociable" du MCD en MLD. Si l'on souhaite obtenir autre chose au niveau MLD, et bien on modélise autrement (par exemple en décomposant l'association, ce qui laisse alors de larges possibilités en terme de choix d'identifiant, composé ou non, avec identification relative ou pas, ...).

En résumé, un MCD "bien foutu" permettra à un bon outil de modélisation de générer un script tout aussi "bien foutu" .

[escartefigue]

Cet élément de réponse m'avait échappé :

Dans le cas d'une table associative, dénuée de propriété, la clé primaire est tout simplement "inutile" : on aura bien une contrainte unique si on veut éviter les doublons (et seulement si on veut les éviter !) mais jamais besoin d'identifier une ligne en particulier autrement qu'en interrogeant les clés étrangères qui la compose.

"Seulement si on veut éviter les doublons" c'est un non sens !
Dans une table associative, c'est obligatoire : le couple de FK d'une association binaire (le triolet de FK pour une ternaire) doit être unique.
Et non seulement unique, mais aussi "not null". Et comme il s'agit d'une clef irréductible on est bien en présence d'une PK.

si la table associative référence 20 tables, ça va toujours être plus simple de faire update where id = 123 que update where a_id = 1 and b_id = 2 ... sans oublier la taille de l'index monstrueux qui en dédoulerait.

Là ça devient grotesque ! 20 tables dans une table associative, rien que ça
J'attends avec impatience les règles de gestion qui ont conduit au MCD et au MLD correspondant à cette situation...
Et quand bien même, si un grand nombre de tables il y a, l'index correspondant existera en plus de l'index redondant mono colonne.

[SQLpro]

...
20 tables dans une table associative, rien que ça
J'attends avec impatience les règles de gestion qui ont conduit au MCD et au MLD correspondant à cette situation...
Et quand bien même, si un grand nombre de tables il y a, l'index correspondant existera en plus de l'index redondant mono colonne.

ha oui, pas mal !!!!! j'avais pas pensé qu'on pouvait faire aussi gore !!!!!!

De toutes façons cela ne passera à mon avis sur aucun SGBDR digne de ce nom.
Par exemple sur Microsoft SQL Server la limite de colonne dans la clé primaire est de 16 et le nombre d'octets de 900 ce qui est déjà délirant !
Pour MySQmerde c'est encore plus restreint : 236 octest (UTF8)....

A +

[StringBuilder]

Bon, vous êtes partis dans des délires de profs entre eux, la discussion devient difficile.

Juste un point tout de même, puisqu'on parle ici de SQLite :
https://www.sqlitetutorial.net/sqlite-primary-key/

Il est stipulé :

SQLite primary key and rowid table
When you create a table without specifying the WITHOUT ROWID option, SQLite adds an implicit column called rowid that stores 64-bit signed integer. The rowid column is a key that uniquely identifies the rows in the table. Tables that have rowid columns are called rowid tables.
If a table has the primary key that consists of one column, and that column is defined as INTEGER then this primary key column becomes an alias for the rowid column.
Notice that if you assign another integer type such as BIGINT and UNSIGNED INT to the primary key column, this column will not be an alias for the rowid column.
Because the rowid table organizes its data as a B-tree, querying and sorting data of a rowid table are very fast. It is faster than using a primary key which is not an alias of the rowid.

Another important note is that if you declare a column with the INTEGER type and PRIMARY KEY DESC clause, this column will not become an alias for the rowid column:

CREATE TABLE table(
pk INTEGER PRIMARY KEY DESC,
...
);

Cela veut donc dire quoi ?
Que non, tous les SGBD ne font pas par défaut des tables HEAP : SQLite organise les données selont le rowid.
Tout comme SQL Server organise par défaut en cluster l'index de la clé primaire.

Cela veut dire aussi que SQLite ne fait rien d'autre que ce que je propose de faire "proprement", plutôt que de laisser au SGBD le loisir de modifier lui-même la modèle des données : remplacer les clé primaires composites par une clé primaire mono-colonne et numérique
En effet, on aura beau créer une clé primaire composée, elle sera de toute façon reléguée par SQLite au rang de clé alternative, la clé primaire physique étant au final rowid qui aura été ajoutée, que vous le vouliez ou non.

Après, faites vous plaisir avec ce que dit de faire MERISE et les scripts générés par vos outils, il n'en reste pas moins que le logiciel ne fonctionne pas comme ça, un point c'est tout.

Generix a été audité dans la fin des années 90 et était parfaitement conforme à MERISE (même si j'ai de gros doutes, c'est l'éditeur qui s'en vantait à l'époque)
Ca n'empêche qu'il se trimbale des tables (EVS par exemple) avec des clés primaires composées de (de mémoire) :
CODSOC NUMBER(38, 0), ACHVTE VARCHAR2(1), TYPEVE VARCHAR2(3), NUMEVE NUMBER(16,0), NUMPOS NUMBER(3, 0), NUMLIG NUMBER(3, 0), NUM??? NUMBER(3, 0)
C'est parfaitement valide d'un point de vue purement MERISE, oui, j'ai appris à faire comme à cette même époque.

Le gros avantage vous dirai-je c'est que quand je veux chercher les numéros de lot des produits de ma commande de vente 1500 dans la société 5 je peux faire :

Code :

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

select * from evs where codsoc = 5 and achvte = 'V' and typeve = 'CDV' and numeve = 1500;

Et ça évite de passer par les postes et les lignes de la commande.
Très intéressant à l'époque des 386 quand on devait gérer des millions de lignes avec seulement quelques Mo de mémoire vive en effet, et que la moindre jointure foutait à genoux le plus performant des serveurs !

Si vous trouvez ça digne d'une modélisation correcte, tant mieux, moi pas. On se retrouve avec des requêtes indigestes, des tables obèses avant d'avoir eu le temps d'ajouter la moindre colonne fonctionnelle, des index lourds, et des erreurs de programmation en pagaille : y'a toujours un con qui va dire "ouais, on est en mono-société on s'emmerde pas à joindre CODSOC, pis TYPEVE=CDV c'est forcément ACHVTE=V, je le met pas non plus et vogue la galère le jour où on ajoute une entité au groupe, ou qu'on décide de mettre en place un nouveau flux reprenant un trigramme de type événement existant.

Alors dans une table purement associative dans le sens du cours MERISE, oui vous avez parfaitement raison, la clé primaire peut être composée uniquement des clés étrangères... et encore, rien ne justifie de se dispenser volontairement d'une PK mono-colonne.
Mais quand cette table "associative" devient par la suite une table de détail (apparition de doublons), ou elle-même parente d'une table de détail (sa clé primaire référencée comme clé étrangère), vous avez l'air malin avec votre clé composite.

On est pas en train de faire un exercice MERISE, on est en train de parler d'un programme, qui va potentiellement évoluer dans le temps. C'est juste idiot de se fermer des portes, pour le plaisir de faire comme le prof a dit.

[escartefigue]

Generix a été audité dans la fin des années 90 et était parfaitement conforme à MERISE (même si j'ai de gros doutes, c'est l'éditeur qui s'en vantait à l'époque)
Ca n'empêche qu'il se trimbale des tables (EVS par exemple) avec des clés primaires composées de (de mémoire) :
CODSOC NUMBER(38, 0), ACHVTE VARCHAR2(1), TYPEVE VARCHAR2(3), NUMEVE NUMBER(16,0), NUMPOS NUMBER(3, 0), NUMLIG NUMBER(3, 0), NUM??? NUMBER(3, 0)
C'est parfaitement valide d'un point de vue purement MERISE, oui, j'ai appris à faire comme à cette même époque.

Non : ce n'est pas conforme à merise, pour avoir autant de colonnes participant à la PK, il faudrait une association à 7 ou 8 pattes, ce qui n'arrive jamais dans un MCD ! Donc celui qui a modélisé cette bouse à fait n'importe quoi et ne connaissait pas Merise.
Et choisir du varchar dans une PK est dangereux, quand en plus il s'agit de varchar(1) ou (2) plus encombrant que du fixe c'est complètement contre-productif.

On se retrouve avec des requêtes indigestes, des tables obèses

Les tables obèses sont sans aucun rapport avec l'utilisation d'une PK naturelle formée des FK ou d'une PK artificielle, redondante et mono colonne
Les tables obèses sont la conséquence du non respect des formes normales. C'est un tout autre débat.

Mais quand cette table "associative" devient par la suite une table de détail (apparition de doublons), ou elle-même parente d'une table de détail (sa clé primaire référencée comme clé étrangère), vous avez l'air malin avec votre clé composite.

Sauf que ceci ne peut pas se produire, la table associative n'a pas d'identifiant propre, elle hérite des identifiants d'autres tables (ou plus précisément des identifiants des types d'entité du MCD, mais je l'ai déja expliqué à maintes reprise en amont, visiblement en vain)
Et par conséquent elle ne peut pas propager ses identifiants dans d'autres tables, c'est le contraire qui se produit.



Bref critiquer la méthode sans même en comprendre les bases est une démarche bien curieuse...

[vanagreg]

Alors Générix conforme à quoi que ce soit ça m'étonnerait D'autant plus qu'ils ont plein de colonnes redondantes dans leurs tables. Par exemple, pourquoi répéter TYPEVE dans la table EVS alors que cette colonne est déjà dans EVE?
Et le fait que leur modèle de données contient zéro clés étrangères ils s'en vantaient aussi?
Pour leur table EVE, il suffisait simplement de faire une PK eve_id, mais bon, c'était beaucoup trop simple !

[StringBuilder]

Sauf que ceci ne peut pas se produire, la table associative n'a pas d'identifiant propre, elle hérite des identifiants d'autres tables (ou plus précisément des identifiants des types d'entité du MCD, mais je l'ai déja expliqué à maintes reprise en amont, visiblement en vain)
Et par conséquent elle ne peut pas propager ses identifiants dans d'autres tables, c'est le contraire qui se produit.

Justement, si.

Dans un TD de fac, non, tu as raison, ça n'existe pas.
Dans la vraie vie, si, malheureusement, ça se produit "tout le temps".

Et je dirais qu'avec l'avènement de la gestion de projet AGILE ça arrive de plus en plus.
Pourquoi ?

Parce que dans la vraie vie, un programme n'est pas conçu "une bonne fois pour toutes" an l'an de grâce 1, puis reste inchangé pendant des millénaires.
Parce que quand le programme est conçu la première fois, les besoins et les contraintes font qu'on prend des décisions sans imaginer les évolutions à venir.

Un exemple simple :
Soit une entreprise qui vent des produits à ses clients.
Suite à un échange commercial, on s'entend avec le client sur un assortiment de produits.
Il ne s'agit de pas d'un contrat, pas de négociation de tarifs, juste que le client souhaite commander parmi cette liste de produits, et pas les autres.

On va donc naturellement avoir deux entités "client" et "produit", avec une relation "assortiment" qui va donner lieu à une table associative.

On y va gaiement, c'est tip top, quand un client souhaite consulter le catalogue produit, il ne voit que les produits de son assortiment, c'est magique.

Maintenant, après quelques années, notre entreprise évolue, ou alors l'éditeur trouve une autre entreprise avec un besoin similaire. On va se contenter de faire évoluer le produit.

Ok, finalement, cet assortiment fait suite à une négociation, et ou souhaite ajouter des attributs : date et quantité engagement. On va aussi ajouter une référence personnalisée car le client connaît nos produits sous un autre nom.
Allez, zou, c'est pas top, mais bon, la table est comme ça, on sait pas trop comment changer la clé primaire sans péter toute l'application, on rajoute les attributs dans la table associative.

Et puis après quelques années, on se dit que merde, quand le client sort un produit de son assortiment, on n'en a plus la trace. Et quand il le remet, on ne sait pas s'il y était déjà avant, pas pratique.
Alors on ajoute des dates d'application... et ça devient la merde, car il faut ajouter la date de début d'assortiment à la clé du coup... ça y est, les fameux doublons apparaissent, la clé ne fait plus référence qu'à des clés étrangères. C'est le boxon.
Alors on fait machine arrière. On crée une table de détail, où on va pouvoir avoir une ligne par période d'application... Et merde... cette fois c'est notre table de détail qui référencie une clé étrangère composite... la loose.

Qu'une application passe par un ORM ou des requêtes SQL hardcodées à la main, c'est toujours ultra délicat de remettre en cause à posteriori la structure de base des tables, à savoir les clés primaires et clés étrangères. C'est comme ça que naissent les modèles de données foireux, du genre où y'a pas de clés étrangères : c'est trop la merde à faire évoluer, alors on les a dégagées.

Oui, MERISE est parfait pour concevoir la structure générale de la base, mais oui aussi, je reste en croisade contre les clés primaires composites : j'ai trop de fois été confronté à des merdes sans nom car le modèle évoluait et qu'on (pas que moi, l'éditeur, le client, les collègues, etc.) savait plus à quel moment tout foutre à la benne et tout recommencer, faute de pouvoir faire évoluer.

En revanche, une PK mono-colonne numérique par table systématiquement, ça résout tous ces problèmes avant qu'ils ne se posent, ça coute pour ainsi dire rien (ôh my god, j'ai perdu 4 octets sur chaque ligne de ma table de 2 millions de lignes... mazette, 8 Mo de perdus... sur 4 Go !)

Mettre en place cette pratique permet aussi d'imposer l'abandon des clés varchar ou numeric de merde, porteuses d'information.

[escartefigue]

Dans un TD de fac, non, tu as raison, ça n'existe pas.
Dans la vraie vie, si, malheureusement, ça se produit "tout le temps".

Et je dirais qu'avec l'avènement de la gestion de projet AGILE ça arrive de plus en plus.

AGILE est une méthode de conduite de projet, pas une méthode de modélisation des bases de données, aucun rapport avec le sujet, l'argumentaire commence très mal...

Parce que dans la vraie vie, un programme n'est pas conçu "une bonne fois pour toutes" an l'an de grâce 1, puis reste inchangé pendant des millénaires.
Parce que quand le programme est conçu la première fois, les besoins et les contraintes font qu'on prend des décisions sans imaginer les évolutions à venir.

Les programmes concernent les traitements, toujours aucun rapport avec la modélisation des bases de données, décidément, c'est mal parti

Un exemple simple :
Soit une entreprise qui vent des produits à ses clients.
Suite à un échange commercial, on s'entend avec le client sur un assortiment de produits.
Il ne s'agit de pas d'un contrat, pas de négociation de tarifs, juste que le client souhaite commander parmi cette liste de produits, et pas les autres.

On va donc naturellement avoir deux entités "client" et "produit", avec une relation "assortiment" qui va donner lieu à une table associative.

Une preuve de plus s'il en fallait, que la modélisation n'est pas votre spécialité, une relation ou association "assortiment" est plus que douteuse, merci de préciser les règles de gestion qui conduisent à ce raccourci.
Le client n'est la plupart du temps, pour ne pas dire toujours par prudence, en relation avec un produit qu'au travers d'une commande. Et comme la commande est le plus souvent multi-produit, le trajet n'est pas aussi direct que ça, loin s'en faut.
On a donc ceci :
[CLIENT] 1,n --- passer --- 1,1 [COMMANDE] 1,n --- contenir --- ,1(R) LIGNE_COMMANDE 1,1 --- concerner --- 0,n PRODUIT
On est très loin de votre raccourci hasardeux



La suite étant du même tonneau, je ne perds pas plus de temps à argumenter.

[StringBuilder]

AGILE est une méthode de conduite de projet, pas une méthode de modélisation des bases de données, aucun rapport avec le sujet

Ah bon ?

AGILE délimite (et alloti) le périmètre du projet, et par conséquence l'ensemble de l'analyse, à commencer par MERISE.

Si le lot 1 concerne la partie client et produit, à aucun moment on ne va analyser la partie fournisseur et amortissement comptable.
C'est d'autant plus vrai sur les évolutions (menée en mode AGILE ou non) qui se font sur la durée, après plusieurs années d'utilisation du produit.

Une fois de plus, un produit vit, et en aucun cas l'analyste qui effectue la conception du modèle de données ne va s'attaquer à des pans hors cahier des charges !

Les programmes concernent les traitements, toujours aucun rapport avec la modélisation des bases de données, décidément, c'est mal parti

Le programme est la finalité de l'analyse.
La conception de la base de données qu'une étape parmi la conception globale du logiciel ou du SI.
Y'a qu'en cours à la FAC qu'on modélise des bases de données pour le plaisir, sans prendre en compte les outils qui vont s'en servir.
Si le but du produit est de proposer des catalogues de produits, sans gestion de prise en commande, vous n'allez mettre en place qu'un assortiment de produits, pas une gestion de prise de commande !

Une preuve de plus s'il en fallait, que la modélisation n'est pas votre spécialité, une relation ou association "assortiment" est plus que douteuse, merci de préciser les règles de gestion qui conduisent à ce raccourci.
Le client n'est la plupart du temps, pour ne pas dire toujours par prudence, en relation avec un produit qu'au travers d'une commande. Et comme la commande est le plus souvent multi-produit, le trajet n'est pas aussi direct que ça, loin s'en faut.
On a donc ceci :
[CLIENT] 1,n --- passer --- 1,1 [COMMANDE] 1,n --- contenir --- ,1(R) LIGNE_COMMANDE 1,1 --- concerner --- 0,n PRODUIT

Ah ouais, on part de très très loin en effet.

Alors je suis au marketing, je souhaite pouvoir présenter un espace vitrine a mes clients où je ne leur parle que des produits qui les intéressent, toi tu vas me vendre un site de prise de commande ?

Si j'ai besoin d'avoir simplement une liste d'associations client-produit sans rien de plus, je ne vais pas écrire une gestion commerciale hein !

C'est vrai que si tu écris un outils pour gérer une liste de courses, tu vas modéliser les rayons du magasin, son dépôt et pourquoi pas son réseau d'approvisionnement... "C'est mieux que de faire une table où j'attribue une liste de produit à chaque utilisateur". C'est tout à fait logique, où avais-je la tête !

D'ailleurs, tu as oublié de proposer cette solution à l'auteur du topic, puisque visiblement il veut suivre des achats de produits dans un magasin... mais oui mon con, franchement, pourquoi on n'a pas commencé par là ! Autant puis proposer d'écrire une compta ! Il pourra même calculer l'amortissement de ses pomme de terre entre deux purées !

[Paprick]

Bonsoir,

Le programme est la finalité de l'analyse.
La conception de la base de données qu'une étape parmi la conception globale du logiciel ou du SI.
Y'a qu'en cours à la FAC qu'on modélise des bases de données pour le plaisir, sans prendre en compte les outils qui vont s'en servir.
Si le but du produit est de proposer des catalogues de produits, sans gestion de prise en commande, vous n'allez mettre en place qu'un assortiment de produits, pas une gestion de prise de commande !

J'ai lu vos échanges bien sagement et j'ai même pensé à un moment que vous plaisantiez quant à vos propos sur les profs et la fac... visiblement non, vous avez l'air sérieux (en plus d'être limite insultant).

Alors oui, je plaide coupable : je suis un prof de fac qui modélise des bases de données, ce qui visiblement fait de moi un handicapé de la "vraie vie", et me vaut votre mépris.
(Notons cependant que, outre les 20 ans de ma jeunesse à développer des projets industriels, je continue à suivre au quotidien les entreprises qui développent des "vraies" applications... mais bon...).

Vous dites que le logiciel est la finalité de l'analyse... pourquoi pas, mais en tout cas, ça n'empêche pas de faire une analyse cohérente des données composant le système d'information.
Et, pour vous, c'est quoi un système d'information ? ... Décomposons les mots et prenons notre petit Larousse : on peut résumer la chose en disant que c'est l'ensemble des informations qui concourent au bon fonctionnement du domaine d'étude. Et ces informations sont les fondations du SI, quelle que soit l'application qu'en font les logiciels. Le dictionnaire de données contient donc toutes les informations primaires (on exclut dans un premier temps tout ce qui est calculable). Le logiciel, lui, est là pour manipuler les informations du SI, pas pour en inventer !
Et si l'on recense correctement TOUTES les informations, les logiciels n'auront aucun mal à les mettre en musique.
Ensuite, sur la base de ce dictionnaire, la modélisation conceptuelle peut (doit) commencer.

Et tout votre bla-bla sur les clés mono ou multi-colonnes n'est qu'une histoire de modélisation : les schémas entité-association permettent toutes les modélisations, j'ai bien TOUTES : avec uniquement des clés mono-colonne si vous le souhaitez, avec des identifiants relatifs, des CIF, des clés composés de clés étrangères, ... TOUT est entre les mains du concepteur.
Mais une fois que le concept est posé, le MLD (et donc la structure du schéma relationnel) sera forcément le reflet du MCD.

Alors, après, que vous fassiez de l'AGILE ou pas, cela ne change rien au fait que le MCD, à travers toutes ses éventuelles évolutions, reste la base du SI.

Et prétendre que le modèle de données dépend des outils qui vont s'en servir, est une grave erreur : les données sont définies par le SI, pas par les outils qui manipuleront ces données !

Ensuite, vous semblez avoir bien peu de considération pour les outils de modélisation qui génèrent automatiquement les schémas relationnels... et pourtant !
Pour ne parler que de l'outil que je connais parfaitement (et il y en a d'autres), Looping fait aujourd'hui l'objet de plus de 30 000 utilisations pas mois, et pas uniquement dans les Facs : je n'ai à ce jour reçu aucune plainte sur sa capacité à modéliser tout type de SI et à générer les schémas relationnels correspondants !

Pour finir, vous pouvez penser ce que vous voulez de la FAC et de ses profs... Mais bon, à défaut de respect, un peu de courtoisie serait la bienvenue.

[escartefigue]

Ah bon ?

AGILE délimite (et alloti) le périmètre du projet, et par conséquence l'ensemble de l'analyse, à commencer par MERISE.

Si le lot 1 concerne la partie client et produit, à aucun moment on ne va analyser la partie fournisseur et amortissement comptable.
C'est d'autant plus vrai sur les évolutions (menée en mode AGILE ou non) qui se font sur la durée, après plusieurs années d'utilisation du produit

Le périmètre d'un projet est une chose, la méthode de modélisation une autre
Vous mélangez décidément tout : traitements et données, méthode de conduite de projet et méthode de modélisation
Je ne sais pas ce qui l'emporte entre la mauvaise foi, la confusion et l'incompétence, mais c'est sidérant

[StringBuilder]

@Patrick

Si vous vous sentez insulté, j'en suis désolé. Relisez donc ce que vous avez vous-même écrit à mon sujet, et voyez si j'ai pu me sentir moi-même insulté.

Ensuite, vous parlez de vos 20 ans d'expérience avant de devenir prof, puis de vos interventions régulières en entreprise en parallèle.
=> Osez me dire que vous n'avez jamais, durant votre carrière, été obligé de changer de fusil d'épaule face à une modélisation qui était "parfaite" à un instant T, puis s'est avérée bancale après quelques années d'utilisation, notamment à cause du changement de périmètre de l'application : nouvelles données, nouvelles règles, etc. qui remettent en question l'analyse de départ. Osez me dire que dans ce cas, si vous avez dit "oh ben on va tout bien remodéliser dans PowerAMC, générer un bo script SQL avec, et foutre à la poubelle la base et l'application actuelle pour utiliser la nouvelle base de données toute belle" alors votre client, patron ou je ne sais qui a répondu "oh mais oui biensur, on va tout péter, se lancer dans un projet de migration pharaonique pour couper cette entité en deux".

@Escartefigue

Tu parles de mauvaise fois, mais jusqu'à présent c'est toi qui en fait le plus preuve. Tes propos sont parfaitement insultant, tu remets en systématiquement en question mes compétences et mon expérience, sans jamais apporter de réponse à des cas concrets que je te soumet, sans jamais remettre en question ta vision très réductrice du sujet.

Alors si vous le permettez, soumettez-moi un exemple de votre cru, un beau TD que vous soumettez à vos élèves, qui donne lieu, dans votre correction biblique à une table associative.
Je m'efforcerai en retour de jouer le rôle du client chiant (vous savez, le gars qui change d'avis, dont le métier évolue, tout ça, le truc qui n'existe pas dans les TD) et vous me direz comment, sans remettre en question votre modèle vous aller implémenter ses nouveaux besoins.

Parce que franchement, me sortir une gestion de commandes pour parler d'un assortiment client, niveau mauvaise fois, on est allé bien plus loin que je n'aurais imaginé.

[StringBuilder]

Vous dites que le logiciel est la finalité de l'analyse... pourquoi pas, mais en tout cas, ça n'empêche pas de faire une analyse cohérente des données composant le système d'information.

Bon, c'est un bon début, on est 100% en phase jusque là.

Et, pour vous, c'est quoi un système d'information ? ... Décomposons les mots et prenons notre petit Larousse : on peut résumer la chose en disant que c'est l'ensemble des informations qui concourent au bon fonctionnement du domaine d'étude. Et ces informations sont les fondations du SI, quelle que soit l'application qu'en font les logiciels. Le dictionnaire de données contient donc toutes les informations primaires (on exclut dans un premier temps tout ce qui est calculable). Le logiciel, lui, est là pour manipuler les informations du SI, pas pour en inventer !
Et si l'on recense correctement TOUTES les informations, les logiciels n'auront aucun mal à les mettre en musique.
Ensuite, sur la base de ce dictionnaire, la modélisation conceptuelle peut (doit) commencer.

Ok, je commence à être amoureux, continuons...

Et tout votre bla-bla sur les clés mono ou multi-colonnes n'est qu'une histoire de modélisation : les schémas entité-association permettent toutes les modélisations, j'ai bien TOUTES : avec uniquement des clés mono-colonne si vous le souhaitez, avec des identifiants relatifs, des CIF, des clés composés de clés étrangères, ... TOUT est entre les mains du concepteur.
Mais une fois que le concept est posé, le MLD (et donc la structure du schéma relationnel) sera forcément le reflet du MCD.

Bon, alors enfin quelqu'un qui admet qu'avoir une clé primaire mono-colonne et une clé alternative constituée des clés étrangères, même pour une table identifié comme associative au moment de l'analyse initiale n'est pas une erreur abominable de conception.
Merci beaucoup pour cette confirmation, j'ai vraiment cru à un moment que j'avais tout oublié de MERISE (moi ça vais 20 ans que j'ai fini les cours, donc c'est loin).
Que ce ne soit pas la modélisation "idéale", je veux bien l'entendre, et je suis même d'accord avec ça, mais moi je parle du monde réel, de l'entreprise, pas de la fac. Et dans le monde réel, il n'y a pas de solution idéale, car pour être idéal il faudrait qu'elle s'adapte spontanément aux évolutions des besoins, ce qui à ma connaissance n'existe pas. En revanche, on peut s'en approcher, notamment en faisant attention à ne pas se fermer de portes.

Alors, après, que vous fassiez de l'AGILE ou pas, cela ne change rien au fait que le MCD, à travers toutes ses éventuelles évolutions, reste la base du SI.

On est bien d'accord.
Avec tout de même un bémol à partir de maintenant, on va commencer à avoir des avis divergeants :
AGILE ou pas (après tout, une application qui évolue tous les 5 ans, on ne peut pas vraiment parler de mode AGILE, même si au final cela revient au même, c'est juste le cycle qui est plus long), la définition du dictionnaire des données et le périmètre du SI est cadré en fonction du périmètre sur lequel porte l'analyse.

Pour être plus précis, si vous travaillez pour le Père Noël et que dans vos ateliers vous avez :
- Un pôle Marketing qui gère les promotions de Noël dans les magasins
- Un pôle Relation client qui dépouille les listes de cadeaux demandés par les enfants, corrélées aux listes de bêtises ou bonnes actions qu'ils ont fait durant l'année
- Un pôle Achat qui s'occupe d'acheter les pièces détachées des jouets
- Un pôle Fabrication qui s'occupe d'assembler les jouets
- Un pôle Emballage et expédition qui s'occupe de la distribution des jouets

Lorsque le vieux monsieur va décider de s'informatiser, il va pas vouloir tout faire d'un coup : il n'a pas le budget, pas le temps, les interlocuteurs des différents services ne sont pas disponibles etc.
Donc si le besoin formulé par le client ne concerne que la partie dépouillage des listes de cadeaux des enfants du pôle relationnel, vous n'allez pas avoir en votre possession les données relatives au bêtises, que vous devrez pourtant mettre en corrélation plus tard avec les listes de souhaits, pas plus que la partie achat ou fabrication, et encore moins la livraison !

Pourtant, dans 6 mois, quand vous allez livrer cette partie du SI, de nouveaux ateliers vont démarrer pour intégrer de nouveaux éléments, faire évoluer les premiers qui s'avèrent avoir été parfois mal exprimés, mal compris, ou simplement modifiés depuis la demande de départ.
Votre analyse va donc reprendre de manière itérative, pour ajouter et modifier des éléments sur une analyse pré-existante, que vous ne pourrez pas remettre en question, au risque de présenter un devis au Père Noël qui lui fasse faire faillite !

Il y a donc bien une corrélation forte entre :
- Ce que dois faire l'application, les données qu'elle traite, et son modèle de données
- La méthodologie qui est responsable du découpage en sous-parties du projet : l'analyse est fait de façon itérative, pas d'emblée de manière exhaustive, puisque cette exhaustivité n'existe au mieux qu'à un instant T. Une simple évolution de la législation peut remettre en cause un pan entier de la conception. Moi perso je sais pas ce que le Sénat va nous pondre le mois prochain.

Ensuite, vous semblez avoir bien peu de considération pour les outils de modélisation qui génèrent automatiquement les schémas relationnels... et pourtant !
Pour ne parler que de l'outil que je connais parfaitement (et il y en a d'autres), Looping fait aujourd'hui l'objet de plus de 30 000 utilisations pas mois, et pas uniquement dans les Facs : je n'ai à ce jour reçu aucune plainte sur sa capacité à modéliser tout type de SI et à générer les schémas relationnels correspondants !

J'ai un avis neutre sur le sujet : les programmes sur lesquels je travaille disposent d'un modèle des données déjà établi, et les évolutions que j'y apporte se résument généralement à quelques colonnes dans des tables existantes, quelques nouvelles tables, quelques traitements, mais rarement un modèle justifiant de passer par un MCD.
Ces schémas ne font donc pas partie des livrables demandés par mes clients, et par conséquent la modélisation se cantonne généralement à l'expression du dictionnaire des données, des règles régissant ces données, puis une réalisation directe. Si vous suivez bien votre cours, vous ne pourrez pas me contredire en disant que le MCD découle automatiquement du dictionnaire des données et des règles sur ces données.
Il faut dire en plus que généralement les clients en face n'ont pas les connaissances nécessaires pour relire un MCD. Déjà "un et un seul" c'est compliqué à faire comprendre parfois... alors je ne vous parle pas de "contraintes d'intégrité fonctionnelles" ou de "cardinalités".

En revanche, un outil, quel qu'il soit, reste un outil.
Si on l'utilise mal, il va produire de la *****. Par conséquent, ce n'est pas parce que j'ai un joli MCD qui a donné lieu à un joli MLD dans l'outil qu'au final j'aurai un DDL parfait : si le MCD est bancal, me DDL généré le sera aussi, mais surtout, comment évoqué la première fois qu'on en a parlé, l'outil peut prendre des décisions lors de la génération du DDL qui ne sont pas des plus adaptées.
Il y a par exemple un certain nombre de règles dans un MCD, qui vont donner lieu à du code (triggers par exemple) que ces outils ne sauront pas produire, ou pas en respectant les règles de développement de l'entreprise par exemple.

Pour finir, vous pouvez penser ce que vous voulez de la FAC et de ses profs... Mais bon, à défaut de respect, un peu de courtoisie serait la bienvenue.

Je n'ai rien contre les profs, étant fils de profs moi-même je n'ai pas d'animosité contre eux.
En revanche, j'attend de vous que vous reconnaissiez qu'un exercice est un exercice, et que même s'il est basé sur une situation réelle, ne peut en aucun cas être une situation réelle.
Et que bien souvent, ce que vous décrétez comme faux avec un gros point rouge à côté, découle pourtant d'une démarche parfaitement juste à un instant T, mais qui par la suite c'est avérée être remise en question par de nouvelles règles, inexistantes au moment de l'analyse initiale.

Je me souviens clairement d'une pise de bec avec un prof d'analyse justement, car il était incapable d'accepter qu'une règle de son énoncé pouvait, par simple précaution, être partiellement interprétée et remise en cause, donnant lieu à une solution différente de celle de son bouquin.

Je suis désolé, mais quand la règle c'est "mon client ne peut passer qu'une seule commande", je vais reposer la question 1 fois, 2 fois, 3 fois, changer d'interlocuteur, et si j'ai franchement le doute qui reste, je vais prendre la liberté de prévoir l'erreur ou l'évolution
Et comme par enchantement, au moment de la livraison du programme on a droit à "ah mais le client ne peut avoir qu'une seule commande active à un instant T, mais on veut pouvoir retrouver ces anciennes commandes !". Ouf, j'avais prévu le coup.

Pour ce qui est du respect et de la courtoise, c'est tout réciproque.

[Paprick]

Bonjour,

Je ne vais pas reprendre 90% de vos propos qui ne concernent en fait que l'évolution des SI, ou leur automatisation par étapes : bien sûr qu'un modèle, quel qu'il soit, n'est pas gravé dans le marbre, et qu'il est amené à évoluer... qui pourrait prétendre le contraire ? Personne, même pas les profs !
Le script initial de génération du schéma relationnel sert à la création de la structure, les évolutions s'effectuant ensuite en fonction des besoins : et là, ALTER TABLE et autres commandes servent bien évidemment à l'évolution du schéma relationnel.

Revenons par contre sur certaines de vos affirmations :

J'ai un avis neutre sur le sujet : les programmes sur lesquels je travaille disposent d'un modèle des données déjà établi, et les évolutions que j'y apporte se résument généralement à quelques colonnes dans des tables existantes, quelques nouvelles tables, quelques traitements, mais rarement un modèle justifiant de passer par un MCD.
Ces schémas ne font donc pas partie des livrables demandés par mes clients, et par conséquent la modélisation se cantonne généralement à l'expression du dictionnaire des données, des règles régissant ces données, puis une réalisation directe. Si vous suivez bien votre cours, vous ne pourrez pas me contredire en disant que le MCD découle automatiquement du dictionnaire des données et des règles sur ces données.
Il faut dire en plus que généralement les clients en face n'ont pas les connaissances nécessaires pour relire un MCD. Déjà "un et un seul" c'est compliqué à faire comprendre parfois... alors je ne vous parle pas de "contraintes d'intégrité fonctionnelles" ou de "cardinalités".

Vous seriez surpris de voir à quel point un MCD bien réalisé est expressif, même pour le client final : en tout cas, il l'est bien plus qu'un schéma relationnel. Alors vous me direz surement : la structure de la BD, je ne la montre pas à mes clients... Personnellement, je ne le faisais pas non plus... avant que je me rende compte que, bien exposé, il permet des échanges des plus intéressants, y compris avec des non-initiés.

En revanche, un outil, quel qu'il soit, reste un outil.
Si on l'utilise mal, il va produire de la *****. Par conséquent, ce n'est pas parce que j'ai un joli MCD qui a donné lieu à un joli MLD dans l'outil qu'au final j'aurai un DDL parfait : si le MCD est bancal, me DDL généré le sera aussi, mais surtout, comment évoqué la première fois qu'on en a parlé, l'outil peut prendre des décisions lors de la génération du DDL qui ne sont pas des plus adaptées.
Il y a par exemple un certain nombre de règles dans un MCD, qui vont donner lieu à du code (triggers par exemple) que ces outils ne sauront pas produire, ou pas en respectant les règles de développement de l'entreprise par exemple.

N'enfonçons pas des portes ouvertes : il est évident que si le MCD est mauvais, tout ce qui suivra derrière ne vaudra pas plus, quel que soit l'outil !
Par contre, ne négligez pas le pouvoir d'expression d'un MCD, y compris au niveau technique : si un MCD a la vertu de pouvoir présenter de manière relativement simple la structure générale du SI, il est également capable de donner des directives précises quant la génération du DDL : nature des clés, composition des clés alternatives, des index, rajout de contraintes décrites par des triggers à travers des règles associés aux classes d'entités ou aux associations, ... tout cela s'intègre aujourd'hui très bien dans certains outils de modélisation.
Ainsi, on peut associer dans ces modèles des aspects purement conceptuels lisibles par tous, et des aspects techniques qui relèvent plus du DBA.

En revanche, j'attend de vous que vous reconnaissiez qu'un exercice est un exercice, et que même s'il est basé sur une situation réelle, ne peut en aucun cas être une situation réelle.
Et que bien souvent, ce que vous décrétez comme faux avec un gros point rouge à côté, découle pourtant d'une démarche parfaitement juste à un instant T, mais qui par la suite c'est avérée être remise en question par de nouvelles règles, inexistantes au moment de l'analyse initiale.

Dans un souci pédagogique, les exercices que nous donnons à nos étudiants sont tout d'abord faits pour leur permettre d'acquérir la technique de modélisation : pour cela, on s'appuie forcément sur des cas d'écoles.
Quand vous faites un TD en 1h30, il vaut mieux que le compte-rendu d'interview soit clair, et ne prenne pas en compte les évolutions possible du SI dans les 10 ans à venir.

Je me souviens clairement d'une pise de bec avec un prof d'analyse justement, car il était incapable d'accepter qu'une règle de son énoncé pouvait, par simple précaution, être partiellement interprétée et remise en cause, donnant lieu à une solution différente de celle de son bouquin.
Je suis désolé, mais quand la règle c'est "mon client ne peut passer qu'une seule commande", je vais reposer la question 1 fois, 2 fois, 3 fois, changer d'interlocuteur, et si j'ai franchement le doute qui reste, je vais prendre la liberté de prévoir l'erreur ou l'évolution. Et comme par enchantement, au moment de la livraison du programme on a droit à "ah mais le client ne peut avoir qu'une seule commande active à un instant T, mais on veut pouvoir retrouver ces anciennes commandes !". Ouf, j'avais prévu le coup.

Quand on enseigne, il faut savoir faire la part des choses : si vous voulez expliquer, en même temps, toutes les subtilités d'un concept et tous les cas qui y dérogent, vous perdez les étudiants, surtout lorsqu'il est question de modélisation conceptuelle.
Il faut donc leur donner des règles précises, souvent trop précises par rapport à la vraie vie : ensuite, quand s'est installée une certaine maîtrise, je suis le premier à leur expliquer que l'on peut déroger à certaines de ces règles (rubriques calculables, surclés, ...).
Mais, comme je le dis souvent : on déroge en connaissance de cause ! Ce qui permet de se poser les bonnes questions au bon moment...

[StringBuilder]

Dans un souci pédagogique, les exercices que nous donnons à nos étudiants sont tout d'abord faits pour leur permettre d'acquérir la technique de modélisation : pour cela, on s'appuie forcément sur des cas d'écoles.
Quand vous faites un TD en 1h30, il vaut mieux que le compte-rendu d'interview soit clair, et ne prenne pas en compte les évolutions possible du SI dans les 10 ans à venir.


Quand on enseigne, il faut savoir faire la part des choses : si vous voulez expliquer, en même temps, toutes les subtilités d'un concept et tous les cas qui y dérogent, vous perdez les étudiants, surtout lorsqu'il est question de modélisation conceptuelle.
Il faut donc leur donner des règles précises, souvent trop précises par rapport à la vraie vie : ensuite, quand s'est installée une certaine maîtrise, je suis le premier à leur expliquer que l'on peut déroger à certaines de ces règles (rubriques calculables, surclés, ...).
Mais, comme je le dis souvent : on déroge en connaissance de cause ! Ce qui permet de se poser les bonnes questions au bon moment...

Je vous remercie pour votre réponse, j'ai enfin l'impression d'avancer, et pas me retrouver face à une tortue de Scutum hérissée Pilum (pas sûr des pluriels, ça donnerait Scuta et Pila mais c'est bizarre, j'aurais dû faire latin au collège...)


Si je puis me permettre une suggestion très formatrice, c'est justement (et vous le faire peut-être déjà) au cours du cursus, de justement ressortir des TD déjà vu, en apportant des modifications aux règles et en demandant aux étudiants de présenter les avantages et inconvénients de telle ou telle adaptation : avec toujours la question de "faut-il pourrir le modèle des données en conservant sa structure initiale, quitte à introduire de la duplication d'information, des clé étrangères composites à rallonge, ou à l'inverse mettre à la benne une partie de ce qui a été fait, car le travail d'adaptation du SI existant (données existantes comprises) est moins coûteux".
C'est une problématique qui se pose bien plus souvent dans le monde réel (en tout cas, dans le métier qui est le mien) que de partir de la page blanche sur un nouveau SI.

C'est en tout cas fort de mon expérience, que les tables associatives initialement parfaitement classiques, sans attributs et une clé composite je m'en méfie comme la peste.
Du jour au lendemain, elles peuvent devenir subitement porteuses d'informations, parentes d'entités filles, leur clé composite finalement plus unique du tout, etc.
C'est pour cette raison que j'en suis arrivé à la conclusion qu'il était toujours plus sage de prévoir le pire, en créant une clé primaire numérique mono-colonne, et reléguer au rang de clé alternative celle que le MCD avait désigné comme clé primaire : ça ne coûte pour ainsi dire rien au SGBD, c'est même transparent sur un certain nombre (à commencer par SQLite, puisque c'est le SGBD relatif à ce topic, je le rappel), et que ça avait le gros avantage de pouvoir transformer la table associative en table "classique" sans modifier ni le modèle ni les programmes qui l'utilise.

Bref, longue vie au grand philosophe Burt Gummer :