Discussion :

[BlueBeery]

Re bonjour,
Pour le plus grand plaisir de certain (enfin j'espère), j'utilise enfin looping ! Cela me permettra de rapidement déployer une maquette de ma base de données sous microsoft acces une fois le schéma propre
Bien que la prise en main soit intuitive, j'ai quelque doute sur la différence entre certains termes :
Entité : nom / nom logique
Rubrique : nom conceptuel / nom logique

[fsmrel]

j'utilise enfin looping !

Certain plussoie

[escartefigue]

Vous allez aimer looping, c'est un excellent produit

Le nom conceptuel est le nom choisi pour le MCD, par défaut c'est ce nom qui s'applique également aux objets base de données (tables, colonnes).
Le nom logique permet, si on le souhaite, d'affecter d'autres noms aux objets base de données que le nom conceptuel.

[BlueBeery]

Bonjour,
Je viens de transposer la partie Bâtiment du mcd sous looping :



code sql :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
CREATE TABLE GROUPE_SOCIETE(
   groupe_societe_Id INT,
   PRIMARY KEY(groupe_societe_Id)
);

CREATE TABLE TYPE_PIECE(
   type_piece_Id INT,
   liste_type_piece VARCHAR(50) NOT NULL,
   PRIMARY KEY(type_piece_Id),
   UNIQUE(liste_type_piece)
);

CREATE TABLE CONTRAINTE_PIECE(
   contrainte_piece_Id INT,
   liste_con_piece VARCHAR(50) NOT NULL,
   PRIMARY KEY(contrainte_piece_Id),
   UNIQUE(liste_con_piece)
);

CREATE TABLE CONTRAINTE_BATIMENT(
   contrainte_batiment_Id INT,
   liste_con_bat VARCHAR(50) NOT NULL,
   PRIMARY KEY(contrainte_batiment_Id),
   UNIQUE(liste_con_bat)
);

CREATE TABLE TYPE_SITE(
   type_site_Id INT,
   liste_type_site VARCHAR(50) NOT NULL,
   PRIMARY KEY(type_site_Id),
   UNIQUE(liste_type_site)
);

CREATE TABLE CONTRAINTE_SITE(
   contrainte_site_Id INT,
   liste_contrainte_site VARCHAR(50) NOT NULL,
   PRIMARY KEY(contrainte_site_Id),
   UNIQUE(liste_contrainte_site)
);

CREATE TABLE ADRESSE(
   adresse_Id INT,
   pays VARCHAR(50) NOT NULL,
   ville VARCHAR(50) NOT NULL,
   code_postal INT NOT NULL,
   adresse VARCHAR(50),
   PRIMARY KEY(adresse_Id)
);

CREATE TABLE SITE(
   site_Id INT,
   nom_site VARCHAR(50) NOT NULL,
   desc_site TEXT,
   adresse_Id INT NOT NULL,
   PRIMARY KEY(site_Id),
   UNIQUE(nom_site),
   FOREIGN KEY(adresse_Id) REFERENCES ADRESSE(adresse_Id)
);

CREATE TABLE BATIMENT(
   batiment_id INT,
   description_batiment TEXT,
   adresse_Id INT NOT NULL,
   site_Id INT,
   PRIMARY KEY(batiment_id),
   FOREIGN KEY(adresse_Id) REFERENCES ADRESSE(adresse_Id),
   FOREIGN KEY(site_Id) REFERENCES SITE(site_Id)
);

CREATE TABLE ETAGE(
   batiment_id INT,
   etage_Id INT,
   numero INT NOT NULL,
   PRIMARY KEY(batiment_id, etage_Id),
   FOREIGN KEY(batiment_id) REFERENCES BATIMENT(batiment_id)
);

CREATE TABLE PIECE(
   batiment_id INT,
   etage_Id INT,
   piece_Id INT,
   PRIMARY KEY(batiment_id, etage_Id, piece_Id),
   FOREIGN KEY(batiment_id, etage_Id) REFERENCES ETAGE(batiment_id, etage_Id)
);

CREATE TABLE BATIMENT_SOCIETE(
   batiment_id INT,
   groupe_societe_Id INT,
   PRIMARY KEY(batiment_id, groupe_societe_Id),
   FOREIGN KEY(batiment_id) REFERENCES BATIMENT(batiment_id),
   FOREIGN KEY(groupe_societe_Id) REFERENCES GROUPE_SOCIETE(groupe_societe_Id)
);

CREATE TABLE SITE_SOC(
   site_Id INT,
   groupe_societe_Id INT,
   PRIMARY KEY(site_Id, groupe_societe_Id),
   FOREIGN KEY(site_Id) REFERENCES SITE(site_Id),
   FOREIGN KEY(groupe_societe_Id) REFERENCES GROUPE_SOCIETE(groupe_societe_Id)
);

CREATE TABLE PIECE_TYPE(
   batiment_id INT,
   etage_Id INT,
   piece_Id INT,
   type_piece_Id INT,
   DESC_PIECE TEXT,
   PRIMARY KEY(batiment_id, etage_Id, piece_Id, type_piece_Id),
   FOREIGN KEY(batiment_id, etage_Id, piece_Id) REFERENCES PIECE(batiment_id, etage_Id, piece_Id),
   FOREIGN KEY(type_piece_Id) REFERENCES TYPE_PIECE(type_piece_Id)
);

CREATE TABLE PIECE_CONTRAINTE(
   batiment_id INT,
   etage_Id INT,
   piece_Id INT,
   contrainte_piece_Id INT,
   description_contrainte_piece TEXT,
   PRIMARY KEY(batiment_id, etage_Id, piece_Id, contrainte_piece_Id),
   FOREIGN KEY(batiment_id, etage_Id, piece_Id) REFERENCES PIECE(batiment_id, etage_Id, piece_Id),
   FOREIGN KEY(contrainte_piece_Id) REFERENCES CONTRAINTE_PIECE(contrainte_piece_Id)
);

CREATE TABLE BAT_CON(
   batiment_id INT,
   contrainte_batiment_Id INT,
   DESC_CON_BAT TEXT,
   PRIMARY KEY(batiment_id, contrainte_batiment_Id),
   FOREIGN KEY(batiment_id) REFERENCES BATIMENT(batiment_id),
   FOREIGN KEY(contrainte_batiment_Id) REFERENCES CONTRAINTE_BATIMENT(contrainte_batiment_Id)
);

CREATE TABLE SITE_TYPE(
   site_Id INT,
   type_site_Id INT,
   PRIMARY KEY(site_Id, type_site_Id),
   FOREIGN KEY(site_Id) REFERENCES SITE(site_Id),
   FOREIGN KEY(type_site_Id) REFERENCES TYPE_SITE(type_site_Id)
);

CREATE TABLE SITE_CONTRAINTE(
   site_Id INT,
   contrainte_site_Id INT,
   desc_con_site TEXT,
   PRIMARY KEY(site_Id, contrainte_site_Id),
   FOREIGN KEY(site_Id) REFERENCES SITE(site_Id),
   FOREIGN KEY(contrainte_site_Id) REFERENCES CONTRAINTE_SITE(contrainte_site_Id)
);

J'ai aussi réaliser une exportation du code SQL sur Acces, me permettant de pouvoir tester la mise en place de mes 1er écrans (mais c'est une autre histoire).

