Namenskonventionen
in der Oracle Datenbank

Ein wichtiger Teil von Code Conventions sind die Namenskonventionen. In den Namenskonventionen wird vereinbart, wie „Dinge“ zu benennen sind. Im Falle einer Datenbank handelt es sich bei den zu benennenden „Dingen“ um Schema-Objekte wie Tabellen, Sequenzen, Indexe, Views, Trigger, aber auch um Constraints. In einer Datenbank gilt es, die Namen mit besonderer Sorgfalt zu wählen.

Denkt man an eine Datenbank mit mehreren Datenlieferanten und -abnehmern (darunter in der Regel Applikationen und Schnittstellen von und zu weiteren Datenbanken), so ist leicht vorstellbar, dass Objekte nicht einfach umbenannt werden können. Es sollten also von Anfang an die passenden Namen vergeben werden.

Verglichen mit der Benennung von Klassen in objektorientierten Programmiersprachen, hat der Datenbankentwickler zudem mit der beschränkten Hierarchie von Namensräumen zu kämpfen. Während Oracle nur das Schema für alle Objekttypen und für PL/SQL-Code zusätzlich die Packages kennt, kann in Java eine frei benennbare Hierarchie von Java-Packages aufgespannt werden, in der Klassen eingeordnet werden können.

Ebenso kann die Länge eines Bezeichners eingeschränkt sein. Glücklicherweise wird mit Oracle 12cR2 die Beschränkung von 30 Byte für einen Bezeichner auf 128 Byte angehoben.

Wahl von passenden Namen

Bei der Wahl von Namen sollte stets der fachliche Bezug berücksichtigt werden. In der Regel wird sich der fachliche Bezug in den Namen der Relationen (Tabellennamen) widerspiegeln.
Nicht zuletzt aufgrund der Längenbeschränkung für Bezeichner empfiehlt es sich, ein menschenlesbares Kürzel (also ein mnemonic) für jede Tabelle einzuführen.
Einer Tabelle zugeordnet sind z.B. Trigger, Indexe, Sequenzen oder Constraints. Deren Benennung sollte gewissen Regeln folgen. Die Zugehörigkeit eines solchen Objekts zu einer Tabelle sollte ersichtlich sein; ebenso wie der Objekt-Typ und damit letztlich die technische Ausführung.

Beispiel:
Alle Beschäftigen sind in der Tabelle employee enthalten (Fachlicher Bezug).
Die Tabelle employee erhält das Kürzel emp.
Es existiert eine Sequenz mit dem Namen emp_seq.
Es existiert ein Trigger mit dem Namen emp_seq_tg

Anhand unserer Namenskonventionen wissen wir nun Folgendes:

Die Sequenz emp_seq gehört, ebenso wie der Trigger emp_seq_tg, zur Tabelle employee, da diese das Kürzel emp trägt.
Da die Sequenz einen Namen gemäß unserer Konvention trägt:
- wird aus der Sequenz die technische Schlüsselspalte employee.id befüllt
- beginnt die Sequenz bei 1 und endet bei 10¹⁸-1, passt somit, ebenso wie employee.id, in einem 64bit Integer
- Die Sequenz wiederholt sich nicht.

Da ebenso der Trigger einen Namen gemäß unserer Konventionen trägt, wissen wir, dass:
- Dieser Trigger befüllt die technische Schlüsselspalte employee.id
- Der Trigger tut nichts anderes. (Das ist gut!)

Das ist schon eine Menge implizites Wissen, welches durch die Namenskonventionen transportiert wird. In unsere Namenskonventionen haben wir auch ein paar „Best Practices“ einfließen lassen, so z.B. der weitgehende Verzicht auf Trigger und die Datentypen für Sequenzen und id-Spalten.

Namenskonventionen müssen lebendig sein

Wir haben uns entschieden, unsere Namenskonventionen unter Open Source Lizenz öffentlich zu machen und wollen diese auch öffentlich diskutieren. Diese sind hier zu finden:
https://github.com/triologygmbh/database-conventions/blob/master/i18n/README.de.md
Die in diesem Artikel beschriebenen Konventionen befinden sich dort und enthalten noch weitere Konventionen im Detail.