Exercices

Une solution possible :

CREATE TABLE points(x FLOAT,y FLOAT);
INSERT INTO points(x,y) VALUES (-50,-50);
INSERT INTO points(x,y) VALUES (50,-50);
INSERT INTO points(x,y) VALUES (50,50);
INSERT INTO points(x,y) VALUES (-50,50);

SELECT * from points;

Une solution possible :

Ensemble des chiffres pairs en intension :

• \(E = \{ x \; \mid \; x \in \mathbb{N} \land x \equiv 0 \mod 2 \land (x>=0 \land x<10) \}\)

Requête SQL pour récupérer les chiffres pairs dans l’ensemble des entiers :

SELECT x FROM E WHERE x%2 = 0 AND x >=0 AND x < 10;

Une solution possible :

• \(card(E_1 \cup E_2) = card(E_1) + card(E_2) - card(E_1 \cap E_2)\)

SELECT count(*) AS "card(E1 Union E2)"
FROM (SELECT *  FROM E1 UNION SELECT * FROM E2);

SELECT "" AS "=";

SELECT count(*) AS "card(E1)" FROM E1;

SELECT "" AS "+";

SELECT count(*) AS "card(E2)" FROM E2;

SELECT "" AS "-";

SELECT count(*) AS "card(E1 Intersect E2)"
FROM (SELECT * FROM E1 INTERSECT SELECT * FROM E2);

Une solution possible :

\(card(E_1 \setminus E_2) = card(E_1) - card(E_1 \cap E_2)\)

SELECT count(*) AS "card(E1 Minus E2)"
FROM (SELECT *  FROM E1 EXCEPT SELECT * FROM E2);

SELECT "" AS "=";

SELECT count(*) AS "card(E1)" FROM E1;

SELECT "" AS "-";

SELECT count(*) AS "card(E1 Intersect E2)"
FROM (SELECT * FROM E1 INTERSECT SELECT * FROM E2);

Une solution possible :

 SELECT x AS "digits" FROM E;

 -- create view E1 : chiffres pairs --
 CREATE VIEW E1 AS
 SELECT * FROM E WHERE  x%2=0;

 SELECT x AS "event digits" FROM E1;

-- create view E2 : chiffres impairs --
 CREATE VIEW E2 AS
 SELECT * FROM E
 EXCEPT
 SELECT * FROM  E1;

 SELECT x AS "odd digits" FROM E2;

 -- card(E \ (E U E2)) = 0 --
 SELECT count(*) AS "card(E \ (E U E2)) = 0"
 FROM E
 WHERE NOT EXISTS (
     SELECT * FROM E1
     UNION
     SELECT * FROM E2
 );

Une solution possible :

• \((A \cup B) \setminus (A \cap B)= \emptyset\)

CREATE VIEW B AS
SELECT * FROM A ORDER BY x DESC;

SELECT * FROM A;
SELECT * FROM B;

SELECT COUNT(*)
FROM
(
 SELECT x FROM A  UNION SELECT x FROM B
 EXCEPT
 SELECT x FROM A  INTERSECT SELECT x FROM B
)

Une solution possible :

SELECT * FROM E;

-- create view E1 (even digits) --
CREATE VIEW E1 AS
SELECT x FROM E WHERE x%2=0 AND x>=0 AND x<10;

SELECT x AS "even digits" FROM E1;

-- create view E2 (odd digits) --
CREATE VIEW E2 AS
SELECT x FROM E WHERE x>0 AND x<10 AND x NOT IN (SELECT x FROM E1);

SELECT x AS "odd digits"  FROM E2;

-- card(E1\E) = 0 => E1 inclus dans E  --
SELECT count(*) AS "card(E1\E)" FROM E1 EXCEPT SELECT x FROM E;
-- card(E\E1)  --
SELECT count(*) AS "card(E\E1)"  FROM E EXCEPT SELECT x FROM E1;
-- card(E2\E) = 0 => E2 inclus dans E ---
SELECT count(*) AS "card(E2\E)" FROM E2 EXCEPT SELECT x FROM E;
-- card(E\E2)  --
SELECT count(*) AS "card(E\E2)" FROM E EXCEPT SELECT x FROM E2;

