Discussion :

[StringBuilder]

Non, dans le cas que je décrit, SIGTIE peut être identique selon les TYPTIE et les CODSOC.

En ce qui concerne l'erreur de casting, j'admet que je ne suis pas pointilleux sur les mots.

En revanche, je ne vais pas me laisser limite insulter de la sorte.

La plupart du temps, la dénormalisation est motivée avant tout par une tentative de "simplification" du modèle des données.

Les cas de dénormalisation à des fins d'optimisation sont rares, même si c'est cet argument qui ressort lorsqu'on demande pourquoi, car il est plus convainquant qu'un simple "j'en ai marre d'avoir 200 tables dans mes requêtes".

Il n'est pas rare de trouver, au moment de la conception, des tables avec une adresse dans la commande.

"Ben oui, mais c'est parceque mon client il a déjà une adresse, le fournisseur aussi, et du coup ça m'ennuie de faire une table de plus pour stocker les adresses des livraisons".

Ca, c'est un cas de dénormalisation typique, qui est évité sans problème par la phase d'abstraction que j'ai énnoncé, et que nombre de personnes ne font pas : c'est clairement pas à l'école qu'on apprend ça, et encore moins dans les SSII où les développeurs/chef de projets n'ont aucun suivit pédagogique, aucun moyen de capitaliser d'un projet à l'autre.

[Fabien Celaia]

D'accord avec SQLPro, sauf sur ce cas-la:

L'expérience m'a montré que lorsque la bse avait été bien normalisé et à condition de n'utiliser que des clefs auto incrémentées avec des index clusterisés, aucune dénormalisation n'avait besoin d'être introduite.

L'indexation cluster determine generalement l'ordre physique dans lequel sont stockes les enregistrements (hormis dans le cas exceptionnel des tables DOL sous ASE). Dans ce cas, creer un index cluster sur un champ autoincremente genere un hot-sport enorme sur la derniere page de ladite table (grosse contention) qui est un frein aux performances.

[siocnarf]

--> Pomalaix

Merci

[SQLpro]

Excuse moi Pomalaix, mais je peut pas laisser dire cela...

Les bases de données relationnelles, ont été créées pour gérer des relations et non pour recommencer un sempiternel modèle de données basé sur des fichiers.
A ce titre, ce que savent le mieux faire les SGBDR c'est la mise en relation des données.

Maintenant quand tu dit dans "pourquoi normaliser [...] ?"
1) par souci d'économie...
2) par souci de cohérence
...

tu oublie le principe même de la normalisation qui est la dépendance fonctionnelle.
Si cette donnée dépend d'autres données alors normalisation.
Maintenant cette dépendance n'est pas binaire au sens stricte. Je dirais que la dépendance fonctionnelle est plutôt en logique flou : un pourcentage compris entre "dépendance fonctionnelle = Vrai" et "dépendance fonctionnelle = Faux".
Comment évaluer ce pourcentage ? Simple : compter la dispersion des données d'une colonne. Plus cette dispersion est élevée moins la dépendance est claire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Un petit exemple
****************

Une table des personnes (PRS_ID, PSR_TITRE, PRS_NOM)

Premier cas, notre table contient 3 lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
PRS_ID PRS_TITRE PRS_NOM 
------ --------- ------- 
1      M.        DUPONT  
2      Mme.      DURAND  
3      Null      DUBOIS

Les questions a se poser sont les suivantes :

1) Y a t-il dépendance fonctionnelle de PRS_TITRE ? Pas évident !
2) quelle est la dispersion de PRS_TITRE ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT COUNT(DISTINCT PRS_TITRE) / (SELECT COUNT(*) FROM MaTable)
FROM MaTable

Résultat : 1 => la dispersion est maximale donc dépendance fonctionnelle quasi inexistante.

Second cas, notre table contient 30 000 lignes...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT COUNT(DISTINCT PRS_MASCULIN) / (SELECT COUNT(*) FROM MaTable)
FROM MaTable

Résultat : 0,2545758 => la dispersion est suffisament forte compte tenu du nombre de ligne pour procéder à la normalisation.

Quel sera la gain ?
PRS_TITRE nécessite au moins 5 octets ("Mlle.")
Une table externe peut utiliser un entier pour coder ce titre (ou un smallint le gain sera quasiement le même).
La table peut être construite de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
TIT_ID TIT_TITRE
------ ---------
1      M.
2      Mme.
3      Mlle.
4      Me.

