Die einheitliche Bezeichnung von Objekten in einer Projektdatenbank ist sinnvoll, um gleichartige Objekte zu kennzeichnen. Damit vermeidet man Verwechslungen und Überschneidungen mit Objekten, die durch DeltaMaster ETL automatisch erzeugt werden. Zudem verbessert sich die Lesbarkeit und Orientierung in einem Projekt.
Die im nachfolgenden Blogbeitrag beschriebenen Namenskonventionen gelten als Leitfaden für alle DeltaMaster Projekte.

In Ergänzung zu dem bereits existierenden Blogbeitrag Stilregeln in SQL- und MDX-Statements sowie SSIS-Paketen, sollen in diesem Blogbeitrag die Namenskonventionen aufgelistet werden, welche für unsere SQL-Projekte grundlegend Bedeutung haben.

Namenskonventionen dienen einer einheitlichen Bezeichnung von Objekten, dem Reservieren von bestimmten Namensräumen für DeltaMaster-ETL-Objekte und der automatischen Erkennung von Objekten in DeltaMaster ETL.

Darüber hinaus enthält dieser Artikel Hinweise für eine korrekte, einheitliche Bezeichnungsweise von Objekten und Hinweise zur Codequalität.

Zulässige Namensräume

In der folgenden Aufzählung wird das jeweilige Präfix für ein Objekt beschrieben:

Tabellenpräfix

T_Import_

Namenskonvention: Präfix + identifizierender Name für die Art der importierten Daten oder Tabellenname des Vorsystems. Wenn bereits im Vorfeld feststeht, ob es sich bei der Art der Daten um reine Dimensions- bzw. Faktendaten handelt, kann dem Präfix ein DIM_ bzw. FACT_ folgen. Es kann dem Tabellennamen des Vorsystems auch der Name des Vorsystems vorangestellt werden. Dies erleichtert die Zuordnung der Quelle der importierten Daten, wenn mehrere Vorsysteme genutzt werden.

Alternativ können Importtabellen aus verschiedenen Vorsystemen auch in verschiedene Datenbankschemata abgelegt werden.

Beschreibung: Kopie der Daten des Vorsystems

Beispiele: T_Import_DIM_Produkt, T_Import_FACT_Kosten, T_Import_BAAN_TTISFC001310

Beispiele mit Datenbankschema: sap.T_Import_Hauptbuchdaten, baan.T_Import_TTISFC001310

T_D_

Namenskonvention: Präfix + identifizierender Name für die Art der Fakten

Beschreibung: Tabellen für manuell in der Anwendung erfasste Faktendaten

Eingabe über relationale Eingabeanwendung, einmaliger Import oder manuell erfasste Daten

Beispiel: T_D_Waehrungskurs

T_S_

Namenskonvention: Präfix + identifizierender Name für die Art der Dimensionsdaten

Beschreibung: Tabellen für manuell in der Anwendung erfasste Dimensionsdaten

Eingabe über relationale Eingabeanwendung, einmaliger Import oder manuell erfasste Daten

Beispiel: T_S_Niederlassung

T_APP_

Namenskonvention: Präfix + identifizierender Name für die Art der applikationsspezifischen Daten in der Tabelle

Beschreibung: Globale, applikationsspezifische Tabellen

Beispiel: T_APP_Parameter

TMV

Namenskonvention: Präfix + Name der materialisierten View ohne deren Präfix

Beschreibung: Materialisierte View

Wird meist aus Performancegründen erstellt.

Beispiel: TMV_Import_FACT_Kosten

Sichtenpräfix

V_Import_

Namenskonvention: Präfix + identifizierender Name für die Art der importierten Daten oder Tabellenname des Vorsystems.

Steht fest, dass die Sicht Dimensionsdaten enthält, ist das Präfix T_Import_DIM_ zu verwenden, für Faktendaten T_Import_FACT_.

Beschreibung: Zur Cube Erstellung optimierte Quelldaten für Dimensionen und Fakten

V_Import_DIM_: Diese Sichten werden als Standardquelle für ETL Dimensionen verwendet und enthalten die Daten, die zur Erstellung der Dimension oder einer Dimensionsebene erforderlich sind.

