Discussion :

[hbx360]

Bonjour,

Je suis en train de faire un MCD dans le cadre de ma formation et je voudrai savoir si mon MCD convient ou si il y a des choses à revoir.

Contexte :

C'est un site de vente de voiture qui mettra en relation par l'intermédiaire du propriétaire du site M. X des professionnels et des particulier.

M. X souhaiterait une plateforme permettant aux professionnels de mettre à disposition des voitures d’occasions sous forme d’annonce.

- Le site possédera une barre de recherche (marque, modèle, carburant, etc) et une liste d'annonce.
- Le particulier devra contacter M. X si il est intéressé par une voiture.
- Les professionnels ne pourront pas créer de compte par eux-mêmes ils enverront les info nécessaire Nom, prénom, Adresse mail, téléphone, siret.
- Chaque professionnel pourra avoir plusieurs garage avec nom, adresse, téléphone.
- Chaque garage pourra avoir aucune ou plusieurs annonces.
- Une annonce aura : photos, titre, description, année de mise en circulation, kilométrage, prix modèle, carburant.
- L'année, la marque, modèle ou carburant seront des listes déroulantes.

Là ou j'ai un doute c'est pour l'héritage et la connexion adresse civilité pour le garage.
Voilà merci pour votre aide.

Voici mon MCD :

[fsmrel]

Bonjour hbx360,

Observation E1

L’association DETENIR entre GARAGE et CIVILITE est louche. En effet, sauf l’adresse électronique et le téléphone, les attributs de CIVILITE ne concernent en rien les garages...


Observation E2

Pour le garage g1, via l’association DETENIR entre GARAGE et CIVILITE g1 détermine la civilité c1. Via les associations APPARTENIR et AVOIR, g1 peut déterminer la civilité c2, ce qui est fâcheux, c’est du trapèze sans filet.


Observation E3

L’entité-type CARACTERISTIQUE n’est porteuse d’aucune propriété naturelle : sémantiquement parlant, l’héritage dont elle est la source n’apporte rien. En plus il faudra programmer la contrainte XT.

