Version imprimable
Pour une base de donnée touristique, les règles sont:
Departement contient des Communes qui contiennent des Lieux
Un Hotel appartient à un lieu et possède un site Web
Un site Web peut être lié à une Commune, ou non !
Ce qui donne ce diagramme:
Pièce jointe 535496
Il n'y a pas un problème avec la boucle Commune Site Web Hotel Lieu ?
Est ce qu'il existe une meilleure solution ?
Je ne vois pas de soucis quelconque, mais rajoute des Id à tes tables ! :)
Tu pourrais également rajouter des associations pour y voir plus claire !
Pourquoi penses tu qu'il y a un problème ?
Bonsoir,
Via le chemin Hotel > Lieu > Commune, , on peut atterrir sur la commune C1,
Via le chemin Hotel > SiteWeb > Commune, on peut atterrir sur la commune C2.
Si C1 et C2 doivent désigner la même commune, il y a un problème. Si la base de données utilisée est du genre SQL, ça pourra être résolu au moyen d’une contrainte (mise en oeuvre par exemple d’un trigger affecté à la table Hotel).
Merci d'avoir pris le temps de lire le schéma.
J'ai rajouté les id sauf pour la table Commune ou le contexte permet d'utiliser la chaîne Commune comme clé primaire. (une particularité du système considéré)
En fait le problème que je soupçonnais s'est révélé pleinement avec la contribution de "fsmrel" ... et avec un rapide maquettage fait sur Base dans Libre Office.
Le cœur du problème c'est qu'on peut avoir deux lieux identiques (dont le nom est identique) situés dans deux communes différentes.
Exemple fictif dans le Gard: (Nimes, Canet) (Bagnols, Canet)
Pour le problème des lieux dont le nom est identiques, une précédente solution (dans la version ancienne de la base datée de 20 ans :) ) consistait à définir une table séparée:
Relation(idLieu, Commune, Lieu)
Ensuite on définit chaque objet à partir de son idLieu, solution qui marche bien mais oblige à gérer une table supplémentaire et pas mal de jonglage dans les formulaires.
Evidemment l'ancienne base étant dans Access et la nouvelle dans Base, je pourrais faire un transfert et basta. Mais c'est pas possible parce qu'il y avait des erreurs de conception gênantes et que je dois tout réécrire. Et tant qu'à faire si je peux simplifier le système (Commune, Lieu) ...
J'en suis arrivé provisoirement à ce schéma et ca ne va toujours pas !
Pièce jointe 536653
Ce qui m'intéresserait c'est de voir les différentes solutions possibles ...
Bonsoir passant13,
Pour être plus à l’aise, je bascule vers Looping (gratuit) qui permet de représenter des MCD aussi bien que des diagrammes de classes.
Le diagramme de classes ci-dessous :
est issu du MCD :
Je rappelle que les cardinalités (multiplicités) du MCD sont inversées par rapport à celles du diagramme de classes.
La cardinalité 1,1(R) portée par la patte connectant COMMUNE et COM_DEP se lit : la commune C est identifiée relativement au département D, ce qui veut dire qu’au stade SQL, la clé primaire de la table COMMUNE sera la paire {departementId, communeId}. En plus, l’identification relative a donné lieu à une composition UML.
Utiliser des propriétés naturelles (par exemple Commune) pour les clés primaires a causé des ravages dans le passé et ça n’est pas fini. L’attribut CommuneId du MCD (ou idCommune, peu importe le mode de nommage) est artificiel, et donnera lieu en SQL à la clé primaire de la table COMMUNE, tandis que le code de la commune (communeCodeInsee ci-dessus) fera l’objet d’une clé alternative (contrainte "UNIQUE" en SQL). L’attribut communeId étant artificiel, il s’en suit qu’il ne doit avoir aucune valeur sémantique, il est donc invariant et garantit la validité des liens entre les tables SQL (clés étrangères référençant les clés primaires). Les valeurs des identifiants artificiels n’ont pas à être utilisées par les applications, lesquelles, pour accéder aux données useront des clés alternatives telles que {departementNumero}, {communeCodeInsee}, {lieuCode}, etc.Citation:
Envoyé par passant13
Dans les diagrammes ci-dessus, un lieu détermine une commune, ce qui n’interdit aucunement que le même nom de lieu existe pour deux communes différentes. Exemple :Citation:
Envoyé par passant13
Les attributs soulignés sont les éléments de la clé primaire des tables.COMMUNE {departementId communeId communeCodeInsee ...} 5 1 30189 ... 5 4 30028 ... LIEU {departementId communeId lieuId lieuCode lieuNom ...} 5 1 1 C0041 Canet ... 5 4 1 C0178 Canet ...
Il faut faire disparaître l’attribut #Commune de la classe Lieu, il sera accessible en SQL par une requête de jointure entre les tables COMMUNE et lieu. Exemple :Citation:
Envoyé par passant13
Vous observerez qu’on ne se sert absolument pas des valeurs des attributs artificiels departementId, communeId, on n’utilise que les valeurs des attributs naturels (lieuCode dans cet exemple).SELECT communeCodeInsee FROM LIEU AS x JOIN COMMUNE AS y ON x.departementId = y.departementId AND x.communeId = y.communeId WHERE lieuCode = 'C0041' ;
En passant, à partir de cette de cette requête vous pouvez concevoir une vue SQL (qui n’est jamais qu’une table virtuelle) :
On obtient le résultat en accédant à la vue :CREATE VIEW LIEU_COMMUNE (communeCodeInsee, lieuCode, lieuNom) AS SELECT communeCodeInsee, lieuCode, lieuNom FROM LIEU AS x JOIN COMMUNE AS y ON x.departementId = y.departementId AND x.communeId = y.communeId ;
L’emploi des vues plutôt que des tables devrait vous faciliter la vie pour les formulaires et compagnie.SELECT communeCodeInsee FROM LIEU_COMMUNE WHERE lieuCode = 'C0041' ;
On reviendra plus tard sur l’histoire des sites Web.
Annexe :
Code SQL généré par Looping, hors Web (notez la présence de "UNIQUE")
CREATE TABLE DEPARTEMENT( departementId INTEGER, departementNumero VARCHAR(3) NOT NULL UNIQUE, departementNom VARCHAR(32) NOT NULL UNIQUE, PRIMARY KEY(departementId) ); CREATE TABLE COMMUNE( departementId INTEGER, communeId INTEGER, communeCodeInsee VARCHAR(6) NOT NULL UNIQUE, communeNom VARCHAR(48) NOT NULL, PRIMARY KEY(departementId, communeId), FOREIGN KEY(departementId) REFERENCES DEPARTEMENT(departementId) ); CREATE TABLE LIEU( departementId INTEGER, communeId INTEGER, lieuId INTEGER, lieuCode VARCHAR(8) NOT NULL UNIQUE, lieuNom VARCHAR(48) NOT NULL, PRIMARY KEY(departementId, communeId, lieuId), FOREIGN KEY(departementId, communeId) REFERENCES COMMUNE(departementId, communeId) ); CREATE TABLE HOTEL( hotelId INTEGER, hotelCode VARCHAR(8) NOT NULL UNIQUE, hotelNom VARCHAR(48) NOT NULL, departementId INTEGER NOT NULL, communeId INTEGER NOT NULL, lieuId INTEGER NOT NULL, PRIMARY KEY(hotelId), FOREIGN KEY(departementId, communeId, lieuId) REFERENCES LIEU(departementId, communeId, lieuId) );
A part merci je ne peux rien ajouter d'autre car il va me falloir un petit moment pour assimiler tout ca et faire des tests !
Je dispose de Looping mais j'ignorais qu'il pouvait produire le source SQL. Mes diagrammes viennent de StarUML qui me suffit car je travaille directement en UML.
Pour le problème de la table siteWeb, je reviens dès que j'ai digéré toutes ces infos :)
Cordialement.
Bonjour,
Modéliser directement en UML un schéma relationnel de base de données peut induire quelques difficultés en termes de conception, car le formalisme des diagrammes de classes UML n'a pas été conçu pour ça au départ.
L'époque où UML devait tout remplacer est révolue, et les concepteurs de bases de données reviennent de plus en plus vers une modélisation entité-association qui est parfaitement adaptée à la génération des modèles logiques de données et au code SQL qui va avec.
Bon courage pour votre projet : avec fsmrel, vous êtes entre de très bonnes mains ! :ccool:
Côté UML sur le site il y a aussi bouml,
je contribue à pgModeler (mySQLWorkbench pour PostgreSQL) qui est super chouette!
Voilà la solution retenue.
J'ai ajouté un identifiant à toutes les classes. En UML tout objet a un identifiant et souvent on l'omet en conception, mais c'est plus clair avec.
Pour les lieux j'ai retenu les clés primaires: Département(département) Commune(département, commune) et Lieu(département, commune, lieu)
C'est un peu lourd mais en effet ca marche.
Pour les sites Web le couple (département, commune) pour éviter les doublons.
Et un grand merci aux aidants. Et je suis en train de lire "Modélisation Conceptuelle des Données, une approche pragmatique" pour me perfectionner !
PS. Le système complet fait 19 tables et produit des fiches touristiques ou des cartes (genre carteslozere.free.fr). De quoi bien occuper ma retraite :)
Excellent choix ! :mouarf: Je plaisante ! Mais, en tout cas, n'hésitez pas à me dire ce que vous en avez pensé.Citation:
Envoyé par passant13
Bonne lecture !