Une solution possible :

 SELECT * FROM E;

  -- create view E1 : chiffres pairs  --
 CREATE VIEW E1 AS
 SELECT x FROM E WHERE x%2=0 AND x>=0 AND x<10;


 -- create view E2  : chiffres impairs --
 CREATE VIEW E2 AS
 SELECT x FROM E WHERE  x>0 AND x<10 AND x NOT IN (SELECT x FROM E1);

 SELECT x AS "even digits"  FROM E1;
 SELECT x AS "odd digits" FROM E2;

-- create view E_numbers  --
 CREATE VIEW E_numbers  AS
 SELECT x FROM E WHERE x NOT IN (SELECT x FROM  E1) AND  x NOT IN (SELECT x FROM E2);

 SELECT x AS "numbers"  FROM E_numbers;

 -- create view E_union = E_numbers + E1 + E2  --
 CREATE VIEW E_union AS
 SELECT x FROM  E_numbers
 UNION
 SELECT x FROM E1 UNION SELECT x FROM  E2;

 -- E - E_union = 0 --
 SELECT count(*) AS "E-E_union=0" FROM (SELECT x FROM E EXCEPT SELECT x FROM E_union);

Une solution possible :

Cet exercice pourra être résolu par une méthode de représentation d’ensembles sous forme de diagramme de Venn et de calcul de cardinalité d’ensembles.

Ces ensembles représentent l’ensemble des élèves (\(E_1\)) qui ne feront pas de sports et les ensembles d’élèves qui font un ou plusieurs sports :

• \(E= E_1 \cup Football \cup Natation \cup Course\)

où :

• \(card(E)=card(E_1)+card(Football)+card(Natation)+card(Course)=200\)

On défini alors un partitionnement de l’ensemble des élèves (\(E\)) en sous-ensembles :

• les élèves qui ne pourront participer à la journée de sport (\(E_1)\)
• les élèves qui participeront à un seul sport (\(E_2,E_3,E_4)\)
• les élèves qui participeront à deux sports (\(E_5,E_6,E_7)\)
• les élèves qui participeront aux trois sports(\(E_8)\)

représentés par le diagramme de Venn ci-dessous :

A partir des données du problème on peut déjà identifier :

• 10 élèves sont blessés et ne participent pas

  \(\Rightarrow card(E_1)=10\)

• 18 participent au 3 sports

  \(\Rightarrow card(E_8)=18\)

• 103 ne font que 2 sports

• 79 font du foot et de la natation

• 19 ne font que le la course

  \(\Rightarrow card(E_4)=19\)

• 129 font de la natation dont 40 que de ça .

  \(\Rightarrow card(E_3)=40\)

représentés par le diagramme de Venn ci-dessous :

79 font du foot et de la natation :

• \(card(E_5)+card(E_8)=79\)
• \(card(E_5)+18=79\)

\(\Rightarrow card(E_5)=61\)

129 font de la natation dont 40 que de ça :

• \(card(E_3)+card(E_5)+card(E_7)+card(E_8)=129\)
• \(40+61+card(E_7)+18=129\)

\(\Rightarrow card(E_7)=10\)

103 ne font que 2 sports

• \(card(E_5)+card(E_6)+card(E_7)=103\)
• \(61+card(E_6)+10=103\)

\(\Rightarrow card(E_6)=32\)

200 élèves en tout :

• \(card(E_1)+card(E_2)+card(E_3)+card(E_4)+card(E_5)+card(E_6)+card(E_7)+card(E_8)=200\)
• \(10+card(E_2)+40+19+61+32+10+18=200\)

\(\Rightarrow card(E_2)=10\)

On obtient donc la partition suivante de l’ensemble des élèves pour la journée de sport :