[escartefigue]

Bonjour,

il y a une inversion des cardinalités entre site et adresse et l'adresse peut être identifiée relativement au site.

Les typologies (type de pièces, type de sites) sont ici associées plusieurs fois à leur entité-type de rattachement, c'est possible mais pas le plus courant.
Une pièce peut vraiment être de plusieurs types ? (des exemples de typologie aideraient à la compréhension sur ce point)

[BlueBeery]

il y a une inversion des cardinalités entre site et adresse

Un site à une adresse / une adresse réfère de 0 à n site.

Il est vrai que le fait qu'une adresse puisse référer à plusieurs sites, c'est bizarre, je vais mettre une adresse réfère de 0 à 1 site. Cependant je ne vois pas où j'ai inversé la cardinalité (un site étant un regroupement de bâtiment, leurs existences n'est pas nécessaires à celle de bâtiment).

Il est vrai que cela est un peu confus ! Donc je propose quelques modifications :

Un GROUPE/SOCIETE possède de 1 à n SITE / un SITE réfère de 1 à n SOCIETE
Un SITE possède de 0 à n BATIMENT / un BATIMENT appartient à 1 SITE. Et ajouter une identification relative de BATIMENT envers SITE.
un SITE possède 1 ADRESSE / une ADRESSE réfère de 0 à 1 SITE.
un BATIMENT possède 1 ADRESSE / une ADRESSE réfère de 0 à 1 BATIMENT.
un BATIMENT appartient de 1 à 0 SOCIETE / SOCIETE possède de 0 à n BATIMENT