V_Import_FACT_: Diese Sichten werden als Standardquelle für ETL MeasureGroups verwendet und enthalten alle Kennzahlen für die entsprechende MeasureGroup sowie alle Identifikationsspalten für die Dimensionen, mit denen die MeasureGroup verknüpft werden soll. Innerhalb dieser Faktensicht können bereits umfangreiche Berechnungen auf relationaler Ebene erfolgen.

Auch bei diesen Sichten kann der Name des Vorsystems als Datenbankschema verwendet werden.

Beispiele: V_Import_DIM_Produkt, V_Import_FACT_Kosten, V_Import_Baan_T_124_Deckungsbeitrag

Beispiel mit Datenbankschema: baan.V_Import_T_124_Deckungsbeitrag

V_D_

Namenskonvention: Präfix + identifizierender Name für die Art der Fakten

Beschreibung: optimierte Sicht aus T_D_-Tabelle für eine DeltaMaster Pflegeanwendung oder für eine ETL MeasureGroup

Beispiel: V_D_Waehrungskurs

V_S_

Namenskonvention: Präfix + identifizierender Name für die Art der Dimensionsdaten

Beschreibung: optimierte Sicht aus T_S_-Tabellen für eine DeltaMaster Pflegeanwendung oder für eine ETL Dimension

Beispiel: V_S_Niederlassung

V_SEC_

Namenskonvention: Präfix + FACT + MeasureGroupNummer + MeasureGroupName

Beschreibung: für eingeschränkte Sichten vorbehalten, z.B. zur Berücksichtigung von Berechtigungen bei SQL-Durchgriffsberichten

Beispiel: V_SEC_FACT_01_Kosten

Prozedurenpräfix

P_APP_

Namenskonvention: Präfix + identifizierender Name für die Art der Prozedur

Beschreibung: Globale, applikationsspezifische Prozeduren

Zum Beispiel Prozeduren, die Daten aus Quelltabellen in Archivtabellen einfügen oder komplexe Berechnungen ausführen

Beispiel: P_APP_Insert_Kosten

P_APP_Select_

Namenskonvention: Präfix + identifizierender Name für die Art der selektierten Daten

Beschreibung: Prozeduren zur DropDown-Auswahl in relationalen Anwendungen

Beispiel: P_APP_Select_Region

P_APP_Import_

Namenskonvention: Präfix + identifizierender Name für die Art der importierten Daten

Beschreibung: Importprozeduren, die z.B. aus CustomApp gestartet werden oder Prozeduren für die Historisierung von Daten aus Quellsystemen

Diese Prozeduren können umfangreiche Datenprüfungen und Berechnungen enthalten.

Beispiel: P_APP_Import_Waehrungskurse

P_UDIM_

Namenskonvention: Präfix + DimensionsNummer + DimensionsebenenNummer  + DimensionsebenenName + Quelltabelle oder Quellsicht

Beschreibung: für individuell erstellte Prozeduren vorbehalten, die am Ende der Dimensionsbefüllung (innerhalb des Schritts „Fill relational Schema“) mit ausgeführt werden sollen

Beispiele: P_UDIM_01_01_Jahr_V_S_Periode, P_UDIM_03_01_Jahr_T_S_Region

P_UFACT_

Namenskonvention: Präfix + MeasureGroupNummer + MeasureGroupName + NummerQuelltabelle + NameQuelltabelle

Beschreibung: für individuell erstellte Prozeduren vorbehalten, die am Ende der Faktenbefüllung (innerhalb des Schritts „Fill relational Schema“) mit ausgeführt werden sollen

Beispiel: P_UFACT_01_Kosten_01_V_Import_FACT_Kosten_2017

P_Delete_

Namenskonvention: Präfix + Name der betroffenen Tabelle oder Sicht

Beschreibung: für Prozeduren vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden oder für Prozeduren für Löschvorgänge in relationalen Eingabeanwendungen. Letztgenannte Prozeduren können mit der Prozedur P_BC_Generate_DeltaMaster_TableProc erstellt werden.

Beispiele: P_Delete_V_Model_Applications, P_Delete_V_S_Niederlassung

P_Insert_

Namenskonvention: Präfix + Name der betroffenen Tabelle oder Sicht

