Eine der ersten und wichtigsten Entscheidungen bei der Data-Vault<\/a>-Entwicklung betrifft die Definition von Namenskonventionen f\u00fcr Datenbankobjekte. Als wesentlicher Bestandteil der Standardisierung sind diese Konventionen zwingend erforderlich, um ein gut strukturiertes und konsistentes Data-Vault-Modell<\/a> aufrechtzuerhalten. Angemessene Namenskonventionen erh\u00f6hen die Benutzerfreundlichkeit des Data Warehouses erheblich, nicht nur f\u00fcr Entwickler, sondern auch f\u00fcr Power-User bei der Datenexploration. <\/span><\/p>\n In diesem Artikel stellen wir Ihnen die wichtigsten \u00dcberlegungen aus unserem Standardprozess zur Definition von Namenskonventionen vor.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“25″][vc_column_text css=““ text_direction=“default“] In this article:<\/p> Letztendlich h\u00e4ngt die Entscheidung f\u00fcr eine bestimmte Schreibweise vom verwendeten Datenbankmanagementsystem ab. Einige Systeme wie PostgreSQL unterst\u00fctzen case-sensitive Objektnamen, was bei Abweichungen die Verwendung von Anf\u00fchrungszeichen erforderlich macht.<\/span> Daher bevorzugen PostgreSQL-Nutzer standardm\u00e4\u00dfig oft die Kleinschreibung, da kleingeschriebene Objektnamen den zu schreibenden Code reduzieren und gleichzeitig die Benutzerfreundlichkeit bei Ad-hoc-Abfragen durch Power-User verbessern. Dennoch ist es zwingend erforderlich, eine einheitliche Gro\u00df- und Kleinschreibung sowohl f\u00fcr Entit\u00e4ts- als auch f\u00fcr Spaltennamen beizubehalten.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“40″][image_with_animation image_url=“29664″ image_size=“full“ animation_type=“entrance“ animation=“None“ animation_movement_type=“transform_y“ hover_animation=“none“ alignment=“center“ border_radius=“none“ box_shadow=“none“ image_loading=“lazy-load“ max_width=“100%“ max_width_mobile=“default“][vc_custom_heading text=“Figure 1: Naming Convention – Letter Case“ font_container=“tag:div|text_align:center“ google_fonts=“font_family:Droid%20Serif%3Aregular%2Citalic%2C700%2C700italic|font_style:400%20regular%3A400%3Anormal“][divider line_type=“No Line“ custom_height=“15″][vc_column_text css=““ text_direction=“default“]\n I<\/span>n logischen Modellen sollten Objektnamen so selbsterkl\u00e4rend wie m\u00f6glich sein. Das bedeutet, dass die meisten W\u00f6rter vollst\u00e4ndig ausgeschrieben werden sollten \u2013 mit Ausnahme etablierter Abk\u00fcrzungen wie \u201edept\u201c f\u00fcr \u201edepartment\u201c oder \u201eorg\u201c f\u00fcr \u201eorganization\u201c. In physischen Modellen hingegen werden typischerweise Abk\u00fcrzungen und Akronyme genutzt, um die Objektnamen kurz zu halten.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][vc_column_text css=““ text_direction=“default“]\n Sind Sie daran interessiert, wie wir bei Scalefree Namenskonventionen standardisieren? In einem der n\u00e4chsten Artikel werden wir konkrete Vorschl\u00e4ge f\u00fcr Namenskonventionen vorstellen, die sich sowohl bei unseren Kunden als auch in unserem eigenen Team in der Praxis bew\u00e4hrt haben.<\/span><\/p>\n Lassen Sie uns in den Kommentaren diskutieren: Wie setzen Sie Namenskonventionen in Ihrer Data-Vault-Entwicklung um? Welchen Standards folgen Sie?<\/span>[\/vc_column_text][\/vc_column][\/vc_row]\n","protected":false},"excerpt":{"rendered":" [vc_row type=“in_container“ full_screen_row_position=“middle“ column_margin=“default“ column_direction=“default“ column_direction_tablet=“default“ column_direction_phone=“default“ scene_position=“center“ text_color=“dark“ text_align=“left“ row_border_radius=“none“ row_border_radius_applies=“bg“ overflow=“visible“ overlay_strength=“0.3″ gradient_direction=“left_to_right“ shape_divider_position=“bottom“ bg_image_animation=“none“][vc_column column_padding=“no-extra-padding“ column_padding_tablet=“inherit“ column_padding_phone=“inherit“ column_padding_position=“all“ column_element_direction_desktop=“default“ column_element_spacing=“default“ desktop_text_alignment=“default“ tablet_text_alignment=“default“ phone_text_alignment=“default“ background_color_opacity=“1″ background_hover_color_opacity=“1″ column_backdrop_filter=“none“ column_shadow=“none“…<\/p>\n","protected":false},"author":91,"featured_media":59633,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3949],"tags":[],"class_list":["post-59630","post","type-post","status-publish","format-standard","has-post-thumbnail","category-data-warehouse"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tDokumentation von Namenskonventionen<\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Es ist eine Sache, die Namenskonventionen f\u00fcr die Entwicklung Ihres Data Warehouses einfach nur zu definieren. Eine ganz andere Herausforderung ist es jedoch, die n\u00f6tige Konsistenz zu etablieren, damit diese Konventionen auch tats\u00e4chlich zu gelebten Standards werden. Daher geh\u00f6rt es zu den Best Practices, eine klare Richtlinie f\u00fcr die Benennung von Data-Warehouse-Objekten zu dokumentieren. In den folgenden Abschnitten er\u00f6rtern wir verschiedene Aspekte, die Sie bei der Definition von Namenskonventionen f\u00fcr eine Data-Warehouse-L\u00f6sung ber\u00fccksichtigen sollten.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“35″][vc_column_text css=““ text_direction=“default“]\n
Namenskonventionen: Gro\u00df- und Kleinschreibung<\/span><\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Wenn es um die Gro\u00df- und Kleinschreibung von Namen geht, gibt es verschiedene Optionen: durchgehende Gro\u00dfschreibung, durchgehende Kleinschreibung, Camel Case und Pascal Case. Auch wenn die Unterschiede gering erscheinen m\u00f6gen, hat jede Option ihre eigenen Vor- und Nachteile hinsichtlich der Lesbarkeit und der Schnelligkeit beim Tippen.<\/span><\/p>\n
Namenskonventionen:<\/span> Verwendung von Unterstrichen \u201e<\/span>_\u201c<\/span> und Bindestrichen<\/span> \u201e-\u201c<\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Zur Verbesserung der Lesbarkeit sind Worttrenner wie Unterstriche \u201e_\u201c oder, je nach Anwendungsfall, Bindestriche \u201e-\u201c w\u00fcnschenswert. Es ist jedoch wichtig zu bedenken, dass Bindestriche in vielen Systemen als Minuszeichen interpretiert werden. Dennoch werden Bindestriche h\u00e4ufig in XML- oder JSON-Datenformaten verwendet. Sie lassen sich jedoch leicht durch Unterstriche ersetzen, falls diese als Standard-Trennzeichen definiert sind. <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][vc_column_text css=““ text_direction=“default“]\n
Namenskonventionen:<\/span> Abk\u00fcrzungen und Akronyme<\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Einige Systeme erzwingen Zeichenbegrenzungen f\u00fcr Objektnamen. So erlauben beispielsweise Oracle 12.1 und \u00e4ltere Versionen nur eine maximale L\u00e4nge von 30 Bytes f\u00fcr Objektnamen. Daher bieten sich Abk\u00fcrzungen und Akronyme bei der Objektbenennung an, auch wenn diese leicht zu Missverst\u00e4ndnissen f\u00fchren k\u00f6nnen. Um dem entgegenzuwirken, empfiehlt es sich, ein Dokument mit einer Liste aller verwendeten Abk\u00fcrzungen und deren genauer Bedeutung zu erstellen. Um jedoch potenzielle Verwirrung zu vermeiden, sollten Sie den Einsatz von Abk\u00fcrzungen und Akronymen auf ein Minimum beschr\u00e4nken.<\/p>\n
Namenskonventionen: Singular- vs. Plural-Objektnamen<\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Es ist g\u00e4ngige Praxis, Substantive oder Nominalphrasen in ihrer Singularform als Objektnamen zu verwenden. So l\u00e4sst sich vermeiden, dass man sich mit unregelm\u00e4\u00dfigen englischen Pluralformen (z. B. man\/men, person\/people) auseinandersetzen muss, was das Datenmodell unn\u00f6tig verkomplizieren w\u00fcrde. <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][vc_column_text css=““ text_direction=“default“]\n
Namenskonventionen: Pr\u00e4fix vs. Suffix <\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Ob Objekte mit Pr\u00e4fixen oder Suffixen benannt werden, ist f\u00fcr die Entwicklung von untergeordneter Bedeutung. Dennoch bevorzugen wir intern bei Scalefree<\/a> Tabellennamen mit Suffixen wie \u201ecustomer<\/span>_h<\/b>\u201c und \u201etransaction<\/span>_l<\/b>\u201c anstelle von Pr\u00e4fixen. Der Vorteil dieser Methode: Da die meisten Datenbank-Tools Tabellen alphabetisch sortieren, werden alle Tabellen, die sich auf dasselbe Gesch\u00e4ftsobjekt beziehen, automatisch gruppiert. Beispielsweise werden alle Hubs, Satelliten und Links f\u00fcr Kontakte, deren Namen mit \u201econtact_\u2026\u201c beginnen, im Datenbank-Browser direkt untereinander angezeigt. Dies erleichtert die Datenexploration f\u00fcr Power-User und Entwickler erheblich.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][image_with_animation image_url=“29663″ image_size=“full“ animation_type=“entrance“ animation=“None“ animation_movement_type=“transform_y“ hover_animation=“none“ alignment=“center“ border_radius=“none“ box_shadow=“none“ image_loading=“lazy-load“ max_width=“100%“ max_width_mobile=“default“][vc_custom_heading text=“Figure 2: Naming Convention – Prefix“ font_container=“tag:div|text_align:center“ google_fonts=“font_family:Droid%20Serif%3Aregular%2Citalic%2C700%2C700italic|font_style:400%20regular%3A400%3Anormal“][divider line_type=“No Line“ custom_height=“20″][vc_column_text]Dennoch k\u00f6nnen Pr\u00e4fixe in bestimmten F\u00e4llen sinnvoll sein. Beispielsweise hilft die Verwendung von Pr\u00e4fixen bei den Schema-Namen der verschiedenen Layer dabei, diese im Datenbank-Browser \u00fcbersichtlich zu gruppieren.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][image_with_animation image_url=“29662″ image_size=“full“ animation_type=“entrance“ animation=“None“ animation_movement_type=“transform_y“ hover_animation=“none“ alignment=“center“ border_radius=“none“ box_shadow=“none“ image_loading=“lazy-load“ max_width=“100%“ max_width_mobile=“default“][vc_custom_heading text=“Figure 3: Naming Convention – Schemas“ font_container=“tag:div|text_align:center“ google_fonts=“font_family:Droid%20Serif%3Aregular%2Citalic%2C700%2C700italic|font_style:400%20regular%3A400%3Anormal“][divider line_type=“No Line“ custom_height=“20″][vc_column_text]\n
Fazit<\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Namenskonventionen sind zu einem gewissen Grad eine Frage der pers\u00f6nlichen Vorliebe und der internen Richtlinien. Unabh\u00e4ngig davon gilt: Je systematischer und konsistenter die Namenskonventionen definiert sind, desto gr\u00f6\u00dfer ist der Nutzen bei der Entwicklung und Implementierung Ihrer Data-Vault<\/a>-L\u00f6sung. Um dies sicherzustellen, empfehlen wir Data-Vault-Entwicklungsteams, eine einfache SQL-Funktion zu implementieren, die die gesamte Datenbank automatisch auf Abweichungen von den Namenskonventionen \u00fcberpr\u00fcft. So wird die Einhaltung der Standards kontinuierlich gew\u00e4hrleistet.<\/span><\/p>\n