Conception des bases de données SOLID : Responsabilité unique et normalisation

Bonjour à tous,:)

Je vous présente cet article traduit de Chris Travers intitulé :

Conception des bases de données SOLID

Responsabilité unique et normalisation

Je vous invite à le consulter pour mieux appréhender l'applicabilité des principes SOLID aux bases de données et aux applications.

Citation:

Cet article est le second de la suite d'articles Conception des bases de données SOLID rédigés par Chris Travers. Il présente l'application du principe de la responsabilité unique à la conception des bases de données relationnelles. L'auteur fait également un détour sur la normalisation des bases de données. Chris Travers est un blogueur très actif et nous avons souhaité partager avec la communauté francophone ses contributions afin que chacun en tire profit.

Je vous souhaite bonne lecture ! :)

Citation:

À suivre dans la même série :

3- Le principe d'Ouverture/Fermeture (à suivre)
4- La substitution de Liskov (à suivre)
5- La ségrégation des interfaces ou garder les procédures stockées simples (à suivre)
6- Inversion de dépendances et interfaces robustes de bases de données (à suivre)

:fleche: Vous voulez contribuer en traduction ou en rédaction ? Cliquez sur ce lien :ccool:

L'exemple de l'adresse IP donné comme infaisable dans un SGBDR est l'exemple même de la stupidité de cette thèse. Il se trouve en plus que je donne cet exercice en cours de modélisation pour mes élèves ingénieurs. En effet une adresse IP est bien un et un seul entier (de type SQL INTEGER) que l'on a pris l'habitude de représenter sous forme de 4 petits entiers allant de 0 à 255.
Or on oublie trop souvent que devrait être associé au MPD de la base (modèle physique) le MED ou Modèle Externe de Données, c'est à dire des vues qui décortique et présente l'information de manière élégante et facile à utiliser que ce soit pour le développeur comme pour l'utilisateur final.
Donc la table aura un seul entier et la vue 4 petits entiers. Il sera possible de mettre à jour les données à travers la vue grâce aux déclencheurs INSTEAD OF.

Bref, encore une fois un tissus de connerie de quelqu'un qui n'a aucune culture du monde des SGBDR et essaye dramatiquement d'inventer une roue carré !!!!

Beurk !

J'ai relevé des erreurs qu'on ne peut pas laisser passer à propos du modèle relationnel de données.

Citation:

Envoyé par L’auteur

Les relations sont les structures de données qui enregistrent l'état.

Fichtre ! Sachez qu'une relation est un ensemble ! C’est une valeur. Un variable relationnelle (en abrégé relvar) est une variable dont les valeurs sont des relations. Voyez la référence The Relational Database Dictionary.

Citation:

Envoyé par L’auteur

Et si elles répondent à la deuxième forme normale, elles ont une identité sous la forme d'une clé primaire.

1) Le concept de clé primaire fait partie du langage SQL, mais dans le modèle relationnel de données le rasoir d’Ockham est passé il y a longtemps, car l'adjectif « primaire » est en fait inessentiel. Dans le modèle relationnel de données on ne parle que de clés candidates (clés pour abréger).

2) Quelle définition donnez-vous de la deuxième forme normale ? Je redoute le pire.

3) De toute façon, inutile d’évoquer la deuxième forme normale, car celle-ci concerne les relvars (donc les relations), lesquelles sont de facto normalisées en première forme normale (sinon ce ne sont pas des relvars, puisque par définition il ne peut y exister de tuples en double). Dans le cas de SQL, il faut effectivement définir une clé (primaire) pour chaque table qu’on veut conforme au modèle relationnel, sinon ça n’est pas un ensemble, mais un sac (bag) : l’algèbre relationnelle ne s’applique alors pas, ce qui est bien embêtant. En tout cas, on peut définir des clés sans pour autant respecter la deuxième forme normale.

Citation:

Envoyé par L’auteur

Une « raison de changer » est épistémologiquement problématique.

L’épistémologie est en quelque sorte le tribunal des sciences, quel rôle joue-t-elle ici ?

Citation:

Envoyé par L’auteur

La définition de Codd stipule qu'une relation (table) est en 3FN, si et seulement si les deux conditions suivantes sont réunies :
•la relation R (table) est en 2FN ;
•chaque attribut non clé de R est non transitivement dépendante de la super clé de R.

