Discussion :

[fsmrel]

Bonsoir,

Souplixx, je pense que vous confondez le MRD et le MLD.
Merise prévoit notamment 3 outils : MCD, MLD et MPD.
Pour le MRD, c'est une toute autre histoire qui correspond à la Théorie Relationnelle.

Si l’on se situe dans le cadre de Merise, il est un fait qu’on parle de MLD, pas de MRD.

Dans leur ouvrage de référenceLa méthode Merise, Tome 1 : Principes et outils, Tardieu, Rochfeld et Colletti traitent du MLD, mais dans le contexte de l’époque, c'est-à-dire quand le modèle CODASYL (navigationnel, réseau) était en vogue, alors qu’aujourd’hui on n’en parle plus guère. Dans cet ouvrage, une part fut quand même faite au « modèle logique dans une représentation relationnelle ». Ainsi, pour éviter une certaine ambiguïté, il n’aurait pas été inutile de parler de MLDC (pour le MLD CODASYL), MLDR (relationnel), et pour faire bonne mesure, parler aussi de MLDH (hiérarchique), voire MLDI (modèle liste inverse, plutôt méconnu en France, d’où le silence des auteurs à son sujet).

Souplixx, je suggère donc que dans votre PDF, vous remplaciez MRD par MLDR et explicitiez ce sigle, en écrivant :

MLDR (Modèle logique relationnel des données).

MacFly, votre avis ?

[MacFly58]

Bonsoir,

Tout d'abord merci à fsmrel d'avoir consacré une large partie de son sommeil paradoxal à répondre à mes interrogations SQLiennes (3h50 du mat, vu !)

MacFly, votre avis ?

J'ai lu un livre (peu recommandable) sur Merise qui évoquait :
- le MLD relationnel
- le MLD CODASYL
- le MLD Fichiers classiques

Avec le MLD CODASYL, visiblement très en vogue le jour de ma naissance, on parle de RECORD, de SET, etc.
Donc l'idée de fsmrel existe, mais sans les abréviations du genre MLDC.

Concernant le MLDR, on entend cet acronyme parfois, mais je ne l'utilise pas. Le seul intérêt de ce mot pour moi, c'est qu'il fait rire les jeunes étudiants, ils sont MDR

En ce qui me concerne, je préfère ne pas inventer de nouveaux mots pour deux raisons. D'une part je ne me considère pas suffisamment expert pour prétendre détenir une vérité. Et d'autre part je ne souhaite pas inventer de nouveaux mots ou sigles, car notre jargon souffre déjà bien trop des abus de langages et des excès d'incultures.

Bref, mon avis serait le suivant. Vu que Souplixx parle de MCD dans ses contributions, logiquement je lui conseillerai de parler de MLD afin de rester dans le contexte de Merise.
Par contre s'il applique les règles de fsmrel pour dériver son MCD (ce qui étoffe les règles purement Merisiennes), ce n'est plus un vrai MLD, et il n'exite pas de terme exact pour nommer cet outil. Ce fils spirituel de Merise et de Fsmrel attend depuis des années que ses parents lui donne un nom

[Souplixx]

Bonsoir,

Désolé pour les petites fautes d'inattention,on est pas tous aussi frais que vous passé minuit
Vous me proposez d'appeller ce modèle le modèle MLRD au lieu de MRD mais qu'est ce que ca change en pratique ? Quelles ont été les modifications que vous m'avez conseillé pour que ca ne soit pas considéré comme un MRD classique !

Les clés étrangères ce sont pour les associations 1:n non ? Ce sont les clés qui identifient la deuxieme entité dans la relation?

Qu'entendez vous par clé alternative ? J'ai préféré garder IdParticipation en clé pour que la clé soit la plus courte possible.

[fsmrel]

Bonsoir,

Vous me proposez d'appeler ce modèle le modèle MLDR au lieu de MRD mais qu'est ce que ca change en pratique ?