Dans le cas où l'on voudrait juste donner une adresse à 1 élément de GROUPE/SOCIETE, on lui associe 1 site avec 1 adresse sans bâtiment. Par la suite il devient alors simple de rajouter des bâtiments au site si besoin.



Je me demande alors si il n'y pas moyen de supprimer la liaison entre SOCIETE et BATIMENT ? (mais je vois pas comment m'y prendre vu qu'un bâtiment peut accueillir plusieurs sociétés ... même problème pour étage, dans mon modèle on sait à quel bâtiment appartient un étage mais pas à quelle société )

Les typologies (type de pièces, type de sites) sont ici associées plusieurs fois à leur entité-type de rattachement, c'est possible mais pas le plus courant.
Une pièce peut vraiment être de plusieurs types ? (des exemples de typologie aideraient à la compréhension sur ce point)

Il faut que j'en discute avec les utilisateurs finaux !

[escartefigue]

Il faut que les cardinalités correspondent aux règles de gestion validées par le donneur d'ordre, si c'est bien le cas, c'est parfait.

Si validé, il faudra alors ajouter une contrainte d'exclusion entre les deux associations pour montrer que l'adresse se rapporte soit à un site, soit à un bâtiment, mais pas aux deux.

[escartefigue]

Je reviens sur un point sémantique

Un GROUPE/SOCIETE possède de 1 à n SITE / un SITE réfère de 1 à n SOCIETE
[...]
Je me demande alors si il n'y pas moyen de supprimer la liaison entre SOCIETE et BATIMENT ? (mais je vois pas comment m'y prendre vu qu'un bâtiment peut accueillir plusieurs sociétés ... même problème pour étage, dans mon modèle on sait à quel bâtiment appartient un étage mais pas à quelle société )
Il faut que j'en discute avec les utilisateurs finaux !

Il faudra surtout bien distinguer l'appartenance de la simple occupation.
Si un étage appartient alors l'appartenance est définie à ce niveau
Si un étage est occupé par une société, mais qu'il appartient à celle à qui appartient le site et le bâtiment, alors tout va bien (il s'agit alors d'une simple location, voire, d'une occupation à titre gratuit)
Il faut donc bien distinguer qui est propriétaire et qui est occupant de tel ou tel lieu (site, bâtiment, étage, voire pièce peut-être)

[BlueBeery]

Je reviens sur un point sémantique

Il faudra surtout bien distinguer l'appartenance de la simple occupation.
Si un étage appartient alors l'appartenance est définie à ce niveau
Si un étage est occupé par une société, mais qu'il appartient à celle à qui appartient le site et le bâtiment, alors tout va bien (il s'agit alors d'une simple location, voire, d'une occupation à titre gratuit)
Il faut donc bien distinguer qui est propriétaire et qui est occupant de tel ou tel lieu (site, bâtiment, étage, voire pièce peut-être)

Je vois où vous voulez en venir, mais je pense que c'est pousser trop loin la modélisation, le but étant de savoir qui/quoi est où !

Voici mon dernier MCD pour Bâtiment :



Je pense qi'il va y avoir une histoire de contrainte : Pour qu'une société est un bâtiment sur un site, il faut qu'elle appartienne déjà au site où est le bâtiment (même histoire pour étage).

[escartefigue]

Bonjour Bluebeery

Je vois où vous voulez en venir, mais je pense que c'est pousser trop loin la modélisation, le but étant de savoir qui/quoi est où !
Je pense qi'il va y avoir une histoire de contrainte : Pour qu'une société est un bâtiment sur un site, il faut qu'elle appartienne déjà au site où est le bâtiment (même histoire pour étage).

Je ne veux en venir à rien, je souhaite comprendre à quoi on s'intéresse : à la localisation des sociétés dans les pièces, étages, bâtiments et sites ou à la possession de ces mêmes lieux.
Car ici vous dites que vous souhaitez savoir qui / quoi est où (donc être locataire répond à cette question), mais plus haut dans le fil de discussion, vos règles de gestion utilisaient le terme "posséder". C'est pourquoi je pose cette question, selon le cas vous aurez à modéliser des choses sans doute différentes. Peut-être les deux notions sont elles requises, peut-être une seule.

À préciser.

[BlueBeery]

J'ai en effet mal choisi certains termes (c'est corrigé sur le dernier mcd), seul la localisation m'importe, pas la possession

[escartefigue]

