Database Reference
In-Depth Information
Dans une base de données relationnelle, donc fortement transactionnelle, rien ne justiie
a priori la dénormalisation. Il faut avant tout normaliser au maximum. La dénormali-
sation étant un acte fort, elle ne peut que résulter d'une décision risquée prise en pleine
connaissance de cause à l'aide des critères suivants.
• Le gain de dénormalisation doit être prouvé : il faut donc mettre à l'épreuve la base
avec un volume de données signiicatif et une concurrence équivalente à celle de l'ex-
ploitation. Cela ne peut se faire généralement qu'en cours d'exploitation…
• Le gain doit être très important. Un gain minime sera généralement perdant à long
terme du fait du surcroît de volume généré par la redondance et l'accroissement des
temps de transaction (plus de données à mettre à jour, c'est toujours plus long).
• Le gain doit s'analyser globalement. L'erreur la plus courante est de ne mesurer que
le gain apporté à la table qui est dénormalisée. Or, la dénormalisation entraîne systé-
matiquement des effets de bord, qu'il est souvent dificile de mesurer de prime abord.
Par exemple, l'accroissement du volume des données comme l'allongement du temps
de mise à jour induit par la dénormalisation, a des répercussions sur les transactions
dont la durée augmente. De ce fait, les verrous durent plus longtemps et les risques de
blocage comme d'interblocage sont accrus.
Plus une table est petite (en nombre de colonnes), plus elle est facile à indexer. D'ailleurs,
le respect absolu de la normalisation des relations (pas de valeurs
NULL
) conduit à une
base dont les tables sont formées d'une clé et d'au plus un attribut non clé.
Enin, avant de dénormaliser, il existe d'autres techniques telles que : l'hypernormalisa-
tion (par exemple ajouter une table des prénoms au lieu de mettre la colonne prénom dans
la table personne) ou le partitionnement.
Quelle que soit la solution d'implémentation que vous choisirez : normaliser au maximum,
dénormaliser, indexer telle ou telle colonne, programmer une contrainte dans une procédure
plutôt que dans un déclencheur, etc., vous rencontrerez des avantages, mais aussi des inconvé-
nients. Vous devrez toujours peser le pour et le contre de toute implémentation ou optimisation
pour décider inalement le plus souvent après des tests à grandeur nature.
Les règles de Brouard
Pour en terminer avec ces mécanismes d'optimisation, quelques conseils d'ordre général à
propos de vos requêtes et de l'utilisation d'un SGBD. Parues en 2008 sur le blog de F. Brouard
(http://blog.developpez.com/sqlpro), voilà les 10 meilleures pratiques pour développer avec un
SGBDR.
1. Une base de données relationnelle doit gérer des relations et non des ichiers.
Assurez-vous que vos tables ne contiennent pas un nombre trop important de colonnes.
Respectez la normalisation introduite par le modèle relationnel. Contrairement à une
