Speicheraliase

Erfahren Sie mehr über die Rollenspeicher-Aliasse, die bei der Datenmanipulation und Felderstellung im gespielt werden ServiceNow AI Platform.

Das Verständnis von Speicheraliasen ist wichtig für eine effektive Datenverwaltung und Schemaanpassung in ServiceNow AI Platform, Insbesondere beim Umgang mit komplexen Tabellenhierarchien wie denen in der Tabelle „Aufgabe“ [Aufgabe].

Standardmäßig haben Administratoren Zugriff auf die Tabelle „Speicherspaltenaliasse“ [sys_Storage_alias] in einer Instanz. Transaktionsprozesse für diese Tabelle können jedoch nicht von einem Administrator über die Anwenderoberfläche ausgeführt werden.

Tabellenhierarchie und -Modelle

Das Verständnis von Speicheraliasing erfordert Kenntnisse über Tabellenhierarchien in der Tabelle „Aufgabe“ [Task], die zwei Modelle umfasst: Tabelle pro Hierarchie und Tabelle pro Klasse.

Tabelle pro Hierarchie

Dieses Modell verwendet eine einzelne physische Tabelle, die Aufgabentabelle [Task], die eine reduzierte Hierarchie aufweist, in der alle Spalten innerhalb der Aufgabenhierarchie nur in der Aufgabentabelle vorhanden sind. Zum Beispiel befinden sich Felder im Zusammenhang mit Change-Anforderungen nicht in einer separaten Tabelle „Change-Anforderung“ [Change_Request], sondern sind in die Tabelle „Aufgabe“ [Aufgabe] integriert. Sie können überprüfen, ob eine Tabelle eine Tabelle pro Hierarchie ist, indem Sie das Feld Erweiterungsmodell in der Tabelle Tabellen [sys_DB_object] überprüfen. Wenn das übergeordnete Element der Tabelle ein direkt untergeordnetes Element der Aufgabentabelle [Task] ist, verwendet die Tabelle Tabelle Tabelle pro Hierarchie.

Eine erweiterte Tabelle erbt die Hierarchie ihres übergeordneten Elements. Beispielsweise ist die IMAC-Tabelle [Change_Request_imac] eine untergeordnete Tabelle der Tabelle „Change-Anforderung“ [Change_Request], die die Tabelle „Aufgabe“ [Aufgabe] erweitert. Da die Tabelle „Change-Anforderung“ [Change_Request] „Tabelle pro Hierarchie“ ist, ist das Tabellenmodell „IMAC“ [Change_Request_imac] auch „Tabelle pro Hierarchie“. Legacy-Tabellen wie die Tabelle „Incident“ [Incident], die Tabelle „Change-Anforderung“ [Change_Request] und die Tabelle „Problem“ [Problem] sind alle Teil der reduzierten Tabellenhierarchie „Aufgabe“ [Aufgabe].

Tabelle pro Klasse

Dieses Modell gilt für Tabellen, die physisch in der Datenbank vorhanden sind. Wird für neue Tabellen verwendet, die sich direkt aus der Tabelle „Aufgabe“ [Aufgabe] erstrecken, wenn die Anzahl der Aufgabenzeilen 1 Million Zeilen überschreitet. Im Gegensatz zu „Tabelle pro Hierarchie“ verwendet „Tabelle pro Klasse“ kein Glomming, da sie nicht innerhalb einer reduzierten Hierarchie funktioniert.

Speicheralias-Definition

Für jedes Feld in einer Tabelle in einer Instanz wird ein Speicheralias erstellt. Machen Sie sich mit den Schlüsselfeldern in der Tabelle „Speicherspaltenaliasse“ [sys_Storage_alias] vertraut.

Elementname

Gibt an, wie das Feld Anwendern angezeigt wird, was für Interaktionen und Skripting der Anwenderoberfläche wichtig ist.

Speicheralias

Gibt die genaue physische Spalte an, in der die Daten für ein Feld gespeichert werden. Der Speicheralias-Wert wird in Kombination mit dem Wert table_Name verwendet, um zu identifizieren, welche Daten bearbeitet werden sollen. Der Speicheralias-Wert ist die tatsächliche physische Spalte in der Tabelle „Aufgabe“ [Aufgabe].

