Discussion :

[Fae Kiseki]

Bonjour.
Je veux écrire une requête de suppression et de mise à jour en langage algébrique (celui avec les opérateurs binaires et unaires) mais je ne peux que l'écrire en SQL. J'aimerais savoir si quelq'un sait comment on fait pour écrire ce genre de requête en langage algébrique.
Merci d'avance.

[fsmrel]

Bonjour Fae

Votre demande n’est pas assez précise.

Soit vous vous situez au niveau des fondements, avec les connecteurs AND, OR, NOT (algèbre A), soit vous vous vous situez un cran au-dessus avec les opérateurs traditionnels de l’algèbre relationnelle, RESTRICT, PROJECT, PRODUCT, JOIN, DIVIDE, UNION, INTESECT, DIFFERENCE.

Votre préférence ?

[Fae Kiseki]

Salut. Voici donc l'énoncé de l'éxercice à traiter. J'ai un souci au niveau des clés primaires.
Pièce jointe 593179
Quand on regarde la table QUALIFICATIONS on voit que la clé primaire de la table avion c'est type-avion et celui de la EMPLOYES c'est id-emp. Moi je pense que tous ceci implique à dire que la table VOLS a pour clé primaire id-avion car si on prend n-vol comme étant clé primaire de cette table elle ne sera liée à qaucune autre table et après ça je trouve bizarre que l'id d'un avion soit clé primaire de la table VOLS

[fsmrel]

Bonsoir Fae,

Quand on regarde la table QUALIFICATIONS on voit que la clé primaire de la table avion c'est type-avion

Soit la règle : Un employé donné peut piloter plus d’un type d’avion et un type d’avion donné peut être piloté par plusieurs employés.

Ainsi, le corps de la variable relationnelle QUALIFICATION peut être par exemple celui-ci :

id_emp    type_avion
------    ----------
e01       type01
e01       type03
e01       type04
e02       type02
e02       type03
e02       type04 

Si la clé primaire de cette variable était le singleton {type_avion}, cela voudrait dire que pour un type d’avion donné, il n’y aurait qu’un et un seul employé qualifié pour ce type d’avion, par exemple soit e01, soit e02 pour le type d’avion type03 : contradiction avec la règle. En conséquence, la clé primaire est composée de la paire {id_emp, type_avion} ⁽¹⁾.

et celui de EMPLOYES c'est id-emp

Cette fois-ci c’est d’accord.

Moi je pense que tous ceci implique à dire que la table VOLS a pour clé primaire id-avion

En fonction de ma première remarque, je pense que vous saurez corriger l’erreur que vous commettez. Par ailleurs, il existe bien une association avec la table AVION, grâce à l’attribut id_avion qui joue le rôle de clé étrangère (fait référence à la table AVION) plutôt que de clé primaire de VOL...
____________________

⁽¹⁾ Je rappelle qu’une variable relationnelle est un ensemble, même chose pour une clé. C’est pour cela que j’utilise des accolades "{" et "}". De même, peu importe l’ordre des attributs dans la clé.

Une variable relationnelle est la conséquence d’un prédicat, c’est-à-dire que, pour un logicien, QUALIFICATION se lit :

L’employé id_emp est qualifié pour piloter le type d’avion type_avion.

Les tuples <e01 type01>, <e01 type03>, etc. sont les instances du prédicat.

Autre conséquence : comme tout prédicat, QUALIFICATION s’écrit au singulier.

[Fae Kiseki]

Merci beaucoup pour vos explications et remarques donc si j'en deduis bien :
Donnons les clés de ces relations, elles seront soulignées et en gras dans le schéma relationnel suivant :

• VOL (n-vol, id-avion, ville-dep, ville-arr, distance, heure-dep, heure-arr)