Une solution possible :

On vérifiera que le résultat final \(R\) des opérations ensemblistes suivantes est nul

• \(U=\cup(A,B)\)
• \(I=\cap(A,B)\)
• \(E=\setminus(U,I)\)
• \(R=\Pi_{(count(x))}(E)\)

Une solution possible :

Algèbre relationnelle :

• \(R=\times(A,B)\)

Une solution possible :

dans le premier cas (\(f : \mathbb{R} \rightarrow \mathbb{R}\)) la fonction (\(f : x \longrightarrow x^2\)) est :

• non-injective : deux éléments de l’ensemble de départ ont la même image \(\{ -1,+1 \} \rightarrow \{ +1 \}\)
• non-surjective : des éléments de l’ensemble d’arrivée n’ont pas d’antécédent (ex : \(y=-4\) n’a pas d’antécédent)
• non-bijective : puisque non-injective et non-surjective

dans le deuxième cas (\(f : \mathbb{R_+} \rightarrow \mathbb{R}\)) la fonction (\(f : x \longrightarrow x^2\)) est :

• injective : Les éléments de l’ensemble d’arrivée ont au plus un antécédent
• non-surjective : des éléments de l’ensemble d’arrivée n’ont pas d’antécédent (ex : \(y=-4\) n’a pas d’antécédent)

dans le troisième cas (\(f : \mathbb{R} \rightarrow \mathbb{R_+}\)) la fonction (\(f : x \longrightarrow x^2\)) est :

• non-injective : deux éléments de l’ensemble de départ ont la même image \(\{ -1,+1 \} \rightarrow \{ +1 \}\)
• surjective : tout élément de l’ensemble d’arrivée a au moins un antécédent
• non-bijective : puisque non-injective

dans le dernier cas (\(f : \mathbb{R_+} \rightarrow \mathbb{R_+}\)) la fonction (\(f : x \longrightarrow x^2\)) est :

• injective : Les éléments de l’ensemble d’arrivée ont au plus un antécédent
• surjective : tout élément de l’ensemble d’arrivée a au moins un antécédent
• bijective : puisque injective et surjective

Une solution possible :

SELECT * FROM A;
SELECT * FROM B;

-- A xor B --
SELECT x AS "A xor B"  FROM A WHERE x NOT IN (SELECT y FROM B)
UNION
SELECT y FROM B WHERE y NOT IN (SELECT x FROM A);

Pour aller plus loin : on peut aussi exprimer la disjonction exclusive avec l’opérateur de jointure FULL OUTER JOIN mais cet opérateur n’est pas implémenté en SQLite par contre le lecteur intéressé pourra le tester sous PostgreSQL par exemple. Les différentes jointures (INNER,OUTER,NATURAL) seront détaillées dans le chapitre SQL.

code SQL pour la disjonction exclusive à l’aide de jointure :

SELECT COALESCE(A.x, B.y) AS "A xor B"
FROM  A FULL OUTER JOIN B
ON A.x = B.y
WHERE A.x IS NULL OR B.y IS NULL;

Une solution possible :

On peut reformuler la phrase : « Pour que les étudiants réussissent, il faut qu’ils étudient. »

par : « Si les étudiants étudient alors ils réussissent »

D’où les propositions :

• \(P\) : « les étudiants étudient »
• \(Q\) : « les étudiants réussissent »

En représentant la table de vérité de l’implication (Si P alors Q) :

Implication
P	Q	P => Q
0	0	1
0	1	1
1	0	0
1	1	1

On peut interpréter les différents cas :

1. \(P,Q\) sont toutes deux fausses : les étudiants n’étudient pas et ils ne réussissent pas (c’est classique !)
2. \(P\) fausse, \(Q\) vraie : les étudiants n’étudient pas et ils réussissent (ça arrive, mais c’est rare !)
3. \(P\) vraie, \(Q\) fausse : les étudiants étudient et ils ne réussissent pas (ce n’est pas possible !)
4. \(P\) vraie, \(Q\) vraie : les étudiants étudient et ils réussissent (c’est normal !)

