Inrichten van een Oracle database, deel 1: naamgevingsstandaard

Het installeren, inrichten en configureren van een Oracle Database is een lastige klus. In veel projecten wordt hierover telkens weer opnieuw nagedacht met een grote kans dat hierbij fouten gemaakt worden die later lastig te herstellen zijn. In een serie van drie artikelen laten we zien hoe deze inrichting op een gestructureerde manier vorm kan worden gegeven. In het eerste deel behandelen we de naamgevingstandaard.

Nieuwe naamgevingsstandaard

Er zijn al diverse naamgevingsstandaarden te vinden op internet. Google even op de termen “Oracle naming standard” en je vindt er diverse.

We hebben hier toch gekozen om er nog een aan toe te voegen en wel om de volgende redenen:

1. Er is een standaard nodig als uitgangspunt voor de in deel 2 beschreven inrichting;
2. De meeste standaarden gebruiken geen korte code voor tabel of systeem. Deze is nodig voor een gestructureerde naamgeving van gerelateerde componenten (tablespaces bij een database, relaties bij een tabel);
3. De meeste standaarden zijn minder uitgebreid als deze. Ze beschrijven bijvoorbeeld niet de componenten als systeem of domein.

Deze standaard beschrijft geen naamgeving binnen PL/SQL code.

Uitgangspunt is dat het gegevensmodel zelf in een data dictionary wordt vastgelegd en dat vandaar uit de scripts voor de tabellen, indexen en de primaryen foreign key constraints worden gegenereerd. De scripts voor de andere componenten (tablespaces, users, rollen, views, procedures, etc.) zullen grotendeels handmatig worden geschreven. Deze scripts beginnen allemaal met een standaard stuk commentaar.
Het model in figuur 1 wordt gebruikt bij alle voorbeelden in deze artikelenreeks. Het is opgesteld met Power Designer maar dit had ook Oracle Designer, JDeveloper, Enterprice Architect of een ander CASE tool kunnen zijn.

Toelichting op het model

Het gegevensmodel in figuur 1 is bedoeld als voorbeeld voor deze artikelenreeks. Het pretendeert zeker niet de volledige functionaliteit voor een dergelijk systeem te bevatten. Het bevat wel:

• Een tabel met artikelen;
• Een tabel met BTW codes en percentages; van de BTW
  wordt het percentage historisch bijgehouden;
• Een tabel met klanten;
• Een klant kan een particuliere of een zakelijke klant zijn;
  hiervoor worden in twee extra tabellen de specifieke gegevens van deze twee types vastgelegd;
• Een tabel met contactpersonen die bij een zakelijke klant horen;
• Bij een klant kunnen enkele telefoonnummers worden vastgelegd voor bijvoorbeeld een vaste telefoon, een GSM en een FAX;
• Een tabel met orders en orderregels; deze hebben relaties met klanten resp. artikelen;
• Een tabel met systeemconstanten, bijvoorbeeld de systeemnaam en bedrijfsnaam.

Het voordeel van het opnemen van de bedrijfsnaam in de tabel met systeemconstanten is dat deze in de kop van rapporten getoond kan worden en dat bij wijziging van de bedrijfsnaam deze alleen in de tabel behoeft te worden aangepast en niet
alle rapporten gewijzigd moeten worden. Ook kan het systeem zo voor meer bedrijven gebruikt worden.
Er mag altijd maar één record in deze tabel staan. Daarom is er een primary key (dus een unieke waarde) gedefinieerd die alleen de waarde 1 mag hebben. Het inserten van een tweede record is dan niet meer mogelijk.