Je regarderai tout ça de plus près, tandis que le Capitaine Escartefigue et Paprick auront certainement pas mal de choses à dire (si ce n'est déjà fait).

Par ailleurs, vous aurez à générer le code SQL correct de création des tables, aussi je vous engage vivement à utiliser l’excellent AGL Looping.

[fsmrel]

Quelles informations, quelles fonctionnalités perdriez-vous en supprimant l’association DETENIR entre GARAGE et CIVILITE ?

D’autre part, la cardinalité 1,N portée par l’association AVOIR fait que le tuple (ligne)

<estHomme='vrai', nom='Martin', prenom='Pierre', email='p.martin@machin.fr', telephone='0123456789'>

est applicable à plus d’un client, ce qui doit quand même être plutôt rare. Bref, quel inconvénient à rapatrier les attributs de CIVILITE dans CLIENT ?

[Paprick]

Bonjour,
En complément des remarques déjà formulées à juste titre par fsmrel, voici quelques points qui me paraissent discutables :

• Comme déjà noté, le choix de l'héritage autour de "Caractéristique" ne me parait pas judicieux : en effet, surtout avec la contrainte de partition XT, cela signifierait que le véhicule à soit des portes, soit une boite de vitesse, soit du Co2, soit... bref, toutes ces rubriques caractérisent un modèle de véhicule, je pense que le MCD gagnerait à être réalisé bien plus simplement en ce sens.
• Vouloir regrouper les nom, prénom, email et téléphone au sein d'une même classe d'entités concernant clients professionnels, particuliers et garages n'est pas forcément une bonne idée : en effet, le fait que certaines classes d'entités aient des rubriques similaires ne signifie pas forcément que ces rubriques doivent être regroupées... Le nom d'un garage n'a rien à voir avec le nom d'un client, même si les deux sont des noms. Y-a-t-il un intérêt à avoir toutes ces informations dans la même classe... j'en doute...
• Même doute pour la classe d'entités "Adresse"...

Bref, je pense que vous devriez réfléchir en termes d'entités présentes dans le SI (client, garage, annonce, ...) et simplifier considérablement votre MCD, même si vous aurez parfois l'impression (à tord) que certaines rubriques sont redondantes.
Petite curiosité personnelle : quel logiciel avez-vous utilisé pour réaliser ce MCD ? Je vois que vous pouvez utiliser plusieurs fois le même nom d'association... certes, avec ces cardinalités, elles ne génèreront pas de tables pour le schéma relationnel, mais cela reste tout de même cavalier...
Bonne continuation, et suivez attentivement les conseils de fsmrel.

[fsmrel]

quel logiciel avez-vous utilisé pour réaliser ce MCD ?

Il s’agit de JMerise, qui a rendu pas mal de services au niveau MCD, mais qui est défaillant lors de la génération SQL.
Vois par exemple JFreesoft dans le forum Merise.

[fsmrel]

Adresses :

hbx360, selon votre MCD, un client, qu’il soit professionnel ou particulier, habite au moins et au plus à une adresse. Soit.
Par ailleurs, à une adresse habite au moins un client : si c’est l’adresse d’un garage, il se peut effectivement qu’un professionnel (disons le patron du garage) y habite, ou encore un ou plusieurs particuliers, mais il se peut aussi qu’aucun client n’habite à l’adresse de ce garage : logiquement, la cardinalité 1,N de la patte connectant ADRESSE et HABITER doit devenir 0,N.

[hbx360]

Merci beaucoup à tout le monde pour votre aide je vais revoir mon MCD.
Oui c'est bien jMerise mais c'est vrai qu'il est limité.

[hbx360]

Suivant vos recommandation j'ai modifier mon MCD :



J'aurai quelques questionnements concernant :

- L'entité caractéristique :
J'ai fait l'héritage comme vue dans mon 1er MCD en me basant sur un exo qu'on avait fait. Comme sa ressemblais, je me suis dit que je pouvais faire pareil ; c'est l'entité composant (en haut à gauche).
Je vous montre la correction de celui-ci :



On voit qu'il y a un XT j'ai repris cette contrainte dans mon MCD.

Paprick dit :

Comme déjà noté, le choix de l'héritage autour de "Caractéristique" ne me parait pas judicieux : en effet, surtout avec la contrainte de partition XT, cela signifierait que le véhicule à soit des portes, soit une boite de vitesse, soit du Co2, soit... bref, toutes ces rubriques caractérisent un modèle de véhicule, je pense que le MCD gagnerait à être réalisé bien plus simplement en ce sens.

Dans composant c'est bien pareille n'a-t-on pas soit un processeur, soit un barette de RAM, etc.
Mais comme on parle d'un composant et qu'un ordinateur peut avoir 1 ou plusieurs composant sa me semblais logique ?
Parce que, si on avait tout mis dans composant, sa aurait voulu dire qu'un composant est constitué de plusieurs éléments et donc la cardinalité (1,N) du côté ordinateur n'aurait pas été bonne non ?
Sa voudrait dire que un ordinateur peut avoir 1 ou plusieurs composants qui sont eux-même constitués d'un processeur, carte, lecteur RAM etc qu'en pensez-vous ? Donc on pourrait avoir un ordinateur avec 2 lecteurs, 2 processeurs, 2 cartes mères, 2 carte PCI, etc ?

- Pour l'entité adresse je l'ai mis en entité car j'ai lu que sa pouvais évité d'avoir la même adresse est-ce judicieux ?
voir le cours https://sqlpro.developpez.com/cours/...tion/heritage/ ou il est dit :

Enfin, pour résoudre la problématique des adresses multiples, rien ne nous empêche d'externaliser les adresses dans une table à part :

- Concernant les cardinalités je rencontre des difficultés car c'est suivant notre interprétation. Ex : un propriétaire peut avoir 1 ou plusieurs chien mais un chien peut avoir un seul et un seul propriétaire, mais on pourrait le voir aussi de cette façon : un chien peut avoir un ou plusieurs propriétaires dans sa vie. Donc comment savoir quel cardinalité mettre ? Si on parle de propriétaire il est naturellement évident qu'il à automatiquement un chien donc on à 1 en cardinalité on ne peut pas mettre 0 non ?

- Quand on dit une adresse peut avoir 0 ou plusieurs clients est-ce que sa veut dire qu'a la même adresse on a plusieurs client ? Ou bien cela veut-il dire que pour une infinité d'adresse on a une infinité de clients ?
J'ai du mal avec ce type d'association à bien savoir quoi mettre car pour moi j'aurai tendance à mettre 1 adresse = 1 client et un client = 1 adresse ce qui obligerait à tout mettre dans la même entité mais dans le même cours cité plus haut au chapitre 3 il mette en cardinalité : personne 0,N possède 0,N adresse.

- Si on doit mettre pour les associations un seul verbe comment on fait si on a plusieurs dizaine d'association ? Je trouve qu'on est assez limité en verbe non ?

[fsmrel]

Bonjour,

hbx360, la 2e version de votre MCD a l'air d'être correcte. Attention toutefois à la production du code SQL de création des tables, puisque JMerise est souvent défaillant à ce stade. Prenez calmement le temps de reprendre ça avec Looping, histoire de vous rassurer, dans la série ceinture, bretelles et épingle à nourrice...

Je ne reprends pas ici tout ce que écrivez dans votre post, mais je fais quand même une mise au point quant aux cardinalités, sources de certaines difficultés pour vous. Je vous cite :

Concernant les cardinalités je rencontre des difficultés car c'est suivant notre interprétation. Ex : un propriétaire peut avoir 1 ou plusieurs chien mais un chien peut avoir un seul et un seul propriétaire, mais on pourrait le voir aussi de cette façon : un chien peut avoir un ou plusieurs propriétaires dans sa vie. Donc comment savoir quel cardinalité mettre ? Si on parle de propriétaire il est naturellement évident qu'il à automatiquement un chien donc on à 1 en cardinalité on ne peut pas mettre 0 non ?

Dans cet exemple, puisqu’un chien a pu avoir plus d’un maître dans sa vie, il faut prendre en compte la dimension temporelle. D’une façon générale, on sépare la partie historique (DEPUIS telle date le toutou a tel maître, et auparavant, DURANT telle période, il a eu tel maître). Je détaille ce distinguo DEPUIS / DURANT dans le paragraphe 6.4 « Données actives et données historisées » de mon article Bases de données relationnelles et normalisation : de la première à la sixième forme normale.

En admettant les règles de gestion suivantes :

RG01 : à une date donnée un toutou a exactement (c’est-à-dire au moins et plus) un maître ;

RG02 : à une date donnée un maître peut avoir plusieurs toutous (il peut hélas ne plus en avoir, c’est la vie...) ;

Le MCD correspondant est le suivant, avec une CIF (contrainte d’intégrité fonctionnelle) exprimant la contrainte d’unicité de la règle RG01 (en notant par ailleurs qu’un maître peut ne plus posséder de toutou) :

Génération SQL par Looping (notez la clé primaire de la table POSSEDER) :

CREATE TABLE LA_DATE
(
   laDate DATE,
   CONSTRAINT LA_DATE_PK PRIMARY KEY(laDate)
);

CREATE TABLE TOUTOU
(
   toutouId INT,
   CONSTRAINT TOUTOU_PK PRIMARY KEY(toutouId)
);

CREATE TABLE MAITRE
(
   maitreId INT,
   CONSTRAINT MAITRE_PK PRIMARY KEY(maitreId)
);

CREATE TABLE POSSEDER(
   toutouId INT,
   laDate DATE,
   maitreId INT NOT NULL,
   CONSTRAINT POSSEDER_PK PRIMARY KEY(toutouId, laDate),
   CONSTRAINT POSSEDER_DATE_FK FOREIGN KEY(laDate) REFERENCES LA_DATE(laDate),
   CONSTRAINT POSSEDER_TOUTOU_FK FOREIGN KEY(toutouId) REFERENCES TOUTOU(toutouId),
   CONSTRAINT POSSEDER_MAITRE_FK FOREIGN KEY(maitreId) REFERENCES MAITRE(maitreId)
; 

Ce code SQL est une conséquence du MCD merisien, dans lequel je n’ai pas fait le distinguo traité dans mon article, ce dont on peut se dispenser ici.

Sinon, si l’on tient à mettre le passé en évidence pour un toutou qui a son maître à lui :

code SQL généré par Looping :

CREATE TABLE MAITRE
(
   maitreId INT,
   CONSTRAINT MAITRE_PK PRIMARY KEY(maitreId)
);

CREATE TABLE TOUTOU
(
   toutouId INT,
   maitreId INT NOT NULL,
   CONSTRAINT TOUTOU_PK PRIMARY KEY(toutouId),
   CONSTRAINT TOUTOU_MAITRE_FK FOREIGN KEY(maitreId) REFERENCES MAITRE(maitreId)
);

CREATE TABLE JADIS
(
   toutouId INT,
   dateDebut DATE,
   dateFin DATE NOT NULL,
   maitreId INT NOT NULL,
   CONSTRAINT JADIS_PK PRIMARY KEY(toutouId, dateDebut),
   CONSTRAINT JADIS_TOUTOU_FK FOREIGN KEY(toutouId) REFERENCES TOUTOU(toutouId),
   CONSTRAINT JADIS_MAITRE_FK FOREIGN KEY(maitreId) REFERENCES MAITRE(maitreId)
);

Il y a pas mal à dire quant aux périodes, car le type correspondant n’est guère disponible qu’avec PostgreSQL, mais bon...

[hbx360]

Merci pour ta réponse fsmrel.
Comme c'est ok pour mon MCD alors je vais passer par looping car effectivement si je ne prends pas la version payante de jMerise je vais être très limité.
J'aurai tout à refaire mais bon pas grave.

[fsmrel]

Bonjour hbx360,

Tout à refaire, soit, mais le jeu en vaut la chandelle. Et puis si vous rencontrez des difficultés, vous pouvez toujours compter sur l'aide de Paprick, celle du Capitaine Escartefigue et la mienne.

Bonne route !

[Paprick]

Bonjour,

J'aurai tout à refaire mais bon pas grave.

Rassurez-vous, la reprise de votre MCD sous Looping ne devrait vous prendre que quelques dizaines de minutes, qui seront largement rentabilisées lors du passage au MLD et aux requêtes SQL de création de la base de données.

Bonne continuation !

[fsmrel]

Bonsoir,

hbx360, une partie qui reste à éclaircir...

Quand on dit qu’une adresse peut avoir 0 ou plusieurs clients est-ce que ça veut dire qu'à la même adresse on a plusieurs clients ?

Cela veut dire qu’à une adresse donnée, disons a1, à n’importe quel moment, peuvent résider 0 client, 1 ou 2 ou 3 ou N clients. La liste de ces clients peut évoluer dans le temps, du fait des changements d’adresse des clients, de la prise en compte de nouveaux clients, de leur suppression, etc.

Exemple, situation à la date t1

ADRESSE
idAdresse
a1
a2
a3
a4
a5
a6
a7

CLIENT
idClient    idAdresse  
c1          a5 
c2          a2
c3          a1
c4          a2
c5          a6
c6          a5
c7          a2
c8          a6
c9          a4

Dans cet instantané pris à la date t1, on constate que seul le client c3 réside à l’adresse a1, 3 clients résident à l’adresse a2, aucun client ne réside à l’adresse a3, seul le client c9 réside à l’adresse a4, 2 clients résident à l’adresse a5, 2 clients résident à l’adresse a6, aucun client ne réside à l’adresse a7.

Ou bien cela veut-il dire que pour une infinité d'adresses on a une infinité de clients ?

Pour une infinité d’adresses, à la date t, on peut avoir 0 client, 1 client, 2 client, une infinité de clients (si tant est que le terme « infinité » ait ici un sens...) On sort du contexte de Merise et de celui du modèle relationnel de données pour entrer dans celui de la théorie des ensembles, voyez à cette occasion l’exemple de l’Hôtel de Hilbert, hôtel hébergeant une infinité de clients, tandis qu’arrive un car bourré d’une infinité de nouveaux clients à héberger eux aussi).

J'ai du mal avec ce type d'association à bien savoir quoi mettre

A propos des règles de gestion des données

L’essentiel est de commencer par rédiger les règles de gestion des données de telle sorte qu’elles répondent de façon précise à ce veut l’utilisateur. Dans l’élaboration des MCD, c’est l’étape déterminante, celle dans laquelle il ne faut pas se rater et où il faut donc consacrer un maximum de rigueur et de temps.

(U1) Si pour l’utilisateur, la règle de gestion est

Un client peut ne pas avoir d’adresse, et s’il en a une, c’est au plus une

alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 0,1 :

[CLIENT]----0,1----(RESIDER)----

(U2) Si pour l’utilisateur, la règle de gestion est

Un client réside à au moins et au plus une adresse

alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 1,1 :

[CLIENT]----1,1----(RESIDER)----

(U3) Si pour l’utilisateur, la règle de gestion est

Un client peut ne pas avoir d’adresse, mais il peut très bien en avoir plusieurs

alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 0,N :

[CLIENT]----0,N----(RESIDER)----

(U4) Si pour l’utilisateur, la règle de gestion est

Un client a au moins une adresse et au plus plusieurs

alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 1,N :

[CLIENT]----1,N----(RESIDER)----

En les adaptant, ces règles de gestion ont leur pendant concernant la patte connectant l’entité-type CLIENT et l’association RESIDER.

Ainsi, il ne doit y avoir aucune ambiguïté quant aux règles de gestion des données et chaque cardinalité portée par une patte d’association doit nécessairement être la conséquence d’une règle.

Je vous engage à lire ce qu’écrivent D. Nanci (RIP) et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), au chapitre 7 (« Modélisation conceptuelle des données », paragraphe « Les cardinalités d’une entité type dans une relation type », pages 104 et suivantes.

j'aurai tendance à mettre 1 adresse = 1 client et un client = 1 adresse ce qui obligerait à tout mettre dans la même entité

Remontez impérativement aux règles de gestion. Dans votre cas, l’une d’elles doit explicitement préciser qu’un client réside à au moins et au plus une adresse et une autre règle doit explicitement préciser qu’à une adresse réside au moins et au plus un client. Ce qui implique la représentation merisienne :

[CLIENT]----1,1----(RESIDER)----1,1----[ADRESSE]

En l’occurrence, il y a une magnifique bijection, et si mathématiquement parlant il n’y a pas de problème, dans le contexte des bases de données relationnelles on doit être particulièrement vigilant car la bijection est très sournoise

Passons en effet au stade relationnel. L’usage veut qu’on mette en oeuvre des clés étrangères pour assurer la cohérence des références entre les tables issues des objets du MCD (entités-types et associations). Dans le cas de la bijection, les clés étrangères sont aussi efficaces que des cautères sur des jambes de bois. Elles n’empêchent pas des infractions comme celle-ci-dessous, bien que selon les règles (le règlement...), le client c3 réside seulement à l’adresse a1, qu’à l’adresse a1 ne réside que le seul client c3, que le client c9 réside seulement à l’adresse a4, et qu’à l’adresse a4 ne réside que le seul client c9 :

CLIENT                                 ADRESSE
+-----------+-----------+             +-----------+----------+
| idClient  | idAdresse |             | idAdresse | idClient |
|-----------+-----------|             |-----------+----------|
|       c3  |        a1 |             |        a1 |       c9 |
|       c9  |        a4 |             |        a4 |       c3 |
+-----------+---- ------+             +-- --------+----------+ 
 

La table CLIENT est conforme au règlement, mais la table ADRESSE est pourrie de tuples délinquants.

Et voilà pourquoi, prudence oblige, l’usage en SQL est que la table CLIENT absorbe la table ADRESSE, même principe au stade MCD, les propriétés de l’entité-type ADRESSE sont évacuées dans l’entité-type CLIENT et cette entité-type ADRESSE disparaît du MCD. De loin ça ressemble à la fusion (coalescence) de deux trous noirs, à ceci près que la fusion d’entités-types ne donne quand même pas lieu à l’émission d’ondes gravitationnelles...

Dans le cadre du modèle relationnel de données, contrairement aux SGBD de type SQL, on n’éprouve aucunement le besoin pressant de fusionner les structures des tables (pardon, des variables relationnelles), la bijection ne pose pas de problème, il suffit de déclarer une contrainte remplaçant les clés étrangères inefficaces et bonnes pour la poubelle :

CONSTRAINT RESIDER_CHK01
        CLIENT {idClient, idAdresse} = ADRESSE {idClient, idAdresse} ; 

Pour en savoir un peu plus, voyez mon billet « Merise : cardinalités 1,1 ---- 1,1 => intégrité référentielle = cautère sur jambe de bois  », ainsi que les commentaires qu’en fait CinePhil.

dans le même cours cité plus haut au chapitre 3 il met en cardinalité : personne 0,N possède 0,N adresse.

Je n’ai pas lu ce cours, mais les cardinalités mentionnées doivent être impliquées par les règles de gestion :

RGx - Un client peut avoir plusieurs adresses (et il est possible qu’il n’en ait aucune) ;

RGy - A une adresse donnée on peut avoir plusieurs clients (et il est possible qu’il n’y ait personne).

[fsmrel]

Bonsoir à nouveau,

Si on doit mettre pour les associations un seul verbe comment on fait si on a plusieurs dizaine d'association ? Je trouve qu'on est assez limité en verbe non ?

L’utilisation par le concepteur d’un même nom pour deux associations rend pénible le travail du relecteur ou de celui qui analyse les MCD, sans parler de la tâche de l’AGL chargé par exemple de produire le code SQL. Evidemment si de manière naturelle le verbe « avoir » a tendance à proliférer, et une fois qu’on a usé des synonymes « appartenir », « posséder », « détenir », « contenir », comme disait Béru, « comment est-ce que fait-on ensuite ? » Investir dans un gros dictionnaire des synonymes ? Remplacer à l’occasion un verbe par le substantif qui va bien (« possession », « détention », etc.) Evidemment on cherchera plutôt à utiliser des verbes qui se trouvent souvent plus appropriés au plan sémantique, mais la panne sèche peut quand même se produire, et le découragement à force de tourner en rond. Quand je sèche ou suis pris par le temps, quitte à me faire incendier par les merisiens purs et durs, je n’y vais pas par quatre chemins, comme ici, où fleurissent les doux noms d’associations tels que PFC_P, PFC_C, PFC_V, etc. et que vous ne trouverez pas dans les dictionnaires.

[hbx360]

@fsmrel : merci beaucoup pour ton aide et tes conseils et le temps que tu as passé à me répondre c'est beaucoup plus compréhensible maintenant.

@Paprick : oui je vais y faire tranquillement.

[fsmrel]

Merci hbx360, et n'oubliez pas de liker les posts qui ont pu vous éclairer...

[hbx360]

J'aurai une autre question, j'ai vue sur certain MCD cette façon de faire :

Une table annonce lié à un modèle puis le modèle lié à la marque, mais pourquoi on ne pourrai pas inversé marque et modèle, sa me semble plus juste non ? Parce qu'il se pourrait qu'il y est plusieurs modèle identique de plusieurs marque ?

Je vois sur cette image :
que le quartier est lié au logement, mais idem si il y a plusieurs quartier qui porte le même nom dans plusieurs commune différentes sa pose problème non ? Je trouve plus logique de faire l'inverse, même si un logement est d'abord situé dans un quartier puis le quartier dans la commune.

Si vous pouviez m'éclairer à ce sujet.

Serait-il possible par rapport à mon schéma

de relié modèle et marque ensemble pour plus de cohérence, voir même de mettre comme dit plus haut, lié le modèle à la marque et la marque à l'annonce.

Merci par avance

[fsmrel]

Bonsoir hbx360,

Dès qu’il y a la notion de quartier, un logement ne peut appartenir à une commune que transitivement via un quartier.

Il est évident que deux quartiers de deux communes différentes peuvent avoir le même nom, tout comme deux personnes de deux familles différentes peuvent avoir le même prénom.

Par contre, que dans la même commune deux quartiers aient le même nom n’est pas possible.

Preuve par SQL :

CREATE TABLE COMMUNE
(
   communeId INT,
   communeNom VARCHAR(48) NOT NULL,
   CONSTRAINT COMMUNE_PK PRIMARY KEY(communeId)
);

CREATE TABLE QUARTIER

(
   quartierId INT,
   quartierNom VARCHAR(48) NOT NULL,
   communeId INT NOT NULL,
   CONSTRAINT QUARTIER_PK PRIMARY KEY(quartierId),
   CONSTRAINT QUARTIER_COMMUNE_FK FOREIGN KEY(communeId) 
       REFERENCES COMMUNE(communeId)
 , CONSTRAINT QUARTIER_UK UNIQUE (communeId,quartierNom),
);


CREATE TABLE LOGEMENT(
   logemenId INT,
   numero VARCHAR(8) NOT NULL,
   rue VARCHAR(48) NOT NULL,
   quartierId INT NOT NULL,
   CONSTRAINT LOGEMENT_PK PRIMARY KEY(logemenId),
   CONSTRAINT LOGEMENT_QUARTIER_FK FOREIGN KEY(quartierId) 
       REFERENCES QUARTIER(quartierId)
);

INSERT INTO COMMUNE (CommuneId, communeNom)
VALUES
    (1, 'Trifoully')
  , (2, 'Monluc')
;
SELECT * FROM COMMUNE ;

INSERT INTO QUARTIER (communeId, quartierId, quartierNom)
values
    (1, 1, 'Q1')
  , (1, 2, 'Q2')
  , (1, 3, 'Q3')
  , (1, 4, 'Q1')   -- Rejeté par SQL du fait de la contrainte QUARTIER_UK  
  , (2, 5, 'Q1')   -- Ok, deux communes peuvent avoir des quartiers ayant même nom 
  ;

SELECT * FROM QUARTIER ;

INSERT INTO LOGEMENT (logemenId, numero, rue, quartierId)
values
  (1, '57 bis', 'rue en pente', 1)
;
SELECT * FROM LOGEMENT ;

=>

communeId   communeNom

1           Trifoully
2           Monluc

quartierId  quartierNom   communeId

1           Q1            1
2           Q2            1
3           Q3            1
5           Q1            2

logemenId   numero   rue            quartierId

1           57 bis   rue en pente   1

Les communes 1 et 2 ont légalement et légitimement toutes les deux un quartier nommé Q1.

Pour les marques et les modèles, même principe.

[fsmrel]

Cas des annonces, marques et modèles :

Bien que ce ne soit pas une nécessité, il n’est pas mauvais d’identifier MODELE relativement à MARQUE (connaissance directe de marqueId dans ANNONCE).

En supposant que deux marques distinctes puissent avoir des modèles ayant le même nom (sinon, l’attribut modeleNom devra faire l’objet d’un identifiant alternatif de MODELE) :

CREATE TABLE MARQUE
(
   marqueId INT,
   marqueNom VARCHAR(48) NOT NULL,
   CONSTRAINT MARQUE_PK PRIMARY KEY(marqueId)
);

CREATE TABLE MODELE
(
   marqueId INT,
   modeleId INT,
   modeleNom VARCHAR(48) NOT NULL,
   CONSTRAINT MODELE_PK PRIMARY KEY(marqueId, modeleId),
   CONSTRAINT MODELE_MARQUE_FK FOREIGN KEY(marqueId) 
       REFERENCES MARQUE(marqueId),
  -------------  CONSTRAINT MODELE_UK UNIQUE(marqueId, modeleNom),
);

CREATE TABLE ANNONCE
(
   annonceId INT,
   marqueId INT,
   modeleId INT NOT NULL,
   description VARCHAR(48) NOT NULL,
   CONSTRAINT ANNONCE_PK PRIMARY KEY(annonceId),
   CONSTRAINT ANNONCE_MODELE_FK FOREIGN KEY(marqueId, modeleId) 
       REFERENCES MODELE(marqueId, modeleId)
);

INSERT INTO MARQUE (marqueId, marqueNom)
VALUES
    (1, 'Marque 1')
  , (2, 'Marque 2')
;
SELECT * FROM MARQUE ;

INSERT INTO MODELE (marqueId, modeleId, modeleNom)
VALUES
    (1, 1, 'M1')
  , (1, 2, 'M2')
  , (1, 3, 'M3') 
---------  , (2, 1, 'M1')   -- Ok, deux marques peuvent avoir des modèles ayant même nom
 , (2, 1, 'M4') 
;
SELECT * FROM MODELE ;

INSERT INTO ANNONCE (annonceId, marqueId, modeleId, description)
VALUES
  (1, 1, 1, 'occasion à saisir')
;
SELECT * FROM ANNONCE 
;

=>

marqueId    marqueNom

1           Marque 1
2           Marque 2

marqueId    modeleId    modeleNom

1           1           M1
1           2           M2
1           3           M3
2           1           M4

annonceId   marqueId    modeleId    description

1           1           1           occasion à saisir 

[hbx360]

Merci pour tes explications fsmrel