Comme dit MacFly, si vous faites référence à Merise, on parle de MLD, le terme MRD est inconnu au bataillon. Si donc vous tenez à ce dernier (ce qui pour ma part ne me gêne en rien), mentionnez toutefois qu’il s’agit pour vous d’un synonyme de MLD. Sinon, gare à la confusion des genres, car MRD est aussi l’abréviation de Modèle relationnel de données, et là, ça change tout parce qu’il ‘agit pour le coup de la théorie relationnelle de E. F. Codd, théorie qui ne se résume pas à un diagramme...

Quelles ont été les modifications que vous m'avez conseillé pour que ca ne soit pas considéré comme un MRD classique ! Les clés étrangères ce sont pour les associations 1:n non ? Ce sont les clés qui identifient la deuxième entité dans la relation ?

Ça n’est pas en ajoutant un attribut IdTypeSponsor dans l’en-tête de la table SPONSOR que pour autant vous déclarez une clé étrangère : les clés étrangères doivent toutes l'être nommément. Elles jouent un rôle capital quant à l’intégrité des données, l’intégrité référentielle en l’occurrence.

Ainsi, en relationnel pur on procède de la façon suivante, en utilisant le terme KEY pour les clés candidates (le terme PRIMARY KEY ne fait plus partie du vocabulaire relationnel car il est en fait inessentiel), et le terme FOREIGN KEY pour les clés étrangères :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
TYPE_SPONSOR BASE RELATION 
        {idTypeSponsor        INTEGER,
         typeSponsor          CHAR}
    KEY {idTypeSponsor} ;
     
SPONSOR BASE RELATION 
        {idSponsor            INTEGER,
         nomSponsor           CHAR,
         idTypeSponsor        INTEGER}
    KEY {idSponsor}
    FOREIGN KEY {idTypeSponsor} REFERENCES TYPE_SPONSOR ; 
     
Etc.

Qu'entendez-vous par clé alternative ? J'ai préféré garder IdParticipation en clé pour que la clé soit la plus courte possible.

En relationnel pur, on n’utilise plus ce terme de « clé alternative », mais je suis obligé de le faire en dehors de ce contexte, donc quand on parle des clés primaires, c'est-à-dire dans le contexte SQL. Une clé alternative est une clé qui est en compétition avec une autre clé pour être élue miss clé primaire de la table qui les héberge. Par exemple, si deux bateaux ne doivent pas porter le même nom, alors {nomBateau} est clé candidate comme {idBateau} au titre de miss clé primaire de la table BATEAU, et c'est vous qui tiendrez le rôle de Madame de Fontenay.

En relationnel :

Code :

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

1
2
3
4
5
6
7
8
BATEAU BASE RELATION 
        {idBateau           INTEGER,
         nomBateau          CHAR,
         tailleBateau       INTEGER,
         idTypeBateau       INTEGER}
    KEY {idBateau}
    KEY {nomBateau}
    FOREIGN KEY {idTypeBateau} REFERENCES TYPE_BATEAU ;

Cas de PARTICIPATION : si vous conservez l’attribut idParticipation, en relationnel le code est le suivant :

Code :

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

1
2
3
4
5
6
7
8
9
PARTICIPATION BASE RELATION 
        {idParticipation    INTEGER,
         idBateau           INTEGER,  
         dateEpreuve        DATE,
         Remuneration       INTEGER,
         Classement         INTEGER}
    KEY {idParticipation}
    KEY {idBateau, dateEpreuve}
    FOREIGN KEY {idBateau} REFERENCES BATEAU ;

En notant au passage qu’il n’y a pas de table DATE, donc pas de clé étrangère {dateEpreuve}.

[fsmrel]

J’ai oublié celle-là... :


Revenons sur la table EQUIPER. Dans votre PDF, son en-tête est le suivant :

EQUIPER {IdNavigateur, idParticipation} ;

Et elle y a pour clé {IdNavigateur, idParticipation}.

Souvenez-vous que l’entité-type PARTICIPATION est en réalité une association déguisée en entité-type, que vous avez identifiée à l’aide d’un attribut ad-hoc.

Ce que vous avez signalé ainsi :

J'ai rajouté un attribut à Participation.

Ce à quoi j’avais répondu :

Il s’agit donc de l’identifiant provisoire (dans le MLD il dégagera).

Ainsi, on était parti du diagramme MySQL Workbench :




Pour arriver à cette partie du MCD :