• AVION (#id-avion, type-avion, distance-croisière)

• QUALIFICATION (#id-emp, #type-avion)

• EMPLOYE (id-emp, nom-emp, salaire-annuel)

J'aurais d'autres questions mais j'aimerais toutefois avancé dans l'exercice et vous proposer une solution suivi de mes questions.

[fsmrel]

Rebonsoir Fae,


Prenons le cas de la table AVION. Si {type_avion} est clé primaire, alors pour le type d’avion type01, il n’y a qu’une seule distance de croisière, ce qui correspond en fait à la réalité ! Ainsi les avions du type A300 (ou plutôt d’une déclinaison de l’A300, à savoir A300B1, A300B2, A300B3, etc.) ont tous la même distance de croisière. Autrement dit, la table AVION devrait être renommée en TYPE_AVION. Mais il y a le caillou dans la chaussure, à savoir l’attribut id_avion qui sert à identifier chaque avion et non pas chaque type d’avion...
Il manque manifestement, la table TYPE_AVION, mais on va essayer de s’en passer, sachant qu’en contrepartie il y aura de la redondance dans la table AVION... (cf. plus bas).

Bref, {id_avion} doit être clé primaire de la table AVION et chaque avion est d’un type d’avion.


Prenons le cas de VOL. Vous dites que {id_avion} est clé primaire de VOL, mais alors (contrainte d’unicité oblige), pour un avion donné, il y a au moins et au plus une ville de départ, une ville d’arrivée, une heure de départ, une heure d’arrivée, etc. Bref, un avion ne volera qu’une seule fois dans son existence ! Après quoi il restera définitivement cloué au sol... Si on veut qu’il puisse voler plus d’une fois, utilisons le numéro de vol (n_vol) pour la clé.


Pour compléter (je vous laisse déterminer les bonnes clés primaires) :

EMPLOYE {id_emp    nom_emp      salaire_annuel}
         ------    ---------    --------------
         e01       Fernand      50000
         e02       Raoul        45000
         e03       Paul         45000
         e04       Patricia     45000

AVION {id_avion    type_avion    distance_croisère}
       --------    ----------    -----------------
       av01        type01        dist01
       av02        type02        dist02
       av03        type01        dist01
       av04        type01        dist01
       av05        type03        dist03
       av06        type04        dist04

QUALIFICATION {id_emp    type_avion}
               ------    ----------
               e01       type01
               e01       type03
               e01       type04
               e02       type02
               e02       type03
               e02       type04
               e04       type01
               e04       type04

VOL {n_vol    id_avion    ville_dep    ville_arr    distance    heure_dep    heure_arr}
     -----    --------    ---------    ---------    --------    ---------    ---------
     v01      av01        ville01      ville02      3000        h011         h012
     v02      av01        ville02      ville01      3000        h021         h022
     v03      av01        ville02      ville03      2000        h031         h032
     v04      av02        ville01      ville04      1000        h041         h042
     v05      av02        ville01      ville02      3000        h051         h052
    ...

Je reviens sur la table AVION. Votre schéma initial comporte une anomalie (volontaire ou pas de la part de votre prof...) : comme je l’ai écrit plus haut, puisque la distance de croisière d’un avion ne dépend pas de l’avion lui-même (à moins d’avoir été bricolé !) mais du type auquel il appartient, à chaque fois qu’une ligne de la table AVION fera mention du type d’avion, par exemple le type type01, alors la distance de croisière devra être la même, dist01 dans cet exemple. Comme je l’ai mentionné, il manque la table TYPE_AVION, mais on va essayer de s’en passer, sachant qu’il y aura de la redondance dans la table AVION, et sachez que la redondance est l’ennemie jurée des bases de données. Vous étudierez sans doute cela de façon plus formelle dans le cadre de la normalisation des bases de données (disons que la table AVION viole la troisième forme normale et c’est affreux à cause des redondances qu’il faudra garantir...)


En complément :

Concernant les règles structurelles (clés, etc.), je vous engage à vous référer au chapitre 3 « Les règles d’intégrité structurelle » de l’ouvrage Bases de données
du professeur Georges Gardarin.

Concernant l’algèbre relationnelle, voyez le chapitre 4 du même ouvrage, « L’algèbre relationnelle : opérations de base »


N.B. Attention à l’emploi du trait-d’union dans les noms des attributs : dans le cas de SQL, c’est aussi l’opérateur de soustraction et les problèmes de syntaxe pourraient se produire.

[Fae Kiseki]

Bonjour

Merci beaucoup pour les cours je ne manquerai pas de les lire.
Donc si je comprend bien la table Avion a pour attribut "id-avion" ce qui implique à dire que type-avion n'est pas une clé primaire, on aura donc dans la table QUALIFICATION id-emp comme clé étrangère et type-avion comme clé primaire ? Si c'est le cas type avion devient clé étrangère dans la table AVION.
Moi je pensais que la table qualification était une association devenue table...
Vous avez dit plus haut que la table QUALIFICATION avait pour clé primaire la concaténation des deux attribut qui l'a compose or moi je sais que l'on ne peut concatener deux attributs que s'ils sont des clées primaires dasn d'autres tables

[fsmrel]

Bonsoir Fae,


En préambule, je précise quelques points concernant la terminologie dans le cadre de la théorie relationnelle.

Dans le langage SQL, on parle de tables, alors que dans la théorie relationnelle (dont SQL n’est un avatar) le terme employé est celui de relvar (abréviation commode de variable relationnelle).

Une relvar est dotée d’au moins une clé candidate, et si dans le passé, on utilisait à la place le terme « clé primaire », les années passant, ce terme a disparu de la théorie, n’est resté que celui de « clé candidate ». Une relvar pouvant comporter plus d’une clé candidate, il était convenu que l’une d’entre elles serait « plus égale » que les autres et ainsi qualifiée de « primaire » (il serait plus correct de remplacer cet anglicisme par « principale », mais bon, on fait avec). Ce qualificatif de « primaire » étant devenu inutile, il a aujourd’hui disparu de la théorie, mais a été conservé dans le langage SQL.

Dans ce qui suit, tant que faire se peut j’utiliserai les termes « relvar » et « clé candidate ». Néanmoins, comme il n’y a pas de confusion, rien ne vous empêche de continuer à utiliser la terminologie SQL.

si je comprend bien la table Avion a pour attribut "id-avion" ce qui implique à dire que type-avion n'est pas une clé primaire

La relvar AVION a pour attributs id_avion, type_avion, distance_croisière. Ce n’est pas parce que id_avion est attribut de cette relvar que {type_avion} est ou n’est pas clé ! A moins que vous ne vouliez dire que c’est la présence de cet attribut qui empêche {type_avion} d’être clé, mais alors il faut le démontrer.

Ainsi, {type_avion} serait clé candidate de la relvar AVION seulement si on vérifiait chacune des règles suivantes :

(R1) Pour chaque valeur de l’attribut type_avion de la relvar AVION il y a au moins et au plus une valeur pour l’attribut distance_croisière dans cette relvar.

(R2) Pour chaque valeur de l’attribut type_avion de la relvar AVION il y a au moins et au plus une valeur pour l’attribut id_avion dans cette relvar

Ce que l’on écrit plus volontiers ainsi, sous forme de dépendances fonctionnelles :

DF1 : {type_avion} → {distance_croisière}

DF2 : {type_avion} → {id_avion}.

Comme on l’a vu, pour un type d’avion il y a exactement une seule distance de croisière, ce qui fait que DF1 est vérifiée, mais pour un type d’avion il peut y avoir plusieurs avions de ce type, en conséquence de quoi DF2 n’est pas vérifiée, autrement dit la règle R2 est contredite, en conséquence de quoi {type_avion} n’est pas clé candidate de la relvar AVION. ■

on aura donc dans la table QUALIFICATION id-emp comme clé étrangère et type-avion comme clé primaire ? Si c'est le cas type avion devient clé étrangère dans la table AVION.

Une clé primaire (donc candidate) doit respecter une contrainte disons d’intégrité d’identité, à savoir les règles d’unicité et d’irréductibilité des clés candidates. Une clé étrangère a une autre vocation, elle doit respecter une contrainte dite d’intégrité référentielle (pour chaque tuple (ligne en SQL) de la relvar QUALIFICATION, la valeur prise par l’attribut id_emp doit être une valeur prise par l’attribut id_emp dans la relvar de référence EMPLOYE). Un attribut d’une relvar peut parfaitement participer à la fois à une clé candidate et à une clé étrangère. Ainsi, en compagnie de l’attribut type_avion, l’attribut id_emp participe à la clé candidate {id_emp, type_avion} de QUALIFICATION, mais il participe aussi à la clé étrangère {id_emp} qui fait référence à la relvar EMPLOYE. Mais une clé étrangère fait impérativement référence à une clé candidate d’une relvar. {id_emp} fait référence à la clé candidate {id_emp} de la relvar EMPLOYE : c’est tout bon. Quand vous écrivez que {type_avion} devient clé étrangère dans la relvar AVION, cette clé étrangère doit faire référence à une clé candidate d’une relvar de référence, mais quelle est cette relvar ? Elle n'existe pas ! Par exemple, la relvar QUALIFICATION ne peut pas être référencée par la relvar AVION car QUALIFICATION a pour clé candidate la paire {id_emp, type_avion} mais pas le singleton {id_emp}. Pour un motif identique, la relvar AVION ne peut pas être référencée par la relvar AVION. Donc on travaille sans filet, et pour travailler en sécurité, il faudrait créer une relvar TYPE_AVION ayant pour clé candidate {type_avion}, et référençable par QUALIFICATION et AVION.

je pensais que la table qualification était une association devenue table...

En fait, si la relvar TYPE_AVION existait, la relvar QUALIFICATION serait conceptuellement une association entre TYPE_AVION et EMPLOYE. Au stade SQL, on pourrait alors dire que QUALIFICATION serait une table associative.

Vous avez dit plus haut que la table QUALIFICATION avait pour clé primaire la concaténation des deux attribut qui l'a compose or moi je sais que l'on ne peut concatener deux attributs que s'ils sont des clées primaires dasn d'autres tables

Ici, le terme « concaténation » est impropre, à bannir. On est en fait dans le contexte de la théorie des ensembles, car la théorie relationnelle s’en réclame. QUALIFICATION a pour clé la paire {id_emp, type_avion}, nuance !

Cela dit, dans quel but voulez-vous « concaténer » ? Si c’est pour déclarer une clé candidate, par définition on n’a pas à tenir compte de ce qui existe dans les autres relvars, les seules règles sont l’unicité et l’irréductibilité des clés candidates. Si c’est pour déclarer une clé étrangère, alors celle-ci doit effectivement être d’abord clé candidate d’une relvar, comme je l’ai écrit ci-dessus.

[Fae Kiseki]

Bonsoir

Je n'arrive pas à saisir clairemament ce que vous dites par rapport à la relvar QUALIFICATION. Sachant que id-emp est une clé étrangère dans cette dernière et que type-avion ne l'ai pas... Comment pouvons nous dire que les deux attributs sont clés de la relvar ? C'est ce que je ne comprend pas.
L'écriture sera la suivante : QUALIFICATION (#id-emp, type-avion) et moi je trouve ça bizarre vu que ca ne se fait qu'avec les clés étrangères (d'après mes connaissances.

Je n'arrive pas à bien cerner ce que vous dites au sujet de cette relvar.

[Fae Kiseki]

Re bonsoir

je viens de lire un cours et je vois que oui il est possible de faire cela donc je propose que schema relationnel suivant
Donnons les clés de ces relations, elles seront soulignées et en gras dans le schéma relationnel suivant :

• VOL (n-vol, #id-avion, ville-dep, ville-arr, distance, heure-dep, heure-arr)
• AVION (id-avion, #type-avion, distance-croisière)
• QUALIFICATION (#id-emp, type-avion)
• EMPLOYE (id-emp, nom-emp, salaire-annuel)

Donnez moi votre avis s'il vous plait.
Aussi j'aimerais m'excuser, mes lacunes par rapport à ceci sont dues au cours que l'on a eu à faire qui manquait cruellement d'informations sur la conception des bases de données, contenait des érreurs et on a pas eu à faire des exercices dirigés. Donc j'ai appris sur le tas et à la vas-vite.

[fsmrel]

Rebonsoir,

Je n'arrive pas à saisir clairement ce que vous dites par rapport à la relvar QUALIFICATION. Sachant que id-emp est une clé étrangère dans cette dernière et que type-avion ne l'ai pas... Comment pouvons nous dire que les deux attributs sont clés de la relvar ? C'est ce que je ne comprend pas.
L'écriture sera la suivante : QUALIFICATION (#id-emp, type-avion) et moi je trouve ça bizarre vu que ca ne se fait qu'avec les clés étrangères (d'après mes connaissances.

Pour déterminer une clé candidate d’une relvar (ou clé primaire de table en SQL), qu’il s’agisse de la relvar QUALIFICATION ou autre, évacuez de votre esprit la notion de clé étrangère, vous ne la considérerez qu’une fois les clés candidates définies. Comme je l’ai expliqué dans mon précédent message, les clés candidates servent à garantir l’unicité des tuples (lignes de table en SQL) : l’employé e01 ne doit pas être présent deux fois dans la relvar EMPLOYE, on ne doit pas avoir deux fois le tuple <e01, type01> dans la relvar QUALIFICATION, etc. Pour leur part, je répète que les clés étrangères n’ont pas d’autre fonction que de garantir l’intégrité référentielle, c’est-à-dire la cohésion des liens entre les différentes relvars : les employés (par exemple e01, e02, etc.) qu’on retrouvera dans la relvar QUALIFICATION doivent impérativement des employés qu’on trouvera d’abord dans la relvar EMPLOYE et c’est la mise en oeuvre des clés étrangères qui permet un tel contrôle.

Donnons les clés de ces relations, elles seront soulignées et en gras dans le schéma relationnel suivant :

• VOL (n-vol, #id-avion, ville-dep, ville-arr, distance, heure-dep, heure-arr)
• AVION (id-avion, #type-avion, distance-croisière)
• QUALIFICATION (#id-emp, type-avion)
• EMPLOYE (id-emp, nom-emp, salaire-annuel)

C’est bon. Cela dit, comme l'ont fait beaucoup depuis une quarantaine d’années, vous faites usage du symbole « # » pour mettre en évidence les attributs qui sont éléments des clés étrangères, pourquoi pas. Mais l’attribut type_avion de la relvar AVION n’appartient à aucune clé étrangère de cette relvar, donc le nom de cet attribut ne doit pas être précédé du symbole « # ».

[Fae Kiseki]

Rebonsoir,

Mais l’attribut type_avion de la relvar AVION n’appartient à aucune clé étrangère de cette relvar, donc le nom de cet attribut ne doit pas être précédé du symbole « # ».

Merci beaucoup, je vais de ce pas retirer le symbole. Je continue à rediger mon travail, puis-je continuer à vous faire part de mes questions par rapport à cet exercice dès que j'en aurai ?

[fsmrel]

Bonjour Fae,

Vous pouvez toujours continuer à poser vos questions.

Bon courage pour la suite !

[Fae Kiseki]

Bonsoir

Je viens au sujet de l'attribut "type-avion", vous avez dit qu'il n'est pas une clé étrangère dans la relvar AVION. Or c'est une clé primaire dans la relvar QUALIFICATION. J'aimerais donc savoir pourquoi cet Attribut n'est pas une clé étrangère. Aussi si cet attribut n'est pas une clé étrangère, comment peut-il crée une relation entre QUALIFICATION et AVION?

[fsmrel]

Bonsoir Fae,

Je viens au sujet de l'attribut "type-avion", vous avez dit qu'il n'est pas une clé étrangère dans la relvar AVION. Or c'est une clé primaire dans la relvar QUALIFICATION. J'aimerais donc savoir pourquoi cet Attribut n'est pas une clé étrangère.

La paire {id_emp, type_avion} est clé candidate de la relvar QUALIFICATION. A cette occasion je rappelle qu’une clé primaire est une clé candidate d’une relvar R qu’on a privilégiée par rapport aux autres quand elles existent dans R : c’est un choix disons subjectif. En tout cas, comme elle est la seule clé candidate de la relvar QUALIFICATION, la paire {id_emp, type_avion} est automatiquement élue Miss clé primaire de cette relvar.

Par ailleurs, par définition une clé étrangère fait nécessairement référence à une clé candidate mais pas à une de ses parties. Ainsi, comme je vous l’ai déjà dit, le singleton {type_avion} n’est qu’une partie, un sous-ensemble strict de la clé candidate {id_emp, type_avion} et n’est donc pas qualifié pour être clé candidate lui-même, en conséquence de quoi ce singleton ne peut pas être référencé par une clé étrangère. Pour que la relvar AVION possède une clé étrangère référençant la relvar QUALIFICATION, il faudrait ajouter un attribut id_emp à la relvar AVION, ce qui serait évidemment en l'occurrence un non sens.

Aussi si cet attribut n'est pas une clé étrangère, comment peut-il crée une relation entre QUALIFICATION et AVION?

Si une clé étrangère établit une relation entre relvars, toutes les relations entre relvars ne sont pas la conséquence de clés étrangères ! Ainsi, il y a une sorte de relation implicite permise entre AVION et QUALIFICATION parce que ces relvars font référence au type d’avion au moyen de l’attribut type_avion, et il est donc permis de coder des requêtes auxquelles participent ces deux relvars, en faisant intervenir cet attribut. Par exemple « Quels sont les avions que les employés peuvent piloter grâce à leur qualification ». Cette requête fait intervenir les relvars AVION et QUALIFICATION grâce à la présence dans leur en-tête respectif de l’attribut type_avion.

Cette requête avec Tutorial D (Databases, Types, and the Relational Model, The Third Manifesto) :

{AVION JOIN QUALIFICATION} {id_emp, id_avion}

C’est-à-dire jointure naturelle des relvars AVION et QUALIFICATION, puis projection sur id_emp et id_avion.

Avec SQL :

Code :

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

1
2
SELECT y.id_emp, x.id_avion
FROM   AVION as x JOIN QUALIFICATION as y ON x.type_avion = y.type_avion

Incidemment, pensez à utiliser les termes pertinents. Un attribut n’est qu’un élément d’un ensemble et n’est pas un ensemble par lui-même, ainsi en va-t-il de l’attribut type_avion. Par contre le singleton {type_avion} est un ensemble, en l’occurrence un sous-ensemble strict de {id_emp, type_avion}, et il ne contient que le seul élément (attribut) type_avion.

Prenez l’habitude d’utiliser les accolades "{" et "}" pour distinguer les éléments des ensembles auxquels ils appartiennent.

Pensez aussi à voter, en cliquant sur le pouce vert, pour les réponses qui ont pu vous aider.

Bon courage !

[Fae Kiseki]

Bonsoir

Merci beaucoup c'est exactement où je voulais en venir. Je me disais que cela n'était pas possible j'apprend beaucoup dans cette discussion.
Je continue donc mon travail et désolé pour le retard je composais.

[fsmrel]

Bonsoir Fae,

J'apprend beaucoup dans cette discussion.

Une bonne raison pour ne pas oublier de voter pour les réponses qui ont pu vous aider.

Je continue donc mon travail et désolé pour le retard je composais.

Bon courage pour la poursuite de votre travail, prenez votre temps. Pas d’inquiétude, pour les réponses tardives, mieux vaut tard que jamais. En ce qui concerne la théorie relationnelle, le temps ne fait rien à l’affaire...

[Fae Kiseki]

Bonjour

J'aimerais savoir comment ressortir le MPD et le MLD de ce schema relationnel. Je n'arrive pas à faire la différence entre ces deux modèles et je ne comprend pas trop bien le scheminement.
Voici à quoir ressemble mon MCD.

Pièce jointe 593870

J'aimerais aussi avoir votre avis dessus. Les association sont en noir.
Aussi lorsque je vais sur ACCESS pour enregister un jeu d'essai et creer les requêtes, je n'arrive pas à faire en sorte qu'il y ai plusieurs pilotes qui puissent piloter un A300 car je suis dans l'obligation de mettre l'index de type-avion en "indexé sans doublon" sinon il n'y aura pas de liaison entre AVIONS et QUALIFICATIONS.

[fsmrel]

Bonsoir Fae,


Rien de tel qu’un MCD pour y voir clair ! Malgré quelques petites erreurs, le vôtre mérite une bonne note


A propos du nom des entités-types

A l’instar de l’auteur de référence D. Nanci⁽¹⁾ (RIP), j’utilise le terme entité type ou plutôt entité-type (avec un trait d’union entre entité et type), terme synonyme de « type d’entité ». D’autres auteurs de référence utilisent une terminologie différente mais équivalente : Classe d’entités (P. Bergougnoux, papa de Looping), individu-type (Tardieu, Rochfeld, Tabourier). Souvent les gens abrègent entité-type en entité, mais je considère cela comme du relâchement, en tout cas un manque de rigueur.

Il est important de noter qu’en fait une entité-type est la conséquence d’un prédicat dont les propositions sont des entités. En ce sens, Le Professeur Bergougnoux est explicite quand il privilégie le terme Classe d’entités. Quoi qu’il en soit, ce que j’écrivais dans le post #4 va dans le même sens :

Une variable relationnelle est la conséquence d’un prédicat, c’est-à-dire que, pour un logicien, QUALIFICATION se lit :

L’employé id_emp est qualifié pour piloter le type d’avion type_avion

Les tuples <e01 type01>, <e01 type03>, etc. sont les instances du prédicat.

Autre conséquence : comme tout prédicat, QUALIFICATION s’écrit au singulier.

Ce qui vaut pour une relvar (variable relationnelle) vaut bien entendu pour une entité-type, représentant le prédicat suivant :

L’employé id_emp a pour nom nom_emp et a pour salaire annuel salaire_annuel

Ce prédicat a lui-même un nom, à savoir EMPLOYE, et comme tout prédicat on l’écrit au singulier.

Les instances du prédicat EMPLOYE ne sont plus appelées des tuples, mais des occurrences, ce qui revient au même, bien qu’on puisse chipoter en disant que tuple est plus précis (tuple est l’abréviation de n-tuple, n-uplet en français où n désigne le degré de la relvar, c’est-à-dire le nombre de ses attributs, n = 3 dans le cas de EMPLOYE).
Au même titre que les tuples de la théorie relationnelle, les occurrences merisiennes suivantes sont les instances, les propositions du prédicat EMPLOYE :

<e01 Fernand 50000>  
<e02 Raoul 45000> 
<e03 Paul 45000> 
<e04 Patricia 45000> 

En français, sous forme de propositions :

L’employé e01 a pour nom Fernand et a pour salaire annuel 50000
L’employé e02 a pour nom Raoul et a pour salaire annuel 45000  
L’employé e03 a pour nom Paul et a pour salaire annuel 45000  
L’employé e04 a pour nom Patricia et a pour salaire annuel 45000  

Et comme tout prédicat, EMPLOYE s’écrit au singulier ! Cela vaut évidement pour VOL, AVION, QUALIFICATION. L’emploi du pluriel est une erreur.


Concernant les associations

Selon les auteurs on utilise soit le terme association soit le terme relation, voire relation type. Pour ma part, j’utilise association, mais employez le terme qui vous convient le mieux. En tout cas, vos associations sont correctes.


Concernant les cardinalités

Les cardinalités sont portées par les pattes connectant les entités-types et les associations. Vous êtes dans les clous, sauf pour la cardinalité 1,N portée par la patte connectant EMPLOYE et QUALIFIER. En effet, 1,N signifie que tout employé est qualifié pour piloter, ce qui n’est pas le cas. En effet, dans votre énoncé initial (post #1) il est précisé que les pilotes sont qualifiés pour piloter au moins un type d’avion, ce qui les distingue des autres employés : du fait de ces autres employés qui ne pilotent pas mais n’en font pas moins l’objet d’occurrences de l’entité-type EMPLOYE, on est astreint à remplacer 1,N par 0,N.


Une erreur classique

La connaissance de l’avion qui effectue un vol donné est fournie par l’association EFFECTUER car la patte connectant cette association et l’entité-type VOL est 1,1. L’attribut id_avion doit donc disparaître de l’entité-type VOL, sa présence contrevient à la règle « one fact, one place ». C’est à l’occasion de la génération du MLD et du code SQL de création des tables que l’AGL générera dans la table VOL l’attribut (ou colonne) rendu nécessaire à ce stade, id_avion, tout comme il générera les attributs id_emp et id_avion dans la table QUALIFIER.


Passage au MLD et au code SQL

Vous mentionnez des problèmes au stade SQL. Je vous engage à utiliser l’excellent Looping, gracieusement proposé par le professeur Patrick Bergougnoux (merci Paprick !). Jetez un bon coup d’oeil au forum Looping.

Avec Looping, dans la fenêtre des propriétés, vous pouvez choisir votre SGBD :

Propriétés > MLD- SQL > SGBD cible

Même si ACCESS n’est pas vraiment un SGBD, il fait partie de la liste.

Voilà par exemple dans le cas d’ACCESS ce que génère Looping si dans la barre d’outils (accès rapide) je clique sur l’icône « Script SQL au format TXT » :

Sub Create_Tables()

DoCmd.RunSQL "CREATE TABLE AVION(" & _
   "id_avion INT," & _
   "type_avion VARCHAR(16) NOT NULL," & _
   "distance_croisiere INT NOT NULL," & _
   "CONSTRAINT AVION_PK PRIMARY KEY(id_avion)" & _
");"   

DoCmd.RunSQL "CREATE TABLE VOL(" & _
   "n_vol INT," & _
   "ville_dep VARCHAR(48) NOT NULL," & _
   "ville_arr VARCHAR(48) NOT NULL," & _
   "distance INT NOT NULL," & _
   "heure_dep DATETIME NOT NULL," & _
   "heure_arr DATETIME NOT NULL," & _
   "id_avion INT NOT NULL," & _
   "CONSTRAINT VOL_PK PRIMARY KEY(n_vol)," & _
   "CONSTRAINT VOL_AVION_FK FOREIGN KEY(id_avion) REFERENCES AVION(id_avion)" & _
");"   

DoCmd.RunSQL "CREATE TABLE EMPLOYE(" & _
   "id_emp INT," & _
   "nom_emp VARCHAR(48) NOT NULL," & _
   "salaire_annuel INT NOT NULL," & _
   "CONSTRAINT EMPLOYE_PK PRIMARY KEY(id_emp)" & _
");"   

DoCmd.RunSQL "CREATE TABLE QUALIFIER(" & _
   "id_avion INT," & _
   "id_emp INT," & _
   "type_avion VARCHAR(16) NOT NULL," & _
   "CONSTRAINT QUALIFIER_PK PRIMARY KEY(id_avion, id_emp)," & _
   "CONSTRAINT QUALIFIER_AVION_FK FOREIGN KEY(id_avion) REFERENCES AVION(id_avion)," & _
   "CONSTRAINT QUALIFIER_EMPLOYE_FK FOREIGN KEY(id_emp) REFERENCES EMPLOYE(id_emp)" & _
");"   

End Sub

Vu les votes, des réponses vous ont apporté une aide bienvenue
_____________________________

⁽¹⁾ D. Nanci, B. Espinasse Ingénierie des systèmes d’information : Merise deuxième génération (4e édition, 2001).

[Fae Kiseki]

Bonsoir.
J'ai fais le travail en entier et j'aimerai avoir votre avis sur le document théorique.
Pièce jointe 594033