Beschreibung: für Prozeduren vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden oder für Prozeduren für Einfügevorgänge in relationalen Eingabeanwendungen. Letztgenannte Prozeduren können mit der Prozedur P_BC_Generate_DeltaMaster_TableProc erstellt werden.

Beispiele: P_Insert_V_Model_Applications, P_Insert_V_S_Niederlassung

P_Update_

Namenskonvention: Präfix + Name der betroffenen Tabelle oder Sicht

Beschreibung: für Prozeduren vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden oder für Prozeduren für Aktualisierungsvorgänge in relationalen Eingabeanwendungen. Letztgenannte Prozeduren können mit der Prozedur P_BC_Generate_DeltaMaster_TableProc erstellt werden.

Beispiele: P_Update_V_Model_Applications, P_Update_V_S_Niederlassung

P_Update_PIV_

Namenskonvention: Präfix + Name der betroffenen Tabelle oder Sicht

Beschreibung: für Prozeduren vorbehalten, die aus Pivotberichten aus relationalen Eingabeanwendungen zurückschreiben

Beispiel: P_Update_PIV_V_D_Waehrungskurs

Funktionenpräfix

F_APP_

Namenskonvention: Präfix + identifizierender Name für die Art der Funktion

Beschreibung: Globale, applikationsspezifische Funktionen

Beispiel: F_APP_getKalenderwoche

Präfix für Keys

PK_

Namenskonvention: Präfix + Tabellenname

Beschreibung: Primärschlüssel auf spezifische Tabelle

Beispiel: PK_T_Import_DIM_Produkt

FK_

Namenskonvention: Präfix + Tabellenname + Spaltenname(n)

Beschreibung: Fremdschlüssel auf spezifische Tabelle

Beispiel: FK_T_Import_FACT_Kosten_ProduktID

Indizespräfix

IX_

Namenskonvention: Präfix + Tabellenname + Spaltenname(n)

Beschreibung: NonClustered Indizes auf spezifische Tabelle

Beispiel: IX_T_D_Waehrungskurse_MonatID_LandID

IXC_

Namenskonvention: Präfix + Tabellenname + Spaltenname(n)

Beschreibung: Clustered Indizes auf spezifische Tabelle

Beispiel: IXC_T_Import_FACT_Kosten_PeriodeID_ProduktID

CSI_

Namenskonvention: Präfix + Tabellenname

Beschreibung: NonClustered Columnstore Indizes auf spezifische Tabelle

Beispiel: CSI_T_Import_FACT_Deckungsbeitag

CSIX_

Namenskonvention: Präfix + Tabellenname

Beschreibung: Clustered Columnstore Indizes auf spezifische Tabelle

Beispiel: CSIX_TMV_WriteBackSQL_DIM_03_PeriodView

Triggerpräfix

TR_

Namenskonvention: Präfix + Tabellenname + Aktion

Beschreibung: Trigger auf spezifische Tabelle

Beispiel: TR_T_Import_FACT_Kosten_AFTER_INSERT

Synonyme und Sequenzen (Präfix)

S_

Namenskonvention: Präfix + Objektname ohne dessen Präfix

Beschreibung: Synonym auf spezifisches Objekt

S_ ersetzt das sonst eingesetzte Präfix, wenn das Originalobjekt bereits in der Ziel-Datenbank existiert. Sonst wird der Originalobjektname als Synoymname verwendet.

Synonyme dienen der Vereinfachung der datenbankübergreifenden Nutzung von Objekten.

Beispiele:

S_ModelInfo_SysObjects als Synonym für die in der separaten Writeback-Datenbank verwendeten sys.objects, da die sys.objects auch in der aufrufenden Datenbank vorhanden sind.

T_WritebackSQL_FACT_01_Kosten als Synonym für die in der separaten Writeback-Datenbank vorhandene Tabelle T_ WritebackSQL_FACT_01_Kosten

Der Zugriff auf dieses Objekt erfolgt über das Synonym und nicht über [DB].[Schema].[Objekt].

SEQ_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: Sequenz = Sequenz numerischer Werte in aufsteigender oder absteigender Reihenfolge in einem definierten Intervall

Beispiel: SEQ_Zaehler

Gesperrte Namensräume

