55
4.1 Modélisation de la base de données
est temps de créer une entité Adresse, avec un attribut discriminant, spécifiant le
type d’adresse. La création de « séquences » d’attributs est un cercle vicieux : vous
avez l’impression d’y mettre un doigt, et bientôt vous y avez enfoncé le bras tout
entier. À chaque besoin nouveau, vous vous retrouvez à ajouter une nouvelle
colonne, avec un incrément de séquence. Que ferez-vous lorsque vous en serez arrivé
à la colonne Propriete20, ou Telephone12 ? Modélisez votre base correctement, ou si
vous devez maintenir un modèle existant, « refactorez ».
Refactoring
Le concept de refactoring indique les techniques de modification du code tout au long de son
existence. Il faut, en matière de modèle de données, songer à modifier la structure lorsque
des nouveaux besoins se font sentir. Il faut résister à l’envie de coder en dur des modifications
de logique, pour éviter de récrire ses requêtes après modification de schéma. Adapter son
schéma est plus long, mais bien plus solide et évolutif.
Lorsque la base est normalisée, il est parfois utile de dénormaliser, c’est-à-dire de
dupliquer au besoin – et uniquement lorsque c’est absolument nécessaire – le contenu d’une colonne. La plupart du temps, dénormaliser n’est pas nécessaire. Souvent
les dénormalisations sont faites avant même de tester les performances des requêtes,
ou pour résoudre des problèmes de performances qui proviennent d’une mauvaise
écriture de code SQL. Même si la dénormalisation se révèle utile, des mécanismes de
SQL Server comme les colonnes calculées ou les vues indexées permettent de dupliquer logiquement les données sans risque d’incohérences. L’autre solution pour
dénormaliser consiste à créer des colonnes physiques qui vont contenir des données
provenant d’autres tables, et qui sont maintenues par code, en général par déclencheur ou procédure stockée. Cette approche comporte quelques inconvénients :
ajouter du code augmente les risques d’erreur, diminue les performances générales et
complique la gestion de la base. Nous vous conseillons en tout cas vivement, dans ce
cas, d’utiliser une méthodologie simple, claire et consistante. Créez par exemple des
déclencheurs, avec une convention de dénomination qui permet de les identifier
rapidement, et optimisez leur code.
Une chose en tout cas est importante : la dénormalisation n’est pas la règle, mais
tout à fait l’exception. Elle ne doit être menée qu’en dernier ressort. En tout cas,
comme son nom l’indique, elle consiste à modifier un schéma déjà normalisé. En
aucun cas, elle ne peut être une façon préliminaire de bâtir son modèle.
Logiquement, plus votre modèle est normalisé, plus le nombre de tables augmente, et moins vous avez de colonnes par table. Cela a de nombreux avantages de
performance : vous diminuez le nombre de données dupliquées, donc le volume de
votre base, vous réduisez le nombre de lectures nécessaires pour extraire un sousensemble de données (on cherche en général à récupérer une partie seulement des
lignes et colonnes, pas une table tout entière), vous augmentez la possibilité de créer
des index clustered (plus sur ce concept dans le chapitre 6), et donc la capacité à
obtenir des résultats triés sans des opérations de tri coûteuses et à générer des plans
4.1 Modélisation de la base de données
est temps de créer une entité Adresse, avec un attribut discriminant, spécifiant le
type d’adresse. La création de « séquences » d’attributs est un cercle vicieux : vous
avez l’impression d’y mettre un doigt, et bientôt vous y avez enfoncé le bras tout
entier. À chaque besoin nouveau, vous vous retrouvez à ajouter une nouvelle
colonne, avec un incrément de séquence. Que ferez-vous lorsque vous en serez arrivé
à la colonne Propriete20, ou Telephone12 ? Modélisez votre base correctement, ou si
vous devez maintenir un modèle existant, « refactorez ».
Refactoring
Le concept de refactoring indique les techniques de modification du code tout au long de son
existence. Il faut, en matière de modèle de données, songer à modifier la structure lorsque
des nouveaux besoins se font sentir. Il faut résister à l’envie de coder en dur des modifications
de logique, pour éviter de récrire ses requêtes après modification de schéma. Adapter son
schéma est plus long, mais bien plus solide et évolutif.
Lorsque la base est normalisée, il est parfois utile de dénormaliser, c’est-à-dire de
dupliquer au besoin – et uniquement lorsque c’est absolument nécessaire – le contenu d’une colonne. La plupart du temps, dénormaliser n’est pas nécessaire. Souvent
les dénormalisations sont faites avant même de tester les performances des requêtes,
ou pour résoudre des problèmes de performances qui proviennent d’une mauvaise
écriture de code SQL. Même si la dénormalisation se révèle utile, des mécanismes de
SQL Server comme les colonnes calculées ou les vues indexées permettent de dupliquer logiquement les données sans risque d’incohérences. L’autre solution pour
dénormaliser consiste à créer des colonnes physiques qui vont contenir des données
provenant d’autres tables, et qui sont maintenues par code, en général par déclencheur ou procédure stockée. Cette approche comporte quelques inconvénients :
ajouter du code augmente les risques d’erreur, diminue les performances générales et
complique la gestion de la base. Nous vous conseillons en tout cas vivement, dans ce
cas, d’utiliser une méthodologie simple, claire et consistante. Créez par exemple des
déclencheurs, avec une convention de dénomination qui permet de les identifier
rapidement, et optimisez leur code.
Une chose en tout cas est importante : la dénormalisation n’est pas la règle, mais
tout à fait l’exception. Elle ne doit être menée qu’en dernier ressort. En tout cas,
comme son nom l’indique, elle consiste à modifier un schéma déjà normalisé. En
aucun cas, elle ne peut être une façon préliminaire de bâtir son modèle.
Logiquement, plus votre modèle est normalisé, plus le nombre de tables augmente, et moins vous avez de colonnes par table. Cela a de nombreux avantages de
performance : vous diminuez le nombre de données dupliquées, donc le volume de
votre base, vous réduisez le nombre de lectures nécessaires pour extraire un sousensemble de données (on cherche en général à récupérer une partie seulement des
lignes et colonnes, pas une table tout entière), vous augmentez la possibilité de créer
des index clustered (plus sur ce concept dans le chapitre 6), et donc la capacité à
obtenir des résultats triés sans des opérations de tri coûteuses et à générer des plans