Speicheraliase

Erfahren Sie mehr über die Rolle, die Speicheraliase bei der Datenbearbeitung und Felderstellung in Now Platformspielen.

Das Verständnis von Speicheraliassen ist für eine effektive Datenverwaltung und Schemaanpassung in Now Platformwichtig, insbesondere beim Umgang mit komplexen Tabellenhierarchien wie denen in der Aufgabentabelle [task].

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

Tabellenhierarchie und -modelle

Um das Aliasing des Speichers zu verstehen, sind Kenntnisse der Tabellenhierarchien innerhalb der Aufgabentabelle [task] erforderlich, 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 über eine abgeflachte Hierarchie verfügt, bei der alle Spalten innerhalb der Aufgabenhierarchie nur in der Aufgabentabelle vorhanden sind. Beispielsweise befinden sich Felder im Zusammenhang mit Change-Anforderungen nicht in einer separaten Tabelle für Change-Anforderungen [change_request], sondern sind in die Tabelle „Aufgabe“ [task] 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 direktes untergeordnetes Element der Aufgabentabelle [task] ist, verwendet die 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 Change-Anforderungstabelle [change_request], welche die Aufgabentabelle [task] erweitert. Da die Tabelle „Change-Anforderung“ [change_request] „Tabelle pro Hierarchie“ ist, ist das IMAC-Tabellenmodell [change_request_imac] auch „Tabelle pro Hierarchie“. Veraltete Tabellen wie die Tabelle „Incident“ [incident], die Tabelle „Change-Anforderung“ [change_request] und die Tabelle „Problem“ [problem] sind alle Teil der reduzierten Aufgabentabellenhierarchie [task].

Tabelle pro Klasse

Dieses Modell gilt für Tabellen, die physisch in der Datenbank vorhanden sind. Es wird für neue Tabellen verwendet, die direkt von der Aufgabentabelle [task] aus erweitert werden, wenn die Aufgabenzeilenanzahl 1 Million Zeilen überschreitet. Im Gegensatz zu „Tabelle pro Hierarchie“ verwendet „Tabelle pro Klasse“ kein Dekomprimieren, da es nicht innerhalb einer abgeflachten Hierarchie funktioniert.

Definition des Speicheralias

Für jedes Feld in einer Tabelle innerhalb einer Instanz wird ein Speicheralias erstellt. Machen Sie sich mit den wichtigsten Feldern in der Tabelle „Speicherspalten-Aliasse“ [sys_storage_alias] vertraut.

Elementname

Gibt an, wie das Feld Benutzern angezeigt wird. Dies ist wichtig für Interaktionen mit der Benutzeroberfläche und Skripting.

Speicher-Alias

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

Name der Speichertabelle

Gibt die physische Tabelle an, die das Element enthält. Für Tabellen vom Typ „Tabelle pro Hierarchie“ ist der Wert immer „Aufgabe“. Bei Tabellen vom Typ „Tabelle pro Klasse“ entspricht der Wert dem Namen der physischen Tabelle.

Tabelle

Gibt die logische Klasse an, mit der jedes Element in der physischen Aufgabentabelle [task] verknüpft ist. Das Element „Tabelle“ enthält den Wert „table_name“, der das Klassendiskrimininator ist.

Abbildung : 1. Aliasse der Speicherspalte

In diesem Beispiel lautet der Speicheralias für das Element cab_delegate a_ref_2, und die physische Speichertabelle, in der die Daten gespeichert werden, lautet task. Das Beispiel zeigt 10 logische Elemente in verschiedenen logischen Klassen in der Aufgabentabelle [table], die alle mit dem gleichen Alias „a_ref_2“ in der physischen Aufgabentabelle [task] verknüpft sind.

Die gleichgeordneten Elemente sind glommiert, was bedeutet, dass sie sich eine physische Spalte in der Aufgabentabelle [task] teilen. Sie können Daten aus dem logischen Element „cab_delegate“ mit einer Abfrage wie der folgenden abfragen:

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 physischen Aufgabentabelle [task] abzufragen.

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

Funktionalität und Nutzung

Speicher-Aliasse 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 in einer physischen Spalte zusammengefasst werden, die größer als die maximale Länge des logischen Elements ist.

Glimmen

Mit Aliassen können mehrere gleichgeordnete Elemente eine einzelne physische Spalte in einer Tabelle pro Hierarchiemodell gemeinsam nutzen.

Bezeichnungszuordnung

Aliasse verknüpfen sys_documentation-Datensätze (Bezeichnung) mit ihren jeweiligen Elementen und verbessern so die Transparenz in Formularen, Berichten und Listenansichten.

Einschränkungen und Regeln

• Zwei logische Elemente innerhalb derselben Klasse können eine physische Spalte nicht gemeinsam nutzen. Beispielsweise können zwei Zeichenfolgenfelder, die in der Incident-Tabelle [incident] erstellt wurden, nicht derselben physischen Spalte in der Datenbank zugeordnet werden.
• Ein übergeordnetes Element und sein untergeordnetes Element können eine physische Spalte nicht gemeinsam nutzen. Beispiel: Ein in der Incident-Tabelle [incident] erstelltes Feld kann keiner physischen Spalte zugeordnet werden, wenn diese physische Spalte bereits einem Feld in der Aufgabentabelle [task] 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 Incident-Tabelle [incident] und können beide derselben physischen Spalte zugeordnet sein.
• Felder, die direkt in der Aufgabentabelle [task] erstellt wurden (wobei „sys_class_name“ für „task“ festgelegt ist), können nicht glommiert werden.