Mais en route, on a perdu la clé légitime de EQUIPER, à savoir la paire {dateEpreuve, IdNavigateur}, autrement dit la dépendance fonctionnelle {dateEpreuve, IdNavigateur} -> {idBateau} qui dit qu’au cours d’une épreuve, un navigateur n’est que sur un seul bateau.

Comment rattraper le coup ?

Soit vous éliminez l’attribut idParticipationId de la relvar PARTICIPATION pour revenir à la situation initiale (cf. le diagramme MySQL Workbench) :

Code :

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

1
2
3
4
5
6
7
PARTICIPATION BASE RELATION 
        {idBateau           INTEGER,  
         dateEpreuve        DATE,
         Remuneration       INTEGER,
         Classement         INTEGER}
    KEY {idBateau, dateEpreuve}
    FOREIGN KEY {idBateau} REFERENCES BATEAU ;

Code :

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

1
2
3
4
5
6
7
EQUIPER BASE RELATION 
        {idBateau           INTEGER,  
         dateEpreuve        DATE,
         idNavigateur       INTEGER}
    KEY {idNavigateur, dateEpreuve}
    FOREIGN KEY {idBateau, dateEpreuve} REFERENCES PARTICIPATION 
    FOREIGN KEY {idNavigateur} REFERENCES NAVIGATEUR ;

Soit vous conservez vos structures (donc l’attribut idParticipation) :

Code :

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

1
2
3
4
5
6
7
8
9
10
PARTICIPATION BASE RELATION 
        {idParticipation    INTEGER,
         idBateau           INTEGER,  
         dateEpreuve        DATE,
         Remuneration       INTEGER,
         Classement         INTEGER}
    KEY {idParticipation}
    KEY {idBateau, dateEpreuve}
    KEY {Classement, dateEpreuve}
    FOREIGN KEY {idBateau} REFERENCES BATEAU ;

Code :

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

1
2
3
4
5
6
EQUIPER BASE RELATION 
        {idParticipation   INTEGER,  
         idNavigateur       INTEGER}
    KEY {idParticipation, idNavigateur}
    FOREIGN KEY {idParticipation} REFERENCES PARTICIPATION 
    FOREIGN KEY {idNavigateur} REFERENCES NAVIGATEUR ;

Mais il faudra mentionner dans votre dossier que vous garantirez la dépendance fonctionnelle {dateEpreuve, IdNavigateur} -> {idBateau} en programmant une contrainte, c'est-à-dire une assertion SQL, autrement dit (au moins) un trigger puisque les SGBD commerciaux méconnaissent l’instruction CREATE ASSERTION (c'est le prix à payer si vous voulez que « la clé soit la plus courte possible »...)

[fsmrel]

Bonsoir,


A propos des assertions, au cas où vous souhaiteriez conserver l’attribut idParticipation (cf. mon message précédent).

Traduisons en SQL le code de déclaration des relvars PARTICIPATION e EQUIPER :

TABLE PARTICIPATION

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE PARTICIPATION 
(
         idParticipation        INT            NOT NULL,
         idBateau               INT            NOT NULL,
         dateEpreuve            DATE           NOT NULL,
         Classement             INT            NOT NULL,
         Remuneration           INT            NOT NULL,
    CONSTRAINT PARTICIPATION_PK PRIMARY KEY (idParticipation),
    CONSTRAINT PARTICIPATION_BAT_AK UNIQUE (idBateau, DateEpreuve),
    CONSTRAINT PARTICIPATION_CLS_AK UNIQUE (Classement, DateEpreuve),
    CONSTRAINT PARTICIPATION_BATEAU_FK FOREIGN KEY (idBateau) REFERENCES BATEAU,
    CONSTRAINT PARTICIPATION_EPREUVE_FK FOREIGN KEY (DateEpreuve) REFERENCES EPREUVE
 ) ;

TABLE EQUIPER

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE EQUIPER 
(
         idParticipation        INT            NOT NULL,
         idNavigateur           INT            NOT NULL,
    CONSTRAINT EQUIPER_PK PRIMARY KEY (idParticipation, idNavigateur),
    CONSTRAINT COMPOSER_NAVIGATEUR_FK FOREIGN KEY (idNavigateur) REFERENCES NAVIGATEUR,
    CONSTRAINT EQUIPER_PARTICIPATION_FK FOREIGN KEY (idParticipation) REFERENCES PARTICIPATION
 ) ;

