Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage SQL Discussion :

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


Sujet :

Langage SQL

  1. #1
    Membre régulier
    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 ?


    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.

  2. #2
    Modérateur

    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

  3. #3
    Membre régulier
    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.

  4. #4
    Modérateur

    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)
    );
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  5. #5
    Membre éprouvé
    Bonsoir,
    Citation Envoyé par CinePhil Voir le message
    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) :
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  6. #6
    Membre régulier
    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.

  7. #7
    Modérateur

    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).
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  8. #8
    Membre régulier
    Oui, sans propriété et sans association.

    En fait, j'étais d'accord avec Waldar
    Citation Envoyé par Waldar Voir le message
    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.

###raw>template_hook.ano_emploi###