Bonsoir,
Envoyé par
escartefigue
J'avoue être complètement perdu par cette présentation : j'ai mis en couleur ce qui me semble faux, mais sans doute est-ce du au fait que je n'arrive pas à lire ce tableau
Quoi qu'il en soit vrai ou inconnu donne vrai et non inconnu
Dans le tableau que j’ai présenté, vrai ou inconnu donne bien vrai. Je suis désolé si la présentation paraît sibylline, mais c’est celle de C .J. Date (francisée), qu’il fournit ça et là, par exemple à la page 333 de Date on Database: Writings 2000-2006, et qu’il reprend chez Codd, voyez le paragraphe 8.9 « The Three-Valued Logic of RM/V1 », page 236 de l’ouvrage (téléchargeable) The Relational Model for Database Management, Version 2.
Dans cet ouvrage, la présentation des tables de vérité par Codd est la suivante (francisée) :
A | NON A
-----------+--------
vrai | faux
inconnu | inconnu
faux | vrai
| B
|-------------------------
A ET B | vrai | inconnu | faux
------------+---------+---------+-----
| vrai | vrai | inconnu | faux
A | inconnu | inconnu | inconnu | faux
| faux | faux | faux | faux
| B
|-------------------------
A OU B | vrai | inconnu | faux
------------+---------+---------+--------
| vrai | vrai | vrai | vrai
A | inconnu | vrai | inconnu | inconnu
| faux | vrai | inconnu | faux
Cela dit, votre tableau est vraisemblablement plus facile à lire.
Envoyé par
SQLpro
SQL étant un langage normalisé, la norme nous dit ceci :
Les 3 valeurs de tests de la logique ternaire sont :
•True
•False
•Unknown
On est d’accord, inconnu (unknown) est bien une valeur.
Envoyé par
SQLpro
Page 24 :
The data type boolean comprises the distinct truth values true and false.
Unless prohibited by a NOT NULL constraint, the boolean data type also supports the unknown truth value as the null value.
CQFD
Hum... Dans son ouvrage SQL and Relational Theory, au chapitre 4 « No Duplicates, No Nulls », C.J. Date ne manque pas de remettre les pendules à l’heure et montre que cet énoncé est faux, à savoir que Null et la « valeur de vérité unknown » ne sont pas interchangeables.
Histoire de troller un peu, Je répète ce que j’ai déjà écrit (post #13) à propos de cet énoncé :
« Comme le note malicieusement Peter Gulutzan (|i]SQL-99 Complete, Really[/i], page 212), selon la norme il revient au même de dire : « Je ne sais pas » et « Je sais que l’information est absente » ! »
Dans SQL and Relational Theory, Date relève « quelques » inepties et approximations dans SQL en relation avec NULL. Par exemple, je trouve que la remarque suivante qu’il fait est de bon sens et caractérise les approximations de la norme sur le sujet :
« NOT NULL doesn’t apply to data types, it applies to uses of data types (typically as part of column definition). »
Il est aussi écrit dans la norme :
« All boolean data type values and SQL truth values are mutually comparable and assignable. The value true is greater than the value false, and any comparison involving the null value or an unknown truth value will return an unknown result. »
Je vous renvoie aux commentaires de Date...
Envoyé par
Artemus24
Nous sommes d'accord sur le fait que la valeur NULL est une marque pour indiquer l'absence de valeur. Inutile de revenir sur ce point.
Une fois encore, on ne peut pas accoler valeur et NULL.
Envoyé par
Artemus24
Sauf qu'ici, on substitue Inconnue par NULL ?????
On n’a pas à substituer. Si l’évaluation d’une expression donne inconnu au lieu de vrai ou faux, le SGBD doit réaliser le marquage. Dans le cas de DB2 for z/OS, marquer à Null consiste à remplacer X'00' par X'FF' dans l’octet de service fait pour ça, associé à chaque cellule concernée.
Envoyé par
Artemus24
Le OU logique se comporte comme la recherche du maximum dans le classement : Faux < Inconnu < Vrai.
Le ET logique se comporte comme la recherche du minimum dans le classement : Faux < Inconnu < Vrai.
Ce qui revient à dire que Faux = 0 et Vrai = 1. Alors Inconnu est une valeur comprise entre 0 et 1.
Certes. Et cela vaut pour la norme SQL, comme il y est écrit (cf. ci-dessus), « All boolean data type values and SQL truth values are mutually comparable » : « TRUE > FALSE » est donc légal et renvoie TRUE, par contre, selon la norme « TRUE > UNKNOWN » est légal, mais renvoie NULL (UNKNOWN)...
Envoyé par
Artemus24
si c'est une marque, et bien ce n'est pas une valeur et de ce fait, il ne peut pas être traité dans la logique ternaire de Kleene.
La logique trivaluée de SQL ou de Codd se contente du domaine (type) booléen étendu à trois valeurs : {vrai, faux, inconnu}.
Envoyé par
Artemus24
On remarque que la logique binaire est incluse dans la logique ternaire de Kleene.
Tout comme elle est incluse dans la logique ternaire de Chamberlin, quand celui-ci a défini les tables de vérité de SQL, en 1976, logique qui aurait plus à voir avec celle de Bochvar, même si elle n’en est pas issue : je vous renvoie à l’article de David McGoveran, « Classical Logic: Nothing Compares 2 U », paru en janvier 1994 dans Database Programming & Design. J’en extrais ceci :
The most common versions of many-valued logic are variations on other systems, such as those developped by Łukasiewicz, Post and Kleene. Variations of Łukasiewicz’s systems are sometimes referred to as the basis for SQL’s 3VL. While this supposition cannot be true,⁴ it is worth examining the properties of the Łukasiewicz systems. Łukasiewicz systems are not truth functionally complete (so the system would not be able to verify some facts using the available operators), nor are they natural extensions of the classical propositional logic. Certain tautologies of the propositional logic cease to be true in the Łukasiewicz systems, and, conversely, certain tautologies of the Łukasiewicz systems have no counterpart in the propositional logic. In our terminology, they are deviants.
Łukasiewicz’s where intended to treat contingent (especially future contingent) propositions as meaning "temporarily unknown." The "UNKNOWN" in his 3VL is similar to Codd’s A-marks. For example, the truth value of "it will rain tomorrow" would be "UNKNOWN", but would eventually be determined as either "TRUE" or "FALSE". Therefore the Łukasiewicz "UNKNOWN" is a temporary placeholder for a standard truth value. These various facts about Łukasiewicz systems eliminate them from further considerations: They are not candidates for use as a DBMS’s logical system. We can prove that some many-valued logics are truth functionally complete (all are consistent by definition if at least one truth value is undesignated), but have semantics clearly inappropriate for a DBMS. Here are a few examples: in Post’s systems, truth valuations apply only to sets of propositions (that is, sets of rows), each individual proposition having a classical truth valuation, rather than the individual propositions. Kleene had in mind the truth valuations of propositions involving mathematical functions undefined for certain ranges of predicate values. The concept of undefined is similar to the purpose of Codd’s I-marks. Bochvar created a system with a set of "internal" truth tables and a set of "external" truth tables, treating unknown as "undecidable" or "meaningless". This system is similar to SQL in the sense that SQL effectively returns false (the external system) to the user when the answer is unknown (the internal system), but Bochvar’s systems are dissimilar in other respects.
[...]
⁴ Łukasiewicz gave "IMPLIES" and "NOT" as his primitive connectives, deriving "OR" and "AND" from them. His definition of "IMPLIES" is different from that used in the propositional or predicate calculi, which define "P IMPLIES Q" as "NOT P OR Q". In fact, Łukasiewicz ‘s version of "IMPLIES" cannot be derived from the definition of "NOT", "AND", and "OR". This is because "NOT", "AND", and "OR" each preserve "UNKNOWN" from the inputs (and therefore so do any combinations of these), whereas Łukasiewicz version of IMPLIES does not. Since SQL does not define IMPLIES, claims that "it is based on a variant of Łukasiewicz’s 3VL" must be false!
[...]
Envoyé par
Artemus24
Si c'est une valeur, alors on peut appliquer la logique ternaire de Kleene.
A ceci près que, si j’en crois McGoveran, la « troisième valeur de vérité » de Kleene correspond à la marque I-Mark de Codd (traduisible par « sans objet », « inapplicable »). La marque A-Mark (« inconnu », « applicable ») ne serait donc pas prise en considération par Kleene.
Envoyé par
Artemus24
C'est ce point qui me pose le plus de problème, à savoir traiter la marque comme une valeur.
On sort de SQL...
Envoyé par
Artemus24
Un des opérateur qui me pose un problème d'interprétation est le 'IN'.
Date nous avertit (page 363 de SQL and Relational Theory, Third Edition) qu’à l’origine SQL a été conçu pour ne pas être plaqué sur l’algèbre relationnelle ou sur le calcul relationnel, estimés trop compliqués pour les utilisateurs que nous sommes (avec le temps SQL a grossi et comporte de l’algèbre et du calcul), donc « IN » peut effectivement poser un problème d’interprétation. Néanmoins, on peut l’interpréter comme l’équivalent SQL de l’opérateur d’appartenance à un ensemble « ∈ » (cf. page 91 de l’ouvrage).
Reprenons la requête :
SELECT P.*
FROM P
WHERE P.Weight NOT IN (SELECT P.Weight
FROM P
WHERE P.City = 'Oslo') ;
Cela dit, (cf. le même ouvrage, page 434) IN peut être remplacé par =ANY et NOT IN par <> (bien que Date recommande de n’en rien faire pour des raisons d’erreurs d’interprétation de notre part, vite arrivées) :
SELECT P.*
FROM P
WHERE P.Weight <> (SELECT P.Weight
FROM P
WHERE P.City = 'Oslo') ;
Envoyé par
Artemus24
Et rien du tout, ce n'est pas une ligne contenant que des NULL.
S’attendre un résultat vide est bien légitime, mais MySQL a affiché une ligne où chaque colonne est marquée NULL... Cela dit, la requête suivante renvoie 0 :
SELECT COUNT(*) FROM
(SELECT P.*
FROM P
WHERE P.Weight NOT IN (SELECT P.Weight
FROM P
WHERE P.City = 'Oslo')
) as truc
;
Répondre avec citation
de mon aide, vous pouvez cliquer sur 
.
Partager