Tabellenreduzierung
Durch die Tabellenreduzierung wird eine Hierarchie zugehöriger Tabellen als eine einzige Tabelle in einer relationalen Datenbank gespeichert.
Erweiterungsmodelle
Das System bietet diese Erweiterungsmodelle zum Speichern einer Tabellenhierarchie in einer relationalen Datenbank.
| Erweiterungsmodell | Tabellen reduzieren? |
|---|---|
| Tabelle pro Klasse | Nein |
| Tabelle pro Hierarchie | Ja |
| Tabelle pro Partition | Ja |
Tabelle pro Klasse
Das Erweiterungsmodell „ Tabelle pro Klasse “ speichert jede Tabelle der Hierarchie in einer eigenen physischen Tabelle in der relationalen Datenbank. Jede physische Tabelle verwendet das Tabellenpräfix der Quelltabelle. Jede speichert eine andere Klasse von Datensätzen. Ein Beispiel für das Erweiterungsmodell „Tabelle pro Klasse“ ist die Tabelle „Asset“ [alm_asset] und ihre untergeordneten Tabellen: Hardware [alm_hardware], Verbrauchsgut [alm_consumable], Facility [alm_facility] und Softwarelizenz [alm_license]. Die übergeordnete Tabelle der Hierarchie, Asset, speichert eine Kopie jedes Datensatzes in den untergeordneten Tabellen.
Um Datensätze im Erweiterungsmodell „Tabelle pro Klasse“ zu finden, fragt das System Datensätze aus mehreren Tabellen ab und verknüpft die Ergebnisse. Wenn Sie beispielsweise nach Hardware in einer zugehörigen Einrichtung suchen, muss das System Ergebnisse aus den Tabellen „Hardware“, „Anlage“ und „Asset“ verbinden.
Tabellenverknüpfungen verursachen bei relationalen Datenbanken einen Leistungsengpass. Je mehr Klassen eine Abfrage enthält, desto schlechter ist die Abfrageleistung. Daher weist jede Abfrage nach Datensätzen von oben in der Tabellenhierarchie die schlechteste Leistung auf, da sie das Verknüpfen aller untergeordneten Tabellen erfordert.
Beim Erstellen von Tabellen verwendet das System standardmäßig das Erweiterungsmodell „Tabelle pro Klasse“. Die meisten Systemtabellen verwenden auch das Erweiterungsmodell „Tabelle pro Klasse“, da sich durch ihre Reduzierung keine Leistungsvorteile ergeben.
Tabelle pro Hierarchie
Das Erweiterungsmodell „ Tabelle pro Hierarchie “ speichert eine gesamte Tabellenhierarchie in einer einzelnen flachen physischen Tabelle in der relationalen Datenbank. Die physische Tabelle ist nach der übergeordneten Tabelle der Hierarchie benannt, z. B. Aufgabe. Die physische Tabelle enthält alle Datensätze der Tabellenhierarchie und weist jeder untergeordneten Tabelle der Hierarchie einen Klassennamenspaltenwert zu. Das System verwendet den Namen der Quelltabelle als Klassennamenwert. Aufgabendatensätze können beispielsweise Klassennamen wie „Change“, „Incident“ oder „Problem“ aufweisen.
Um Datensätze in einer Tabellenhierarchie zu finden, fragt das System die physische Tabelle ab und verwendet die Klassennamenspalte, um die Ergebnisse einzuschränken. Da für solche Abfragen keine Ergebnisse aus mehreren Tabellen verknüpft werden müssen, bietet das System eine bessere Suchleistung.
Das System verwendet das Erweiterungsmodell „Tabelle pro Hierarchie“ für die Aufgabentabellenhierarchie in MySQL-Datenbanken. Andere Tabellen verwenden das Erweiterungsmodell „Tabelle pro Klasse“, da ihre Reduzierung keinen Leistungsvorteil bietet. Um Tabelle pro Hierarchie in einer Oracle-Datenbank zu verwenden, wenden Sie sich an den technischen Support.
Tabelle pro Partition
Das Erweiterungsmodell „ Tabelle pro Partition “ speichert eine gesamte Tabellenhierarchie in einer einzigen flachen logischen Tabelle in der relationalen Datenbank. Jede logische Tabelle kann von mehreren physischen Speichertabellen, den sogenannten Partitionen, unterstützt werden. Jede Partition optimiert die für eine physische Tabelle verfügbaren Datenbankressourcen, z. B. Spaltenanzahl, Indexanzahl und Zeilengröße. Das System fügt eine Partition hinzu, wenn die logische Tabelle zusätzliche relationale Datenbankressourcen benötigt.
Jede logische Tabelle ist nach der übergeordneten Tabelle der Hierarchie benannt, und jede unterstützende physische Partition besteht aus dem logischen Namen und einem Partitionsnamen. Beispiel: Die Tabelle „Basiskonfigurationselement“ [cmdb] beginnt als logische Tabelle ohne Partitionen. Angenommen, Ihre Hardwarekonfigurationselemente verbrauchen genügend Datenbankressourcen, sodass das System eine Partition namens cmdb$par1 zum Speichern dieser Elemente erstellt. Später könnten Computerkonfigurationselemente genügend Datenbankressourcen verbrauchen, um zu rechtfertigen, dass das System eine zweite Partition namens cmdb$par2 erstellt, in der diese Datensätze gespeichert werden.
In jeder logischen Tabelle weist das System jeder untergeordneten Tabelle der Hierarchie einen Klassennamenspaltenwert zu. Beispielsweise gibt es in der logischen Tabelle „Base Configuration Item“ Datensätze mit Klassennamen für „Anwendung“, „Computer“ und „IP-Router“. Das System weist außerdem jeder untergeordneten Tabelle in der Hierarchie einen zweistelligen Klassenpfadwert zu. Der Klassenpfad basiert auf der Position der Tabelle in der Hierarchie. Beispielsweise kann die übergeordnete Klasse „Hardware“ einen Klassenpfad wie „/!!/!D“ und die untergeordnete Klasse „Computer“ einen Klassenpfad wie „/!!/!D/!!“haben. .
Um Datensätze im Erweiterungsmodell „Tabelle pro Partition“ zu finden, fragt das System die logische Tabelle und ihre Partitionen ab und verwendet die Klassenpfadspalte, um die Ergebnisse einzuschränken. Da für diese Abfragen keine Ergebnisse aus mehreren Tabellen verknüpft werden müssen, bietet das System eine bessere Suchleistung. Darüber hinaus reduziert der Klassenpfad die Gesamtzahl der zu durchsuchenden Datensätze, was die Suchleistung weiter verbessert.
Das System verwendet das Erweiterungsmodell „Tabelle pro Partition“ für die Tabellenhierarchie des Basiskonfigurationselements [cmdb] in MySQL-Datenbanken. Um „Tabelle pro Partition“ in einer Oracle-Datenbank zu verwenden, wenden Sie sich an den technischen Support.