Tabellenpräfix

T_DIM_

Namenskonvention: Präfix + DimensionsNummer + DimensionsEbenenNummer + DimensionsName

Beschreibung: für Dimensionstabellen vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden

Beispiele: T_DIM_01_01_Jahr, T_DIM_01_04_Tag

T_FACT_

Namenskonvention: Präfix + MeasureGroupNummer + MeasureGroupName; für Zellkommentartabellen zusätzlich + _TEXT

Beschreibung: für Faktentabellen vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden und für Zellkommentartabellen

Beispiele: T_FACT_01_Kosten, T_FACT_01_Kosten_TEXT

T_Model

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Tabellen vorbehalten, die von DeltaMaster ETL intern verwendet werden

Beispiel: T_Model_Fact

T_MODELSYS_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Tabellen vorbehalten, die von DeltaMaster ETL intern verwendet werden

Beispiel: T_MODELSYS_MetaDataLabel

T_SYSLOG_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Log-Tabellen vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden

Beispiel: T_SYSLOG_DataError

T_WriteBack_

Namenskonvention: Präfix + FACT + MeasureGroupNummer + MeasureGroupName

Beschreibung: für Rückschreibtabellen OLAP-Planung vorbehalten

Beispiel: T_WriteBack_FACT_01_Kosten

T_WriteBackSQL_

Namenskonvention: Präfix + FACT + MeasureGroupNummer + MeasureGroupName

Beschreibung: für Rückschreibtabellen Hybridplanung vorbehalten

Beispiel: T_WriteBackSQL_FACT_01_Kosten

TMV_WriteBackSQL_

Namenskonvention: Präfix + DIM + DimensionsNummer + DimensionsName + DimensionsebenenNummer + DimensionsebenenName

Beschreibung: für Rückschreibtabellen vorbehalten

Beispiele: TMV_WriteBackSQL_DIM_01_Periode, TMV_WriteBackSQL_DIM_01_Periode_01_Jahr

T_WriteTable_

Namenskonvention: Präfix + MeasureGroupName

Beschreibung: für Rückschreibtabellen OLAP-Planung vorbehalten

Beispiel: T_WriteTable_Kosten

_CSBACKUP_

Namenskonvention: Präfix + Name der Snowflake-Tabelle

Beschreibung: für Sicherungstabellen bei der Modellaufbereitung (Create Snowflake Schema) vorbehalten

Beispiel: _CSBACKUP_T_DIM_01_01_Jahr

_PCRBACKUP_

Namenskonvention: Präfix + Name der Archivtabelle

Beschreibung: für Sicherungstabellen des PackageCreators bei der Neuerstellung der Archivtabellen vorbehalten

Beispiel: _PCRBACKUP_T_Import_MARA_Archive

_BACKUP_

Namenskonvention: Präfix + Datum + Uhrzeit + kompletter Name WriteBack – oder WriteBackSQL-Tabelle

Beschreibung: für (OLAP- bzw. Hybrid-) Plandatentabellen, die bei der Modellaufbereitung gesichert werden, vorbehalten

Beispiele: _BACKUP_20190306_1025_T_WriteBack_FACT_01_Kosten, _BACKUP_20190308_1605_T_WriteBackSQL_FACT_01_Kosten

Sichtenpräfix

V_DIM_

Namenskonvention: Präfix + DimensionsNummer + DimensionsEbenenNummer + DimensionsName

Beschreibung: für Dimensionssichten vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden

Beispiele: V_DIM_01_01_Jahr, V_DIM_01_04_Tag

V_FACT_

Namenskonvention: Präfix + MeasureGroupNummer + MeasureGroupName

Beschreibung: für Faktensichten vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden

Gibt es zu der MeasureGroup Writeback-Tabellen, werden diese in V_FACT_UNION-Sichten berücksichtigt. Sie enthalten die Daten der Faktentabelle und die Daten aus der entsprechenden Writeback- und Writetable.

Beispiele: V_FACT_01_Kosten, V_FACT_UNION_03_SalesPlanning

V_Model

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Sichten vorbehalten, die von DeltaMaster ETL intern verwendet werden

Beispiel: V_Model_Fact

