IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage SQL Discussion :

Dénormalisation de table. Quand ? [Débat]


Sujet :

Langage SQL

  1. #81
    Membre éclairé

    Développeur Web
    Inscrit en
    Mars 2002
    Messages
    412
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Mars 2002
    Messages : 412
    Points : 657
    Points
    657
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    J’ai extrait ce qui suit de l'article de Chamberlin (qui s’inspire de ce qu’il avait déjà écrit en 1994 avec trois de ses collègues chez IBM, « Extending relational database technology for new applications ») :
    Vos contributions sont précieuses. Grand merci. Vous m'avez instruit.

    Après avoir à nouveau retourné le problème dans ma tête aujourd'hui, je suis repassé à trois tables (la solution avec héritage). Je garde la redondance de la méthode du chemin mais j'hésite à la virer et mettre la récursion (qui devrait être rare) dans l'application.

    Citation Envoyé par CinePhil Voir le message
    laffreuxthomas, tu devrais proposer ton MCD dans le forum Schéma mais en tout cas, ça, c'est vraiment affreux, Thomas !
    J'avoue avoir un peu peur de me faire taper pour ne pas être capable de vous soumettre un beau dessin. Je n'ai aucun logiciel pour faire ça bien que j'aie noté celui proposé par CinéPhil. Et d'ailleurs mon schéma principal ne contient que trois tables. Alors je raisonne direct en DDL…

    Malgré tout il serait intéressant de discuter des différentes manières de représenter des arbres. Avez-vous parcouru l'exposé indiqué plus haut ? Ce que j'aime bien dans la méthode du chemin, c'est que son volume en base est proportionnel au nombre des éléments. Contrairement à la méthode de la table externe contenant toutes les combinaisons "ascendant-descendant" qui, elle, est proportion du carré du nombre des éléments (j'édite pour barrer, c'est une bêtise).

  2. #82
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Postez votre cas particulier dans une discussion séparée et dans le forum approprié.

    En l'occurrence, puisqu'il s'agit plus de discuter du modèle de données que de langage SQL, je vous recommande vivement de créer votre nouvelle discussion dans le forum Schéma dont j'ai donné le lien plus haut.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  3. #83
    Membre éclairé

    Développeur Web
    Inscrit en
    Mars 2002
    Messages
    412
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Mars 2002
    Messages : 412
    Points : 657
    Points
    657
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    En l'occurrence, puisqu'il s'agit plus de discuter du modèle de données que de langage SQL, je vous recommande vivement de créer votre nouvelle discussion dans le forum Schéma dont j'ai donné le lien plus haut.
    C'est fait.

  4. #84
    Membre éprouvé Avatar de redoran
    Homme Profil pro
    Développeur-Amateur
    Inscrit en
    Juin 2010
    Messages
    1 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur-Amateur
    Secteur : Santé

    Informations forums :
    Inscription : Juin 2010
    Messages : 1 346
    Points : 1 031
    Points
    1 031
    Par défaut Pourquoi dénormaliser une table ?
    salut ; pourquoi dénormaliser une table ?
    généralement la dénormalisation est faite pour extraire les données rapidement ( gain de temps) .
    quand peut-on dénormaliser ?
    pour me répondre à cette question , je crois que certains le font a défaut de conception ( modélisation incorrecte) là du coté du concepteur.
    d'autres le font dans les cas suivants :
    1. pour éviter le jointures sur plusieurs tables,
    2. pour faciliter les calculs sur des colonnes de table différentes, je ne sais d'autres motifs d'utilisation... !

    devant ces arguments , le choix de dénormaliser est-il bien pensé ?
    normalement on doit cherché des solutions coté normalisation , indexation et utilisation de requête avancées.
    coté fonctionnement SGBDR:
    je ne suis pas expert dans la matière , mais je crois que le SGBDR est doté d'un optimiseur basé sur des algorithmes avancés pour prendre en charge les requêtes dans un délai optimal.
    Est ce que les limites des SGBD nous poussent à dénormaliser ?

  5. #85
    Invité
    Invité(e)
    Par défaut
    Pour répondre à Redoran : la dénormalisation est souvent pratiquée quand le SGBDR est chargé à la fois en données et en connexions. Les MCDs exposés sur ce forum, sont souvent très contractés et facile de compréhension, mais dans "la vraie vie" ils sont souvent très complexes et difficiles à modéliser en restant fidèle aux normes. La dénormalisation prend en compte de nombreux paramètres : la manière de coder des développeurs, la solicitation de certaines procédures stockées et surtout mais vraiment surtout les temps de réponses du SGBDR de la forme normalisée rapport à une forme qui ne le serait pas. L'avantage de la forme normalisée est d'être rapidement compréhensible et facilite le développement mais aussi il est compréhensible à un public élargi. Mais comme toute chose une norme a des limites et parfois il faut prendre l'initiative de ne pas la respecter. Il existe de nombreuses manières de normaliser une BDD et il peut arriver qu'aucune ne réponde efficacement aux contraintes métiers existantes mais doivent aussi permettre d'être adaptable aux évolutions.
    Enfin, ce que je précise ici n'engage que moi. Mais de part mon expérience, je constate que les personnes qui s'offusquent de ces "dérives" sont
    en général les puristes alors que les donneurs d'ordres sont totalement satisfaits par les différents tests au moment de la réception, les maintenances effectuées ne sont jamais liées à un problème ne normalisation, mais plus à une évolution.
    Dernière modification par Invité ; 21/11/2012 à 22h10.

  6. #86
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par cladsous Voir le message
    Pour répondre à Redoran : la dénormalisation est souvent pratiquée quand le SGBDR est chargé à la fois en données et en connexions.
    Elle est, d'après ce que je lis sur les forums DVP, pratiquée surtout à tort et à travers !
    Même un SGBDR chargé en données et en connexions doit être capable de répondre rapidement à toute requête. Dans la grande majorité des cas, un modèle de données bien normalisé, une bonne indexation des tables et des requêtes bien écrites ne demanderont pas de dénormalisation pour obtenir de bonnes performances.

    Les MCDs exposés sur ce forum, sont souvent très contractés et facile de compréhension, mais dans "la vraie vie" ils sont souvent très complexes et difficiles à modéliser en restant fidèle aux normes.
    Mon exéprience se limite principalement à ce que je rencontre sur les forums de DVP et certains MCD exposés dans le forum Schéma sont parfois quand même un poil complexes.
    Par contre, j'ai aussi constaté que le modèle de données de l'ERP que j'utilise comprend de nombreuses redondances qui semblent quand même surtout dues à la mise en commun de modèles de données au départ indépendants. Et c'est vrai que reconcevoir l'ensemble représenterait un boulot gigantesque que personne n'a envie de prendre le temps de faire.

    La dénormalisation prend en compte de nombreux paramètres : la manière de coder des développeurs
    Surtout pas !
    Le modèle de données obéit à des règles de gestion des données qui ne doivent pas tenir compte de "la manière de coder des développeurs" !


    la solicitation de certaines procédures stockées
    Là encore, une procédure stockée étant un programme, elle ne doit pas contraindre le modèle de données mais au contraire s'y plier. Elle peut même être une aide au respect des contraintes sur les données issues des règles de gestion de celles-ci.

    et surtout mais vraiment surtout les temps de réponses du SGBDR de la forme normalisée rapport à une forme qui ne le serait pas.
    Voilà la seule raison qui devrait être prise en considération pour dénormaliser une BDD, après prototypage et tests approfondis et surtout après avoir vérifié les autres paramètres (modèle de données normalisé, indexation, écriture des requêtes, recours aux vues, aux vues matérialisées...).
    La dénormalisation doit être le dernier recours car elle engendre un risque d'incohérence des données et une lourdeur pour justement maîtriser ce risque.
    Je ne parle bien entendu là que de dénormaliser la BDD de production, pas d'en extraire les données d'une manière pratique pour en tirer des statistiques, donc de constituer un data wharehouse.

    L'avantage de la forme normalisée est d'être rapidement compréhensible et facilite le développement mais aussi il est compréhensible à un public élargi.
    Ce n'est pas son but, c'est une conséquence. Et même, cette affirmation est à pondérer car un "public élargi", s'il est un peu profane en modélisation des données, comprendra difficilement pourquoi il faut des tables associatives, de l'héritage de données, modéliser un calendrier, faire une arborescence intervallaire... Il aura plutôt tendance à se raccrocher à quelque chose de plus familier, tel qu'un tableur, et vouloir tout mettre dans une table !
    Le but du modèle de données normalisé est de placer les données là où il faut pour rendre les opérations effectuées par la BDD les plus fluides et rapides possibles.

    Mais comme toute chose une norme a des limites et parfois il faut prendre l'initiative de ne pas la respecter.
    En dernier recours, quand c'est réellement nécessaire, et ça l'est rarement ! Jamais a priori !

    Il existe de nombreuses manières de normaliser une BDD
    Euh... à partir de règles de gestion identiques, deux personnes modélisant avec méthode devraient arriver au même modèle de données, au nom des propriétés, des entités types, des associations et, par voie de conséquence, à la description des tables près.
    Le bémol que je mettrais est l'emploi ou non de l'identification relative dans certains cas car ça constitue déjà une optimisation (mais pas une dénormalisation) du modèle de données pour faciliter le requêtage.

    et il peut arriver qu'aucune ne réponde efficacement aux contraintes métiers existantes
    Les contraintes métier relèvent de l'applicatif. Les contraintes sur les données sont relativement indépendantes des contraintes métier.

    mais doivent aussi permettre d'être adaptable aux évolutions.
    Un modèle de données normalisé est toujours évolutif.
    Un modèle dénormalisé est plus difficilement modifiable.

    Mais de part mon expérience, je constate que les personnes qui s'offusquent de ces "dérives" sont
    en général les puristes alors que les donneurs d'ordres sont totalement satisfaits par les différents tests au moment de la réception, les maintenances effectuées ne sont jamais liées à un problème ne normalisation, mais plus à une évolution.
    Sur ce point, je ne peux te contredire, ne connaissant pas ton expérience et n'en ayant moi-même qu'une assez faible.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  7. #87
    Invité
    Invité(e)
    Par défaut
    D'après SYBASE :

    Dénormalisation de tables et de colonnes
    La normalisation consiste à éliminer la redondance et les dépendances incohérentes entre les tables. Bien que la normalisation soit le plus souvent considérée comme le but de la modélisation de base de données, la dénormalisation, c'est-à-dire la duplication délibérée de certaines données afin d'accélérer l'extraction des données, peut s'avérer utile dans certains cas :
    - Lorsque les requêtes les plus importantes portent sur des données réparties sur plusieurs tables.
    - Lorsque des calculs doivent être effectués sur une ou plusieurs colonnes avant que la requête ne renvoie une réponse.
    - Si les tables doivent être consultées de différentes façon par différents utilisateurs lors d'une même période.
    - Si certaines tables sont très fréquemment utilisées.
    Lorsque vous devez évaluer la pertinence d'une dénormalisation, vous devez analyser vos besoins dans le domaine de l'accès aux données par les applications dans votre environnement ainsi que leurs performances. Le plus souvent, d'éventuels problèmes de performances peuvent être résolus par une politique d'indexation judicieuse et l'emploi d'autres solutions que la dénormalisation.
    La dénormalisation peut être effectuée de différentes façons :
    - Partitionnement horizontal : utilisé pour diviser une table en plusieurs tables contenant les mêmes colonnes, mais moins de lignes.
    Le partitionnement horizontal consiste à segmenter une table en plusieurs tables contenant chacune un sous-ensemble des lignes et les mêmes colonnes que la table partitionnée afin d'optimiser l'interrogation des données. Vous pouvez utiliser n'importe quelle colonne, y compris une colonne de clé primaire, comme critère de partitionnement.

    - Partitionnement vertical : utilisé pour diviser une table en plusieurs tables contenant le même nombre de lignes, mais moins de colonnes.
    Le partitionnement horizontal consiste à segmenter une table en plusieurs tables contenant chacune un sous-ensemble des lignes et les mêmes colonnes que la table partitionnée afin d'optimiser l'interrogation des données. Vous pouvez utiliser n'importe quelle colonne, y compris une colonne de clé primaire, comme critère de partitionnement.

    - Fusion de tables : permet de fusionner des tables afin d'éliminer la jointure entre elles.
    La fusion de tables consiste à combiner plusieurs tables en une seule afin d'éliminer des jointures et d'améliorer les performances des requêtes.
    Dénormalisation de colonnes
    Vous pouvez dénormaliser des colonnes pour éliminer des jointures fréquentes en utilisant la dénormalisation de colonnes.

    - Dénormalisation de colonne : permet de répéter une colonne dans plusieurs tables afin d'éviter d'avoir à créer des jointures entre les tables.
    Vous pouvez dénormaliser des colonnes pour éliminer des jointures fréquentes en utilisant la dénormalisation de colonnes.

  8. #88
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 144
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    En même temps, si je ne m'abuse, SQL Server était basé sur Sybase jusqu'à sa version 6.5. Et c'était une merde qui était à peine capable de rivaliser avec Access (en exagérant un peu évidement)
    Et il a commencé à devenir à peut près potable avec la version 7.0, et réellement correct avec la version 2000, quand Microsoft à décidé de réécrire complètement le moteur.

    Donc je prendrais les conseils de Sybase avec des pincettes (après, le produit à peut-être lui aussi évolué dans le bon sens, on sait jamais).

    En effet, Sybase était, à l'époque tout du moins, de ce genre de SGBD dont les performances s'écroulaient dès qu'on devait faire une jointure.

    En pratique, la dénormalisation était utile d'un point de vue performances jusque vers la fin des années 90. Depuis, force est de constater qu'il est plus que rare qu'on puisse tirer le moindre profit d'une dénormalisation.
    Et quand cette dernière est réellement nécessaire, on peut s'en passer la plupart du temps en utilisant des fonctionnalités bien plus avancées, telles que les colonnes calculées ou les vues matérialisées.
    On ne jouit bien que de ce qu’on partage.

  9. #89
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par cladsous Voir le message
    D'après SYBASE
    Si j’en crois Wikipedia, SYBASE fut fondée en 1984, un paquet d’années après que Ted Codd (inventeur de la théorie relationnelle) ait défini la normalisation.

    Histoire que tout le monde parle de la même chose, je rappelle en quelques lignes ce qu'est la normalisation dans le contexte des bases de données (pour en savoir plus, voyez par exemple ici).

    En 1970, dans son article fondateur A Relational Model of Data for Large Shared Data Banks, Codd définit la normalisation en première forme normale, ce qu’il appelait simplement « normalisation ».
    La même année Codd définit les deuxième et troisième formes normales (The Second and Third Normal Forms for the Relational Model, IBM technical memo, October 6th, 1970). Voici une photo de la page 27 d’un article daté de 1972, Further Normalization of the Data Base Relational Model, dans lequel Codd résume les étapes de la normalisation :



    En 1974, conjointement avec son collègue d’IBM, Raymond Boyce, Codd définit la forme normale de Boyce-Codd.

    En 1977, Ronald Fagin (un autre de ses collègues d’IBM lui aussi) définit la quatrième forme normale (in Multivalued Dependencies and a New Normal Form for Relational Databases) puis la cinquième forme normale en 1979 (Normal forms and relational database operators).

    Enfin en 2003 C.J. Date, H. Darwen et N. Lorentzos définirent la sixième forme normale (in Temporal Data and the Relational Model).

    Voilà pour ce qu’on appelle la normalisation au sens habituel du terme.

    De la 2NF à la 6NF, la technique utilisée pour normaliser une variable relationnelle (relvar, informellement table en SQL) consiste par une opération de projection à produire deux relvars « mieux » normalisées R1 et R2 à partir d’une relvar R violant la xième forme normale, sachant que par jointure (naturelle) de R1 et R2 on doit retrouver exactement R (principe de la décomposition sans perte).

    Incidemment, on notera que la 5NF est née 5 ans avant Sybase.


    Citation Envoyé par cladsous Voir le message
    La normalisation consiste à éliminer la redondance
    Le verbe "consister" est ici impropre, car normaliser consiste à décomposer (par projection) une table en deux tables (en rappliquant par exemple le théorème de Heath). En revanche, la normalisation a notamment pour effet la diminution (sinon l'élimination) des redondances.


    Citation Envoyé par cladsous Voir le message
    et les dépendances incohérentes entre les tables
    Plaît-il ? De quoi Sybase veut-il parler ? De l’intégrité référentielle ?


    Citation Envoyé par cladsous Voir le message
    Bien que la normalisation soit le plus souvent considérée comme le but de la modélisation de base de données
    Sybase confond la fin et les moyens. Appliquer la théorie de la normalisation permet de mieux contrôler le processus de la modélisation, mais en l’occurrence cette théorie n’est pas la panacée.


    Citation Envoyé par cladsous Voir le message
    la dénormalisation, c'est-à-dire la duplication délibérée de certaines données afin d'accélérer l'extraction des données
    Pour violer quelle forme normale ? Sybase a-t-il pensé aux risques d’incohérence inhérents lors des mises à jour ?

    Sybase a-t-il démontré par un prototypage de performances ad-hoc qu’il faut dénormaliser ? Il est possible qu’avec son SGBD la conclusion aille en ce sens, mais par exemple, sur la base du verdict du prototypage, j’ai mis en œuvre des bases de données de plus de mille tables sans avoir à dénormaliser. Il faut dire qu’ave un SGBD comme DB2 for z/OS, l’optimiseur est particulièrement performant quant aux jointures.

    Accessoirement, quand on dénormalise en joignant deux tables T1 et T2 pour produire une table T3 redondante, les lignes de celle-ci occupent plus de place que ce qui est requis par une jointure figurant dans une requête dans laquelle on ne code pas SELECT T1,*, T2.*, mais où l’on nomme les seules colonnes nécessaires. En voulant bien faire, on peut avoir des surprises.


    Citation Envoyé par cladsous Voir le message
    La dénormalisation peut être effectuée de différentes façons :
    - Partitionnement horizontal
    Aïe ! Le gars de Sybase s’est planté... Ça c’est de l’« optimisation », ça n’a strictement rien à voir avec la [dé]normalisation.


    Citation Envoyé par cladsous Voir le message
    Partitionnement vertical
    Ça a des relents de [dé]normalisation (au fait, pour passer en quelle forme normale ?) Cela dit, il y a une erreur de copier/coller : vous avez recopié la description du partitionnement horizontal.


    Citation Envoyé par cladsous Voir le message
    Fusion de tables : permet de fusionner des tables afin d'éliminer la jointure entre elles.
    La fusion de tables consiste à combiner plusieurs tables en une seule afin d'éliminer des jointures et d'améliorer les performances des requêtes.
    Ouch ! En attente du verdict du prototype ad-hoc, je remplacerai volontiers « améliorer la performance » par « dégrader la performance »...


    Citation Envoyé par cladsous Voir le message
    Dénormalisation de colonne
    C’est seulement de l’optimisation (sous réserve que les la copie de colonne n’entraîne pas viol de la forme normale respectée jusqu’ici par les tables touchées). En tout cas, bonjour les mises à jour, Sybase aurait pu s’abstenir.


    Bref, la [dé]normalisation selon Sybase ça n’est pas très sérieux et c’est surtout redoutable. En 25 ans de DB2 je n’ai pas une seule fois procédé comme le fait Sybase qui a une vision bien curieuse de la normalisation et ferait bien de lire les auteurs sérieux tels que Codd, Date et Fagin, sans oublier de monter des prototypes de performance.

    La défiance de Sybase à l'endroit de la jointure, donc sa volonté de dénormaliser me rappelle les a priori auxquels j'ai dû parfois faire face et évacuer, voyez par exemple ici l'histoire des lots de chèques.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  10. #90
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    728
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 728
    Points : 1 413
    Points
    1 413
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Quant au bonhomme NULL :
    Le sort du bonhomme NULL est tout de suite réglé puisqu’il est banni du modèle relationnel. Ainsi Chris Date écrit (cf. Date on Database, Writings 2000-2006, pages 127 et suivantes, je traduis) :
    Une table est normalisée — de façon équivalente, est en première forme normale, 1NF — si elle est la représentation directe et fidèle d’une relation.
    Date précise : « représentation directe et fidèle » veut dire « isomorphe ». Plus précisément, pour mériter le label « normalisée 1NF », la table en question doit préalablement être en conformité avec les cinq obligations suivantes (automatiquement respectées par les relations du modèle relationnel) :
    1. Les lignes n’ont pas à être ordonnées.
    2. Les colonnes n’ont pas à être ordonnées.
    3. Les doublons de lignes sont interdits.
    4. Chaque intersection d’une ligne et d’une colonne contient exactement une valeur du domaine de référence de celle-ci (et rien d’autre).
    5. Toutes les colonnes sont régulières.
    C’est bien sûr le quatrième point qui nous intéresse ici : chaque ligne doit contenir exactement une valeur du domaine (type) approprié pour chaque colonne, en conséquence de quoi l’absence de valeur est en contradiction avec le modèle relationnel et NULL est donc de facto hors-la-loi. Par exemple, en SQL chaque colonne de chaque table doit être définie avec l’option NOT NULL (cf. instruction CREATE TABLE) : si tel n’est pas le cas pour telle table, celle-ci n’est pas la représentation directe et fidèle d’une relation, en conséquence de quoi elle ne peut pas mériter le label « normalisée 1NF ». Autant dire que la 6NF n'a rien à voir dans cette histoire...
    Bonsoir,
    A la relecture de ce passage (oh combien instructif - encore merci) je reviens encore sur ce fameux bonhomme.
    Personnellement je suis assez à l'aise avec son utilisation. Enfin, il me semble.

    Situation 1 : l'inconnue
    Du coup je serais heureux de voir comment on s'en sort avec dans une situation de binaire non genré : on doit remplir un formulaire dont 2 informations sont remarquables : prénom et sexe
    Disons que le prénom est "O" (pourquoi pas, on a bien "X Æ A-12")
    Si on ne connait pas le sexe de la personne ainsi prénommée, on met quoi ?
    Le fait de donner une valeur est, en soit, une information.
    Imaginons que le domaine accepte "ne sais pas" (voire "indéterminé"), on peut alors stocker ce que l'opérateur a à sa connaissance. On pourra le rectifier par la suite.
    Si on veux faire des stats, la 3ieme valeur permet de ne pas "avoir forcé la main" à l'opérateur en attribuant, au hasard, l'une des 2 valeurs habituelles pour le domaine sexe.
    Je valide que "ne sais pas" est bien une "valeur" qui me permet de ne pas avoir recours au bonhomme NULL.
    Mais ça change quoi fondamentalement ?

    Situation 2 : Les "outer" join
    Le remplissage des valeurs non jointes dans la projection est représentée par des NULL afin de respecter le colonage de la réponse
    On aurait pu remplacer ça par n'importe quel symbole signifiant une non correspondance afin d'éviter le NULL
    Mais, quelque soit le choix, la distinction entre le symbole remplaçant le NULL de la jointure externe et le NULL de l'information inconnue risque tout bonnement une "collision", sauf à interdire de pouvoir stocker le symbole les colonnes des tables
    Je trouve l'interdit pire que d'accepter le bonhomme NULL.

    Mais bien plus encore, et largement au delà de mes pauvres illustrations, si "on" conserve la présence de ce bonhomme NULL c'est bien qu'il rempli un usage pérenne

    Du coup, si on admet que le bonhomme NULL est légitime, comment eut il fallu écrire ce passage ?
    une colonne contient exactement une valeur du domaine de référence
    en écrivant "au plus une valeur" le principe de colonne (vecteur) peut être remis en cause. balot.
    en changeant le mot "valeur" par "scalaire" ? J'ai du mal à me dire qu'un scalaire inconnu relève du NULL plutôt que de x.
    Ne serait-ce pas alors un problème de formulation ?

    Bref, je suis un défenseur de ce pauvre bonhomme NULL
    Le savoir est une nourriture qui exige des efforts.

  11. #91
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 059
    Points : 38 269
    Points
    38 269
    Billets dans le blog
    9
    Par défaut
    Bonjour Michel,

    Citation Envoyé par Michel.Priori Voir le message
    Situation 1 : l'inconnue
    Du coup je serais heureux de voir comment on s'en sort avec dans une situation de binaire non genré : on doit remplir un formulaire dont 2 informations sont remarquables : prénom et sexe
    Disons que le prénom est "O" (pourquoi pas, on a bien "X Æ A-12")
    Si on ne connait pas le sexe de la personne ainsi prénommée, on met quoi ?
    Le domaine de valeurs pour le sexe devrait être {masculin, féminin, non déterminé, inconnu}, ainsi, pas besoin de marqueur "null".
    non déterminé correspond au cas où, à la naissance, la détermination est douteuse
    et inconnu correspond justement au cas où on ne possède pas l'information.

    Citation Envoyé par Michel.Priori Voir le message
    Situation 2 : Les "outer" join
    Le remplissage des valeurs non jointes dans la projection est représentée par des NULL afin de respecter le colonage de la réponse
    On aurait pu remplacer ça par n'importe quel symbole signifiant une non correspondance afin d'éviter le NULL
    Mais, quelque soit le choix, la distinction entre le symbole remplaçant le NULL de la jointure externe et le NULL de l'information inconnue risque tout bonnement une "collision", sauf à interdire de pouvoir stocker le symbole les colonnes des tables
    Je trouve l'interdit pire que d'accepter le bonhomme NULL.
    Là c'est différent, il s'agit non pas de stocker un marqueur "null" dans la BDD, mais de restituer le fait que la données est inconnue dans la base, nuance


    D'une façon générale, je suis plutôt hostile au marqueur "null", toutefois, dans le cas où le MCD autorise une association de cardinalité minimale de zéro, je ne génère pas systématiquement une table de correspondance juste pour éviter les FK marquées "null". À mon sens, la FK nulle est légitime.

  12. #92
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Invité Voir le message
    D'après SYBASE : ...
    Ce document date d'il y a au moins 25 ans... !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  13. #93
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Michel.Priori Voir le message
    ....
    Si on ne connait pas le sexe de la personne ainsi prénommée, on met quoi ?
    On ne le met pas dans cette table. On le met dans une autre table... Il n'y a donc aucun NULL stocké, à la différence des NULL générés par la jointure externe, mais qui ne sont pas stockés !

    ça fait une grosse différence dans une base de prévoir des octets pour des choses vides !
    • Cela oblige à plus de RAM
    • Les sauvegardes sont plus grosses
    • La maintenance dure plus longtemps....


    Autrefois indexer les NULLs était impossible (Oracle à mis très longtemps à le faire...)

    Le fait de donner une valeur est, en soit, une information.
    Imaginons que le domaine accepte "ne sais pas" (voire "indéterminé"), on peut alors stocker ce que l'opérateur a à sa connaissance. On pourra le rectifier par la suite.
    Oui mais ça c'est pas une information, c'est un mensonge une fake news, de la merde quoi!
    Dans bien des requêtes tu vas être obligé de rajouter une clause WHERE du genre je veux pas les "indéterminé" ! donc des perfs en baisse...

    Si on veux faire des stats, la 3ieme valeur permet de ne pas "avoir forcé la main" à l'opérateur en attribuant, au hasard, l'une des 2 valeurs habituelles pour le domaine sexe.
    Je valide que "ne sais pas" est bien une "valeur" qui me permet de ne pas avoir recours au bonhomme NULL.
    Mais ça change quoi fondamentalement ?
    Mensonge et contorsions !


    Situation 2 : Les "outer" join
    Le remplissage des valeurs non jointes dans la projection est représentée par des NULL afin de respecter le colonage de la réponse
    On aurait pu remplacer ça par n'importe quel symbole signifiant une non correspondance afin d'éviter le NULL
    Tu peux mettre ce que tu veux à la place. C'est mieux d'avoir un choix que quelque chose de fixe... Utilise COALESCE...
    Mais, quelque soit le choix, la distinction entre le symbole remplaçant le NULL de la jointure externe et le NULL de l'information inconnue risque tout bonnement une "collision", sauf à interdire de pouvoir stocker le symbole les colonnes des tables
    Je trouve l'interdit pire que d'accepter le bonhomme NULL.
    Collison ???? Tu serais pas tombé sur la tête un jour ?

    Mais bien plus encore, et largement au delà de mes pauvres illustrations, si "on" conserve la présence de ce bonhomme NULL c'est bien qu'il rempli un usage pérenne

    Du coup, si on admet que le bonhomme NULL est légitime, comment eut il fallu écrire ce passage ?

    en écrivant "au plus une valeur" le principe de colonne (vecteur) peut être remis en cause. balot.
    en changeant le mot "valeur" par "scalaire" ? J'ai du mal à me dire qu'un scalaire inconnu relève du NULL plutôt que de x.
    Ne serait-ce pas alors un problème de formulation ?

    Bref, je suis un défenseur de ce pauvre bonhomme NULL
    Oui s'il est bien employé mais la tu ne l'a visiblement pas bien compris....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  14. #94
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

    Pauvre Michel, ça vous tombe dessus comme à Gravelotte...

    Pour ma part, je rappelle qu’il s’agit de faire soigneusement la distinction entre le Modèle Relationnel de Données (le Relationland où réside la théorie relationnelle) et son avatar SQL (Sorry Query Language), le Askew Wall qui l’entoure.

    Ainsi l’outer join n’existe pas en relationnel, mais bien dans SQL, car il est une conséquence de NULL. Je ne dis pas qu’il faille systématiquement bannir cet opérateur et ce marqueur, mais il y a bien des précautions à prendre dans leur utilisation, c’est un peu comme la dynamite, si on ne sait pas maîtriser ça complètement, ça peut nous péter dans la face...



    Des bouquets et des fleurs.

    Quand je sqlise, il m’arrive d’utiliser NULL, par exemple dans ce post, quand il s’agit de mettre en commun les commentaires des utilisateurs (les clients) concernant fleurs et bouquets d’icelles :


    Inévitablement le cardinalités 0,1 du MCD entraînent la mise en oeuvre de NULL dans la table SQL Commentaire (colonnes bouquetId et fleurId) :  

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    CREATE TABLE Commentaire
    ( commentaireId INT IDENTITY
     , utilisateurId INT NOT NULL
     , commentaireTitre VARCHAR(50) NOT NULL
     , commmentaireContenu VARCHAR(max) NOT NULL
     , commentaireDate DATE NOT NULL
     , bouquetId INT, fleurId INT
     , CONSTRAINT Commentaire_PK PRIMARY KEY(commentaireId)
     , CONSTRAINT Commentaire_Bouquet_FK FOREIGN KEY(bouquetId) REFERENCES Bouquet(bouquetId)
     , CONSTRAINT Commentaire_Fleur_FK FOREIGN KEY(fleurId) REFERENCES Fleur(fleurId)
     , CONSTRAINT Commentaire_Utilisateur_FK FOREIGN KEY(utilisateurId) REFERENCES Utilisateur(utilisateurId)
     , CONSTRAINT Commentaire_soit_bouquet_soit_fleur CHECK 
          (bouquetId is not NULL AND fleurId is NULL OR bouquetId is NULL AND fleurId is not NULL)) ;

    Notez la contrainte Commentaire_soit_bouquet_soit_fleur

    Prise en compte de quelques commentaires de clients contents :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    insert into Commentaire values
       (2, 'Un beau bouquet !', 'Ma femme sera contente !', '10/05/2022', 1, NULL)
     , (2, 'Un beau bouquet !', 'Ma femme va être ravie !', '10/05/2022', NULL, 2)
    Les précautions étant prises, on peut consulter la table Commentaire (avec référence à la table Utilisateur, pour connaître les auteurs des commentaires) :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    select utilisateurNom as Nom
         , commentaireTitre as Titre, commmentaireContenu as Contenu
         , coalesce(b.bouquetNom, '/') as Bouquet
         , coalesce(f.fleurNom,'/') as Fleur
    from Commentaire as c
    join Utilisateur as u on c.utilisateurId = u.utilisateurId
    left join Bouquet as b on c.bouquetId = b.bouquetId
    left join Fleur as f on c.fleurId = f.fleurId ;
    =>

    Nom     Titre              Contenu                   Bouquet             Fleur
    Naudin  Un beau bouquet !  Ma femme sera contente !  bouquet de saison   / 
    Naudin  Un beau bouquet !  Ma femme va être ravie !  /                   pivoine
    Notez l’emploi de Coalesce pour afficher par exemple "/" plutôt que NULL.

    Théorème de Heath  

    Prenons le cas du théorème de Heath, omniprésent dans la normalisation des bases de données :

    Si la relation R {A, B, C} satisfait à la dépendance fonctionnelle A → B, alors R peut être décomposée selon ses projections R1 {A, B} et R2 {A, C}, avec préservation du contenu de la base de données, c'est-à-dire que l’on retrouve très exactement R par la jointure naturelle de R1 et de R2.

    Avec SQL, ce théorème est massacré si A peut être marqué null. Exemple :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    create table R 
    (
       a varchar(8) 
     , b varchar(8)
     , c varchar(8)
    )
    ;
    insert into R values
       ('a1', 'b1', 'c1')
     , (null, 'b2', 'c2')
    ;
    select 'R' as 'Table', * from R ;
    =>

    Table	a	b	c
    R	a1	b1	c1
    R	NULL	b2	c2

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    create table R1
    (
       a varchar(8) 
     , b varchar(8)
    )
    ;
    insert into R1 (a, b)
       select a, b from R
    ;
    select 'R1' as 'Table', * from R1 ;
    =>

    Table	a	b
    R1	a1	b1
    R1	NULL	b2
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    create table R2
    (
       a varchar(8) 
     , c varchar(8)
    )
    ;
    insert into R2 (a, c)
       select a, c from R
    ;
    select 'R2' as 'Table', * from R2 ;
    =>

    Table	a	c
    R2	a1	c1
    R2	NULL	c2 
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    select 'natural' as 'Table', R1.a, b, c 
    from R1 join R2 on R1.a = R2.a
    ;
    =>

    Table  	a	b	c
    natural	a1	b1	c1 
    On n’a pas retrouvé R

    Plongeons dans le glauque avec Outer :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    select 'left' as 'Table', R1.a, b, c 
    from R1 left outer join R2 on R1.a = R2.a
    =>

    Table	a	b	c
    left	a1	b1	c1
    left	NULL	b2	NULL 
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    select 'right' as 'Table', R1.a, b, c 
    from R1 right outer join R2 on R1.a = R2.a ;
    =>

    Table	a	b	c
    right	a1	b1	c1
    right	NULL	NULL	c2 
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    select 'full' as 'Table', R1.a, b, c 
    from R1 full outer join R2 on R1.a = R2.a ;
    =>

    Table	a	b	c
    full	a1	b1	c1
    full	NULL	NULL	c2
    full	NULL	b2	NULL
    Si vous vous y retrouvez instantanément, vous avez de la chance, ça n’est pas mon cas...


    Citation Envoyé par Michel.Priori
    une colonne contient exactement une valeur du domaine de référence
    en écrivant "au plus une valeur" le principe de colonne (vecteur) peut être remis en cause. balot.
    Votre citation est incomplète et vous en tirez des conséquences qui n’ont rien à voir. Pour ma part, j’ai écrit :

    Citation Envoyé par fsmrel
    Chaque intersection d’une ligne et d’une colonne contient exactement une valeur du domaine de référence de celle-ci (et rien d’autre).
    C’est bien à l’intersection d’une ligne et d’une colonne qu’on trouve une valeur.

    Si l’on admettait la légitimité de Null (cas de SQL), il faudrait écrire quelque chose du genre :

    Chaque intersection d’une ligne et d’une colonne, soit contient une valeur, soit est marquée NULL.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

Discussions similaires

  1. [Débutant] Récupérer un élément de la table quand ID==ID
    Par solid_sneak06 dans le forum Silverlight
    Réponses: 11
    Dernier message: 18/05/2012, 20h57
  2. Réponses: 2
    Dernier message: 05/08/2009, 11h30
  3. [FN] Dénormaliser une table de cumuls mensuels
    Par doudou_rennes dans le forum Schéma
    Réponses: 3
    Dernier message: 27/02/2007, 17h18
  4. [DEBUTANT]requete de jointure avec identifiant quand ds une table
    Par tripper.dim dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 17/05/2006, 14h46
  5. Et quand tes tables gonflent trop...
    Par hphil dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 22/03/2005, 16h43

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo