Discussion :

[DavidleVrai]

Bonjour à tous,

J'ai une question qui est très simple mais pour laquelle je n'arrive pas à trouver de réponse sur Developpez ou internet.

Comment réaliser les relations de type 0,1 - 1,1 qui, je crois, représentent des booléens ?

Si je prends comme exemple des documents qui sont archivable ou non, est-ce que je dois créer des tables qui suivent le modèle ci-dessous ?


Cela est mieux que de créer une table comme celle-ci ou on ajouterait un booléen ?

--------------------------
document
--------------------------
PK - id : integer
archivable : boolean
--------------------------

Merci pour votre aide.

[Waldar]

Les deux solutions sont correctes.
Le choix se fera si vous requêtez souvent cet attribut ou pas.

Si vous le manipulez souvent, laissez-le dans la table principale, sinon déportez-le dans une autre table, et encapsulez le tout dans une vue avec une jointure externe.
Exemple sous postgreSQL :

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
create table doc_document
( id_document   integer
, lb_document   varchar(10)
, constraint pk_doc_document
    primary key (id_document)
 );
 
create table doc_archivable
( id_document   integer
, constraint pk_doc_archivable
    primary key (id_document)
, constraint fk_doc_archivable_document
    foreign key (id_document)
    references doc_document (id_document)
);
 
create view v_document as
    select doc.id_document
         , doc.lb_document
         , case when arc.id_document is not null then true else false end as fl_archivable
      from doc_document   as doc
 left join doc_archivable as arc on arc.id_document = doc.id_document;
 
 
 insert into doc_document values (1, 'Doc1'), (2, 'Doc2');
 insert into doc_archivable values (2);
 
 
explain 
select *
  from v_document;
 
explain 
select id_document, lb_document
  from v_document;
-- dans ce cas la jointure externe n'est pas effectuée par la base de donnée

[DavidleVrai]

Merci, ça répond à ma question.

Je ne connaissais pas la commande EXPLAIN. Très pratique pour optimiser ou connaître la charge engendrée par une requête ou encore comprendre son fonctionnement.

[CinePhil]

Commencez par les règles de gestion des données.

Manifestement, dans votre cas, vous avez cette règle de gestion :
Un document peut être un document archivable et un document archivable est un document.

Si L'entité-type document_archivable n'est associée à rien d'autre, l'association devient inutile et il suffit de mettre une propriété booléenne dans l'entité-type document pour dire s'il est archivable. Si par contre, le fait qu'un document soit archivable entraîne la nécessité d'autres informations (durée d'archivage, par exemple) ou d'autres associations (avec une boîte d'archive, par exemple), alors nous avons là à faire à un cas d'héritage de données.

Votre MCD devient alors :
Document -0,1----être----(1,1)- Document_archivable

Les cardinalités 1,1 entre parenthèses signifient une identification relative, ce qui veut dire que, comme vous l'avez fait, l'identifiant du document archivable est celui du document. Mais on ne représente pas cette propriété au niveau du MCD. D'ailleurs, comme vous semblez avoir utilisé Looping, vous devriez alors représenter l'association avec l'outil d'héritage (le triangle) :


Ce qui donne le script suivant, généré par Looping :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE te_document_doc(
   doc_id COUNTER,
   doc_tutre VARCHAR(50),
   doc_date_creation DATETIME,
   PRIMARY KEY(doc_id)
);
 
CREATE TABLE th_doc_archivable_dar(
   doc_id INT,
   dar_duree_conservation INT NOT NULL,
   PRIMARY KEY(doc_id),
   FOREIGN KEY(doc_id) REFERENCES te_document_doc(doc_id)
);

[Paprick]

Bonsoir,

Votre MCD devient alors :
Document -0,1----être----(1,1)- Document_archivable
Les cardinalités 1,1 entre parenthèses signifient une identification relative, ce qui veut dire que, comme vous l'avez fait, l'identifiant du document archivable est celui du document. Mais on ne représente pas cette propriété au niveau du MCD. D'ailleurs, comme vous semblez avoir utilisé Looping, vous devriez alors représenter l'association avec l'outil d'héritage (le triangle)

Effectivement, ces 2 représentations sont équivalentes (avec à droite le MLD correspondant) :

[DavidleVrai]

Si j'opte pour ce type de relation dans le cas où les documents archivable n'ont pas de propriété spécifique, je me retrouve avec un entité vide sur le schéma.

[CinePhil]

Si j'opte pour ce type de relation dans le cas où les documents archivable n'ont pas de propriété spécifique, je me retrouve avec un entité vide sur le schéma.

D'où ce que j'ai écrit :

Si L'entité-type document_archivable n'est associée à rien d'autre, l'association devient inutile et il suffit de mettre une propriété booléenne dans l'entité-type document pour dire s'il est archivable.

Mais notez bien qu'il y a deux cas :
- si l'entité-type document archivable n'a pas de propriété spécifique (une date d'archivage, une date de destruction, par exemple) ;
- ET si elle n'est associée à rien d'autre (une boîte d'archive, par exemple).

[DavidleVrai]

Oui, sans propriété et sans association.

En fait, j'étais d'accord avec Waldar

Les deux solutions sont correctes.
Le choix se fera si vous requêtez souvent cet attribut ou pas.

Si vous le manipulez souvent, laissez-le dans la table principale, sinon déportez-le dans une autre table, et encapsulez le tout dans une vue avec une jointure externe.

Il me semblait que les deux cas avaient des avantages différents :
Faire porter le booléen par la table demande moins d'opérations au SGBD mais peut avoir une charge en mémoire plus importante que de créer une table supplémentaire.