Aplatissement de la table

L’aplatissement de table stocke une hiérarchie de tables connexes comme une seule table dans une base de données relationnelle.

Modèles d'extension

Les tables telles que les tables Tâche et Élément de configuration de base [cmdb] ont une hiérarchie de tables connexes où une ou plusieurs tables enfants s’étendent à partir d’une table parente. Le système propose ces modèles d’extension pour stocker une hiérarchie de tables sur une base de données relationnelle.

Tableau 1. Modèles d’extension disponibles

Modèle d'extension	Aplatit les tables ?
Table par classe	Non
Table par hiérarchie	Oui
Table par partition	Oui

Le modèle d’extension n’affecte pas la façon dont les tables apparaissent ou fonctionnent dans l’instance. Toutes les fonctionnalités de table, y compris les vues de base de données, restent inchangées par le modèle d’extension.

Table par classe

Le modèle d’extension Table par classe stocke chaque table de la hiérarchie dans sa propre table physique sur la base de données relationnelle. Chaque table physique utilise le préfixe de table de la table source, chacune stockant une classe d’enregistrements différente. La table Actif [alm_asset] et ses tables enfants sont des exemples de modèle d’extension Table par classe : Matériel [alm_hardware], Consommable [alm_consumable], Installation [alm_facility] et Licence de logiciel [alm_license]. La table parente de la hiérarchie, Actif, stocke une copie de chaque enregistrement dans ses tables descendantes.

Pour trouver des enregistrements dans le modèle d’extension Table par classe, le système interroge les enregistrements de plusieurs tables et joint les résultats. Par exemple, lors de la recherche de matériel dans une installation connexe, le système doit joindre les résultats des tables Matériel, Installation et Actif.

Les jointures de tables entraînent un goulot d’étranglement des performances sur les bases de données relationnelles. Plus une requête inclut de classes, plus les performances de la requête sont mauvaises. Par conséquent, toute requête d’enregistrements située en haut de la hiérarchie des tables offre les pires performances, car elle nécessite de joindre toutes les tables descendantes.

Le système utilise le modèle d’extension Table par classe par défaut lors de la création de tables. La plupart des tables système utilisent également le modèle d’extension Table par classe, car il n’y a aucun avantage en termes de performances à les aplatir.

Table par hiérarchie

Le modèle d’extension Table par hiérarchie stocke une hiérarchie entière dans une table physique plate unique de la base de données relationnelle. La table physique est nommée d’après la table parente de la hiérarchie, telle que Tâche. La table physique contient tous les enregistrements de la hiérarchie de tables et attribue une valeur de colonne de nom de classe à chaque table descendante de la hiérarchie. Le système utilise le nom de la table source comme valeur de nom de classe. Par exemple, les enregistrements de tâches peuvent avoir des noms de classe tels que Changement, Incident ou Problème.

Pour trouver des enregistrements dans une hiérarchie de table, le système interroge la table physique et utilise la colonne de nom de classe pour contraindre les résultats. Étant donné que ces requêtes ne nécessitent pas de joindre les résultats de plusieurs tables, le système offre de meilleures performances de recherche.

Le système utilise le modèle d’extension Table par hiérarchie pour la hiérarchie de table Tâche sur les bases de données MySQL. D’autres tables utilisent le modèle d’extension Table par classe, car il n’y a aucun avantage en termes de performances à les aplatir. Pour utiliser Table par hiérarchie sur une base de données Oracle, contactez le support technique.

Table par partition

Le modèle d’extension Table par partition stocke une hiérarchie de tables entière dans une table logique plate unique de la base de données relationnelle. Chaque table logique peut avoir plusieurs tables de stockage physique appelées partitions qui la prennent en charge. Chaque partition optimise les ressources de base de données disponibles pour une table physique, telles que le nombre de colonnes, le nombre d’index et la taille des lignes. Le système ajoute une partition chaque fois que la table logique a besoin de ressources de base de données relationnelles supplémentaires.

Chaque table logique porte le nom de la table parente de la hiérarchie, et chaque partition physique de prise en charge se compose d’un nom logique et d’un nom de partition. Par exemple, la table Élément de configuration de base [cmdb] commence sous la forme d’une table logique sans partitions. Supposons que vos éléments de configuration du matériel consomment suffisamment de ressources de base de données pour que le système crée une partition appelée cmdb$par1 pour les stocker. Plus tard, les éléments de configuration de l’ordinateur pourraient consommer suffisamment de ressources de base de données pour justifier la création par le système d’une deuxième partition appelée cmdb$par2 pour stocker ces enregistrements.

Dans chaque table logique, le système attribue une valeur de colonne de nom de classe à chaque table descendante de la hiérarchie. Par exemple, dans la table logique de l’élément de configuration de base, il existe des enregistrements avec des noms de classe pour l’application, l’ordinateur et le routeur IP. Le système attribue également une valeur de chemin d’accès de classe à deux chiffres à chaque table descendante de la hiérarchie. Le chemin d’accès de la classe est basé sur l’emplacement de la table dans la hiérarchie. Par exemple, la classe parente Hardware peut avoir un chemin d’accès de classe tel que / !! /! D et la classe enfant Computer peuvent avoir un chemin de classe tel que / !! /! D/ !!.

Pour trouver des enregistrements dans le modèle d’extension Table par partition, le système interroge la table logique et ses partitions et utilise la colonne de chemin d’accès de la classe pour contraindre les résultats. Étant donné que ces requêtes ne nécessitent pas de joindre les résultats de plusieurs tables, le système offre de meilleures performances de recherche. En outre, le chemin d’accès de la classe réduit le nombre total d’enregistrements à rechercher, ce qui améliore encore les performances de recherche.

Le système utilise le modèle d’extension Table par partition pour la hiérarchie de table Élément de configuration de base [cmdb] sur les bases de données MySQL. Pour utiliser Table par partition sur une base de données Oracle, contactez le support technique.