En ce cas, la localisation doit être modélisée au niveau le plus fin : la pièce.
Si une société est localisée dans la pièce, elle est forcément également localisée dans l'étage, le bâtiment et le site d'appartenance de ladite pièce
Et ça permet à plusieurs sociétés de cohabiter dans un même étage, un même bâtiment ou un même site.

[BlueBeery]

Mettre la localisation au niveau le plus fin => cad mettre l'adresse ADRESSE en relation avec PIECE ?. Je comprends l'idée d'inclusion qui en découle, mais :
- Je peux par exemple, ne renseigner q'un site pour une société (le cas d'un fournisseur), donc mettre ADRESSE en relation avec SITE et PIECE ?
- Lors de la création de plusieurs pièces, je vais donc devoir pour chaque pièce renseigner l'adresse ?

[escartefigue]

L'adresse ou plutôt les adresses c'est autre chose.
Chaque établissement (SIRET) peut avoir des adresses de différents types : adresse géographique, adresse de facturation, de livraison, du service contentieux etc.
Ensuite, à une même adresse, il peut y avoir plusieurs entreprises qui partagent le même bâtiment, mais certains bureaux sont occupés par telle ou telle entreprise.
Si on veut savoir quel bureau est occupé par quelle entreprise, il faut établir un lien entre entreprise et bureau (ou pièce).
Si on veut uniquement connaître les différentes adresses que j'ai citées ci-dessus, on n'a pas besoin de gérer l'affectation des pièces.

[BlueBeery]

Concernant les adresses, je me limite dans un premier temps à l'adresse géographique (je verrai dans un second temps avec les utilisateurs finaux s'ils ont besoin de plus de précision).
Ainsi, je veux savoir pour une société X :
- Au minimum, celle-ci a un site avec une adresse.
- Si celle-ci est cliente, alors elle possède de l'équipement que j'ai installé chez elle. Ainsi, je veux connaître dans quel(s) batiment(s), quel(s) étage(s) et quelle(s) pièce(s) sont ces équipements pour la société X.

je propose ainsi le nouveau MCD :



Au passage merci pour vos réponses !

[escartefigue]

Pour l'adresse, il est conseillé de modéliser comme suit :

[ADRESSE] 1,1 --- (localiser) --- 0,n [VILLE] 1,1 ---(situer) --- 0,n [PAYS]

Ainsi vous évitez les redondances et tous les maux associés

De plus, en l'état, un bâtiment B1 situé dans le site S1 peut avoir une adresse A1 alors que le S1 possède une adresse A2.
A1 pouvant être située en France et A2 au Botswana, ce qui n'est pas très cohérent.
Il est préférable de rattacher l'adresse au site et, au niveau traitement, on ira cherche le numéro du bâtiment pour compléter l'adresse.

[BlueBeery]

Pour l'adresse, il est conseillé de modéliser comme suit :

[ADRESSE] 1,1 --- (localiser) --- 0,n [VILLE] 1,1 ---(situer) --- 0,n [PAYS]

Ainsi vous évitez les redondances et tous les maux associés

Je vais ajouter ça sur ma liste de changement futur, pour le moment je test un premier déploiement sur Acces avec gestion des écrans de saisie, je vais donc laisser ADRESSE comme cela le temps de me familiariser avec Acces.

De plus, en l'état, un bâtiment B1 situé dans le site S1 peut avoir une adresse A1 alors que le S1 possède une adresse A2.
A1 pouvant être située en France et A2 au Botswana, ce qui n'est pas très cohérent.
Il est préférable de rattacher l'adresse au site et, au niveau traitement, on ira cherche le numéro du bâtiment pour compléter l'adresse.

En effet, cependant l'idée dernière étant dans le cas de site important, de pouvoir distinguer les différences adresse des bâtiments sur site. Je vais essayer de modifier ça en m'inspirant de votre idée.

[laurentSc]

Mais Laurent est arrivé à utiliser Looping, qu’il qualifie même d’« outil génial » et en est devenu un fan !

Je viens par hasard de découvrir ça ; je confirme et j'ai juste un regret : n'avoir connu ce logiciel que depuis un mois ; un vrai plaisir...

[escartefigue]

En effet, cependant l'idée dernière étant dans le cas de site important, de pouvoir distinguer les différences adresse des bâtiments sur site. Je vais essayer de modifier ça en m'inspirant de votre idée.