V_MODELSYS_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Sichten vorbehalten, die von DeltaMaster ETL intern verwendet werden

Beispiel: V_MODELSYS_MetaDataLabel UNI

V_SYSLOG_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Log-Sichten vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden

Beispiel: V_SYSLOG_DataError

V_WriteBack_

Namenskonvention: Präfix + FACT + MeasureGroupNummer + MeasureGroupName

Beschreibung: für Rückschreibtabellen OLAP-Planung vorbehalten

Beispiel: V_WriteBack_FACT_01_Kosten

V_WriteBackSQL_

Namenskonvention: Präfix + FACT + MeasureGroupNummer + MeasureGroupName

oder: Präfix + DIM + DimensionsNummer + DimensionsName + DimensionsebenenNummer + DimensionsebenenName

Beschreibung: für Rückschreibtabellen Hybridplanung vorbehalten

Beispiele: V_WriteBackSQL_FACT_03_SalesPlanning, V_WriteBackSQL_DIM_01_Periode_01_Jahr

Prozedurenpräfix

P_BC_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Prozeduren vorbehalten, die von DeltaMaster ETL zur Verfügung gestellt werden

Beispiel: P_BC_Generate_TMV

P_DIM_

Namenskonvention: Präfix + DimensionsNummer + DimensionsebenenNummer  + DimensionsebenenName + Quelltabelle oder Quellsicht

Beschreibung: für Prozeduren vorbehalten, die von DeltaMaster ETL erstellt werden

Beispiele: P_DIM_01_01_Jahr_V_S_Periode, P_DIM_02_01_Jahr_T_S_Wertart

P_FACT_

Namenskonvention: Präfix + MeasureGroupNummer + MeasureGroupName + NummerQuelltabelle + NameQuelltabelle

Beschreibung: für Prozeduren vorbehalten, die von DeltaMaster ETL erstellt werden

Beispiele: P_FACT_01_Kosten_01_V_Import_FACT_Kosten_2017, P_FACT_01_Kosten_02_V_Import_FACT_Kosten_2018

P_ELEMDEL_

Namenskonvention: Präfix + DimensionsNummer + DimensionsEbenenNummer + DimensionsName

Beschreibung: für Prozeduren vorbehalten, die von DeltaMaster ETL erstellt werden

Beispiel: P_Elemdel_04_03_Kunde

P_Model_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Prozeduren vorbehalten, die von DeltaMaster ETL intern verwendet werden

Beispiel: P_Model_GetTableColumns

P_SYSLOG_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Log-Prozeduren vorbehalten, die von DeltaMaster ETL erstellt und verwendet werden

Beispiel: P_SYSLOG_LOG

P_Transform_

Namenskonvention: P_Transform_

Beschreibung: reservierter Name für Prozeduren zum Füllen des relationalen Modells

Beispiele: P_Transform_All, P_Transform_ConsolidateWriteTables

P_WriteBackSQL_

Namenskonvention: Präfix + identifizierender Name oder + FACT + MeasureGroupNummer + MeasureGroupName und optional + PreProcess oder + Postprocess

Beschreibung: für Rückschreibprozeduren (Hybridplanung) vorbehalten

Beispiele: P_WriteBackSQL_Begin, P_WriteBackSQL_FACT_01_Kosten, P_WriteBackSQL_FACT_01_SalesPlanning_PreProcess

Funktionenpräfix

F_BC_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Funktionen vorbehalten, die von DeltaMaster ETL zur Verfügung gestellt werden

Beispiel: F_BC_DateCODE

F_Model_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Funktionen vorbehalten, die von DeltaMaster ETL verwendet werden

Beispiel: F_Model_GetNextID

F_MODELSYS_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Funktionen vorbehalten, die von DeltaMaster ETL verwendet werden

Beispiel: F_MODELSYS_GenerateRowID

F_SYSLOG_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Log-Funktionen vorbehalten, die von DeltaMaster ETL verwendet werden

Beispiel: F_SYSLOG_GetErrorMessage

Triggerpräfix

DTR_DMM_

Namenskonvention: Präfix + identifizierender Name

Beschreibung: für Trigger vorbehalten, die von DeltaMaster ETL verwendet werden

Beispiel: DTR_DMM_SYSLOG_DDLEvent