Une solution possible :

Définition en intension :

\(E=\{ 2^n | n \in \mathbb{N} \land n>=0 \land n<=8 \}\)

Cet ensemble représente les puissances de 2 allant de 1 jusqu’à 256.

Si l’on veut étendre cet ensemble à tous les entiers naturels :

• \(E=\{ 2^n | n \in \mathbb{N} \}\)

Une solution possible :

\(\mathscr{P}(E)=\{ \{ \}, \{ 1 \}, \{ 2 \}, \{ 3 \}, \{ 1,2 \},\{ 1,3 \},\{ 2,3 \},\{ 1,2,3 \} \}\)

on vérifie bien :

• \(card(\mathscr{P}(E))=2^{card(E)}\)
• \(8=2^3\)

Une solution possible :

Une solution possible :

• \(coordonnes=\{(x,y) | x\in abscisses \land y \in ordonnees \}\)

CREATE TABLE abscisses (x INTEGER);
CREATE TABLE ordonnees (y INTEGER);

INSERT INTO abscisses VALUES(0);
INSERT INTO abscisses VALUES(1);
INSERT INTO ordonnees VALUES(0);
INSERT INTO ordonnees VALUES(1);

CREATE VIEW coordonnees AS
SELECT * FROM abscisses,ordonnees;

SELECT * FROM coordonnees;

Pour créer dans une vue les coordonnées d’un cube unitaire, il faudrait créer un nouvel ensemble (table « altitudes ») avec les valeurs \(\{0,1\}\) et faire le produit cartésien entre les trois tables.

Une solution possible :

Les bars qui servent de la « Chouffe » (DRC)

• \(Q=\{bar | services(bar,biere='Chouffe')\}\)

Les bières servies au « Bar du Coin » (TRC)

• \(Q=\{s.biere | services(s) \land s.bar='Bar \; du \; Coin'\}\)

Les deux notations sont équivalentes, cependant la notation en calcul relationnel de n-uplet (TRC) est plus représentative sur la manipulation d’éléments dans un ensemble et de formulation logique.

On pourrait écrire de la même manière :

• \(Q=\{s.biere | s \in services \land s.bar='Bar \; du \; Coin'\}\)

qui définit bien la proposition logique que l’ensemble des éléments doit vérifier :

• \(Q=\{x | P(x) \}\)

où, dans notre cas la fonction caractéristique de l’ensemble est :

• \(P(x)= (x \in services \land x.bar='Bar \; du \; Coin')\)

on doit vérifier que le service proposant la biere en question est (appartient) bien dans l’ensemble des services et qu’il concernera le 'Bar du Coin'.

Une solution possible :

les bars qui servent de la « Chouffe » (DRC)

• \(Q=\Pi_{(bar)}(\sigma_{[biere='Chouffe']}(services))\)

Lorsque l’expression utilise plusieurs opérateurs de l’algèbre relationnelle on peut décomposer la recherche en plusieurs étapes :

• \(R_1=\sigma_{[biere='Chouffe']}(services)\)
• \(R_2=\Pi_{(bar)}(R_1)\)
• \(Q=R_2\)

Attention : il ne faut pas inverser les opérations de restriction et projection. La requête ci-dessous ne sera pas valide :

• \(Q=\sigma_{[biere='Chouffe']}(\Pi_{(bar)}(services))\)

Le résultat de l’opération de projection (\(\Pi\)) ne permettra pas d’avoir accès à l’attribut biere pour pouvoir établir la condition (\([biere='Chouffe']\)) de l” opération de restriction (\(\sigma\)) .

Une solution possible :

\(R=\{(r.a,s.e) | R(r) \land S(s) \land r.b=s.d \land r.c=s.d\}\)

On aurait également pu décomposer le calcul relationnel :