etc...

La table de référence va donc couter : 9 octets * 4 lignes soit : 36 octets.
elle sera lue en une seule passe (car les SGBDR lisent des pages de l'ordre de 4 à 8 Ko !)

La table non normalisée coutera n octets de volume avec un PRS_TITRE de 5 octets.
Si elle devient normalisée elle ne coutera qu'un seul octet de moins puisque la différecne entre CHAR(5) et entier est de 1 octet.
Mais elle comporte 30 000 lignes... soit 8 pages lues.
Donc ta table non normalisée demande 8 pages de lecture supplémentaire... Bien entendu si l'on code la clef de la table de référence en smallint on passe à 24 pages lues en plus et si entier < 256 => 32 pages lues supplémentaires...
La normalisation a au moins fait gagner 7 pages en lecture...

La conclusion est simple :
La nécessité de normaliser ou pas, doit s'apprécier en fonction de la dispersion des données et de la taille des pages lues par le SGBDR.
J'ai coutûme de dire que :
pour les tables faiblement populées la normalisation doit s'effectuer si la dispersion est inférieure à 90%
pour les tables moyennement populées la normalisation doit s'effectuer si la dispersion est inférieure à 99%
pour les tables fortement populées la normalisation doit s'effectuer si la dispersion est inférieure à 99,9%

Autres avantages :
Si la données est stockée directement, rien n'empêche de saisir 'M.', 'Mr', 'Mr.' correspondant à Monsieur. Or cela va créer à tyerme de nombreux problèmes. Il faut donc mettre en place un contrôle de validité.
Le choix est simple : une contrainte CHECK VALUE IN ('M.', 'Mme.', 'Mlle.'). C'est léger, simple et... emmerdant !
En effet si notre quidam qui a modélisé la base n'a pas pensé à mettre toutes les valeurs, alors il faut modifier la structure de la table en passant un ordre ALTER !
Super !!! Par exemple notre quidam à oublié 'Me.' pour Maître (notaire, avocat...) et 'Dr.' pour Docteur !
L'avantage d'avoir une table de référence est donc bien de pemettre l'ajout ou la suppression de données sans altérer le modèle de données.
La containte d'intégrité référentielles fera la même chose que le CHECK VALUE....
Donc une grande souplesse en plus !

Contrairement donc à ce que tu dis, dans toues les cas ou le volume des données est en jeu, cette normalisation ne présente que des avantages !

En ce qui concerne les valeurs agrégées c'est une autre problématique...
D'abord l'exemple que tu donne n'est vraiement pas le bon, car toutes les compagnies, comme toutes les gestion de stocks possèdent des colonnes de comptage indépendante de la valeur réllément compté et cela pour deux problématiques différentes : la cie d'avion pour faire du surbooking, la gestion des stocke à cause de la démarque inconnue et donc de la nécessité de procéder régulièrement à un inventaire...
Si l'on veut conserver une valeur agrégée qui possède un réel intérêt il faut donc mettre en place un trigger qui lors des insert, update et delete, va recalculer cet agrégat.
Dès lors analysons différents cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Peu de lecture, peu de modif           => pas de nécessité de dénormaliser
Peu de lecture, beaucoup de modif      => surtout pas de normalisation
beaucoup de lecture, beaucoup de modif => la dénormalisation va dégrader sensiblement les perfomances du serveur
beaucoup de lecture, peu de modif      => la dénormalisation sera gagnante

N'oublions pas que les triggers sont les procédures les plus couteuses en ressources systèmes, bien plus que le procédures stockées !

La conclusion est donc simple : la dénormalisation ne peut s'engager qu'après avoir normalisé sa base,l'avoir mis en production et l'avoir auditée...
Une normalisation "préventive" s'avère généralement un remède pire que le mal !

[SQLpro]

Facade :

L'indexation cluster determine generalement l'ordre physique dans lequel sont stockes les enregistrements (hormis dans le cas exceptionnel des tables DOL sous ASE). Dans ce cas, creer un index cluster sur un champ autoincremente genere un hot-sport enorme sur la derniere page de ladite table (grosse contention) qui est un frein aux performances.

Oui, mais là c'est le travail ddu DBA et ce n'est plus du ressort du développeur ou CDP... Plan de maintenance.

A +

[SQLpro]

De plus des problèmes ne peuvent survenir que dans le cas d'insertion massive dans une table avec auto incrément et la plupart du temps c'est contournable en débranchant le mécanisme d'auto incrément

A +

[Pomalaix]

Je vais essayer d'être bref et d'aller à l'essentiel.

Ce avec quoi je ne suis absolument pas d'accord dans votre démarche, c'est quand vous dites qu'il faut attendre la mise en production de la base pour voir si la normalisation absolue ne pose pas de problème.

Des bases en 5NF, je n'en vois pas tous les jours. Mais heureusement, beaucoup d'entre elles donnent toute satisfaction. D'ailleurs, le jour où un théoricien va découvrir la 6NF, devra-t-on en déduire que toutes les bases existantes sont à jeter ??

Normaliser par défaut, oui, puisque la méthode est éprouvée. (Je ne préconise absolument pas une dénormalisation préventive).
Attendre la production pour vérifier que le modèle est efficace, c'est délirant.

Dans un projet digne de ce nom, on a une phase de test de charge permettant de vérifier que le traitement des gros volumes reste efficace, et que de nombreuses connexions concurrentes sont bien supportées.

Bien entendu, on n'est pas à l'abri de laisser passer un problème durant cette phase de test, mais "attendre et voir", c'est de la folie.
Comme l'a relevé un intervenant, une fois qu'un système est en production, devoir l'arrêter pour révision du modèle est une véritable catastrophe.

Vos exemples chiffrés ont le mérite de rendre les choses plus concrètes, même s'ils sont numériquement inexacts et extrapolés à mauvais escient.
* Sur l'exemple des titres de civilité, "Mlle" ne requiert que 4 caractères, et non 5. (Sur http://sqlpro.developpez.com/Normes/SQL_normes.html, j'ai souvenance d'une rubrique relative aux titres de civilité qui précise "Attention à la présence ou l'absence du point terminal de l'abréviation.")
* Les pages de SGBD ne font pas nécessairement 4 ou 8 Ko. D'ailleurs, en dernier ressort, c'est au niveau de l'OS et des disques physiques que ça se joue, avec une granularité qui peut être différente de celles des pages du SGBD du fait des caches de lecture anticipée.
* 8 pages de surcharge ( ou 24 ou 32) en cas de dénormalisation du titre. Même en admettant l'exactitude du calcul, ce point n'est pas fondamental. En effet, en transactionnel, on accède principalement aux données de manière ciblée, grâce aux index. Il est donc peu probable qu'on lise la table complète.

Par ailleurs, je l'avais dit d'emblée, puis en conclusion : la dénormalisation s'accompagne d'inconvénients. Il faut juger si les avantages qu'on obtient de la dénormalisation sont supérieurs.
Votre argument sur le manque de souplesse de la dénormalisation des titres (si subitement on veut en ajouter un) se situe à ce niveau-là : suis-je prêt à accepter cette incommodité ?

* Le critère numérique de dispersion est bien discutable.
En effet, sur une grande table de clients, on en conclurait qu'il faut créer une table des prénoms, puisqu'on n'a que quelques centaines de prénoms différents, alors qu'on a des milliers de noms de famille
Si vous avez un complément là-dessus, je suis preneur.

[SQLpro]

Je n'ais pas dit qu'il fallait aller jusqu'à la 5eme forme normale.

En fait 3 NF me suffit en général et couvre généralement la plupart des cas de figure.

En revanche, les tests de monté en charge sont rarement faits, et l'impasse sciement opérée sur ce point est monaie courante. De plus généralement les tests de montée en charge prennent rarement en compte la charge qui sera exactement celle d'ici 3 mois, 6 mois, un an... parce qu'il est très difficile de s'accorder sur le nombre de ligne de chaque table à terme.
De plus les schéma évoluent au gré des besoins et remettent en question l'étude "a priori". Connais tu des bases de données qui, depuis leur mise en exploit n'ont jamais vu leur schéma modifié ?

Arrêter un SGBDR pour en modifier son schéma n'est pas monnaie courante. Lorsque cela s'avère c'est généralement preuve d'un problème de conception à la base donc défaut d'analyse et/ou de modélisation.

Arrêter une appli pour le même motif relève que les développeurs ne réflêchissent pas au "style" de développement qui devrait être induit de la possible évolution du schéma.

Par exemple je préconise en général le style de dev suivant : lecture vai des requêtes SELECT sur tables ou mieux sur VUES et encapsulation du code SQL dans des bibliothèques ou des objets afin de pouvoir remédier rapidement aux modif. Mises à jour (INSERT/UPDATE, DELETE) dans des procédures stockées.
Lorsque ce style est mis en oeuvre, et il n'est pas plus couteux qu'un développement de "bidouilleur" la modification des schémas et des applicatifs est un jeu d'enfant puisque l'IHM et l'accès aux données ne subit quasiement aucun changement...

Lorsqu'on ne met pas en place des tables de ref il advient que si les colonnes visées sont fortement sollcictées il faut ajouter des index couteux car créé sur des types littéraux. Le probléme devient alors celui de la mise à jour des données et des index...

Quand à la table des prénoms ou des noms, elle existe sur de très grosses bases de données. Cela présente l'avantage d'être sûr que tous les Alain sont saisie de l'unique littéral mentionné et nom "ALAIN" ou "alain" ou encore " Alain" avec un espace devant !
De plus pour des éléments spécifiques comme les noms existe des mécanismes d'indexation phonétiques comme les soundex et autres (tables de Cutter par exemple) qui peuvent s'avérer payant.
Pensons aussi à l'indexation textuelle !

A +

[Fabien Celaia]

De plus des problèmes ne peuvent survenir que dans le cas d'insertion massive dans une table avec auto incrément et la plupart du temps c'est contournable en débranchant le mécanisme d'auto incrément

Non, pas seulement: n'importe champ numerique/date qui est la cle d'un index cluster et qui s'incremente aura ce genre de goulet d'etranglement.

[Fabien Celaia]

Facade :

L'indexation cluster determine generalement l'ordre physique dans lequel sont stockes les enregistrements (hormis dans le cas exceptionnel des tables DOL sous ASE). Dans ce cas, creer un index cluster sur un champ autoincremente genere un hot-sport enorme sur la derniere page de ladite table (grosse contention) qui est un frein aux performances.

Oui, mais là c'est le travail du DBA et ce n'est plus du ressort du développeur ou CDP... Plan de maintenance.

Alors dans ce cas, il faudra laisser au DBA le choix de definir le type d'index adequat... ce n'est heureusement pas toujours le cas (si "mes" 50 developpeurs ne s'en sortaient pas tout seul, je serais "mort"... ainsi que mon moteur SQL )

Par contre, entierement d'accord qu'on ne peut passer a une denormalisation sans avoir au prealable normalise. Je pense cependant que l'experience permet d'eviter de faire jouer les cobayes a la production et que la denormalisation ne doit pas passer forcement par un niveau "try & see".

[SQLpro]

En guise de conclusion et pour répondre à notre questionneur :

Mieux vaut commencer par une normalisation que par une dénormalisation !

A +

[Pomalaix]

En guise de conclusion et pour répondre à notre questionneur :
Mieux vaut commencer par une normalisation que par une dénormalisation !

Arf, tout ça pour ça !
Comme quoi le consensus tient en peu de mots...

[SQLpro]

J'étais sûr que cela te ferait rigoler !!!!

On est pas payé mais au moins on rigole !!!!

A +

[Bruno75]

Merci pour toutes vos réponses.

Une petite remarque. SQL pro j'ai l'impression que tu travailles avec des moyens très important parce que

Le probléme de conversion en décisionnel est tout autre. Dans ce cas : modèle en étoile ou flocon + réplication
...
Mais pour du DataWaehouse il existe des SGBD (R ?) spécialisé comme celui de Sybase...

Donc pas besoin de faire du DW dans du SGBDR. Choisir le bon outil pour donner la bonne solution au problème posé !

+ les stratégies d'audit de bases.

Chanceux va.

[Fabien Celaia]

C'est toujours moins cher d'acheter un bon moteur que de devoir rafistoler un mauvais a coup de CPU et de RAM
De plus, l'economie de disque (3x moins) peut se reveler payant pour un DW digne de ce nom

[SQLpro]

Bon exemple Alexandre T... C'est ce que je traite à longueur de journée dans mes audits...

Enfin en ce qui concerne ce que dit Pomalaix en général :

Attendre la production pour vérifier que le modèle est efficace, c'est délirant.
Dans un projet digne de ce nom, on a une phase de test de charge permettant de vérifier que le traitement des gros volumes reste efficace, et que de nombreuses connexions concurrentes sont bien supportées.

Malheureusement il est TRES rare de voir de voir des tests de charge et les rares tests de charge que j'ai vu étaient sur des volumes insignifiants ou des machines inapropriée. Quelques exemple : test de charge 2 go... Sur une base devant recevoir en 3 années d'exploit 600 Go...
Autre exemple : test de charge sur un serveu P2 à 1 Ghz mono processeur avec disque IDE... Pour un site web devant tourner avec une web farm et des serveurs quadri pro SCSI répliqués sur 4 serveurs !!!
Et ce sont des gros projets avec de gros moyens !!!! ;-)

Pomalaix
Pourquoi normaliser, au fait ? Principalement :
[...]

tu as oublié deux éléments les plus essentielles à mes yeux :
1) un SGBDR est optimisé pour faire des relations entre les tables. Donc, ne pas s'en priver !
2) la normalisation économise le cache des données et comme les caches ne sont pas extensibles à l'infini, plus le cache est dense en info, plus on peut traiter de tuples, plus vite l'information sera traiter. A contrario de grande tables (grande par leur lignes) encombre le cache car un SGBDR n'est pas capable de ne mettre en cache que certaines colonnes d'une table.