Sinon il faut positionner une contrainte d'exclusion entre les assos adresse_site et adresse_bâtiment pour que l'identifiant du site (qui concoure à l'identification du bâtiment) ne soit que dans l'une des deux assos. On évite ainsi d'avoir un site avec une adresse en France et un bâtiment de ce site dont l'adresse est au Botswana. Les cardinalités mini coté site et bâtiment vers adresse doivent être zéro (soit une adresse de type site, soit de type bâtiment)

Ce qui donne le MCD suivant :

Pièce jointe 601009

Et le script, ici décliné pour ACCESS, avec la contrainte vérifiant la présence d'une des deux FK.

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
CREATE TABLE SI_site(
   SI_ident COUNTER,
   SI_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(SI_ident)
);
 
CREATE TABLE BA_batiment(
   SI_ident_BA INT,
   BA_ident COUNTER,
   PRIMARY KEY(SI_ident_BA, BA_ident),
   FOREIGN KEY(SI_ident_BA) REFERENCES SI_site(SI_ident)
);
 
CREATE TABLE PY_pays(
   PY_ident COUNTER,
   PY_code CHAR(3) NOT NULL,
   PY_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(PY_ident),
   UNIQUE(PY_code)
);
 
CREATE TABLE VI_ville(
   VI_ident COUNTER,
   VI_insee CHAR(5) NOT NULL,
   VI_nom VARCHAR(50) NOT NULL,
   PY_ident INT NOT NULL,
   PRIMARY KEY(VI_ident),
   FOREIGN KEY(PY_ident) REFERENCES PY_pays(PY_ident)
);
 
CREATE TABLE AD_adresse(
   AD_ident COUNTER,
   AD_ligne1 VARCHAR(38) NOT NULL,
   AD_ligne2 VARCHAR(38),
   AD_ligne3 VARCHAR(38),
   AD_ligne4 VARCHAR(38),
   AD_cdpos CHAR(5),
   AD_ligne5 VARCHAR(38),
   VI_ident INT NOT NULL,
   SI_ident_BA INT,
   BA_ident INT,
   SI_ident INT,
   PRIMARY KEY(AD_ident),
   UNIQUE(SI_ident_BA, BA_ident),
   UNIQUE(SI_ident),
   FOREIGN KEY(VI_ident) REFERENCES VI_ville(VI_ident),
   FOREIGN KEY(SI_ident_BA, BA_ident) REFERENCES BA_batiment(SI_ident_BA, BA_ident),
   FOREIGN KEY(SI_ident) REFERENCES SI_site(SI_ident)
);
 
alter table AD_adresse
add constraint AD_CHK_001
check (coalesce(SI_ident, SI_ident_BA) is not null ;

L'absence de doublon sur l'identifiant du site dans l'adresse devra être vérifiée par trigger.

[BlueBeery]

Je reviens enfin vers vous !
Après avoir passé du temps sur la mise en "forme" des écrans utilisateurs de la future base de données, je me ré-attaque enfin à la création du schéma MCD de mes parties.
Je commence pour changer, par la partie Bâtiment
Peu de modifications dans cette partie, cependant voici les règles à jour :


RG_BAT_001 : Une société est "Sur site" de 1 à n Site / Un site acceuil de 1 à n société.
RG_BAT_002 : Une société occupe de 0 à n Pièce / Une pièce est occupée par une société.
RG_BAT_003 : Une société a plusieurs types d'adresse (facturation,commercial, etc ....), chacune étant unique.


RG_BAT_004 : Un site a de 0 à n contrainte_site /Une contrainte_site est présente de 0 à n site.
RG_BAT_005 : Un site a de 0 à n type_site /Un type_site est présent de 0 à n site.
RG_BAT_006 : Un site a de 0 à n bâtiment / Un bâtiment est présent dans 1 site.
RG_BAT_007 : Un Site a 1 adresse.

RG_BAT_008 : Un bâtiment a de 0 à n contrainte_bâtiment /Une contrainte_bâtiment est présente de 0 à n bâtiment.
RG_BAT_009 : Un bâtiment possède de 1 à n étage /Un étage est présent dans 1 bâtiment.
RG_BAT_011 : Un bâtiment a 1 adresse.

RG_BAT_012 : Un étage a de 1 à n piéce /Une pièce est présent dans 1 étage.

RG_BAT_013 : Une pièce a de 0 à n contrainte_pièce / Une contrainte_pièce est présente de 0 à n pièce.
RG_BAT_014 : Une pièce a de 1 à n type_pièce /Un type_piéce est présent de 0 à n pièce.
RG_BAT_015 : Une pièce a de 0 à n matériel /Un matériel est présent dans 1 pièce.

Le MCD associé :