Discussion :

[Antoun]

Inutile, car les NULL sont ignorés lors des opérations d'agrégats. Or une somme de NULL ignorés ou de zero donne le même résultat.

Pour dire la même chose que J1 en plus court : une somme de NULL ignorés donne NULL, tandis qu'une somme de zéros donne zéro (ou la tête à Toto ).

[corrector]

Je ne comprends pas pourquoi la somme des éléments d'un ensemble vide ne donne pas 0.

Y a t-il une justification à cette règle?

[Antoun]

@corrector :
J1 a très bien justifié ça quelques messages plus haut :

Or cette dernière requête [càd SUM(NULL)]renvoie bien NULL. Non pas parce que SUM tente de sommer NULL, mais au contraire parce que SUM exclut NULL de la somme et n'a donc rien à sommer. En conséquence, la fonction renvoie NULL pour indiquer que le résultat de cette somme est indéfini, car sans opérande

[fsmrel]

Bonsoir tous,

En modélisation de données (schéma ER) le NULL existe.

Avez-vous des références de théoriciens de l’E/R à ce sujet ? Je suis intéressé car en l’occurrence je suis démuni.

En revanche, si vous modélisez via le schéma ER avec la notaion de votre choix (Merise, IDEF1X, E/R, UML2...) alors là vous utilisez les formes normales, pour lesquelles le NULL est un aspect parmi d'autres...

De quelles formes normales parlez-vous ? Concernant la méthode Merise, on y trouve au niveau du MCD un concept de DF radicalement différent de celui (datant de 1971) de la théorie relationnelle : en Merise, une DF met en jeu une contrainte d’unicité entre des entités-types en relation par le biais d’une association-type, alors que la théorie relationnelle met en jeu cette contrainte entre des sous-ensembles d’attributs d’une relvar (informellement table) et une seule. De même, la normalisation au sens Merise du terme, concerne seulement les associations-types : un attribut d’une association-type ne doit pas être "vérifié" par rapport à un sous-ensemble strict des entités-types faisant partie de la collection de ces entités-types participant à l’association-type (on a là une sorte d’analogie avec la 2NF de la théorie relationnelle).

Concernant IDEF1X, E/R, UML2, j’aimerais savoir comment ils sont positionnés au plan théorique par rapport à la normalisation.

Mais peut-être parlez-vous de traiter les entités-types, associations-types, classes, comme des relvars, auquel cas il faudra, outre les DF, mettre en évidence les DM et autres DJ, ainsi que l'ensemble des clés candidates (dont on exclut ce qui n’est pas attribut, par exemple les OID). Même sans pousser la normalisation dans les tréfonds de la fermeture et de la couverture irréductible, à coups d’axiomes d’Armstrong, pour des raisons évidentes de temps et de nausée garantie...

Concernant la façon dont NULL est perçu dans le contexte des formes normales, je rappelle que les énoncés relatifs à celles-ci sont muets (je fais évidemment référence aux seuls inventeurs, c'est-à-dire Codd, Heath, Boyce et Fagin).

Pour en revenir à Merise, une approche pragmatique et courante concernant l’absence d’information correspond à celle que l’on retrouve chez Diviné, dans Parlez-vous Merise ?, page 182 : «Les vélos on un moteur "à blanc" au niveau physique» (c'est-à-dire au niveau relationnel (gloups !), cf. page 171...)

Cependant, je rappellerais la 6eme forme normale (pour les jusqu'auboutistes) :
Une relation se réduit à un ensemble d'attributs formant la clef et au plus un seul attribut non clef.
Comme cela pas de jaloux : plus besoin de NULLs...

Si SQL impose que les attributs composant la clé primaire d'une table T soient définis comme NOT NULL, il n’en va pas de même pour l’attribut non clé. Et si l’on n’en connaît pas la valeur lors de l’injection de la donnée correspondante dans la base, on pourra donc éprouver le besoin d’avoir recours à NULL...

Pardonnez-moi, mais votre définition de la 6NF est un peu sommaire, car elle omet les dépendances de jointure (en particulier triviales), à la base de cette forme normale : Une relvar est en 6NF si et seulement si elle ne comporte aucune DJ triviale. Je ne me lancerai pas dans un débat sur cette forme normale, mais permettez-moi quand même une digression : Avec son bon sens habituel, Chris Date rappelle que la décomposition des relvars en composants irréductibles n’offre d’intérêt que pour les attributs auxquels on associe une dimension temporelle, au sens période du terme (informellement début et fin, par exemple la date d’entrée d’une personne dans une entreprise et sa date de démission). C’est le contraste opposant ce que l’auteur appelle le SINCE (un fournisseur est sous contrat depuis telle date) et le DURING (ce même fournisseur a été sous contrat pendant telle(s) périodes(s)). Se reporter à son ouvrage Introduction to Database Systems, chapitre 23.

Concrètement, si les attributs d'une relvar ne sont pas concernés par les dates de fin, le respect de la 5NF suffit largement.

[fsmrel]

Bonsoir,

...effectivement, cela me rappelle quelques lignes enflammées de Celko sur l'abominable hérésie Chrisdatiste !

Ça fait au moins 10 ans que je n’ai pas lu quelque chose de Celko (c’était du temps de Database Programming & Design). J’en ai gardé le souvenir de quelqu’un doté d’une imagination fertile, bien plus fort que moi en SQL, mais manquant de rigueur et pas très regardant au plan théorique. Pour tout dire j’ai toujours été circonspect à son sujet.

Concernant l’hérésie de Date, je note que celui-ci fut dans l’orthodoxie au moins jusqu’en 1979, puisque ce n’est qu'à partir de ce moment-là que Codd traita de NULL (Cf. Extending the Database Relational Model to Capture More Meaning).

Dans la 4e édition (1986) de "An Introduction to Database Systems", Date n’a manifestement pas d’état d'âme et c’est l’époque du grand amour avec Codd (du temps où ils avaient quitté IBM et montèrent Codd & Date Limited). Dans la 5e édition du même ouvrage(1990), il évolue concernant l’absence d’information (pages 384 et suivantes) :

"...SQL-style nulls are not a solution..."

"...Codd now regards his approach as an integral part of the relational model... we feel that the incorporation of such a feature into the model is premature at this time, and that it would be preferable to wait until the problem is better understood..."

Dans son ouvrage "Relational Database, Writings 1985 - 1989", Date creuse le sujet, notamment dans le chapitre 8 (NOT is Not "Not") et son copain Hugh Darwen l’accompagne et donne des coups de bélier, voir le chapitre 23 (Into the Unknown) que l'on doit à Hugh.

La rupture avec Codd est consommée avec l’article paru dans Database Programming & Design (octobre 1993) "Much Ado about Nothing", dans lequel les deux protagonistes débattent et réfutent à tout va. Appelez hérésie la position de Date : je dirais plutôt qu’il est retourné au Modèle relationnel traditionnel, d’avant 1979, pour le faire évoluer autrement, en collant à la logique d’Aristote et de Frege. Cela n’a rien d’abominable...

L’abomination est à chercher ailleurs...

[Antoun]

Appelez hérésie la position de Date : je dirais plutôt qu’il est retourné au Modèle relationnel traditionnel, d’avant 1979, pour le faire évoluer autrement, en collant à la logique d’Aristote et de Frege. Cela n’a rien d’abominable...

L’abomination est à chercher ailleurs...

Disons que je tentais d'exprimer l'impression que l'on retire des lignes de Celko (qui n'utilise évidemment pas le terme d'hérésie).

Merci beaucoup pour l'historique du schisme !