Pomalaix
Une question courante de dénormalisation concerne les valeurs agrégées.

***

Pour cela il existe des techniques tout à fait particulière qui combinent les deux mondes :
vues matérialisée dans Oracle, vues indexées dans MS SQL Server.
Là encore le modèle n'est pas dénormalisé, mais une redondance est sciement introduite, calculée automatiquement de manière interne en minimisant les ressources du système.

A noter, je prépare une série d'article sur l'optimisation des bases de données SQL Server pour SQL Server Magazine. Mais ces articles sont des articles TRES génériques dont les principes peuvent être repris pour tous les SGBDR.

A +

[SQLpro]

Extrait de : http://www.developpez.net/forums/sho...74&postcount=4

Ne mélangez pas le niveau logique et le niveau physique : très nombreux sont ceux qui ont oublié que l’indépendance entre le niveau physique et le niveau logique est un point capital et se sont fourvoyés. Commencez par vous focaliser sur le niveau logique. Quant à la performance (niveau physique), on trouve toujours un moyen de la garantir sans dénaturer ce qui a été fait au niveau logique.

[...]

Pour en arriver au niveau physique. Quant à la performance en relation avec le fait de normaliser ou dénormaliser, il n'y a aucune règle absolue. Vous devez construire un prototype, mesurer cette performance et améliorer le paramétrage physique (à commencer par les index...) jusqu’à obtenir les performances attendues. Sachez qu'en vingt ans de ("very large") bases de données relationnelles dans tous les secteurs d'activité, banque, assurance, industrie, services, j'en passe et des meilleures, j'ai toujours normalisé à fond et n'ai jamais eu à dénormaliser. En contrepartie, j'ai prototypé des nuits et des nuits (pour ne pas perturber les autres en pleine journée) et j'ai retenu que rien n'est jamais acquis : ce qui marche bien chez l'un est à reprendre complètement chez l'autre, et c'est ce qui fait du reste un des charmes du métier...

