|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre du Club
![]() Inscription : janvier 2008 Messages : 284 ![]() |
Bonjour,
Dans mon problème un client achète une maison (association client_maison), une même maison contient toujours les mêmes chambres (relation maison_chambres), le nom des chambres ne change jamais quelque soit la maison. Un client peut acheter un ou plusieurs objets (relation client_objet) et le placer une seule fois dans une chambre (relation ctot_ctmn). Dans le modèle 1 que j'ai fait le nombre de tupple dans maison_chambres ne chane jamais; le client place les objets achetés (cient_objet) dans une maison via l'association ctot_CTMN puis choisit la pièce dans lequel l'objet doit etre placé via le champ id_mncs (correspondant à l'id de relation entre maison et chambre). est-ce bon ? ou faut il mieux des qu'un client achete une maison créer autant d'enregistrement maison_chambres qu'il n'y a de pièceS dans chaque maison puis faire le modèle 2, ainsi dès qu'un client achète un objet (client_objet) il le place dans l'association (ctot_mncs) ? Merci d'avance pour votre aide, je m'embrouille un peu les pédales et ... Joyeux Noël ......
__________________
Réalisations : Jeu de gestion d'hypermarché virtuel |
|
|
00
|
|
|
#2 |
|
Expert Confirmé Sénior
![]() ![]() ![]() François de Sainte MarieSpécialiste en bases de données Inscription : septembre 2006 Messages : 3 623 ![]() |
Bonsoir,
Pour vos schémas vous utilisez la notation Codasyl, pourquoi pas. Néanmoins on ne sait pas quels attributs participent aux clés des tables, les cardinalités portées par les liens sont absentes, etc. Pour évacuer les ambiguïtés il est préférable d’utiliser un outil de modélisation tel que MySQL Workbench (gratuit, voyez chez JogodePau un exemple d'utilisation de l'ouil). Cela dit, une interprétation de vos schémas est la suivante : — Un client peut acheter plusieurs maisons et la même maison peut être achetée par plusieurs clients : feriez-vous dans la copropriété ?Le caractère étrange de la situation est nettement amplifié dès qu’il s’agit de placer les objets... Supposons que vous ne donniez pas dans la copropriété. La relation entre une maison et un client est alors la suivante (représentation MySQL Workbench) : Ce qui se lit : — Un client a acheté de 0 à N maisons (0,* se lit : 0,N).A noter que la table MAISON_ACHETÉE hérite de la clé {MaisonId} de la table MAISON. Le losange rougeâtre signifie que {ClientId} est clé étrangère (en l’occurrence par référence à la table CLIENT). Une chambre n’est jamais qu’une propriété multivaluée d’une maison, ce qui se modélise ainsi : Ce qui se lit : — Une maison comporte au moins une chambre (1,*).Par la suite, on peut produire le schéma suivant : Où l’on observe qu’un objet ne peut être placé dans une chambre que si celle-ci fait partie d’une maison qui a été achetée. Il faut par ailleurs s’assurer que cet objet est placé dans une maison qui a été achetée par le client qui a acheté l’objet, sinon il risque d’y avoir de la bagarre. On verra un peu plus tard comment mettre cette contrainte en œuvre. Joyeux Noël à vous aussi !
__________________
_ Faites simple, mais pas plus simple ! (A. Einstein) E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire ») => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale ») __________________ Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !) |
|
|
00
|
|
|
#3 | ||||||
|
Expert Confirmé Sénior
![]() ![]() ![]() François de Sainte MarieSpécialiste en bases de données Inscription : septembre 2006 Messages : 3 623 ![]() |
Bonsoir,
A propos de la contrainte : Un client ne peut pas placer ses propres objets chez les autres clients.Au niveau SQL il faudra en passer par un trigger pour les inserts (et les updates). A noter que j’ai ajouté une table TYPE_OBJET dans le schéma : Au stade SQL (avec SQL Server) : Création des tables Code SQL :
Le trigger mermettant de s’assurer que Raoul ne place pas ses objets (explosifs) chez Fernand : Code SQL :
Un début de jeu d’essai : Code SQL :
A vous de jouer.
__________________
_ Faites simple, mais pas plus simple ! (A. Einstein) E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire ») => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale ») __________________ Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !) |
||||||
|
|
00
|
|
|
#4 | ||
|
Membre du Club
![]() Inscription : janvier 2008 Messages : 284 ![]() |
Bonjour,
Merci beaucoup pour votre réponse. Citation:
Citation:
En fait il s'agit d'un logiciel d'architecture, les maisons sont donc fictives et préfabriquées, un exemple :- La maison "A" comporte 5 pièces parmi lesquelles un salon, une cuisine, une salle de bain, des toilettes et une chambre à coucher. - La maison "B" comporte toujours 6 pièces, elles sont identiques à la maison A et comporta en plus une seconde salle de bain. - La maison "C" comporte toujours 8 pièces, elles sont identiques à "B" mais avec en plus une salle de gym et un sauna. J'ai dans mon exemple créer l'association "maison_chambre" car je souhaite que la table "chambre" comporte une description de chaque pièce (Description type : le salon peut accueillir une télé, un canapé, etc...) pour éviter qu'une personne ne place par exemple une lunette de WC au milieu du salon même si l'action ne serait pas interdite par le logiciel. La pièce "salon" de la maison A peut donc être la même que dans la maison B étant donné que la description ne change pas ... voyez-vous ?? Pour la suite je vais prendre votre schéma car je le trouve bien plus clair ^^ Vous créez une association entre objet_acheté->objet_placé<-chambre Sachant qu'un objet une fois acheté est toujours placé dans une et une seule chambre et que une chambre peut comporter 0 ou n objets on obtient les cardinalités suivantes objet_acheté(1,1)->objet_placé<-(0,n)chambre; ainsi l'association objet_placé ne peut-elle pas être supprimée au profit de : objet_achete(pk_objet, fk_ObjetId, fk_ClientId, fk_MaisonId, fk_ChambreId) ? Qu'en pensez-vous ?
__________________
Réalisations : Jeu de gestion d'hypermarché virtuel |
||
|
|
00
|
|
|
#5 |
|
Expert Confirmé Sénior
![]() ![]() ![]() François de Sainte MarieSpécialiste en bases de données Inscription : septembre 2006 Messages : 3 623 ![]() |
Bonsoir Popy,
Si je comprends bien, on ne fait pas dans le sur-mesure : plutôt que décrire des pièces personnalisées comme je l’ai fait, on a des pièces-types (salon, chambre à coucher, etc.) peuplées d’objets-types (télé, canapé, etc.). A partir de là on compose l’organisation-type d’une maison à partir des pièces-types ; c’est cela ? Si oui, cela conduit à une modélisation différente de celle que j’ai proposée : les pièces d’une maison n’en sont pas des propriétés multivaluées, mais il y a association entre maison et pièce (table COMPOSITION_MAISON), même principe pour les objets-types entrant dans la composition d’une pièce-type (table COMPOSITION_PIÈCE). Une proposition (aménageable !) de représentation (dans laquelle j’ai renommé CHAMBRE en PIÈCE) :
__________________
_ Faites simple, mais pas plus simple ! (A. Einstein) E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire ») => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale ») __________________ Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !) |
|
|
00
|
Copyright © 2000-2013 - www.developpez.com