Van alle scripts voor het maken van het databaseschema kan een zipfile met de voorbeelden worden gedownload via de website van Optimize (http://optimize.nl/Het-Blad/Optimize/ Extra).

Voordat we een gestandaardiseerde werkwijze kunnen beschrijven voor de inrichting van een database of databaseschema, moeten we eerst een aantal afspraken maken over naamgeving. Zonder een duidelijke standaardnaamgeving is er namelijk geen standaardinrichting mogelijk.
Het is een mogelijke standaard. Afwijken van deze standaard is zeker mogelijk, als deze afspraken maar worden vastgelegd en nageleefd. Case tools hebben vaak eigen standaarden voor namen van bijvoorbeeld primaryen foreign keys. Het kan werk besparen door deze standaard gewoon over te nemen. Andere afspraken hebben mogelijk ook consequenties voor de inrichting van de schema’s of database.

NB: Het geheel is gebaseerd op een Oracle-omgeving, maar kan gemakkelijk worden omgezet naar andere database producten.
NB: We gebruiken hier de termen tabel en kolom. Die komen overeen met de termen entiteit en attribuut in het logisch model.

Logische elementen

Voor tabellen, domeinen of datatypes en kolommen wordt vaak een naam gebruikt die uit meerdere woorden is samengesteld. Deze woorden worden gescheiden door een onderstreep teken als in enkele voorbeelden hiervoor. De naam van deze objecten zal vaak gelijk zijn aan de naam van dit object in het logisch model behalve:

• In het logisch model zijn spaties en enkele andere tekens toegestaan die in het fysiek model verboden zijn. Deze worden in het fysiek model vervangen door onderstreep tekens;
• In het logisch model mag de entiteitnaam langer zijn dan 30 posities; in dat geval moet de fysieke tabelnaam hiervan worden afgeleid door deze korter te maken.

We gebruiken voor het systeem of voor een entiteit/tabel, naast de naam, ook altijd een code of mnemonic van drie posities. Afhankelijk van de eisen van de omgeving (veel of weinig systemen) kan er ook voor gekozen worden om altijd een code van vier posities of altijd een code van twee posities te gebruiken. Deze code moet zeker uniek zijn binnen een schema, maar liever ook over de schema’s heen binnen een database.

Fysieke elementen

Speciale tabellen, bijvoorbeeld werktabellen of tijdelijke tabellen met tussentijdse resultaten hebben een naam die begint met een voorvoegsel (bijv. WK_) en vervolgens een logische naam of de naam van de functie waarvoor deze tabel nodig is (WK_KAS2301).
Gebruik van hoofdletters of kleine letters is erg afhankelijk van de gewoonten binnen een organisatie. Ik geef de voorkeur om alle items en codering in kleine letters, maar mnemonics, codes en andere afkortingen in hoofdletters te zetten. Gebruik geen speciale tekens in tabel- of kolomnamen zoals spatie, of “-,.!@#%&*()+=| /? “.
Gebruik nooit versie-informatie in de database of schema namen, tenzij er gelijktijdig verschillende versies van het systeem onderhouden moeten/kunnen worden.
Voorkom het gebruikt van namen die gereserveerde woorden zijn (of zou kunnen worden). Bijvoorbeeld: in ons voorbeeld data model hebben we de tabel ORDERS ipv (enkelvoud) ORDER. Dit omdat het woord ORDER ook wordt gebruikt in het SQL select statement

select * from order order by datum_order;

Deze query zal een foutmelding geven. Het kan wel met:

select * from "order" order by datum_order;

De tabel naam is hierbij ook hoofdlettergevoelig!
Beter is om deze situatie te voorkomen. Door toevoeging van een prefix voor elke tabel (KAS_ORDER, KAS_ARTIKEL, WK_KAS2301_FACTUUR_REGEL, etc) zal de tabelnaam nooit meer een gereserveerd woord worden.

Algemene regels voor het maken van codes of mnemonics voor lange namen:

• Gebruik de eerste letter van elk woord in een samengestelde naam;
• Verwijder klinkers, maar niet als dit het eerste teken van de naam is;
• Verwijder enkele laatste karakters van elk woord of lettergreep.

Enkele Voorbeelden:
NB: BTW wordt niet afgekort, het is al 3 posities en al een afkorting.

In dit deel hebben we een mogelijke naamgevingstandaard beschreven voor een Oracle-omgeving. Deze wordt weer gebruikt in het volgende deel waar we een standaardinrichting voor een Oracle-database of schema beschrijven.

-Toon Loonen

Toon Loonen is werkzaam bij Capgemini en gespecialiseerd in (logisch en fysiek) gegevensmodellering.
Hij is bereikbaar via e-mail: toon.loonen@capgemini.com of toon.loonen@inter.nl.net.