Allgemeine Anmerkungen

Objektnamen

Der Name eines Datenbankobjekts sollte immer sprechend sein. Für die Bezeichnung nach dem Präfix wird der Singular gewählt.

Beispiel:

• T_S_Kunde nicht T_S_Kunden
• T_S_Customer nicht T_S_Customers

Bei der Wahl der Bezeichnungen sollten verschiedene Sprachen nicht vermischt werden. Im Zweifel ist Englisch zu bevorzugen.

Objektnamen werden in PascalCase geschrieben. PascalCase oder auch UpperCamelCase bedeutet: zusammengesetzte Bezeichnungen werden nicht durch „_“ getrennt, sondern die Worttrennung wird durch Großbuchstaben gekennzeichnet. Das Präfix ist davon ausgenommen.

Beispiel: T_Import_DIM_ProduktGruppe nicht T_Import_DIM_Produkt_Gruppe

Bei der Aufzählung der Tabellenspalten sollte das trennende Komma immer ans Ende oder immer an den Anfang gesetzt werden – niemals mischen.

Für Prozeduren empfiehlt es sich nach dem Präfix ein Verb zu verwenden, um einen Hinweis auf die Funktion der Prozedur zu geben.

Beispiel:      P_APP_TransferProposalValues

Codequalität

Bei Verwendung von UNION in einem SQL-Statement sollte aus Performancegründen immer UNION ALL verwendet werden, es sei denn, es ist an der Stelle tatsächlich gewollt, dass doppelte Datensätze aus den verknüpften Abfragen eliminiert werden.

SELECT * sollte grundsätzlich nicht in Abfragen verwendet werden, sondern stattdessen eine Aufzählung der Tabellenspalten. Dadurch wird der Code stabiler gegenüber Änderungen in den zugrundeliegenden Tabellen.

Wie bereits bei den Namenskonventionen für die Synonyme erwähnt, sollten in einem SQL-Statement Verweise auf Objekte in anderen Datenbanken grundsätzlich über Synonyme abgebildet werden. Andernfalls wird es im Falle einer Änderung der verknüpften Datenbanken sehr aufwendig, die hart codierten Verweise zu korrigieren. Die Synonyme lassen sich (insbesondere ab ETL Version 6.2.5) schnell und komfortabel aktualisieren.

Die genannten Punkte werden in DeltaMaster ETL im Bericht „SQL-Code quality check“ bereits für jedes Modell geprüft.

Bei allen verwendeten Objekten sollte man das Schema voranstellen. Auch dies dient der optimalen Abfrageperformance.

SELECT 
Periode  
FROM  
dbo.T_S_Periode 
anstelle von  
SELECT 
Periode  
FROM  
T_S_Periode

Spaltenbezeichnungen zur automatischen Erkennung in DeltaMaster ETL

Bei Dimensionen werden Key-Spalten in den entsprechenden Quelltabellen automatisch erkannt, wenn sie auf „ID“, „_ID“, „Key“ oder „_Key“ enden, die Bezeichnungsspalten, wenn sie auf „BEZ“ „_BEZ“, „Name“, „_Name“, „Text“, „_Text“, „Desc“ oder „_Desc“ enden.

Kennzahlen in Faktentabellen werden automatisch erkannt, wenn sie folgenden Datentyp aufweisen: decimal, numeric, float, money oder smallmoney.

Fazit

Hält man sich bei der Erstellung von SQL-Code an eine einheitliche Namenskonvention und einen einheitlichen Stil, kann man sich selbst und auch anderen das Lesen und Verstehen der erstellten Datenbankobjekte deutlich vereinfachen. Und sei es, dass durch die Verwendung der genannten Präfixe die Datenbankobjekte gut sortiert im Objekt-Explorer des SQL-Managementstudios aufgelistet werden. Das Wissen um die reservierten Präfixe für DeltaMaster ETL verhindert das Verwenden dieser für eigene Datenbankobjekte und sichert damit das Funktionieren eines Modellaufbaus. Überschneidungen und Missverständnisse bei Bezeichnungen werden vermieden.

In diesem Sinne hoffen wir, dass dieser Artikel zur Übersichtlichkeit unserer Projekte beiträgt.