• \(R_1=\{(r,s) | R(r) \land S(s) \}\) (produit cartésien)
• \(R_2=\{r_1 | R_1(r_1) \land r_1.b=r_1.d \land r_1.c=r_1.d \}\) (restriction)
• \(R=\{(r_2.a,r_2.e) | R_2(r_2) \}\) (projection)

qui représentera l’ordre d’application des opérateurs de l’algèbre relationnelle.

Remarque :

• on ne pourrait pas appliquer d’abord les restrictions puisque chacune des conditions s’applique sur les attributs des deux tables. Cette requête ne pourra donc pas être optimisée en appliquant les restrictions avant le produit cartésien.

Une solution possible :

• \(R_1=\sigma_{[biere='Chouffe']}(services)\)
• \(R_2=\Pi_{(bar)}(R_1)\)
• \(Q=R_2\)

Attention : il ne faut pas inverser les opérations de restriction et projection

L’arbre de requêtes ci-dessous traitera d’abord l’opération de projection et nous n’aurons plus accès aux informations sur l’attribut biere pour pouvoir faire l’opération de restriction.

Une solution possible :

Pour écrire cette requête on doit exclure les sportifs qui feraient du rugby et qui seraient en catégorie « junior »

On a donc une disjonction exclusive (\(\oplus\)) :

• \(P \oplus Q = (P \land \neg Q) \lor (\neg P \land Q)\).

sur les propositions :

• \(P\) : sportifs qui font du rugby
• \(Q\) : sportifs en catégorie « junior »

On a donc les conditions :

• \((P \land \neg Q)\) : (activite="rugby" and categorie!="junior")
• \((\neg P \land \neg Q)\) : (activite!="rugby" and categorie="junior")

La requête SQL pourrait donc s’écrire :

SELECT *
FROM sportifs s
WHERE  (activite="rugby" and categorie!="junior")
    OR (activite!="rugby" and categorie="junior");

Une solution possible :

de la phrase : « Si l’accusé est coupable il n’a pas d’alibi. »

nous pouvons établir les propositions suivantes :

• \(P\) : « l’accusé est coupable »
• \(Q\) : « il n’a pas d’alibi »

Et donc l’implication : SI \(P\) ALORS \(Q\)

En représentant la table de vérité de l’implication :

Implication
P	Q	P => Q
0	0	1
0	1	1
1	0	0
1	1	1

On peut interpréter les différents cas :

1. \(P,Q\) sont toutes deux fausses : l’accusé n’est pas coupable et il a un alibi (ç’est classique !)
2. \(P\) fausse, \(Q\) vraie : l’accusé n’est pas coupable et il n’a pas d’alibi (ça arrive !)
3. \(P\) vraie, \(Q\) fausse : l’accusé est coupable et il a un alibi (ce n’est pas possible, l’alibi ment !)
4. \(P\) vraie, \(Q\) vraie : l’accusé est coupable et il n’a pas d’alibi (c’est normal !)

Une solution possible :

de l’implication : \(f(x)=f(y) \Rightarrow x=y\)

nous pouvons établir les propositions suivantes :

• \(P \; : \; f(x)=f(y)\)
• \(Q \; : \; x=y\)

et représenter la table de vérité :

Implication
P	Q	P => Q
0	0	1
0	1	1
1	0	0
1	1	1

On peut alors interpréter les différents cas :

1. \(P,Q\) sont toutes deux fausses : les images et les antécédents sont différents

   

   Dans ce cas l’application pourrait être injective, surjective ou bijective

2. \(P\) fausse, \(Q\) vraie : les images sont différentes pour un même antécédent

   

   Dans ce cas l’application pourrait être injective ou surjective

3. \(P\) vraie, \(Q\) fausse : les images sont les mêmes pour deux antécédents différents

   

   Dans ce cas l’application ne peut pas être injective (l’image doit avoir au plus un antécédent)

