--- sourceDocument: Yokohama Now Plattformverwaltung sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/yokohama/platform-administration Release : - yokohama ft:locale : - de-DE ft:publication_title : - Yokohama Now Plattformverwaltung ft:clusterId : - platadm bundleId : - platadm workflow : - Platform --- # Tabellenreduzierung # Tabellenreduzierung {#ariaid-title1} * Freigeben Version: Yokohama * * Aktualisiert 30. Januar 2025 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 Minuten Lesedauer Bei der Tabellenreduzierung wird eine Hierarchie zugehöriger Tabellen als eine Tabelle in einer relationalen Datenbank gespeichert. ## Erweiterungsmodelle {#c_TaskTableFlattening__section_lsz_nvx_cbb} Das System bietet diese Erweiterungsmodelle an, um eine Tabellenhierarchie in einer relationalen Datenbank zu speichern. {#c_TaskTableFlattening__table_chh_wbf_dbb__entry__2} | Erweiterungsmodell | Reduziert Tabellen? | |-|-| | Tabelle pro Klasse | Nein | | Tabelle pro Hierarchie | Ja | | Tabelle pro Partition | Ja | [Tabelle : 1. Verfügbare Erweiterungsmodelle] {#c_TaskTableFlattening__table_chh_wbf_dbb} ## Tabelle pro Klasse {#c_TaskTableFlattening__section_gcd_t2y_cbb} 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, 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\], 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 nach Hardware in einer zugehörigen Einrichtung 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 sie das Zusammenfügen aller untergeordneten Tabellen erfordert. 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 {#c_TaskTableFlattening__section_qqk_52y_cbb} Die Tabelle pro Hierarchie Das Erweiterungsmodell speichert eine gesamte Tabellenhierarchie in einer einzelnen 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 Aufgabentabellenhierarchie in MySQL-Datenbanken. Andere Tabellen verwenden das Erweiterungsmodell „Tabelle pro Klasse", da es keinen Leistungsvorteil beim Reduzieren gibt. Wenden Sie sich an den technischen Support, um die Tabelle pro Hierarchie in einer Oracle-Datenbank zu verwenden. ## Tabelle pro Partition {#c_TaskTableFlattening__section_d5h_v2y_cbb} Die Tabelle pro Partition Das Erweiterungsmodell speichert eine gesamte Tabellenhierarchie in einer einzelnen 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 erstellt, die aufgerufen wird cmdb$par1 Um sie zu speichern. Später könnten Computerkonfigurationselemente genügend Datenbankressourcen verbrauchen, um sicherzustellen, 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 z. B. 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 diese Abfragen keine Zusammenfügeergebnisse aus mehreren Tabellen erfordern, 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. * **[Zeigen Sie eine Tabellenhierarchie und das Erweiterungsmodell an](https://servicenow-prod.fluidtopics.net/NodYNE0f603gGYWw2LlnxQ)** Bestimmen Sie das von einer Tabelle verwendete Erweiterungsmodell.