[fsmrel]

Merci SQLpro pour les citations.

J'ajouterai que j’ai souvent eu à engager mon entreprise (une SSII) en ce qui concerne la performance des applications chez nos clients. Il est évident qu’un client n’attendra pas que la base de données soit en production pour qu’on lui prédise la durée des traitements !

Et pourtant, histoire vécue... Tel grand cabinet modélise et conçoit une très grosse base de données pour le compte d’une très grande entreprise. Concernant LE batch quotidien, engagement pris sur une durée de traitement de 8 heures. Arrive l’heure de vérité, la mise en production. Durée effective du traitement : 240 heures (je dis bien, 10 jours pleins)... Pour un batch quotidien, dur, dur... Les pénalités vont tomber ? Vous n’y pensez pas, car en cours de route le client à décidé de changer de matériel et de SGBD : le grand cabinet était donc d’office désengagé... Les causes d’un tel désastre ? Le concepteur (du grand cabinet) ne connaissait rien à la modélisation et n’avait jamais touché à une base de données. En conséquence, des tables complètement dénormalisées et inutilement obèses, des requêtes patinant dans d’immenses champs de neige (je veux dire de valeurs nulles). Aucun prototypage de performance effectué, laxisme du client, etc., la totale. Quand j’ai eu à expertiser tout cela, imaginez mon étonnement puis ma colère devant tant d’incurie...

