Discussion :

[irnbru]

Bonsoir Je souhaite avoir de l'aide pour savoir si ma base est bien concue et normalisée. Je sais à tel point cela est important pour les developpements d'application mais je ne suis pas encore sur de moi

Voilà merci
IRNBRU

[fsmrel]

Bonsoir,


Un dessin vaut mieux qu’un long discours, certes. Mais vous seriez bien aimable de définir l’univers du discours qui se cache derrière cette représentation graphique en forme de rébus, sans oublier de rédiger les règles de gestion qui régissent l’univers.

Merci.

[irnbru]

Merci pour ta réponse effectivement les règles de gestion sont importantes.

Il s'agit d'un site de traduction d'articles.

D'abord la source d'un article:

Une source a un type de contenu (magazine, journal, blog)
Une source a une langue (langue utilisée dans la source)
Une source est publié dans un pays donné

Maintenant à propos de l'article:

un article provient d'une seule source
un article peut être traduit en plusieurs langues. (pour une langue donné on peut trouver plusieurs articles évidemment dont on a affaire à un many to many)
Un article a un seul auteur (pour le moment)
Un article est écrit dans un pays donné

J'espère que ces informations sont suffisantes
Merci pour votre aide

IRNBRU

[fsmrel]

Bonjour,

On y voit un peu plus clair.

Un article a un seul auteur (pour le moment)

Autant prévoir tout de suite la structure permettant de connaître les co-auteurs d’un article, c'est-à-dire une table mettant en relation les tables Article et Author. A défaut, le jour où il faudra faire évoluer la structure de la base de données, ça pourra être une opération lourde (je parle d’expérience). Si vous tenez à ce que pour le moment il y ait exactement un auteur pour un article, ce que vous pouvez faire c’est agir au niveau de la table de relation, brider la clé primaire {ArticleId, AuthorId} en la ramenant à {ArticleId}. Le jour où vous permettrez qu’il y ait plus d’un auteur par article, vous débriderez la clé primaire.

Table Article :

Si l’attribut Title_Translated permet de connaître le titre traduit, je suppose que l’attribut Title correspond au titre original, non traduit, donc au titre de la source.

Si tel est le cas, la table Article comporte la dépendance fonctionnelle

{Source} → {Title}

auquel cas la troisième forme normale est violée et l’attribut Title doit dégager et réintégrer la table Source.


Table Languages :

A quoi correspond l’attribut key ?

[irnbru]

Merci fsmrel pour tes conseils

D'abord effectivement le "Title" correspond au titre original (en VO donc) CEPENDANT

Title correspond au titre original, non traduit, donc au titre de la source.

Le titre N'EST PAS le titre de la SOURCE mais celui l'ARTICLE.

Il faut juste comprendre que la table article contient des articles traduits.
Il y a autant de données que d'articles traduits. Un même article peut etre trouvé plusieurs fois si il est traduit en différentes langues

Exemple:

Un article écrit à la base en anglais dont le titre est "Hello World".

La traduction apportée est en francais et le titre traduit est "Bonjour tout le monde"

