Envoyé par
kalix01
Le problème c'est que chez nous ici, il peut arriver que deux quartiers aient le même nom dans deux villes différentes. L'identification relative ne pose-t-il pas problème dans ce cas ?
Plutôt que de faire un exposé théorique, je préfère passer directement au niveau tabulaire concret et prendre un exemple. Ainsi, créons les tables VILLE et QUARTIER.
Code SQL (par exemple SQL Server, histoire de fixer les idées, où « séquentiel » et à remplacer par « IDENTITY ») :
CREATE TABLE VILLE
(
ville_id INT IDENTITY NOT NULL
, ville_nom VARCHAR(30) NOT NULL
, CONSTRAINT VILLE_PK PRIMARY KEY (ville_id)
) ;
Créons quelques villes :
INSERT INTO VILLE (ville_nom)
VALUES ('Londres'), ('Athènes'), ('Madrid')
Au résultat, où l’on voit qu’à ma demande (clause IDENTITY oblige) le SGBD s’est chargé d’affecter les valeurs pour la colonne ville_id :
VILLE {ville_id, ville_nom}
-------- ---------
1 Londres
2 Athènes
3 Madrid
Créons la table QUARTIER :
CREATE TABLE QUARTIER
(
ville_id INT NOT NULL
, quartier_id INT IDENTITY NOT NULL
, quartier_nom VARCHAR(30) NOT NULL
, CONSTRAINT QUARTIER_PK PRIMARY KEY (ville_id, quartier_id)
, CONSTRAINT QUARTIER_AK UNIQUE (ville_id, quartier_nom)
, CONSTRAINT QUARTIER_VILLE_FK FOREIGN KEY (ville_id)
REFERENCES VILLE (ville_id)
) ;
Créons quelques quartiers :
INSERT INTO QUARTIER (ville_id, quartier_nom)
SELECT (SELECT ville_id FROM VILLE WHERE ville_nom = 'Londres'), 'City'
;
INSERT INTO QUARTIER (ville_id, quartier_nom)
SELECT (SELECT ville_id FROM VILLE WHERE ville_nom = 'Londres'), 'Whitechapel'
;
INSERT INTO QUARTIER (ville_id, quartier_nom)
SELECT (SELECT ville_id FROM VILLE WHERE ville_nom = 'Londres'), 'Quartier Sud'
;
INSERT INTO QUARTIER (ville_id, quartier_nom)
SELECT (SELECT ville_id FROM VILLE WHERE ville_nom = 'Athènes'), 'Le Pirée'
;
INSERT INTO QUARTIER (ville_id, quartier_nom)
SELECT (SELECT ville_id FROM VILLE WHERE ville_nom = 'Athènes'), 'Acropole'
;
INSERT INTO QUARTIER (ville_id, quartier_nom)
SELECT (SELECT ville_id FROM VILLE WHERE ville_nom = 'Athènes'), 'Agora'
;
INSERT INTO QUARTIER (ville_id, quartier_nom)
SELECT (SELECT ville_id FROM VILLE WHERE ville_nom = 'Madrid'), 'Amande centrale'
;
INSERT INTO QUARTIER (ville_id, quartier_nom)
SELECT (SELECT ville_id FROM VILLE WHERE ville_nom = 'Madrid'), 'Quartier Sud'
;
Au résultat, où l’on voit qu’à nouveau (clause IDENTITY oblige) le SGBD s’est chargé d’affecter les valeurs pour la colonne quartier_id :
QUARTIER {Ville_id, quartier_id, quartier_nom}
------- ----------- ------------
1 1 City
1 2 Whitechapel
1 3 Quartier Sud
2 4 Le Pirée
2 5 Acropole
3 6 Agora
3 7 Amande centrale
3 8 Quartier Sud
La colonne quartier_id prend les valeurs successives 1, 2, 3, ..., 8, mais on va dire que c’est un hasard.
Moralité : Les villes de Londres et Madrid ont toutes deux un quartier 'Quartier Sud'. Clairement l'identification relative n’a posé aucun problème. Les valeurs prises par les colonnes IDENTITY ont été fournies par le SGBD sans que j’ai à m’en occuper. Ainsi, les colonnes ville_id et quartier_id correspondent à des données artificielles et leurs valeurs m’indiffèrent totalement, je sous-traite leur affectation au SGBD, et qui plus est, je ne mentionne jamais les valeurs affectées à ces colonnes dans les requêtes. Seules les colonnes correspondant à des données naturelles m’intéressent (le nom d’une personne, sa date de naissance, le nom d’une ville, celui d’un quartier, etc.), ce sont les seules colonnes dont je ferai mention des valeurs dans les requêtes.
Par ailleurs, une ville ne peut pas avoir deux quartiers ayant le même nom, d’où la clé alternative QUARTIER_AK (ville_id, quartier_nom) à ajouter à la main dans le MLD. Cette contrainte d’unicité n’est malheureusement pas déclarable au stade MCD.
Concernant l’invariance des clés primaires (donc des identifiants), voir le billet De l’invariance des clés primaires.
dois-je dupliquer la date d'effet dans l'entité-type HISTORIQUE_BAIL ?
Oui, chaque occurrence de cette entité-type doit avoir une date de début et une date de fin, puisque de la date de fin de l’occurrence Oi on ne peut pas systématiquement inférer la date de début de l’occurrence Oi+1.
Partager