3 réponses
un peu de bla bla :
Le modèle logique de donnée (MLD) te donnes un schéma relationnel de ta futur BD (primary key et foreign key)
Pour mettre en place ta BD à partir du MLD il faut te servir du dictionnaire de données pour connaître la nature des champs tel qu'ils ont été définis (char, integer,...)
tu n'as donc plus rien à faire : le MLD contient les relations entre tes tables et le dico de données contien le type de tes champs .
Si tu veux plus de détail précise ton probléme (ex: quel est le SGBD que tu va utiliser ?,...)
@+
Le modèle logique de donnée (MLD) te donnes un schéma relationnel de ta futur BD (primary key et foreign key)
Pour mettre en place ta BD à partir du MLD il faut te servir du dictionnaire de données pour connaître la nature des champs tel qu'ils ont été définis (char, integer,...)
tu n'as donc plus rien à faire : le MLD contient les relations entre tes tables et le dico de données contien le type de tes champs .
Si tu veux plus de détail précise ton probléme (ex: quel est le SGBD que tu va utiliser ?,...)
@+
drizzt
Messages postés
4
Date d'inscription
mercredi 7 mars 2001
Statut
Membre
Dernière intervention
26 avril 2001
26 avril 2001 à 15:06
26 avril 2001 à 15:06
Tu a mal modeliser ton MCD (ou je comprend pas ton exemple)
Je te propose la solution suivante si tu veut absolument modeliser tes diodes or de ta table composant electronique (mais ca me semble pas top et crois moi je suis un pro en Merise ):
Une diode est un composant electronique (donc correspond à min 1 max 1 composant electronique )
et un composant electronique correspond à au moins 1 truc(une diode, un transistor,... car sinon ca sert a rien de le retenir ds la base) et max infini de truc (ou si tu a un nombre max ce fixe, ce nombre)
en MLD tu dois avoir un trucs comme cela :
(# =clef primaire, & = clef etrangere )
TableDiode (#ClefDiode, &ClefCompo,...)
TableCompo(#ClefCompo,...)
Mais un conseil revoit ta modelisation de ton MCD car je le sens vraiment pas ton trucs, ca me semble pas bien modelisé tous ca
mail moi pour plus d'info
Je te propose la solution suivante si tu veut absolument modeliser tes diodes or de ta table composant electronique (mais ca me semble pas top et crois moi je suis un pro en Merise ):
Une diode est un composant electronique (donc correspond à min 1 max 1 composant electronique )
et un composant electronique correspond à au moins 1 truc(une diode, un transistor,... car sinon ca sert a rien de le retenir ds la base) et max infini de truc (ou si tu a un nombre max ce fixe, ce nombre)
en MLD tu dois avoir un trucs comme cela :
(# =clef primaire, & = clef etrangere )
TableDiode (#ClefDiode, &ClefCompo,...)
TableCompo(#ClefCompo,...)
Mais un conseil revoit ta modelisation de ton MCD car je le sens vraiment pas ton trucs, ca me semble pas bien modelisé tous ca
mail moi pour plus d'info
Bon, je vais y arriver à force... L'exemple n'est pas bon mais je vais en trouver un autre...euh...Ah oui !
Parlons cuisine: (désolé, j'ai pas mieux)
on a une table 4QUART avec les infos cle_4quart, qte_beurre, qte_sucre
on a une table 4QUART_NEW_RECETTE avec les mêmes infos que précedemment et une nouvelle info le_secret
Comment faire dans ce cas ?
Parlons cuisine: (désolé, j'ai pas mieux)
on a une table 4QUART avec les infos cle_4quart, qte_beurre, qte_sucre
on a une table 4QUART_NEW_RECETTE avec les mêmes infos que précedemment et une nouvelle info le_secret
Comment faire dans ce cas ?
Je suis juste de passage... mais je me permets quand même d'y mettre mon grain de sel. Ce que tu décrits me semble s'appeller l'héritage. Même si cela a une connotation objet, cela offusque tellement peu un Merisien que les nouvelles versions de Merise l'intègre, de même que l'excellent outils AMC-Designor. Si tu ne connaît pas, voici comment cela peut se passer.
Tu as un père objet "GATEAU" (et non 4QUART qui est une instance de la GATEAU), qui contient les propriétés communes. Et autant de fils qu'il existe de "variantes", ici un objet "GATEAU_AMELIORE" (qui contiendra 4QUART_new_look) qui va avoir des propriétés descriptives complémentaires. Pour le représenter (modèle AMC-D) une patte part du père (flèche vers le père) et s'accroche à un demi-disque, d'où partent des pattes vers les fils...
Au niveau logique (ou directement physique si c'est une bdd relationelle), tu as deux solutions : une seule table, ou autant de tables que de variantes.
Si c'est une seule table, une propriété discréminante fait la différence (type d'entité par exemple) et justifie l'existance ou non de valeurs dans les propriétés des variantes (il faudra programmer les contrôles !)
Plusieurs tables : une pour le père, et dans chaque table variante une clé étrangère qui pointe vers le père. Un Merisien pur et dur de l'ancienne école réfléchira à une représentation conceptuelle avec des relations, mais ce n'est sans doute pas l'effet que tu recherche ?
En espérant avoir correctement interpréter ton problème.
Bon courage...
Tu as un père objet "GATEAU" (et non 4QUART qui est une instance de la GATEAU), qui contient les propriétés communes. Et autant de fils qu'il existe de "variantes", ici un objet "GATEAU_AMELIORE" (qui contiendra 4QUART_new_look) qui va avoir des propriétés descriptives complémentaires. Pour le représenter (modèle AMC-D) une patte part du père (flèche vers le père) et s'accroche à un demi-disque, d'où partent des pattes vers les fils...
Au niveau logique (ou directement physique si c'est une bdd relationelle), tu as deux solutions : une seule table, ou autant de tables que de variantes.
Si c'est une seule table, une propriété discréminante fait la différence (type d'entité par exemple) et justifie l'existance ou non de valeurs dans les propriétés des variantes (il faudra programmer les contrôles !)
Plusieurs tables : une pour le père, et dans chaque table variante une clé étrangère qui pointe vers le père. Un Merisien pur et dur de l'ancienne école réfléchira à une représentation conceptuelle avec des relations, mais ce n'est sans doute pas l'effet que tu recherche ?
En espérant avoir correctement interpréter ton problème.
Bon courage...
Ok, je pense que toutes vos explications sont très claires. Je suis d'accord pour l'héritage, c'est tout à fait cela ! Mais quand à l'utiliser avec Merise, je ne sais pas. Peut-on parler d'héritage avec Merise ?
Enfin, bref...
Je tiens à tous vous remercier car l'aide que vous venez de m'apporter est précieuse et m'est très utile car je l'applique dès mintenant !
A bientôt et encore merci !
Enfin, bref...
Je tiens à tous vous remercier car l'aide que vous venez de m'apporter est précieuse et m'est très utile car je l'applique dès mintenant !
A bientôt et encore merci !
Oui, je vois le soucis. Je garde moi aussi toujours au fond de moi un peu de purisme Merise.
Pour s'en sortir, on peut faire comme cela :
une entité père (père_id, liste_propriétés_père)
une entité fils (fils_id, liste_propriétés_fils)
une association"hériter/être héritier"
cardinalité père : O,n (n'a pas ou a plusieurs fils)
cardinalité fils : 1,1 (a obligatoirement un père) avec en complément à cette cardinalité un contrainte "identifiant dépendant" ce qui signifie que l'identifiant complet du fils est déduit du père. Voila du merise à peu près propre...
Au niveau physique :
une table père (père_id, liste_propriétés_père)
une table fils (identifiant : père_id et fils_id, liste_propriétés_fils)
une clé étrangère dans la table fils constituée par père_id
Bon, je me suis contenté de créer un héritage avec AMC-D, de générer le modèle physique, et de générer un nouveau modèle conceptuel à partir de là. J'ai obtenu ce qui est décrit ci-dessus.
Maintenant, pour la compréhension et l'efficacité, je pense que l'entorse (si entorse il y a) est plus lisible.
Je suis heureux d'avoir été utile. Merci de m'avoir répondu !
La modélisation, même si elle ne fait plus partie de mes activités régulières, m'apporte toujours une petite intincelle de jouvence (;-)
@+ ... si je repasse par là
Pour s'en sortir, on peut faire comme cela :
une entité père (père_id, liste_propriétés_père)
une entité fils (fils_id, liste_propriétés_fils)
une association"hériter/être héritier"
cardinalité père : O,n (n'a pas ou a plusieurs fils)
cardinalité fils : 1,1 (a obligatoirement un père) avec en complément à cette cardinalité un contrainte "identifiant dépendant" ce qui signifie que l'identifiant complet du fils est déduit du père. Voila du merise à peu près propre...
Au niveau physique :
une table père (père_id, liste_propriétés_père)
une table fils (identifiant : père_id et fils_id, liste_propriétés_fils)
une clé étrangère dans la table fils constituée par père_id
Bon, je me suis contenté de créer un héritage avec AMC-D, de générer le modèle physique, et de générer un nouveau modèle conceptuel à partir de là. J'ai obtenu ce qui est décrit ci-dessus.
Maintenant, pour la compréhension et l'efficacité, je pense que l'entorse (si entorse il y a) est plus lisible.
Je suis heureux d'avoir été utile. Merci de m'avoir répondu !
La modélisation, même si elle ne fait plus partie de mes activités régulières, m'apporte toujours une petite intincelle de jouvence (;-)
@+ ... si je repasse par là
bonjour tout le monde!
j'ai 1 pb concernant l'heritage: j'ai un table produit(codeprodt,autresprorietes)
table logiciel(licence,autresproprietes) qui herite produit
table materiel(numeroserie,autresproprietes) qui herite aussi produit
Le pb ce ke lors de l'ajout d'un nouveau materiel ou logiciel, je dois entrer dabord le codeprodt puis le numeroserie ou licence ca depend.
Là je sais pa comment faire si je dois entrer un autre produit pareil avec le precedent (par exemple "onduleur") mais qui se differencie seulement par le numeroserie.Comment faire? Est-ce ne pas la redondance ça ou je me trompe?
L'autre pb ce ke comment faire ça(heritage) avec Mysql.
Je compte sur vous. Merci d'avance!
j'ai 1 pb concernant l'heritage: j'ai un table produit(codeprodt,autresprorietes)
table logiciel(licence,autresproprietes) qui herite produit
table materiel(numeroserie,autresproprietes) qui herite aussi produit
Le pb ce ke lors de l'ajout d'un nouveau materiel ou logiciel, je dois entrer dabord le codeprodt puis le numeroserie ou licence ca depend.
Là je sais pa comment faire si je dois entrer un autre produit pareil avec le precedent (par exemple "onduleur") mais qui se differencie seulement par le numeroserie.Comment faire? Est-ce ne pas la redondance ça ou je me trompe?
L'autre pb ce ke comment faire ça(heritage) avec Mysql.
Je compte sur vous. Merci d'avance!
26 avril 2001 à 14:55
un magasin d'électronique a une bdd. Une table COMPOSANTS_ELECTRONIQUES contient certaines propriétés. La table DIODE contient d'autres info, spécifiques à une diode, mais en plus les infos relatives à un composant electronique de la tale COMPO.... Et ceci est la même choses pour chaques composants vendus ds le magasin.
Mais ca donne quoi, niveau table logiques et physique ?
En tout cas, merci beaucoup pour votre aide !