Pour garantir la contrainte selon laquelle un équipier ne peut pas être sur plus d’un bateau au cours d’une épreuve donnée :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE ASSERTION EQUIPER_CX01 CHECK
(
    NOT EXISTS
        (
         SELECT idNavigateur, dateEpreuve
         FROM   EQUIPER AS x INNER JOIN PARTICIPATION AS y ON x.idParticipation = y.idParticipation
         GROUP BY idNavigateur, dateEpreuve
         HAVING COUNT(*) > 1
        )
) ;

Avec des triggers c’est plus galère, je laisse le soin à d’autres de les programmer. Ne pas oublier le trigger qui s’applique à la table PARTICIPATION (cas des UPDATE).

[MacFly58]

Bonsoir,

J'ouvre une petite parenthèse sur les assertions.

Je cite SqlPro dans son livre "SQL - 3ème édution" :

Compte-tenu de la complexité de mise en oeuvre de la vérification des assertions et de leur coût exorbitant, la plupart ds éditeurs de SGBD relationnels ont préféré ne pas implémenter à la lettre ce genre de contrainte, mais de leu substituer la notion de trigger.

Si les triggers ont les défauts exposés par fsmrel, il sembleraient que les assertions n'aient pas que des qualités. Qu'en pensez-vous ?

[fsmrel]

Si les triggers ont les défauts exposés par fsmrel, il semblerait que les assertions n'aient pas que des qualités. Qu'en pensez-vous ?

fsmrel en pense qu’il va falloir enrichir la liste des « vérités », unanimement partagées par les experts qui ont commencé à se prononcer au début des années quatre-vingts, liste qui s’est enrichie au fil des ans et dans laquelle on trouve des affirmations du genre :

“Relational systems must necessarily perform poorly”.

“The relational approach is intended purely for query, not for production systems”.

“Control is not possible in a relational system”.

“A relational system provide no data integrity”.

Etc.

A les écouter, on en serait encore aux SGBD de 2e génération. Il y a quand même des défis qui furent relevés.

[Souplixx]

Bonsoir !
Je reviens après un certain temps (reprise des cours) pour aborder maintenant la deuxième partie du projet c'est à dire la rédaction dans un premier temps en algebres relationnelle puis en SQL des commandes pour répondre aux questions du sujet.
Je dois créer un nouveau sujet ou bien on continue ici ?

[fsmrel]

Bonsoir Souplixx,


Allez, c’est parti pour créer un nouveau sujet, en commençant par y fournir le MCD et le MLD, car outre le fait qu’on en aura besoin pour construire les requêtes, il y a quelques commentaires à apporter (par exemple, comment faire pour qu’un skipper ne soit pas en même temps équipier...)


Au passage, quel est votre SGBD ?

[Souplixx]

Bonsoir !

Je réponds avec encore du retard mais j'ai enfin libéré un peu de temps pour m'occuper de cette base de données dans les prochains jours...
Question toute bete mais le nouveau topic je le crée dans quelle section ?

Pour répondre à votre question j'utile MySQL comme SGBD.
Dans un premier temps,je vais juste essayer d'écrire les requetes en algebre relationnel je pense que je ne devrais pas avoir trop de problèmes (au moins pour les premières) avant de passer à la création des tables qui je pense va être casse pied à mon avis

[fsmrel]

A mon tour, je vous souhaite le bonsoir,


Pour éviter que je me perde dans la forêt des forums, j’aimerais autant qu’on restât dans le forum schéma.

Pour la création des tables, ne vous en faites pas, la mayonnaise devrait prendre assez vite, mais l’utilisation d’un bon vérificateur tel que MySQL Workbench s’imposera, pour lui soumettre par exemple le code SQL de création des tables et qu’il en fasse la rétro-conception. N’oubliez de prendre votre ciré, car il pourrait y avoir « du houle » (comme on dit dans la Manche)...

L'air du large fera du bien...


N.B. N'oubliez pas de publier vos derniers modèles.