Une année plus tard, je dois à mon tour concevoir l’architecture physique d’une autre grosse base de données chez ce même client, encore sous le choc des 240 heures. Je dois engager mon entreprise quant à la performance. Finirai-je dans le goudron et les plumes ? Ne sachant pas lire dans le marc de café, je demande à pouvoir au préalable monter un prototype. Le client est d’accord pour me prêter une machine, la nuit. Je valide le modèle conceptuel, en m’assurant de la 3e forme normale puis le dérive en base de données et bourre celle-ci ras la gueule, crée les index pertinents, effectue les campagnes d’explains, bref la routine. Au bout de 3 semaines, j’estime le temps de traitement batch à 5 heures : cela convient au client. Autant vous dire que j’ai sensibilisé l’équipe de développement de mon entreprise à cet aspect des choses et nous sommes restés constamment en phase et très vigilants (vous noterez que les développements n’ont été effectués qu’après engagement). Le jour de la mise en production : temps de traitement batch égal à 4h40. Toutes les tables étaient en 3e forme normale, etc.

Je ne cherche pas à dire autre chose que ceci : mieux vaut prévenir que guérir. Et comme dit le poète :

« L’avait l’ don, c’est vrai, j’en conviens,
L’avait l’ génie,
Mais sans technique, un don n’est rien
Qu’un’ sal’ manie... »

