[Article] Bases de données relationnelles - Normalisation [News]

**fsmrel** · 15/03/2011, 20h38

Bonsoir alassanediakite,

La rédaction de l'article est terminée, et je suis en train de le relire pour la nième fois, tout en découvrant à chaque fois que j'ai un bout de paragraphe à rajouter sur la partie 6NF, en relation avec la modélisation des données temporelles (et là, la ceinture blanche part en courant

).

Par ailleurs, je suis bien freiné parce qu'il me faut répondre dans le cadre de discussions où les pinailleurs (pour rester poli) de service en remettent une couche après l'autre (ça redonde, ça prend du temps et ça lasse

...)

Ça ne devrait quand même pas tarder. Patience...

Et merci pour l'attention que vous portez à l'article.

**MacFly58** · 15/03/2011, 23h59

Bonsoir,

F.3. Le clustering selon DB2 for z/OS

(...)

Deuxième scénario : L'index est rendu cluster :

Coûts estimés : CPU Time = 00:17:21 ; I/O Time = 00:01:20 ; Min. Elapsed Time = 00:17:21.

Petite faute de frappe : 17:21 + 1:20 = 00:18:41

PS : Je ne sais pas si c'est le meilleur endroit pour poster ce genre de commentaires.

**fsmrel** · 16/03/2011, 02h59

Bonsoir Mac,

C'est un plaisir de vous revoir. Vous postez au bon endroit, mais votre remarque est nulle et non avenue, car vous additionnez des choux et des navets

. En effet, dans cet exemple, l'I/O time n'a pas d'incidence sur le temps elapse et il n'y a rien à rectifier...

A bientôt,

fsmrel

**alassanediakite** · 18/03/2011, 13h16

Salut fsmrel
Dans ce poste qu'est ce qui empêche de mettre datedemission dans la table emplois et de supprimer la table historique?
Je me prépare pour une discussion à la fin de votre article. J'attends d'avoir une ceinture bleu (comme ça pas de KO au premier round). Le gros problème c'est l'anglais (je peine à comprendre le français et on me dis que les meilleurs documents sont en anglais) faut-il vraiment apprendre l'anglais?
En tous cas, merci pour l'effort immense

**fsmrel** · 18/03/2011, 15h48

Bonjour alassanediakite,

Envoyé par alassanediakite

qu'est ce qui empêche de mettre datedemission dans la table emplois et de supprimer la table historique?

Ce qui empêche ?

Il s’agit tout d’abord de respecter la logique des prédicats. En effet, l’en-tête de la table EMPLOI correspond au prédicat suivant, relatif aux employés en activité :

La personne PsnId a été embauchée à la date DateEmbauche par l’entreprise EntId.

Et l’ajout d’un paramètre DateDemission introduirait une contradiction puisqu’un employé en activité par définition n’a pas démissionné.

Il s’agit de respecter la sémantique pour les mêmes raisons.

Par voie de conséquence, au niveau tabulaire, il faudrait autoriser la présence de ce menteur de bonhomme Null et là, je sors ma sulfateuse (de même si l’on utilise des valeurs spéciales pour les dates, du genre '31/12/9999').

Voyez par exemple les discussions suivantes :

http://www.developpez.net/forums/d96...ions-binaires/
http://www.developpez.net/forums/d94...e/#post5394163
http://www.developpez.net/forums/d65...n/#post3873719

Il s'agit d'un échantillon significatif (je pense)...

