Tabellenreduzierung
Bei der Tabellenreduzierung wird eine Hierarchie zugehöriger Tabellen als eine Tabelle in einer relationalen Datenbank gespeichert.
Erweiterungsmodelle
Das System bietet diese Erweiterungsmodelle an, um eine Tabellenhierarchie in einer relationalen Datenbank zu speichern.
| Erweiterungsmodell | Reduziert Tabellen? |
|---|---|
| Tabelle pro Klasse | Nein |
| Tabelle pro Hierarchie | Ja |
| Tabelle pro Partition | Ja |
Tabelle pro Klasse
Die Tabelle pro Klasse Das Erweiterungsmodell speichert jede Tabelle der Hierarchie in einer eigenen physischen Tabelle in der relationalen Datenbank. Jede physische Tabelle verwendet das Tabellenpräfix der Quelltabelle, die jeweils eine andere Klasse von Datensätzen speichert. 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], Einrichtung [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 in einer zugehörigen Einrichtung nach Hardware suchen, muss das System Ergebnisse aus den Tabellen „Hardware“, „Einrichtung“ und „Asset“ zusammenführen.
Tabellenverknüpfungen verursachen einen Leistungsengpass in relationalen Datenbanken. Je mehr Klassen eine Abfrage enthält, desto schlechter ist die Abfrageleistung. Daher weist jede Abfrage nach Datensätzen vom oberen Rand der Tabellenhierarchie die schlechteste Leistung auf, da alle untergeordneten Tabellen verknüpft werden müssen.
Das System verwendet beim Erstellen von Tabellen standardmäßig das Erweiterungsmodell „Tabelle pro Klasse“. Die meisten Systemtabellen verwenden auch das Erweiterungsmodell „Tabelle pro Klasse“, da es keinen Leistungsvorteil durch eine Reduzierung gibt.
Tabelle pro Hierarchie
Die Tabelle pro Hierarchie Das Erweiterungsmodell speichert eine gesamte Tabellenhierarchie in einer einzigen flachen physischen Tabelle in der relationalen Datenbank. Die physische Tabelle wird 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 Spaltenwert für den Klassennamen zu. Das System verwendet den Namen der Quelltabelle als Klassennamenwert. Beispielsweise können Aufgabendatensätze Klassennamen wie Change, Incident oder Problem haben.
Um Datensätze in einer Tabellenhierarchie zu finden, fragt das System die physische Tabelle ab und verwendet die Spalte „Klassenname“, um die Ergebnisse einzuschränken. Da solche Abfragen keine Zusammenfügeergebnisse aus mehreren Tabellen erfordern, bietet das System eine bessere Suchleistung.
Das System verwendet das Erweiterungsmodell „Tabelle pro Hierarchie“ für die Hierarchie der Aufgabentabelle in MySQL-Datenbanken. Andere Tabellen verwenden das Erweiterungsmodell „Tabelle pro Klasse“, da es keinen Leistungsvorteil beim Reduzieren gibt. Um Tabelle pro Hierarchie in einer Oracle-Datenbank zu verwenden, wenden Sie sich an den technischen Support.
Tabelle pro Partition
Die Tabelle pro Partition Das Erweiterungsmodell speichert eine gesamte Tabellenhierarchie in einer einzigen flachen logischen Tabelle in der relationalen Datenbank. Jede logische Tabelle kann mehrere physische Speichertabellen haben, die aufgerufen werden Partitionen Unterstützt es. Jede Partition optimiert die Datenbankressourcen, die für eine physische Tabelle verfügbar sind, 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. Beispielsweise startet die Tabelle „Basiskonfigurationselement“ [cmdb] als logische Tabelle ohne Partitionen. Angenommen, Ihre Hardware-Konfigurationselemente verbrauchen genügend Datenbankressourcen, damit das System eine Partition namens erstellt cmdb$par1 Um sie zu speichern. Später könnten Computerkonfigurationselemente genügend Datenbankressourcen verbrauchen, um zu gewährleisten, dass das System eine zweite Partition namens erstellt cmdb$par2 Zum Speichern dieser Datensätze.
Innerhalb jeder logischen Tabelle weist das System jeder untergeordneten Tabelle der Hierarchie einen Spaltenwert für den Klassennamen zu. Beispielsweise gibt es in der logischen Tabelle „Basiskonfigurationselement“ Datensätze mit Klassennamen für „Anwendung“, „Computer“ und „IP-Router“. Das System weist jeder untergeordneten Tabelle der Hierarchie auch einen zweistelligen Klassenpfadwert zu. Der Klassenpfad basiert auf dem Tabellenspeicherort in der Hierarchie. Beispielsweise kann die übergeordnete Klasse „Hardware“ einen Klassenpfad wie haben /!!/!D Und der Computer der untergeordneten Klasse hat möglicherweise einen Klassenpfad wie /!!/!D/!! .
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 Zusammenfügeergebnisse aus mehreren Tabellen erforderlich sind, 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.