[Daranc]

Bonjour
j'ai lu ce post (ou fil ,j'ignore le mot employé sur les forum Develloppez). pratiquement tois ans de débat. Mais pourrais je avoir une explication ou un lien qui parle de ce qu'est la normalisation?
Merci
Daranc

[fsmrel]

Bonsoir Daranc,

Très rapidement après qu’il eut inventé le Modèle relationnel en 1970, Ted Codd a traité de problèmes rencontrés avec la manipulation des relations (informellement tables), ce qui l’a conduit à ce qu’il a appelé la "Normalisation des relations" (jeu de mots peut-être lié au contexte de l’époque, dans le cadre des relations des blocs Est-Ouest...)

Objectif à atteindre :

— Minimiser la redondance.
— Minimiser les difficultés et les anomalies lors des opérations de mise à jour (INSERT, UPDATE, DELETE).
— Réduire la nécessité de modifier la structure des relations à l’occasion de la prise en compte de nouveaux types de données (donc d’attributs).
— Aboutir à une base de données structurellement correcte.
— ...

Un exemple tout bête :

Vous êtes en face d’une table T de commandes. On a commandé le produit P1 au fournisseur F1, en quantité 300. Ce fournisseur habite Lyon. T peut avoir l’allure suivante (clé primaire soulignée) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
    T (IdFour   IdProd    Quantité    Ville)
         F1       P1           300    Lyon 

On aimerait bien faire figurer le fait que le fournisseur F2 habite Paris, mais tant que l’on ne lui a rien commandé, impossible de faire figurer cette donnée dans la table.

La normalisation a fait l’objet d’études poussées, entre les années 1971-1980, elle est devenue une théorie que l’on considère comme une branche des mathématiques appliquées.

Références :

E. F. Codd. “Further Normalization of the Data Base Relational Model”. IBM Research Report RJ909 (August 31, 1971).
(C’est un des papiers fondateurs mais dont je ne retrouve plus le contenu sur la toile, désolé...)

Un article de William Kent, qui fut à l’origine de la BCNF, mais curieusement qu’il n’évoque pas ici :
http://www.bkent.net/Doc/simple5.htm
Et où j’observe que sa définition de la 1re forme normale est caduque (aujourd’hui, un attribut peut être du type Relation).

L’ouvrage le plus complet et le plus pertinent sur le sujet reste l’ouvrage de Chris Date (environ 750000 exemplaires vendus à ce jour) :
C.J. Date. An Introduction to Database Systems, 8th edition. (Pearson - Addison-Wesley)
http://www.amazon.com/dp/0321197844?...KC5YNS9WG724E&

La version française existe :
C.J. Date. Introduction aux bases de données, 8e édition (Vuibert)
http://www.amazon.fr/Introduction-ba.../dp/2711748383

N’hésitez pas à fouiller dans les sites suivants :

http://www.dbdebunk.com/index.html
http://www.thethirdmanifesto.com/

Vous pouvez aussi consulter sur le forum Général SGBD, la discussion dans laquelle je suis amené à exposer la BCNF :
http://www.developpez.net/forums/sho...d.php?t=281221

Bonne chance !