Un attribut non clé est un attribut qui ne fait pas partie de la super clé. À la base, ce que la 3FN stipule est que chaque relation doit contenir une super clé et des valeurs fonctionnellement et directement dépendantes de cette super clé.

Aïe ! Savez-vous au moins ce qu’est une « super clé » ? Je vous renvoie à nouveau à l’ouvrage The Relational Database Dictionary.

Pour que le lecteur sache de quoi il s’agit exactement, voici la définition précise donnée par Codd dans son article de 1971 Further Normalization of the Data Base Relational Model :

A relation R is in third normal form if it is in second normal form and every non-prime attribute of R is non-transitively dependent on each candidate key of R.

Vous noterez que Codd précise bien que chaque clé candidate est partie prenante et pas seulement l’une d’entre elles ! Par ailleurs, où voyez vous que Codd parle de surclés ?

Remarque 1 : pour Codd, un prime attribute, est un attribut qui appartient à au moins une clé candidate de R et, a contrario, un non-prime attribute est un attribut qui n'appartient à aucune clé candidate de R.

Remarque 2 : à condition d’avoir défini avec précision chaque terme (se reporter une fois de plus à la référence The Relational Database Dictionary), on peut quand même faire intervenir les surclés dans l’énoncé de la troisième forme normale, mais sous réserve de faire aussi intervenir les sous-clés (se reporter à Database Design & Relational Theory) :

Une relvar R est en troisième forme normale si et seulement si, pour chaque dépendance fonctionnelle non triviale X -> Y valant pour R, X est une surclé ou Y est une sous-clé.

Incidemment, en relationnel on ne perd pas de temps, on modélise et on expertise les bases de données en partant directement de la forme normale de Boyce-Codd (voyez Further Normalization of the Data Base Relational Model pour la définition de Codd...)

Citation:

Envoyé par L’auteur

Les bases de données objet-relationnelles fournissent alors une interface et ainsi dans une base de données relationnelle, les relations et les classes contiennent des ensembles d'objets de certaines classes.

Ça coince. Une relation est une valeur et une classe n’est pas une valeur.

Citation:

Envoyé par L’auteur

Le problème de l'exemple canonique est qu'il n'est pas autonome

Plaît-il ? Ça mérite quelques explications...

Citation:

Envoyé par L’auteur

Le processus de normalisation d'une base de données est un exercice pour créer des bases de données relationnelles où des anomalies de données n'existeront pas. Les anomalies dans les données se produisent soit lorsque la modification des données requiert la modification d'autres données pour maintenir la précision (où aucun changement de faits n'est enregistré), soit lorsque les données existantes peuvent projeter des faits actuels ou historiques non existants (anomalies de jointure).

Vous attribuez beaucoup de vertus à la normalisation ! Son objet est en réalité l’élimination des redondances, donc empêcher certaines erreurs qui autrement pourraient se produire lors de la mise à jour des bases de données. Pour le reste, l’intégrité des données met en jeu les contraintes de type, les contraintes d’attribut, les contraintes de relvars, les contraintes de base de données, d’où les moyens pour garantir cette intégrité : clés candidates, clés étrangères (intégrité référentielle) et plus généralement les contraintes déclarées traduisant les règles de gestion (voyez ... Further Normalization of the Data Base Relational Model...) Vos « anomalies de jointure » me laissent songeur, doit-on y voir une corrélation avec l’intégrité référentielle ? D’où la question : Où avez-vous étudié le modèle relationnel de données ?

Citation:

Envoyé par L’auteur

(en supposant qu'aucune décision de décomposer une relation dans une forme normale de niveau supérieur)

Du point de vue de l’analyse logique votre phrase est boiteuse. Merci de la compléter.

Citation:

Envoyé par L’auteur

les prérequis d'atomicité de la première forme normale (1FN)

L’atomicité varie avec les auteurs. Quelle est votre définition de ce concept ? Même question à propos de la première forme normale.

Citation:

Envoyé par L’auteur

Lorsque cette encapsulation est problématique, elle viole la première forme normale (1FN) parce qu'elle ne peut plus traiter les valeurs atomiques

Là encore, tout dépend de ce que vous entendez par atomicité. Pour mémoire, un attribut de relvar peut être de type relation (consultez une fois de plus l’ouvrage The Relational Database Dictionary, rubrique « Relation Valued Attributes » (en abrégé RVA).

Tout cela, est usant : concepts non définis ou erronés, j’en resterai donc là...

Merci à tous les deux pour vos commentaires. Cela m'a fait gagner du temps.