Name der Speichertabelle

Gibt die physische Tabelle an, die das Element enthält. Für Tabellen pro Hierarchie ist der Wert immer Aufgabe. Für Tabellen pro Klasse ist der Wert der Name der physischen Tabelle.

Tabelle

Gibt die logische Klasse an, mit der jedes Element in der Tabelle „physische Aufgabe“ [Aufgabe] verknüpft ist. Das Tabellenelement enthält den Wert table_Name, der der Klassendiskriminator ist.

Abbildung : 1. Speicherspaltenaliasse

In diesem Beispiel ist der Speicheralias für das CAB_Delegate-Element A_ref_2, und die physische Speichertabelle, in der die Daten gespeichert werden, ist Aufgabe. Das Beispiel zeigt 10 logische Elemente in verschiedenen logischen Klassen in der Aufgabe [Tabelle], die alle mit demselben Alias A_ref_2 in der Tabelle „physische Aufgabe“ [Aufgabe] verknüpft sind.

Die gleichgeordneten Elemente sind glommed, d. h. sie teilen sich eine physische Spalte in der Tabelle „Aufgabe“ [Aufgabe]. Sie können Daten aus dem logischen Element CAB_Delegate mithilfe einer Abfrage wie:

SELECT a_ref_2 from task WHERE sys_class_name='change_request' AND a_ref_2 IS NOT NULL

Die Abfrage gibt Daten in der physischen Spalte A_ref_2 an. Der Klassendiskriminator Change_Request wird in Kombination mit dem Speicheralias A_ref_2 verwendet, um das logische Element CAB_Delegate aus der logischen Klasse Change_Request in der Tabelle „physische Aufgabe“ [Task] abzufragen.

Die Benennungskonvention für Felder, die in den tatsächlichen physischen Tabellen erstellt wurden, kann je nach Feldtyp variieren. In diesem Beispiel ist A_ref_2 ein Alias in der Tabelle „Aufgabe“ [Aufgabe], der Werte für Referenzfelder enthält.

Funktionalität und Nutzung

Speicheraliasse dienen mehreren Zwecken.

Zuordnung

Aliasse ordnen logische Elemente (Tabelle pro Hierarchie) oder physische Elemente (Tabelle pro Klasse) den tatsächlichen physischen Spalten in der Back-End-Datenbank zu. Das logische Element kann zu einer physischen Spalte glommiert werden, die größer ist als die max_length des logischen Elements.

Glomming

Aliasse ermöglichen es mehreren gleichgeordneten Elementen, eine einzelne physische Spalte in einer Tabelle pro Hierarchiemodell gemeinsam zu nutzen.

Bezeichnungszuordnung

Aliasse ordnen sys_documentation-Datensätze (label) ihren jeweiligen Elementen zu, wodurch die Sichtbarkeit in Formularen, Berichten und Listenansichten verbessert wird.

Einschränkungen und Regeln

• Zwei logische Elemente innerhalb derselben Klasse können keine physische Spalte teilen. Beispielsweise können zwei Zeichenfolgenfelder, die in der Tabelle „Incident“ [Incident] erstellt wurden, nicht derselben physischen Spalte in der Datenbank zugeordnet werden.
• Ein übergeordnetes Element und sein untergeordnetes Element können keine physische Spalte teilen. Beispielsweise kann ein Feld, das in der Tabelle „Incident“ [Incident] erstellt wurde, keiner physischen Spalte zugeordnet werden, wenn diese physische Spalte bereits einem Feld in der Tabelle „Aufgabe“ [Aufgabe] zugeordnet ist.
• Nur gleichgeordnete Elemente können eine physische Spalte gemeinsam nutzen. Zum Beispiel ein Referenzfeld in der Tabelle „Change-Anforderung“ [Change_Request] und ein Referenzfeld in der Tabelle „Incident“ [Incident], die beide derselben physischen Spalte zugeordnet werden können.
• Felder, die direkt in der Aufgabentabelle [Task] erstellt wurden (wobei sys_class_Name „Task“ ist), können nicht glommt werden.