Créer des tables avec une relation 0,1 - 1,1 ?

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 ?
Pièce jointe 584386

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.

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:

---

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

---

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.

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) :
Pièce jointe 584487

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

Code:

---

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) );

---

Bonsoir,

Citation:

---

Envoyé par CinePhil

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) :
Pièce jointe 584509

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.
Pièce jointe 584522

Citation:

---

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 :

Citation:

---

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).

Oui, sans propriété et sans association.

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

Citation:

---

Envoyé par 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.