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.