4. \(P\) vraie, \(Q\) vraie : les images sont les mêmes pour le même antécédent

   

   Dans ce cas l’application pourrait être injective, surjective ou bijective

Il n’y a que le troisème cas qui sera faux si l’application est injective.

On a donc bien : \(f(x)=f(y) \Rightarrow x=y\)

La définition d’une application surjective étant que tout élément de l’ensemble d’arrivée doit avoir au moins un antécédent dans l’ensemble de départ, il suffirait donc d’ajouter une image sans antécédent dans l’ensemble d’arrivée pour éviter la possibilité d’avoir une application surjective.

La contraposée de l’implication :

• \(f(x)=f(y) \Rightarrow x=y\)

est :

• \(x \; !=y \Rightarrow f(x) \; !=f(y)\)

nous pouvons établir les propositions suivantes :

• \(P \; : \; x \; !=y\)
• \(Q \; : \; f(x) \; !=f(y)\)

1. \(P,Q\) sont toutes deux fausses : les images et les antécédents sont égaux

   

   Dans ce cas l’application pourrait être injective, surjective ou bijective

2. \(P\) fausse, \(Q\) vraie : pour un même antécédent les images sont différentes

   

   Dans ce cas l’application pourrait être injective ou surjective

3. \(P\) vraie, \(Q\) fausse : pour deux antécédents différents les images sont les mêmes

   

   Dans ce cas l’application ne peut pas être injective (l’image doit avoir au plus un antécédent)

4. \(P\) vraie, \(Q\) vraie : pour deux antécédents différents les images sont différentes

   

   Dans ce cas l’application pourrait être injective, surjective ou bijective

Il n’y a toujours que le troisième cas qui sera faux si l’application est injective.

On a donc bien l’équivalence logique :

• \(x!=y \Rightarrow f(x)!=f(y) \Leftrightarrow f(x)=f(y) \Rightarrow x=y\)

La contraposée de l’implication est équivalent logiquement à l’implication.

La réciproque de l’implication :

• \(f(x)=f(y) \Rightarrow x=y\)

est :

• \(x=y \Rightarrow f(x)=f(y)\)

nous pouvons établir les propositions suivantes :

• \(P \; : \; x=y\)
• \(Q \; : \; f(x)=f(y)\)

1. \(P,Q\) sont toutes deux fausses : les antécédents et les images sont différents

   

   Dans ce cas l’application pourrait être injective, surjective ou bijective

2. \(P\) fausse, \(Q\) vraie : pour deux antécédents différents les images sont les mêmes

   

   Dans ce cas l’application ne peut pas être injective (l’image doit avoir au plus un antécédent)

3. \(P\) vraie, \(Q\) fausse : pour un même antécédent les images sont différentes

   

   Dans ce cas l’application pourrait être injective ou surjective

4. \(P\) vraie, \(Q\) vraie : pour un même antécédent les images sont les mêmes

   

   Dans ce cas l’application pourrait être injective, surjective ou bijective

Si la réciproque de l’implication était logiquement équivalente à cette définition d’une application injective, seul le troisième cas devrait être faux.

La réciproque de l’implication n’est pas équivalente logiquement à l”implication.

Une solution possible :

la requête SQL ci-dessous permettra de retrouver les sportifs qui auraient plus de 18 ans et ne seraient pas inscrits en catégorie « senior » et, en cas de problème d’inscription, les sportifs qui auraient moins de 18 ans et auraient été inscrits en catégorie « senior ».

SELECT *
FROM sportifs
WHERE  (age >18 AND categorie!="senior") OR  (age <= 18 AND categorie="senior");

La négation de la condition de cette requête nous retournera les informations sur les sportifs qui ont plus de 18 ans et qui sont bien inscrits en catégorie « senior » :

SELECT *
FROM sportifs
WHERE  (age <=18 OR categorie="senior") AND  (age > 18 OR categorie!="senior");

A partir des propositions :

• p : \(age > 18\)
• q : \(categorie="senior"\)

