50
Chapitre 4. Optimisation des objets et de la structure de la base de données
diaire qui lie l’employé au magasin, avec – c’est une bonne idée – des dates de validité. Vous trouverez sur la figure 4.1 un modèle très simple de ces entités.
Figure 4.1 — Premier modèle Commerce
Règles métier
Puisque nous abordons l’idée de dates de validité, vous devez être extrêmement attentif lors
de la phase de modélisation aux règles métier (business rules). Elles doivent être placées
autant que possible dans la structure. Les règles complexes pourront être implémentées en
déclencheurs (triggers).
En résumé, il faut stocker autant d’informations utiles possibles, pour permettre
de retrouver des données qui ont du sens et de la valeur, et, par conséquent, placer
l’information au bon endroit, c’est-à-dire dans la bonne entité, celle à laquelle elle
appartient naturellement, en respectant un principe important : l’économie. Cela
veut dire, éviter la duplication de données, qui alourdit le modèle, conceptuellement et physiquement, et diminue les performances.
La granularité des données est aussi à prendre en compte : désirez-vous des données détaillées (tout un ticket de caisse, produit par produit), ou seulement des
totaux ? En général, en application OLTP, les détails sont conservés : vous en aurez
forcément besoin un jour. Dans une application OLAP, on ne garde parfois que des
agrégats, par exemple des totaux par jour.
Chapitre 4. Optimisation des objets et de la structure de la base de données
diaire qui lie l’employé au magasin, avec – c’est une bonne idée – des dates de validité. Vous trouverez sur la figure 4.1 un modèle très simple de ces entités.
Figure 4.1 — Premier modèle Commerce
Règles métier
Puisque nous abordons l’idée de dates de validité, vous devez être extrêmement attentif lors
de la phase de modélisation aux règles métier (business rules). Elles doivent être placées
autant que possible dans la structure. Les règles complexes pourront être implémentées en
déclencheurs (triggers).
En résumé, il faut stocker autant d’informations utiles possibles, pour permettre
de retrouver des données qui ont du sens et de la valeur, et, par conséquent, placer
l’information au bon endroit, c’est-à-dire dans la bonne entité, celle à laquelle elle
appartient naturellement, en respectant un principe important : l’économie. Cela
veut dire, éviter la duplication de données, qui alourdit le modèle, conceptuellement et physiquement, et diminue les performances.
La granularité des données est aussi à prendre en compte : désirez-vous des données détaillées (tout un ticket de caisse, produit par produit), ou seulement des
totaux ? En général, en application OLTP, les détails sont conservés : vous en aurez
forcément besoin un jour. Dans une application OLAP, on ne garde parfois que des
agrégats, par exemple des totaux par jour.