Au plan de la manipulation de données, au quotidien on s’intéresse essentiellement aux données vives. S’il fallait les rechercher dans la table HISTORIQUE, ça reviendrait à patauger dans une montagne de tuples, avec à la clef des requêtes plus complexes, et des problèmes de performance en vue (il est plus sympathique d’avoir des tables de plus faible volumétrie et d'accès plus rapide, en tout cas c’est le point de vue de la direction de la production informatique).

Envoyé par alassanediakite

on me dis que les meilleurs documents sont en anglais

Donc, pour être plus sûr, je vais traduire ma prose in this language...

Envoyé par alassanediakite

En tous cas, merci pour l'effort immense

A mon tour, je vous remercie à nouveau pour l’intérêt que vous portez à l’article (qui arrive aujourd'hui à 150 pages d'un fichier PDF...)

Le monde est trop bien programmé pour être l’œuvre du hasard…

... Et le hasard, c’est Dieu qui passe incognito (A. Einstein) ...

**fsmrel** · 04/08/2011, 17h05

Bonjour,

La 3e (et dernière) partie de l’article est dans les tuyaux, prête à publication. Ça ne devrait pas tarder.

fsmrel

**alassanediakite** · 04/08/2011, 20h26

Bonjour maitre François
Vite vite et n'oublie pas d'autoriser l'impression de la version pdf.
Pour la suite de mon article, j'arrive pas à trouver un moment de réel concentration.
@ très bientôt.

**fsmrel** · 05/08/2011, 00h33

Mise à jour du 14/07/2011

Bonsoir,

Voici la 3e partie de mon article sur la normalisation des bases de données, partie qui traite des quatrième, cinquième et sixième formes normales.

Comme il n’y a pas de normalisation en 7NF par projection/jointure (sauf chez les farfelus), l’article est achevé, aux quelques modifications près d’usage que je peux toujours être amené à effectuer suite à vos observations.

Bonne lecture !

**Philippe Vialatte** · 05/08/2011, 01h12

Enorme...

A l'époque o combien lointaine de mes études, je m'étais arrété a Boyce-Codd (si je me rappelle bien du contexte, Miranda avait abordé le sujet brièvement, mais suite a un malaise vagal d'un tiers de l'amphi...)

Félicitations pour le travail accompli, cela faisait un moment que, même dans l'édition, je n'avais pas vu un tel résultat

Chapeau

**fsmrel** · 05/08/2011, 02h15

Merci Philippe

J'espère qu'il ne traîne pas trop d'erreurs...

Que des étudiants ne s'enthousiasment pas pour le sujet, ça se comprend. Pour ma part, c’est un peu différent, j’ai tout appris sur le terrain (avec les bouquins de Codd et Date quand même en tête), en concevant ou auditant des bases de données dans tous les secteurs d’activité, sur toutes leurs facettes (dossiers de conception, modélisation, performances, etc., etc.), en pratiquant le conseil, le sauvetage en catastrophe, en encadrant les ingénieurs, en les consolant (ou en les eng...) j’en passe et des meilleures.

J’ai même souvent enseigné les bases de données à des ingénieurs qui n’étaient pas des perdreaux de l’année et quand j’en arrivais à la 5NF, si certains me demandaient la permission de dormir, je la leur accordais volontiers

En gros, ce que j’ai écrit ici (scripta manent) est le fruit de nombreux barouds, d’une longue, longue expérience que j’essaie de prolonger et de faire un peu partager...

**f-leb** · 05/08/2011, 19h57

+ de 150 pages fsmrel ! Ce n’est pas un article, c’est une Œuvre, que dis-je un Monument (historique 6FN) !!

Petite question fondamentale, il faut bien que quelqu’un la pose:

Pourquoi avoir mis une image de castor en 1ère page ?

**fsmrel** · 06/08/2011, 02h43

Bonsoir Achille,

Plus de 150 pages, certes, mais j’ai taillé drastiquement dans la masse, car je commençais à raconter ma vie...

Quant à la question fondamentale et impertinente que vous posez (ne prenez pas cet air gêné) :

Un peu avant que vous ne vîntes au monde, j’avais pris goût à l’architecture des bases de données (bon d’accord, à l’époque c'était le modèle hiérarchique et le modèle réseau, mais on fait avec ce qu'on a), et comme le castor a la réputation d’être un excellent architecte, je n’ai pas résisté à la tentation de le faire figurer symboliquement dans le roman (historique lui aussi, 6NF oblige là encore).
Vous le trouverez à l’œuvre par exemple au paragraphe 4.2 ou au paragraphe 5.3. De fil en aiguille, il est remonté jusqu’à la 1re page...

Vous me direz que j’avais le choix de l'emblème, le cerveau choc faisant montre ci-dessous d’excellentes qualités, mais j'avoue ne pas avoir pensé à lui

(mais ça me donne des idées

...)

J’aurais pu aussi retenir Naf-Naf qui a la réputation de bâtir du solide.

Mais bon, va pour le castor comme emblème...

**PyNub** · 01/11/2012, 14h33

Je vous remercie pour la grande qualité de votre article, qui m'a aidé à distinguer le vrai du faux dans le fatras des écrits sur le sujet pas forcément, et bien souvent, non argumentés comme le sont au contraire les vôtres.

**fsmrel** · 02/11/2012, 17h24

Bonjour PyNub,

Votre message fait plaisir. Plutôt que de recopier des affirmations plus ou moins vraies ou fausses, il est vrai que j’ai préféré m’appuyer d’une part sur les travaux de chercheurs et auteurs de très grande qualité, tels Codd, Fagin ou Date, et d’autre part sur mon expérience de terrain (quelques décennies de barouds...) pour tenter de transmettre quelque chose qui soit pertinent, même si ça n’est pas toujours facile...

Si j’ai pu vous aider à y voir plus clair, mon objectif aura été atteint. Bonne route !

**PyNub** · 02/11/2012, 18h06

Bonjour,

Je suis tombé sur votre ouvrage dans le cadre de mes études, et celui-ci m'a aidé à clarifier certaines notions de normalisation. Actuellement je suis en train de le reprendre depuis le début car je l'ai parcouru en complément de mon cours et en sautant quelques étapes. De fait certaines subtilités m'ont échappées. Mais cette relecture est agréable et se fait sans effort, de déchiffrage j'entends, car l'effort de réflexion est par contre certain.

Encore merci.

**Bob_the_developper** · 08/01/2013, 13h25

Bonjour,

J'ai vraiment très envie de lire votre document en entier, seulement, cela me serait bien plus aisé si je pouvais l'imprimer: sauf erreur de ma part le pdf semble non disponible, est-ce bien vrai?

En tout cas bravo pour le travail réalisé et à bientôt.

Cordialement,

**fsmrel** · 08/01/2013, 13h36

Bonjour Bob,

Je viens de vérifier : le PDF a effectivement disparu. Je vais voir ce que je peux faire pour que vous puissiez y avoir accès.

A bientôt,

François

**fsmrel** · 08/01/2013, 14h46

Hello Bob,

J'ai réussi à remettre en place le PDF (enfin une de ses versions...) J'espère que cette version est synchrone et ne contient pas de bogues...

Merci de me signaler ce qui pourrait vous paraître bizarre...

Il va falloir que je surveille de temps en temps la présence du fichier.

Bonne lecture !

Invité · 06/02/2013, 15h30

Bonjour fsmrel

J’ai une petite question concernant le nommage de certains attributs de certaines relations.

Imaginons un concept VOITURE représenté par la relation ‘car’ ayant pour clé primaire ‘car.id’. Si j’ai besoin d’une information optionnelle telle une description par exemple, alors afin d’éviter le bonhomme NULL, je créé une relation ‘car_description’ ayant pour attribut ‘car_description.id’ (clé primaire et étrangère) ainsi qu’un autre attribut représentent le texte de la description.
De par votre expérience, quel serait le mot le plus approprié pour nommer cet autre attribut:

‘car_description.description’

(ça fait redondant et plus particulièrement au niveau du code applicatif)

‘car_description.text’
‘car_description.content’
‘car_description.value’

?

J’ai beaucoup de relations représentant des informations optionnelles tel que des descriptions textuelles, acronymes, grandeurs numériques et je me pose cette question afin d’avoir de l’homogénéité dans mon projet.

Merci pour vos conseils