Modèle relationnel MERISE
Résolu/Fermé
danièle21
-
18 janv. 2013 à 17:14
heliconius Messages postés 545 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 - 22 janv. 2013 à 11:36
heliconius Messages postés 545 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 - 22 janv. 2013 à 11:36
A voir également:
- Modèle relationnel MERISE
- Modèle organigramme word - Guide
- Iphone dernier modèle - Guide
- Modèle fiche de pointage excel - Télécharger - Tableur
- Modèle d'accusé de réception mail - Guide
- Modèle sommaire - Guide
5 réponses
heliconius
Messages postés
545
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
23 juin 2023
137
18 janv. 2013 à 17:52
18 janv. 2013 à 17:52
Bonjour,
Il n'y a pas de cardinalité faible, il y a des cardinalités. Elles indiquent le nombre de fois qu'un objet Merise participe à une relation. Les cardinalités se représentent par 0, 1 ou n.
0 : l'objet peut ne pas participer à la relation
1 : l'objet participe une fois à le relation
n : l'objet participe plusieurs fois à la relation
On indique toujours : cardinalité minimale, cardinalité maximale (soit cmin,cmax)
exemple de cardinalité: 0,1 ou 0,n ou 1,1 ou 1,n
exemple concret: client acheter produit (client et produit = objets ; acheter = relation)
[CLIENT]-0,n---(acheter)---0,n-[PRODUIT]
côté [CLIENT] 0,n :
cmin=0 : un client peut ne pas participer à la relation acheter
cmax=n : mais il peut participer à plusieurs achats {c'est mieux :) }
côté [PRODUIT] 0,n :
cmin=0 : un produit peut ne pas être acheté
cmax=n : mais il peut l'être plusieurs fois
Si tu modélises ainsi:
[CLIENT]-0,n---(acheter)---0,n-[PRODUIT]
=> il se peut qu'un client n'ait jamais acheté (donc du gères les clients potentiels)
Si tu modélises ainsi:
[CLIENT]-1,n---(acheter)---0,n-[PRODUIT]
=> pas de client potentiel, donc pour être dans la base, le client doit avoir acheté au minimum une fois
Autre exemple:
[MOBILE]-1,1---(appartenir)---0,n-[PERSONNE]
une personne peut avoir un ou plusieurs numéros de téléphone mobile
Tout numéro de téléphone mobile appartient obligatoirement à une personne et une seule
etc...
J'avais commencé il y a longtemps une petite doc mais elle n'est pas finie mais si tu débutes avec Merise, tu y trouveras peut-être quelques infos et si ça t'intéresse vraiment dis-le moi, je la continuerai éventuellement :)
http://www.fr-webdev.net/merisintro.php
Bon courage. C'est une excellente méthode...
Il n'y a pas de cardinalité faible, il y a des cardinalités. Elles indiquent le nombre de fois qu'un objet Merise participe à une relation. Les cardinalités se représentent par 0, 1 ou n.
0 : l'objet peut ne pas participer à la relation
1 : l'objet participe une fois à le relation
n : l'objet participe plusieurs fois à la relation
On indique toujours : cardinalité minimale, cardinalité maximale (soit cmin,cmax)
exemple de cardinalité: 0,1 ou 0,n ou 1,1 ou 1,n
exemple concret: client acheter produit (client et produit = objets ; acheter = relation)
[CLIENT]-0,n---(acheter)---0,n-[PRODUIT]
côté [CLIENT] 0,n :
cmin=0 : un client peut ne pas participer à la relation acheter
cmax=n : mais il peut participer à plusieurs achats {c'est mieux :) }
côté [PRODUIT] 0,n :
cmin=0 : un produit peut ne pas être acheté
cmax=n : mais il peut l'être plusieurs fois
Si tu modélises ainsi:
[CLIENT]-0,n---(acheter)---0,n-[PRODUIT]
=> il se peut qu'un client n'ait jamais acheté (donc du gères les clients potentiels)
Si tu modélises ainsi:
[CLIENT]-1,n---(acheter)---0,n-[PRODUIT]
=> pas de client potentiel, donc pour être dans la base, le client doit avoir acheté au minimum une fois
Autre exemple:
[MOBILE]-1,1---(appartenir)---0,n-[PERSONNE]
une personne peut avoir un ou plusieurs numéros de téléphone mobile
Tout numéro de téléphone mobile appartient obligatoirement à une personne et une seule
etc...
J'avais commencé il y a longtemps une petite doc mais elle n'est pas finie mais si tu débutes avec Merise, tu y trouveras peut-être quelques infos et si ça t'intéresse vraiment dis-le moi, je la continuerai éventuellement :)
http://www.fr-webdev.net/merisintro.php
Bon courage. C'est une excellente méthode...
un grand merci heliconius. je débute effectivement avec cette méthode.
au moment du passage du modèle conceptuel au relationnel comment traduit tu la cardinalité?comment tu décides quelle table va contenir les champs de l'autre?
merci d'avance.
au moment du passage du modèle conceptuel au relationnel comment traduit tu la cardinalité?comment tu décides quelle table va contenir les champs de l'autre?
merci d'avance.
michel_m
Messages postés
16603
Date d'inscription
lundi 12 septembre 2005
Statut
Contributeur
Dernière intervention
16 décembre 2023
3 303
21 janv. 2013 à 08:49
21 janv. 2013 à 08:49
bonjour,
a lire absolument pour comprendre et utiliser facilement Merise: du S.I. au MPD
http://www.sam-mag.com/P53,53,5,43,,,default.aspx
a lire absolument pour comprendre et utiliser facilement Merise: du S.I. au MPD
http://www.sam-mag.com/P53,53,5,43,,,default.aspx
heliconius
Messages postés
545
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
23 juin 2023
137
21 janv. 2013 à 12:18
21 janv. 2013 à 12:18
D'abord: il n'y a pas de MCD bon ni de MCD faux. Il y a un MCD qui correspond à une gestion. Comme je te le disais dans le précédent post :
[CLIENT]-0,n---(acheter)---0,n-[PRODUIT]
[CLIENT]-1,n---(acheter)---0,n-[PRODUIT]
sont bons tous les deux mais ils correspondent à une gestion différente (gestion des client potentiels ou pas). Dans la relation :
[PERSONNES]----(avoir pour)----[EMAIL]
Les cardinalités représenteront la manière dont il faudra effectuer la gestion.
Admets-tu qu'une personne puisse ne pas avoir d'email ou en avoir plusieurs : 0,n
Fonctionnes-tu tel qu'une personne doit avoir au minimun 1 email : 1,n
Dois-tu gérer obligatoirement un seul email obligatoire par personne : 1,1
Règle 1:
Chaque objet DOIT posséder un identifiant (entier, adresse mail, référence unique, etc...) L'identifiant d'une relation correspond à la concaténation des identifiants qui participent à la relation.
Exemple: client acheter produit à telle date (3 objets, 1 relation)
CLIENT (idc*, nom, prenom, adresse, etc...)
PRODUIT (idp*, libelle, prix, etc...)
DATE (datachat*)
ACHETER (idc*, idp*, datachat*, quantite, etc...)
NB:
1)
Les étoiles dans ce post indiquent que ces champs, identifiants dans le MCD, sont des champs primaires dans les tables
2)
Cas de la table DATE. La seule information contenue dans cette table est contenue dans la table de relation ACHETER, on peut donc ne pas créer cette table puisqu'on peut retrouver cette information ailleurs.
L'objet DATE est quand même mentionné dans le MCD pour faire savoir que datachat devra faire partie de l'identifiant de la relation. En effet, un identifiant est unique donc "1 - GL322" ne pourra apparaître qu'une fois. C'est embêtant pour un commerce si un client ne peut acheter qu'une fois. Là dans l'exemple, le même client a acheté deux fois le même article (GL322, chemise) mais à des jours différents. Si l'on veut pouvoir lui permettre d'acheter le même article plusieurs fois par jour (on ne sait jamais, c'est mieux :) il ne faudra pas mettre la datachat mais la date et heure c'est à dire le moment* de l'achat (2013-01-05 10:25:30)
3)
L'identifiant de la relation acheter est constitué par l'ensemble des identifiants des tables qui participent à la relation acheter (idc, idp, datachat). Le quatrième champ (quantite) et qui ne fait pas partie de l'identifiant (car non issu d'un objet) est une propriété portée par la relation. En effet, la quantité 2 n'est pas propre au client (il n'achète pas toujours ses articles en double) ni au produit (ils ne sont pas vendus par paire) mais c'est une information que l'on constate au moment de l'achat, donc propre à l'achat.
Quand toutes les cmax d'une relation sont à n, c'est une relation dite n-aire
exemples:
[CLIENTS]-1,n---(acheter)---0,n-[PRODUITS]
[PERSONNES]-0,n---(avoir pour)---1,n-[EMAIL]
Quand au moins une cmax d'une relation est à 1, c'est une relation dite une-aire
exemples:
[PERSONNES]-1,1---(avoir)---0,n-[NATIONALITE] (on ne gère pas les doubles nationalités
[SOCIETE]-1,1---(avoir siege social)---0,n-[PAYS]
RÉPONSE À TA QUESTION
---------------------
Objets:
Tous les objets Merise donnent lieu à la création d'une table (en dehors d'un cas tel que celui de la "datachat").
Relations:
Relation n-aire: création d'une table dite table de relation
Relation une-aire: il y a migration. C'est à dire que l'objet dont la cmax est à 1 va récupérer l'identifiant des autres objets dont la cmas est à n. Cet identifiant sera clef étrangère (en effet, c'est une clef mais comme elle vient d'une autre table...)
exemples:
relation n-aire:
[CLIENT]-1,n---(acheter)---0,n-[PRODUIT]
CLIENT (idc*, nom, prenom, adresse, etc...)
PRODUIT (ref*, libelle, prix, etc...)
ACHETER (idc*, ref*, quantite, remise, etc...)
Relation une-aire:
[PERSONNES]-1,1---(avoir)---0,n-[NATIONALITE]
PERSONNES (idp*, nom, prenom, adresse, datenais, etc..., codenat*)
NATIONALITE (codenat*, nationalite)
Conseils:
Pour établir plus facilement la correspondance entre MCD et tables, donner aux tables et autant que faire se peut, le nom des objets Merise et surtout, lors du développement, prendre des règles draconiennes pour les noms. Je te donne celles que j'utilise. A toi de trouver les tiennes mais respecte-les si tu veux éviter des erreurs dans les noms.
- Nom des tables = nom des objets Merise au pluriel, en minuscules, avec capitales, pas de caractères diacritiques (éèç...)
ex: Clients, Produits, Nationalites, etc...
- Nom des tables de relation = nom des relations Merise sans espace, en minuscules, avec une ou plusieurs capitales si plusieurs mots, sans caractères diacritiques
ex: Acheter, AvoirNationalite, Resider, AvoirPourEmail, etc...
Les tables qui participent à la meme gestion (au même MCD) sont préfixées.
ex: gestion clientèle => gc_*
gc_Clients, gc_Produits, gc_Acheter, gc_AvoirNationalite, etc...
Les tables qui participent à plusieurs gestions ne sont pas préfixées (ex: CodePostaux. En effet s'il y a plusieurs gestions dans la même base de données, les codes postaux peuvent servir à toutes et une mise à jour sur cette table sera répercutée sur toutes les gestions)
- Le nom des champs (et non "Le nom des gens": tu as vu le film ?) sont chez moi tous écris en minuscules, sans espace ni caractère diacritique et au singulier : client, produit, ref, idp, idc, nationalite, etc....
Si tu respectes les normes que tu auras choisies, tu feras moins d'erreur dans ton code quand tu feras référence aux tables et champs...
Voilà. J'espère que ça t'a un peu aidée...
[CLIENT]-0,n---(acheter)---0,n-[PRODUIT]
[CLIENT]-1,n---(acheter)---0,n-[PRODUIT]
sont bons tous les deux mais ils correspondent à une gestion différente (gestion des client potentiels ou pas). Dans la relation :
[PERSONNES]----(avoir pour)----[EMAIL]
Les cardinalités représenteront la manière dont il faudra effectuer la gestion.
Admets-tu qu'une personne puisse ne pas avoir d'email ou en avoir plusieurs : 0,n
Fonctionnes-tu tel qu'une personne doit avoir au minimun 1 email : 1,n
Dois-tu gérer obligatoirement un seul email obligatoire par personne : 1,1
Règle 1:
Chaque objet DOIT posséder un identifiant (entier, adresse mail, référence unique, etc...) L'identifiant d'une relation correspond à la concaténation des identifiants qui participent à la relation.
Exemple: client acheter produit à telle date (3 objets, 1 relation)
[CLIENT]-1,n---(acheter)---0,n-[PRODUIT]
'-------1,n-[DATE]
CLIENT (idc*, nom, prenom, adresse, etc...)
PRODUIT (idp*, libelle, prix, etc...)
DATE (datachat*)
ACHETER (idc*, idp*, datachat*, quantite, etc...)
[CLIENT] +------+---------+---------+-----+ | idc* | nom | prenom | ... | +------+---------+---------+-----+ | 1 | DUPONT | Jean | ... | | 2 | DUVAL | Arthur | ... | | 3 | MARTIN | Danièle | ... | [PRODUIT] +-------+----------+-------------------+ | idp* | article | taille, prix, ... | +-------+----------+-------------------+ | GL322 | chemise | ... | | PG089 | Pull | ... | | ST156 | Sous-tif | ... | [DATE] +------------+ | datachat* | +------------+ | 2013-01-01 | | 2013-01-02 | | 2013-01-03 | | 2013-01-04 | | 2013-01-05 | [Acheter] +------+-------+------------+---------+ | idc* | idp* | datachat* | qantite | +------+-------+------------+---------+ | 1 | PG089 | 2013-01-02 | 1 | | 1 | GL322 | 2013-01-02 | 2 | | 1 | GL322 | 2013-01-05 | 2 | | 3 | ST156 | 2013-01-04 | 1 |
NB:
1)
Les étoiles dans ce post indiquent que ces champs, identifiants dans le MCD, sont des champs primaires dans les tables
2)
Cas de la table DATE. La seule information contenue dans cette table est contenue dans la table de relation ACHETER, on peut donc ne pas créer cette table puisqu'on peut retrouver cette information ailleurs.
L'objet DATE est quand même mentionné dans le MCD pour faire savoir que datachat devra faire partie de l'identifiant de la relation. En effet, un identifiant est unique donc "1 - GL322" ne pourra apparaître qu'une fois. C'est embêtant pour un commerce si un client ne peut acheter qu'une fois. Là dans l'exemple, le même client a acheté deux fois le même article (GL322, chemise) mais à des jours différents. Si l'on veut pouvoir lui permettre d'acheter le même article plusieurs fois par jour (on ne sait jamais, c'est mieux :) il ne faudra pas mettre la datachat mais la date et heure c'est à dire le moment* de l'achat (2013-01-05 10:25:30)
3)
L'identifiant de la relation acheter est constitué par l'ensemble des identifiants des tables qui participent à la relation acheter (idc, idp, datachat). Le quatrième champ (quantite) et qui ne fait pas partie de l'identifiant (car non issu d'un objet) est une propriété portée par la relation. En effet, la quantité 2 n'est pas propre au client (il n'achète pas toujours ses articles en double) ni au produit (ils ne sont pas vendus par paire) mais c'est une information que l'on constate au moment de l'achat, donc propre à l'achat.
Quand toutes les cmax d'une relation sont à n, c'est une relation dite n-aire
exemples:
[CLIENTS]-1,n---(acheter)---0,n-[PRODUITS]
[PERSONNES]-0,n---(avoir pour)---1,n-[EMAIL]
Quand au moins une cmax d'une relation est à 1, c'est une relation dite une-aire
exemples:
[PERSONNES]-1,1---(avoir)---0,n-[NATIONALITE] (on ne gère pas les doubles nationalités
[SOCIETE]-1,1---(avoir siege social)---0,n-[PAYS]
RÉPONSE À TA QUESTION
---------------------
Objets:
Tous les objets Merise donnent lieu à la création d'une table (en dehors d'un cas tel que celui de la "datachat").
Relations:
Relation n-aire: création d'une table dite table de relation
Relation une-aire: il y a migration. C'est à dire que l'objet dont la cmax est à 1 va récupérer l'identifiant des autres objets dont la cmas est à n. Cet identifiant sera clef étrangère (en effet, c'est une clef mais comme elle vient d'une autre table...)
exemples:
relation n-aire:
[CLIENT]-1,n---(acheter)---0,n-[PRODUIT]
CLIENT (idc*, nom, prenom, adresse, etc...)
PRODUIT (ref*, libelle, prix, etc...)
ACHETER (idc*, ref*, quantite, remise, etc...)
Relation une-aire:
[PERSONNES]-1,1---(avoir)---0,n-[NATIONALITE]
PERSONNES (idp*, nom, prenom, adresse, datenais, etc..., codenat*)
NATIONALITE (codenat*, nationalite)
Conseils:
Pour établir plus facilement la correspondance entre MCD et tables, donner aux tables et autant que faire se peut, le nom des objets Merise et surtout, lors du développement, prendre des règles draconiennes pour les noms. Je te donne celles que j'utilise. A toi de trouver les tiennes mais respecte-les si tu veux éviter des erreurs dans les noms.
- Nom des tables = nom des objets Merise au pluriel, en minuscules, avec capitales, pas de caractères diacritiques (éèç...)
ex: Clients, Produits, Nationalites, etc...
- Nom des tables de relation = nom des relations Merise sans espace, en minuscules, avec une ou plusieurs capitales si plusieurs mots, sans caractères diacritiques
ex: Acheter, AvoirNationalite, Resider, AvoirPourEmail, etc...
Les tables qui participent à la meme gestion (au même MCD) sont préfixées.
ex: gestion clientèle => gc_*
gc_Clients, gc_Produits, gc_Acheter, gc_AvoirNationalite, etc...
Les tables qui participent à plusieurs gestions ne sont pas préfixées (ex: CodePostaux. En effet s'il y a plusieurs gestions dans la même base de données, les codes postaux peuvent servir à toutes et une mise à jour sur cette table sera répercutée sur toutes les gestions)
- Le nom des champs (et non "Le nom des gens": tu as vu le film ?) sont chez moi tous écris en minuscules, sans espace ni caractère diacritique et au singulier : client, produit, ref, idp, idc, nationalite, etc....
Si tu respectes les normes que tu auras choisies, tu feras moins d'erreur dans ton code quand tu feras référence aux tables et champs...
Voilà. J'espère que ça t'a un peu aidée...
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
heliconius
Messages postés
545
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
23 juin 2023
137
22 janv. 2013 à 11:36
22 janv. 2013 à 11:36
Petite précision.
Ton MCD est une perception du réel et ne doit inclure que ce qui fait partie de l'univers du discours. Ce sont les termes utilisés par les auteurs de la méthode (Tardieu, Rochfeld et Coletti).
Perception du réel : le MCD doit représenter la réalité. Réalité du fonctionnement de la société, de la gestion à informatiser, etc... Le réel peut très bien être différent d'une gestion à l'autre, d'une société à une autre.
exemple: pour l'une, l'heure de la prise de travail sera quand l'employé aura émargé le cahier de présence ou actionné la pointeuse alors que pour une autre, ce sera l'heure d'ouverture d'une session de travail sur son poste informatique même s'il est dans les locaux depuis une heure ou plus.
L'univers du discours : c'est tout simplement ce que tu dois gérer.
exemple: Tu as à effectuer une gestion de personnel. C'est vrai que telle personne (incluse dans la gestion) a dans la réalité une grand-mère atteinte de la maladie d'Alzheimer et à qui il ne reste plus qu'une dent. Mais la grand-mère, sa dent et sa maladie bien qu'elle fassent partie de la réalité ne font pas partie de l'univers du discours (tu n'as pas à les gérer). => ne pas mettre dans le MCD les choses qui ne sont pas à gérer bien qu'elles fassent partie du réel.
Pour en revenir aux cardinalités et à un type de relation particulière : relation reflexive une-aire
Une relation est dite réflexive quand un objet fait référence à lui-même.
exemple: l'objet [PERSONNES].
Une personne mariée à une autre personne. Les conjoints sont dans le même objet. Si tu construis ton MCD pour une société dans une culture monogame on partira du principe qu'une personne n'est pas mariée ou ne l'est qu'une seule fois au même moment (on ne gère pas les ex), ta relation reflexive pourrait ressemble à ceci :
(NB: dans une culture où la polygamie serait autorisée, la modélisation serait très probablement différente)
En fait il n'y a qu'un seul objet mais il faudra penser comme s'il y en avait deux :
[PERSONNES-CONJOINT-1]-0,1---(marié à)---0,1-[PERSONNES-CONJOINT-2]
(NB: je préfère dire conjoint 1 et 2 plutôt que H et F ;-) Anticipons la loi qui risque de passer au sujet du "mariage pour tous")
Dans ce cas, Migrations. Chaque objet de cmax=1 récupère l'identifiant de l'autre objet.
[PERSONNES-CONJOINT-1] recevrait l'identifiant de [PERSONNES-CONJOINT-2]
[PERSONNES-CONJOINT-2] recevrait l'identifiant de [PERSONNES-CONJOINT-1]
PERSONNES (idpers*, nom, prenom, sexe, adresse, email, ..., conjoint)
Et les enregistrements sur fiches cartonnées donneraient :
LE REEL : Soit à modéliser un truc dans lequel on parle de profs et d'élèves. Il y a bien des profs et des élèves mais la réalité c'est quoi ? Les deux (profs et élèves) sont des personnes avec un nom, un prénom, un sexe, une date de naissance, etc... Pour ce qu me concerne, je mets tout dans le même sac [PERSONNES]. En fait, je considère qu'une personne enseigne à une autre personne et rien ne dit qu'un jour telle personne qui se trouvait à un moment donné élève, n'apparaisse pas plus tard comme enseignant... Si un jour le cas se produisait et que des objets différents avaient été créés ([PROFESSEURS] et [ELEVES]) il y aurait la même information notée deux fois avec tout ce que ça peut comporter d'erreurs...
Voilà. C'était le petit plus.
Tu es d'où ?
Ton MCD est une perception du réel et ne doit inclure que ce qui fait partie de l'univers du discours. Ce sont les termes utilisés par les auteurs de la méthode (Tardieu, Rochfeld et Coletti).
Perception du réel : le MCD doit représenter la réalité. Réalité du fonctionnement de la société, de la gestion à informatiser, etc... Le réel peut très bien être différent d'une gestion à l'autre, d'une société à une autre.
exemple: pour l'une, l'heure de la prise de travail sera quand l'employé aura émargé le cahier de présence ou actionné la pointeuse alors que pour une autre, ce sera l'heure d'ouverture d'une session de travail sur son poste informatique même s'il est dans les locaux depuis une heure ou plus.
L'univers du discours : c'est tout simplement ce que tu dois gérer.
exemple: Tu as à effectuer une gestion de personnel. C'est vrai que telle personne (incluse dans la gestion) a dans la réalité une grand-mère atteinte de la maladie d'Alzheimer et à qui il ne reste plus qu'une dent. Mais la grand-mère, sa dent et sa maladie bien qu'elle fassent partie de la réalité ne font pas partie de l'univers du discours (tu n'as pas à les gérer). => ne pas mettre dans le MCD les choses qui ne sont pas à gérer bien qu'elles fassent partie du réel.
Pour en revenir aux cardinalités et à un type de relation particulière : relation reflexive une-aire
Une relation est dite réflexive quand un objet fait référence à lui-même.
exemple: l'objet [PERSONNES].
Une personne mariée à une autre personne. Les conjoints sont dans le même objet. Si tu construis ton MCD pour une société dans une culture monogame on partira du principe qu'une personne n'est pas mariée ou ne l'est qu'une seule fois au même moment (on ne gère pas les ex), ta relation reflexive pourrait ressemble à ceci :
+-----------+ | PERSONNES | +-----------+ | idpers* | 0,1 | nom +-------+ | prenom | \ | sexe | (marié à) | adresse | / | tel +-------+ | email | 0,1 | ... | +-----------+
(NB: dans une culture où la polygamie serait autorisée, la modélisation serait très probablement différente)
En fait il n'y a qu'un seul objet mais il faudra penser comme s'il y en avait deux :
[PERSONNES-CONJOINT-1]-0,1---(marié à)---0,1-[PERSONNES-CONJOINT-2]
(NB: je préfère dire conjoint 1 et 2 plutôt que H et F ;-) Anticipons la loi qui risque de passer au sujet du "mariage pour tous")
Dans ce cas, Migrations. Chaque objet de cmax=1 récupère l'identifiant de l'autre objet.
[PERSONNES-CONJOINT-1] recevrait l'identifiant de [PERSONNES-CONJOINT-2]
[PERSONNES-CONJOINT-2] recevrait l'identifiant de [PERSONNES-CONJOINT-1]
PERSONNES (idpers*, nom, prenom, sexe, adresse, email, ..., conjoint)
Et les enregistrements sur fiches cartonnées donneraient :
+-----------------+ +-------------------+ |id: 152 | |id: 37 | |nom: DUPONT | |nom: MARTIN | |prenom: Jean | |prenom: Isabelle | |sexe: M | |sexe: F | |...: ... | |...: ... | |conjoint: 37 | |conjoint: 152 | +-----------------+ +-------------------+
LE REEL : Soit à modéliser un truc dans lequel on parle de profs et d'élèves. Il y a bien des profs et des élèves mais la réalité c'est quoi ? Les deux (profs et élèves) sont des personnes avec un nom, un prénom, un sexe, une date de naissance, etc... Pour ce qu me concerne, je mets tout dans le même sac [PERSONNES]. En fait, je considère qu'une personne enseigne à une autre personne et rien ne dit qu'un jour telle personne qui se trouvait à un moment donné élève, n'apparaisse pas plus tard comme enseignant... Si un jour le cas se produisait et que des objets différents avaient été créés ([PROFESSEURS] et [ELEVES]) il y aurait la même information notée deux fois avec tout ce que ça peut comporter d'erreurs...
Voilà. C'était le petit plus.
Tu es d'où ?