et de l’équivalence logique de l’implication :

• \((p \Rightarrow q) \Leftrightarrow (\neg p \lor q)\)

et de l’équivalence logique de l’équivalence logique :

• \((p \Leftrightarrow q) \Leftrightarrow (p \Rightarrow q \land q \Rightarrow q)\)

On peut vérifier que (équivalence logique de l’implication) :

• \((p \Rightarrow q)\) : \((age >18 \Rightarrow categorie="senior") \Leftrightarrow (age \leq 18 \lor categorie="senior")\)
• \((q \Rightarrow p)\) : \((categorie="senior" \Rightarrow age >18) \Leftrightarrow (categorie!="senior" \lor age > 18 )\)

Et donc que le critère de restriction de la clause WHERE de la requête précédente revient exprimer l’équivalence logique de l’équivalence logique (\((p \Leftrightarrow q) \Leftrightarrow (p \Rightarrow q \land q \Rightarrow q)\)) :

• \((age > 18) \Leftrightarrow (categorie="senior")\)

Par conséquent :

• avoir plus de 18 ans est logiquement équivalent à être inscrit en catégorie « senior »

puisque l’on a vérifié :

• \((age >18 \Rightarrow categorie="senior") \land (categorie="senior" \Rightarrow age >18)\)

Autrement dit avoir plus de 18 ans est logiquement équivalent à être inscrit en catégorie « senior ». Ce qui revient à dire que si les sportifs on plus de 18 ans alors ils sont en catégorie « senior » et que s’ils sont en catégorie « senior  » alors ils doivent avoir plus de 18 ans.

Nous pouvons donc formuler la requête SQL ci-dessous pour répondre à cette question.

SELECT *
FROM sportifs
WHERE   (age<=18 OR categorie="senior") AND (categorie!="senior" OR age>18);

Au fait c’était quoi la question ?

Ceci dit, cette requête aurait pu simplement être exprimée par la recherche :

• trouver les sportifs qui ont plus de 18 ans et sont seniors ou ceux qui, s’ils ont moins de 18 ans, ne sont pas seniors

qui s’exprimera en SQL par la requête ci-dessous :

SELECT *
FROM sportifs
WHERE  (age>18 AND categorie="senior") OR (age<=18 AND categorie!="senior");

On peut vérifier que les deux requêtes ci-dessus sont équivalentes, toujours à partir des propositions :

• p : \(age > 18\)
• q : \(categorie="senior"\)

Et en utilisant l’équivalence logique :

• \((\neg p \lor q) \land (\neg q \lor p) \Leftrightarrow (p \land q) \lor (\neg p \land \neg q)\)

Qu’il suffit de prouver !

Le lecteur pourra vérifier cette équivalence logique en établissant les tables de vérités des deux formules définies dans cette équivalence logique.

On pourra également utiliser les propriétés de l’algèbre de Boole, notamment les lois de distributivité des connecteurs logiques et les propriétés de l’élément neutre de la conjonction (\(\land\)) et de la complémentarité de la disjonction (\(\lor\)) .

Lois de la distributivité des connecteurs logiques :

• \(p \lor (q \land r) = (p \lor q) \land (p \lor r)\)
• \(p \land (q \lor r) = (p \land q) \lor (p \land r)\)

appliquées à la formule :

• \((p \land q) \lor (\neg p \land \neg q)\)

on trouve :

• \(((p \lor \neg p) \land (p \lor \neg q)) \land ((q \lor \neg p) \land (q \lor \neg q))\)

A partir des propriétés de :

• complémentarité de la disjonction : \(p \lor \neg p = 1\)
• élément neutre de la conjonction : \(p \land 1 = p\)

la formule précédente devient :

• \((p \lor \neg q) \land (q \lor \neg p)\)

On en vérifie donc bien l’équivalence logique :

• \((\neg p \lor q) \land (\neg q \lor p) \Leftrightarrow (p \land q) \lor (\neg p \land \neg q)\)