Version imprimable
Salut tout le monde
J'ai réalise une conception UML , la question qui me tracasse est si on est cencé dans l uml d avoir une clé primaire.J'ai lu un pdf :http://books.google.com/books?id=TDM...page&q&f=false
j ai conclut que le model objet n a pas besoin de clé primaire et c est tout a fait logique.Sauf que lors de la création dans un SGBD,je connais pas comment je ferai sans clé primaire ni clé étrangère,les relations entre table?
Merci pour votre aide
Pour modéliser des clefs primaires et étrangères on utilise les stéréotypes sur les atributs comme PK pour primary key ou FK pour foreign key.
Pour les relations il suffit de faire des relations de dépendance rien de vraiment spécial.
Bonjour
Concernant les sterotype,c est la première fois que qq1 me le demande de le faire,car ils m 'ont suggérer d'utiliser les tagged values.Je ne sais pas vraiment.
Quant au relation,je ne pense pas qu'un diagramme de classe peut facilement se transformer a un diagramme avec des dépendance.Pourriez vous mieux m expliquer SVP.
Merci
Pourquoi vouloir transformer le diagramme de classe en quoique se soit ?
Il y a le diagramme de classe c'est tout en stéréotypant chaque classe par <TABLE>
Je ne comprends pas ce que tu veux faire. C'est bien la modélisation d'une base de données au niveau physique non ?
salut
En fait je veux passer à l'étape qui suit la modélisation,cad implementer ma base de données dans le SGBD (j'utilise postgresql)
Ayant élaborer un diagramme de classe,c est pas evident de faire avec dans le SGBD car il gère que le relationnel.
Comment faire pour pouvoir exporter mon diagramme de classe en table(ou bien quelque chose qui me facilitera la table)
J'ai jeté un coup d'œil sur le Mapping O/R mais c'est pas donnée car j ai beaucoup de classe.
Merci
Si tu fais un diagramme de classe qui représente les tables physiques d'une base relationnel cela ne change rien je l'ai fais pleins de fois.
Une classe serait tout simplement une table physique dans la base relationnel.
Il ne faut pas confondre la modélisation des tables du SGBD et la modélisation des classes d'accès aux données
Si je suis le raisonnement que vous m avez dit,alors comment je ferai avec l'héritage+les agrégation...
Je n vois pas ce que vous voulez dire
Merci pour votre compréhension.
?Citation:
Envoyé par hellalaboy
Tu pourrais être précis parce que j'ai l'impression que tu confonds plusieurs choses.
J'essaierai de vous expliquer la situation en détail
Je dois réaliser une base de donnée spatiale pour un système d'information géographique.
Alors j'ai utilisé l'AGL BoUml pour la conception.J'ai fait mon diagramme de classe"qui comporte un grand nombre de classes et de relation"association,heritage..."
Maintenant que j ai le modele ,je veux le creer dans mon SGBD pour pouvoir alimenter ma base de données"Or tous les SGBD sont relationnels,donc il faut passer d un diagramme de classe à un diagramme relationnel.
Le fait de stéréotyper la classe avec table ne ressoudera pas le problème car on a des relations complexes entre les classes"ce qui fait la force d'uml".
La solution qui me parait c est de pouvoir exporter mon diagramme de classe en script SQL ou bien un fichier avec une extension que je connais peut être pas puis l'importer avec mon SGBD.
J'espère que vous me comprenez mieux maintenant
Je suis ouvert a toutes vos suggestions
Merci
L'aspect spatial est spécifique au SIG : certains sgbd comme oracle ou mysql incorpore une cartouche spatial mais cela ne change pas grand chose pour la modélisationCitation:
Envoyé par hellalaboy
Je ne vois pas vraiment le problème. On peut modéliser un schéma de base de données relationnel avec UML. Le fait de stéréotyper <Table> ou <Persistant> donne simplement une indication supplémentaire que nous ne sommes plus à un niveau de schéma d'analyse/conception mais physiqueCitation:
Maintenant que j ai le modele ,je veux le creer dans mon SGBD pour pouvoir alimenter ma base de données"Or tous les SGBD sont relationnels,donc il faut passer d un diagramme de classe à un diagramme relationnel.
Le fait de stéréotyper la classe avec table ne ressoudera pas le problème car on a des relations complexes entre les classes"ce qui fait la force d'uml".
Je vous conseille de garder votre modélisation du modèle 'métiers' (qui est plus d'un niveau conceptuel)et d'en faire un autre pour la partie persistance des données(niveau physique) afin d'éliminer les classes et relations 'abstraites' de votre analyse/conception et de le mettre au schéma relationnel
Si je comprends bien vous ne savez pas comment générer votre base de données à partir de votre modèle qui n'est pas conforme aux contraintes relationnelles?Citation:
La solution qui me parait c est de pouvoir exporter mon diagramme de classe en script SQL ou bien un fichier avec une extension que je connais peut être pas puis l'importer avec mon SGBD.
J'espère que vous me comprenez mieux maintenant
Êtes-vous sûr que bouml génère des scripts sql pour vos importations dans vos sgbd cibles ?
Merci pour les reponses
vous avez dit "Si je comprends bien vous ne savez pas comment générer votre base de données à partir de votre modèle qui n'est pas conforme aux contraintes relationnelles?"
La vous avez touché le problème,je ne connais pas commet générer la base de données relationnelles de mon diagramme de classe.
Non Bouml ne génère pas de script SQL:cry:
Je vous ai donné une réponse alors : révisez votre diagramme de classe afin qu'il corresponds non pas à un modèle générique mais à une implémentation dans un schéma relationnel(si le schéma n'était pas relationnel comme avec XML par exemple se serait pareil ->il faut donc prendre en compte les spécificités de votre base de données)
Bonjour,
Faudra peut être réviser la notion de Relationnel/objet. Sinon, le diagramme de classes représente l'aspect statique, les autres diagrammes vous aideront à représenter l'aspect d'interaction, dynamique ...
Donc, pourquoi ne pas avoir recours au vieux MCD et de là passer au MLD (modèle logique de données).
Salutations.
C'est l'aspect statique qui nous intéressent ici, c'est d'ailleurs là où il y a le plus de matière, les interactions à un SGBD se résument plus ou moins à un CRUDCitation:
Envoyé par yasinfo
Il y a des tas de raisons, l'initiateur du thread ayant les siennes (qui peuvent être une contrainte d'entreprise par exemple) on peut par exemple dire que UML est plus souple pour la modélisation car on ne s'encombre pas de pleins de règles inhérentes aux MCD/MLD.Citation:
Envoyé par yasinfo
Voir les débats qui existent autour de ce sujet dans le forum
Merci