Sa source pourrait etre par exemple un journal "blahblah", sans aucune dépendence entre la source (origine de l'article) et la traduction de l'article (dans la table article). La seule dépendence est le fait qu'un article fait bien parti d'une source et une seule (copyright oblige).

Donc pas de violation si tu as compris mes explications

La clé key correspond au nom en anglais (langue utilisée par défaut) de la langue. Par exemple pour la langue française key sera "french" et text sera "français" Peut etre je devrai utiliser des titres plus parlants.

Merci pour ton aide surtout, très appréciée!
IRNBRU

[fsmrel]

Bonsoir irnbru,

Un article écrit à la base en anglais dont le titre est "Hello World".
La traduction apportée est en francais et le titre traduit est "Bonjour tout le monde"
Sa source pourrait etre par exemple un journal "blahblah",

Il y avait un petit quiproquo au départ. Dans la mesure où la source n’est qu’un médiat ou assimilé, et que cette source peut faire l’objet de plusieurs articles (indépendamment du fait qu’on les traduise), ça roule, mon observation ne vaut plus.

[irnbru]

bonsoir fsmrel

Merci pour ton aide, autrement la base est bien normalisée?

Merci encore :ccool
IRNBRU

[fsmrel]

Bonsoir,


Selon la méthode pifométrique, donc sans aucune garantie, votre base de données paraît normalisée.

Pour prouver qu’elle l’est, il faut s’assurer que chaque table l’est. Au fait, que visez-vous ? La troisième forme normale (3NF) ? La forme normale de Boyce-Codd (BCNF) ? La cinquième forme normale (5NF) ?

Pour savoir si une table T est en conformité avec, par exemple, la BCNF, il faut dresser l’inventaire complet des surclés de T et celui des dépendances fonctionnelles non triviales associées à T (voir la discussion avec highlander03). Cela suppose déjà que vous fournissiez une description précise et détaillée de chaque attribut de T (scripta manent...) et les relations qu’y entretiennent ces attributs.

Par exemple, quand on lit :

La clé key correspond au nom en anglais (langue utilisée par défaut) de la langue. Par exemple pour la langue française key sera "french" et text sera "français"

On dispose en l’occurrence d’informations très utiles pour le travail de normalisation même si leur présentation est pour le moins elliptique et à remettre en forme.

Dans un 1er temps, on peut inférer que la table Language {Id, Key, Text}, comporte les dépendances fonctionnelles :

{Id} → {Key}
{Id} → {Text}
{Key} → {Id}
{Key} → {Text}
{Text} → {Id}
{Text} → {Key}

Puis conclure que la table est conforme à la BCNF (on peut même affirmer qu’elle est respecte la 5NF).

Peut etre je devrai utiliser des titres plus parlants.

Peut-être, ne serait-ce que pour éviter d’utiliser des mots réservés SQL, mais ça n’est pas cela qui permet d’entreprendre le travail de (vérification de la) normalisation. Un nom d’attribut n’est pas un énoncé de règle de gestion.

[irnbru]

Je te remercie pour ces explications détaillées, parfois incompréhensible car je ne maitrise pas bien tous ces termes et jargons. Je ne connais que les formes normalisées jusqu'à 3N.

Peux tu me recommander des cours et des articles et livres sur ces notions?

Merci encore pour ton aide et patience.
IRNBRU

[fsmrel]

Bonsoir,

Je te remercie pour ces explications détaillées, parfois incompréhensible car je ne maitrise pas bien tous ces termes et jargons.

Désolé, mais la théorie de la normalisation a été créée par des mathématiciens et s’applique aux relations dans leur acception mathématique. Les explications fournies pour hghlander03 devraient suffire, mais on peut les détailler...


Concept de dépendance fonctionnelle

Je redonne ici la définition de la dépendance fonctionnelle, qui est l’instrument, le tournevis à normaliser.

Soit X et Y deus sous-ensembles quelconques de l’en-tête d’une table S.
S satisfait à la dépendance fonctionnelle (DF) X → Y si et seulement si, à chaque fois que deux tuples (lignes) de S ont même valeur pour X, alors ils ont même valeur pour Y (X est appelé le déterminant et Y le dépendant, on dit encore que X détermine Y).

Je rappelle que l’en-tête d’une table consiste en la liste des attributs (colonnes) de la table. Par exemple, la table Source a pour en-tête :

{Id, Name, Type, Language, Country}

Je vous prie de noter l’utilisation des accolades, car l’en-tête de la table est un ensemble (au sens de la théorie des ensembles), dont les éléments sont Id, Name, Type, Language et Country.
Si Name représente le nom de la source, par exemple El periodico de las bases de datos relacionales, The crazy relational journal, et si pour chaque valeur de Name, l’attribut Language ne peut prendre qu'une seule valeur (respectivement espagnol, anglais) alors on a la dépendance fonctionnelle :

{Name} → {Language}

Notez à nouveau l’emploi des accolades, car {Name} et {Language} représentent encore des ensembles, des singletons en l’occurrence, c'est-à-dire composés d’un seul élément.

En revanche, si pour une valeur de l’attribut Name on peut avoir plus d’une valeur pour l’attribut Language, alors la dépendance fonctionnelle ci-dessus n’existe pas.

Ce qui sûr, c’est que par définition, parce que {Id} est clé (raccourci pour clé candidate), alors on a les dépendances fonctionnelles suivantes :

{Id} → {Name}
{Id} → {Type}
{Id} → {Language}
{Id} → {Country}

Réciproquement, si {Id} détermine fonctionnellement chaque {Attribut} de la table Source, alors {Id} est une clé (candidate) de la table.

Dépendance fonctionnelle triviale

Je rappelle ce que j’ai précisé dans la discussion avec highlander03 :
La DF : X → Y est triviale si et seulement si Y est un sous-ensemble (non nécessairement strict) de X. Une telle DF est toujours vraie.

Dans le cas de la table Source les dépendances fonctionnelles suivantes répondent à cette définition :

{Id} → {Id}
{Name} → {Name}
{Language} → {Language}
{Name, Language} → {Language}
{Name, Language} → {Name}
Etc.

Définition de la surclé

Je reprends la définition donnée dans la discussion avec highlander03 :

Soit SK un sous-ensemble (non strict) de l’entête d’une table S ; SK est une surclé de S si et seulement si deux tuples (lignes) distincts de S ne peuvent avoir la même valeur pour SK. Les surclés doivent donc satisfaire à une contrainte d'unicité.

Application à la table Source :

Soit SK un sous-ensemble (non strict) d’attributs de l’en-tête {Id, Name, Type, Language, Country} de cette table. SK est une surclé de Source si et seulement si deux lignes distinctes de Source ne peuvent avoir la même valeur pour SK.

Le sous-ensemble {Id} est-il une surclé de la table Source ? Oui, car on ne peut pas trouver deux lignes ayant la même valeur pour {Id}.

Le sous-ensemble {Language} est-il une surclé de la table Source ? Non, dans la mesure où deux sources n'ayant pas le même nom peuvent être rédigées dans la même langue.

Le sous-ensemble {Language, Type} est-il une surclé de la table Source ? Non, dans la mesure où deux sources n'ayant pas le même nom peuvent être rédigées dans la même langue et être du même type.

Le sous-ensemble {Language, Type, Country} est-il une surclé de la table Source ? Non, dans la mesure où deux sources n'ayant pas le même nom peuvent être rédigées dans la même langue, être du même type et être publiées dans le même pays.

Le sous-ensemble {Name} est-il une surclé ? Oui si deux sources ne peuvent pas porter le même nom, non dans le cas contraire.

A supposer que deux sources puissent porter le même nom, sauf si elles sont publiées dans le même pays : le sous-ensemble {Name} n’est pas une surclé, mais la paire {Name, Country} en est une si en plus les dépendances fonctionnelles suivantes sont vérifiées :

{Name, Country} → {Type}
{Name, Country} → {Language}
{Name, Country} → {Id}

Maintenant, une chose est sûre, un triplet tel que

{Name, Country, Id} → {Type}

est une surclé, car il contient le sous-ensemble {Id} qui à lui seul garantit la contrainte d’unicité caractérisant les surclés.

Définition de la BCNF (forme normale de Boyce-Codd)

Là aussi je rappelle la définition fournie à highlander03 :

Une table S est en forme normale de Boyce-Codd (BCNF) si et seulement si pour chaque dépendance fonctionnelle non triviale X → Y satisfaite par S, X est une surclé de S.

Autrement dit, à vous de dresser l’inventaire exhaustif des dépendances fonctionnelles de la table Source, en laissant tomber celles qui sont triviales. Ceci fait, vérifiez si le déterminant (la partie gauche) de chacune de ces dépendances fonctionnelles représente une surclé. A ce moment-là vous serez à même de vous prononcer sur le respect de la normalisation par la table.

Je ne connais que les formes normalisées jusqu'à 3N.

J’ai parlé jusqu’ici de la BCNF, plus contraignante que la 3NF.

Reformulons ainsi cette BCNF :

Soit T une table, X un sous-ensemble d’attributs de l’en-tête de T et A un attribut de cet en-tête. T est en forme normale de Boyce-Codd (BCNF) si et seulement si, pour chaque dépendance fonctionnelle X → {A} vérifiée par T, au moins une des conditions suivantes est satisfaite :
1. A est un élément de X (cette dépendance fonctionnelle est donc triviale).
2. X est une surclé de T.

L'énoncé de la 3NF est le même, augmenté d'une chance supplémentaire, donc une contrainte en moins :

Soit T une table, X un sous-ensemble d’attributs de l’en-tête de T et A un attribut de cet en-tête. T est en troisième forme normale (3NF) si et seulement si, pour chaque dépendance fonctionnelle X → {A} vérifiée par T, au moins une des conditions suivantes est satisfaite :
1. A est un élément de X (cette dépendance fonctionnelle est donc triviale).
2. X est une surclé de T.
3. A appartient à une clé candidate de T.

Les deux définitions qui précèdent montrent que la BCNF implique la 3NF, autrement dit vous ne devriez pas avoir de difficulté pour passer de celle que vous connaissez — la moins contraignante — à la plus contraignante, puisqu'il vous suffit en l'occurrence de faire abstraction de la 3e condition.

Pour mémoire (cf. encore la discussion avec highlander03), une clé candidate K est une surclé devant vérifiant une contrainte dite d’irréductibilité : K ne doit pas contenir de sous-ensemble strict vérifiant lui aussi la contrainte d’unicité imposée aux surclés.

[irnbru]

Hello François merci pour toute ta patience et ces explications qui seront certainement profitées par tout le monde!

J'ai vu que tu as aussi une page http://fsmrel.developpez.com/basesre...normalisation/

Qu'il faut bien lire.

Ma question était comment as tu acquéri toute cette expérience et connaissance sur la normalisation. C'est pour cela je voulais savoir si tu as des références, des bibles (en anglais ou francais) pouvant m'aider à aller au fond des choses.

Encore une fois merci.
IRNBRU

[fsmrel]

Bonjour Nicolas,

Merci à mon tour. Comment ai-je acquis cette expérience ? Il n’y a pas de secret...

1) En ayant étudié soigneusement les auteurs les plus pertinents, afin d’acquérir des bases solides. En tout premier lieu, je veux citer Chris Date dont l’ouvrage An Introduction to Database Systems reste incontournable.

2) Ensuite, en ayant crapahuté pendant plus de 20 ans chez les clients de la SSII dont je faisais partie (puis pour mon compte personnel), à construire des bases de données relationnelles normalisées à mort, à en remettre d’autres d’équerre, conseiller et convaincre les architectes du rôle capital de la normalisation, expertiser, auditer, enseigner, démythifier, etc., avec à chaque fois (ah ! ces clients...) le couperet des pénalités prêt à tomber au cas où les performances n’auraient été pas celles sur lesquelles je m’engageais (d’où des nuits à prototyper avant d’annoncer ce sur quoi je pouvais m’engager, à prendre ou à laisser). Dans ce genre d’exercice, il est évident que la normalisation est une des clés du succès, même si ça n’est pas la seule.


Outre l’ouvrage de Chris Date, il y a celui de Georges Gardarin, moins développé mais complet, précis, rigoureux et facile à lire : Bases de données : Les systèmes et leurs langages qu’on doit encore trouver par exemple chez PriceMinister.