Rozdział 4

Konwencje

Niezwykle istotnym czynnikiem, ułatwiającym tworzenie aplikacji klient-serwer,
jest konsekwentne stosowanie standardowych konwencji nazewnictwa i metod
zapisu programu. Problematyka ta wydaje się na tyle istotna, że jej omówienie
poprzedzi właściwe informacje na temat budowania aplikacji.

Niniejszy rozdział zawiera szereg uwag na temat nazewnictwa elementów aplikacji
klient-serwer, napisanych w Delphi. Uwagi te odnosić się będą do elementów
aplikacji klienta i serwera, które omawiane będą oddzielnie.

Zawartość tego rozdziału należy traktować wyłącznie jako zbiór sugestii.
Czytelnicy powinni wybrać takie metody nazewnictwa i zapisu programu, jakie im
najbardziej odpowiadają. Znacznie istotniejsze od wyboru konkretnej konwencji
jest jej konsekwentne stosowanie.

Elementy programu w języku Object Pascal

Dyskusję na temat nazewnictwa rozpoczniemy od elementów programu w Delphi.
Do elementów tych zaliczyć można komponenty, formularze, moduły danych,
moduły kodu (units), zmienne, stałe, itd. Innymi słowy, za elementy programu
w Delphi uznajemy wszystkie te elementy, które nie są wprost związane
z serwerem bazy danych. Do elementów związanych z serwerem bazy danych
zaliczamy m.in. tabele, indeksy, widoki, wyzwalacze, procedury osadzone, reguły,
wartości domyślne, itd.

UWAGA:

Z uwagi na różnorodność wykorzystywanych obecnie środowisk sieciowych,
należy w miarę możliwości unikać stosowania długich nazw plików, dozwolonych
w

Windows 95/NT. Wprawdzie Delphi doskonale radzi sobie z

nazwami

dłuższymi niż 8 znaków, jednak często zdarza się, że aplikacja musi
współpracować z sieciowym systemem operacyjnym lub działać na komputerze, na
którym nazwy takie nie są dozwolone. Jest to szczególnie prawdopodobne
w przypadku aplikacji typu klient-serwer, które często korzystają z serwerów
rezydujących na innym komputerze.

88

Część I

Można się spodziewać, że w niedalekiej przyszłości większość serwerów i sieci
będzie dopuszczać stosowanie długich nazw plików. Obecnie jednak wciąż jeszcze
wskazana jest powściągliwość w korzystaniu z tego udogodnienia.

Katalogi

Omówienie rozpoczniemy od katalogów, gdyż ich struktura bywa często równie
ważna, jak sama zawartość. Wszystkie dane, niezależnie od ich typu, dobrze jest
przechowywać na dysku w jednym, wspólnym katalogu, o nazwie DATA (DANE).
Umożliwia to wykonanie kopii bezpieczeństwa wszystkich danych poprzez proste
skopiowanie zawartości katalogu DATA i jego podkatalogów.

W obrębie katalogu DATA utworzyć można podkatalogi, odpowiadające
poszczególnym aplikacjom - jeden podkatalog dla programu Word Perfect for
Windows, drugi dla Delphi, trzeci dla Quattro Pro for Windows, itd. Ułatwi to
odszukanie pliku utworzonego przy użyciu określonej aplikacji. Taki sposób
postępowania odbiega od modnego ostatnio systemu pracy „zorientowanej na
przetwarzanie dokumentu, a nie uruchamianie aplikacji”, jest jednak dobrze
sprawdzony w praktyce.

W ramach podkatalogu każdej aplikacji umieścić można podkatalogi
odpowiadające poszczególnym projektom. Na przykład, projekt RentalMan
(„zarządzanie wynajmem”), opracowywany w części „Tutorial” niniejszej książki,
mógłby rezydować w

katalogu C:\DATA\DELPHI3\RENTMAN. W

praktyce

bardzo rzadko stosuje się rozszerzenia nazw katalogów. Katalogi powinny mieć
nazwy łatwe do rozpoznania i zapamiętania - takie, które równie dobrze mogłyby
identyfikować segregatory stojące na półce. W istocie, katalogi „udają” przecież
segregatory z

dokumentami. Z

powyższych zasad wynika, że jeśli projekt

opracowywany jest przy pomocy kilku programów, to należy utworzyć podkatalog
projektu, o identycznej nazwie, w podkatalogu każdej z aplikacji. Oczywiście - jak
już wspomniano - powyższe reguły należy traktować wyłącznie jako sugestię
autora, opartą na jego własnych doświadczeniach.

UWAGA:

Windows 95 automatycznie zakłada katalog o

nazwie Moje Dokumenty,

analogiczny do wspomnianego katalogu DATA. W Windows 95 podkatalogi
przyjęto nazywać folderami. Foldery tworzy się m.in. w programie Eksplorator.

Konwencje

89

Nazwy projektów

Nazwy projektów powinny być rozpoznawalne i logiczne, a jednocześnie zgodne
z konwencją nazewnictwa plików „8+3”. Nie należy zmieniać standardowego
rozszerzenia, nadawanego przez Delphi plikom projektów. W rezultacie długość
nazwy projektu zostaje ograniczona do zaledwie ośmiu znaków. Nazwa taka
powinna być identyczna z nazwą katalogu, w którym przechowywany jest projekt.
Dzięki temu możliwe będzie łatwe ustalenie, skąd pochodzi plik, przeniesiony
tymczasowo w inne miejsce albo skopiowany na dysk kolegi.

Nazwy plików

Plikom dobrze jest nadawać nazwy czytelne, logiczne i

„rozszerzalne”.

„Rozszerzalność” można osiągnąć przeznaczając jedną lub dwie ostatnie cyfry
nazwy na numer kolejny wersji. Dzięki takiej numeracji możliwe jest
przechowywanie kilku wersji pliku, z

zachowaniem jego głównej nazwy.

Przykładowo na dysku autora plik, zawierający niniejszy rozdział, nosi nazwę
CSD0400. Kolejne, zmodyfikowane nazwy pliku zapisywane są pod nazwami
CSD0401, CSD0402, itd. Sposób ten umożliwia szybkie rozpoznanie ostatniej
wersji pliku, bez odczytywania daty i godziny jego utworzenia. Ponadto bardzo
łatwo można przenieść, skopiować lub spakować wszystkie wersje pliku,
korzystając z wieloznacznej nazwy plików (zawierającej tzw. wildcards, np.
„CSD04??”). Opisany powyżej sposób nazywania plików przyrównać można do
prymitywnego systemu zarządzania tekstem źródłowym programów. Mimo swojej
prostoty system działa.

Inną praktyczną zasadą jest dodawanie na początku nazwy pliku przynajmniej
jednej litery, identyfikującej projekt, którego plik dotyczy. Pliki należące do
danego projektu wyglądają wówczas podobnie i łatwiej jest nimi zarządzać.
Wszystkie pliki należące na przykład do „systemu zarządzania wynajmem
i konserwacją” (Rental Maintanance Management System), budowanego w części
„Tutorial” niniejszej książki, noszą nazwy rozpoczynające się literą R.

Po literze, identyfikującej projekt, można wpisać od trzech do sześciu znaków
opisujących ogólne przeznaczenie pliku. Jeżeli plik nie ma poza tym żadnego
szczególnego przeznaczenia, to można je scharakteryzować przy pomocy
wszystkich sześciu znaków, pozostających do dyspozycji przed numerem kolejnym
wersji. Jeśli można wyróżnić jakieś szczególne przeznaczenie pliku, to trzy litery
należy poświęcić na symbol ogólnego zastosowania pliku, a trzy kolejne na opis
szczegółowego przeznaczenia. W systemie zarządzania wynajmem i konserwacją
(Rental Maintenance Management) występuje na przykład plik, który zawiera
fragment programu odpowiedzialny za obsługę okna dialogowego do edycji tabeli

CALLS

(zgłoszenia telefoniczne). Plik ten nosi nazwę

RCALEDT0

- od „Rental

maintenance management system”, okno dialogowe

Call Edit

.

90

Część I

Nazwy modułów

Podobnie jak nazwy plików, tak i nazwy modułów (units) mogą być dowolnie
długie, przy czym kompilator rozróżnia nazwy wyłącznie na podstawie pierwszych
63 znaków. Jak już wspomniano, należy unikać nadawania nazw dłuższych niż
ośmioznakowe. Na podstawie nazwy modułu Delphi tworzy odpowiednią nazwę
dla pliku PAS, dlatego nadanie modułowi nazwy dłuższej niż ośmioznakowa
spowoduje utworzenie pliku o równie długiej nazwie.

Nazwy komponentów

Ponieważ nie występuje bezpośrednia relacja między nazwami plików a nazwami
komponentów, te ostatnie powinny być jak najbardziej opisowe - z zastrzeżeniem,
że zbyt długą nazwę będzie trudno wpisywać z klawiatury. Nazwy powinny być
łatwe do wymówienia i dobrane logicznie. Należy także zalecić stosowanie
w nazwach komponentów zarówno dużych, jak i małych liter. W nazwach
komponentów nie można używać spacji, dlatego najlepszym sposobem oddzielania
słów w nazwie jest rozpoczynanie każdego z nich wielką literą. Wreszcie, zaleca
się rozpoczynanie wszystkich nazw typów w języku Pascal (w tym definicji
komponentów, które formalnie są klasami) dużą literą T. Konwencji tej używają
powszechnie autorzy biblioteki Visual Component Library, dostarczanej
w pakiecie Delphi. Dzięki niej definicje typów bardzo łatwo można wyróżnić
w tekście programu. Na przykład, komponent array table z rozdziału 3, ułatwiający
dostęp do tabel baz danych, nosi nazwę

TArrayTable

. Litera

T

wskazuje, że

jest to klasa, zdefiniowana w języku Object Pascal. Opisowa część identyfikatora -

ArrayTable

- charakteryzuje przeznaczenie komponentu.

Nadając nazwy komponentom dostarczanym standardowo w pakiecie Delphi,
dobrze jest używać dwu-, trzy- lub czteroliterowego symbolu, zapisywanego
małymi literami i umieszczanego przed właściwą nazwą komponentu. Nazwy
komponentów

Memo

mogą zatem rozpoczynać się od symbolu

me

; nazwy

kontrolek typu

Edit

rozpoczynałyby się w tej samej konwencji od liter

ed

.

Pozostała część nazwy ma w

takim wypadku charakter opisowy, np.

edIdKlienta

,

edCustomer Name

lub

meKomentarz

. W tabeli 4.1 zebrano

skrócone identyfikatory typów komponentów. Stanowią one oczywiście jedynie
sugestię autora. Należy zwrócić uwagę, że na liście występują także klasy Form
(formularze) i Data Module (moduły danych) - ich nazwy również powinny
mieścić się w przyjętej konwencji.

Wszystkie komponenty, reprezentujące pola dialogowe, oznaczone są
dwuliterowym skrótem, po którym następuje znak podkreślenia (_). Tak
skonstruowane nazwy powinny wyróżniać się w tekście programu. Regułą jest
także rozpoczynanie nazw wszystkich kontrolek, związanych z bazami danych, od
litery

d

. Po niej następuje skrót właściwy dla odpowiedniej standardowej kontrolki,

Konwencje

91

na przykład kontrolce

Edit

odpowiada kontrolka

DBEdit

, powiązana z bazą danych.

Kontrolki

Edit

oznacza się symbolem

ed

, natomiast

DBEdit

-

ded

.

Tabela 4.1 Komponenty Delphi i zalecane skróty

Component - Komponent

Abbreviation - Skrót

Animate an

AutoObject ao

BitBtn bb

BatchMove bm

Bevel be

BDEProvider bp

BDEResolver br

Button bt

ColorDialog co_

Calendar ca

ComboBox cb

DdeClientConv cc

ClientDataSet cd.

DecisionCube cde

DecisionSource cds

DecisionGraph cgp

DecisionGrid cgr

DecisionPivot cpi

DecisionQuery cqu

ColorGrid cg

Chart ch

DdeClientItem ci

CheckBox ck

Coolbar co

ClientSocket cs

ChartFX cx

92

Część I

Component - Komponent

Abbreviation - Skrót

Database db

DriveComboBox dc

DBComboBox dcb

DBCtrlGrid dcg

DBChart dch

DBCheckBox dck

DBEdit ded

DBGrid dgr

DBImage dim

DirectoryListBox dl

DBListBox dlb

DBLookupComboBox dlcb

DBLookupCombo dlco

DBLookupListBox dllb

DBlooupList dlli

DataModule dm

DBMemo dme

DBNavigator dna

DirectoryOutline do

DataSetTableProducer dp

DrawGrid dr

DBRadioGroup drg

DataSource ds

DateTimePicker dt

DBText dte

Edit ed

F1Book f1

FilterComboBox fc

FindDialog fi_

FileListBox fl

Konwencje

93

Component - Komponent

Abbreviation - Skrót

Form fm

FontDialog fo_

Gauge ga

GroupBox gb

Graph gr

GraphicsServer gs

HeaderControl hc

HTTPDispatcher hd

Header he

HotKey hk

HTMLPageProducer hp

HTMLQueryTableProducer hq

HTMLDataSetTableProducer ht

IBEventAlerter ie

ImageList il

Image im

Label la

ListBox lb

ListView lv

MaskEdit md

Memo me

MainMenu mm

MediaPlayer mp

MemoryDataSet ms

Notebook nb

OpenDialog od_

OleContainer ol

OpenPictureDialod op_

Outline ou

Panel pa

94

Część I

Component - Komponent

Abbreviation - Skrót

PaintBox pb

PageControl pc

ProgressBar pr

PrintDialog pr_

PageProducer pp

PrinterSetupDialog ps_

PopupMenu pu

QRBand qba

QRChildBand qcb

QRChart qch

QRCompositeReport qcr

QRDBCalc qdc

QRDBImage qdi

QRDetailLink qdl

QRDBText qdt

QREditor qed

QRExpr qex

QRGroup qgr

QRImage qim

QRLabel qla

QRMemo qme

QueryTableProducer qp

QRPreview qpr

QuickReport qr

QRRichText qrt

QRSysData qsd

QRSubDetail qsd

QRShape qsh

Query qu

RadioButton rb

Konwencje

95

Component - Komponent

Abbreviation - Skrót

RichEdit re

ReplaceDialog re_

RadioGroup rg

Report rp

RemoteServer rs

ScrollBar sa

SaveDialog sa_

SpeedButton sb

DdeServerConv sc

SpinEdit sd

Session se

StringGrid sg

DdeServerItem si

Splitter sl

StoredProc sp

SavePictureDialog sp_

ServerSocket ss

StatusBar st

SpinButton su

ScrollBox sx

Table ta

TrackBar tb

TabControl tc

Thread th

Timer ti

TabbedNotebook tn

Toolbar to

TabSet ts

TreeView tv

UpDown ud

96

Część I

Component - Komponent

Abbreviation - Skrót

UpdateSQL us

VtChart vc

VSSpell vs

WebBrowser wb

WebDispatcher wd

WebSesion ws

WSKAZÓWKA:

Niektóre narzędzia typu CASE (komputerowo wspomagana inżynieria
oprogramowania) pozwalają użytkownikowi na zdefiniowane konwencji
nazewnictwa, stosowanej dla obiektów automatycznie tworzonych przez program.
Przykładem takiego narzędzia jest S-Designor (w najnowszej wersji program ten
nosi nazwę PowerDesignor). W takim przypadku programowi typu CASE można
nakazać stosowanie konwencji nazewnictwa, opisanych w niniejszym rozdziale.

Nazwy typów

Nazwy typów podlegają tym samym konwencjom, co nazwy komponentów.
Wszystkie nazwy typów powinny rozpoczynać się dużą literą T. Pozostała część
nazwy powinna mieć charakter opisowy, należy jednak unikać zbyt długich nazw,
których wielokrotne wpisywanie z klawiatury byłoby uciążliwe. Korzystanie
zarówno z dużych, jak i małych liter, ułatwia oddzielanie poszczególnych wyrazów
w nazwie. W nazwach typów należy przestrzegać tych samych konwencji, co
w nazwach klas - klasy są przecież także typami. Oto przykładowa definicja typu:

TRecordMouse = (rmAll, rmNone, rmClicksAndDrags);

Nazwy stałych

Autor przyjmuje i poleca zasadę pisania nazw stałych wyłącznie dużymi literami -
podobną regułę przyjęto w zapisie nazw stałych (składników definiowanych po
słowie

#define

) w języku C. Pozwala ona odróżnić stałe, których wartości nie

można zmienić, od zmiennych. Poniżej podano przykładową deklarację stałej,
zaczerpniętą z

tekstu źródłowego komponentu

LiveQuery

, opisanego

w rozdziale 27:

DEFAULTCREATEVIEWSQL = ‘CREATE VIEW %s AS ‘;

Konwencje

97

Nazwy zmiennych

W nazwach zmiennych używa się pełnych wyrazów, rozpoczynanych dużymi
literami. Nazwy zmiennych powinny mieć charakter opisowy, a jednocześnie być
na tyle krótkie, by dało się je bez trudu wielokrotnie wpisywać z klawiatury. Oto
przykłady dobrze dobranych nazw zmiennych, pochodzących z tekstu źródłowego
komponentu

LiveQuery

:

TemporaryDB : TDatabase;
WorkSQL: TStrings;

Inna wypróbowana technika polega na dodawaniu na początku każdej nazwy
pojedynczej litery, opisującej zasięg zmiennej: „l” dla zmiennej lokalnej, „g” - dla
globalnej i „c” dla zmiennej związanej z klasą. Przyjęcie takiej konwencji ułatwia
niekiedy określenie pochodzenia i

zasięgu zmiennej, bez konieczności

analizowania deklaracji funkcji, procedur i klas.

Nazwy procedur i funkcji

Nazwy procedur i funkcji należy konstruować zgodnie z zasadami obowiązującymi
dla nazw zmiennych. Należy jedynie, w miarę możliwości, rozróżniać w nazwie
funkcje wymagające podania argumentów od funkcji bezargumentowych. Poniższy
wiersz programu może być mylący, gdyż na pierwszy rzut oka nie można
zorientować się, czy

SalesTax

to zmienna, czy funkcja.

x:=SalesTax;

Problem ten można rozwiązać dodając przed nazwą funkcji bezargumentowych
przedrostek

Get

(„pobierz”). W praktyce okazuje się, że dobrze jest rozpoczynać

nazwy większości funkcji od przedrostka

Get

. Istnieją oczywiście sytuacje,

w których tak skonstruowane nazwy nie mają sensu, jak w przypadku jednej
z wbudowanych funkcji Delphi noszącej nazwę

FileOpen

. Dodawanie w tym

przypadku przedrostka

Get

nie miałoby sensu.

W tekście źródłowym biblioteki VCL przyjęto zasadę stosowania przedrostka

Set

w nazwach procedur, które nadają nazwę atrybutowi, oraz przedrostka

Get

w tych, które zwracają wartość atrybutu. Tę samą zasadę można zastosować
w odniesieniu do procedur i funkcji nie związanych z atrybutami.

Styl zapisu programu w języku Object Pascal

Kolejnym obszarem, w którym standaryzacja przynosi wymierne korzyści, jest styl
zapisu programu. Niemal każdy programista stosuje swój własny styl zapisu.
Okazuje się jednak, że sam styl jest o wiele mniej istotny niż konsekwencja w jego
stosowaniu. Konsekwencja taka zapewnia czytelność programu i ułatwia jego

98

Część I

konserwację. W najbliższych sekcjach omówimy sposoby zapisu konstrukcji

If...else

, bloków

begin...end

oraz komentarzy.

Konstrukcja If...else

Jedną z reguł, stosowanych z powodzeniem przez autora, jest ujmowanie warunku
w konstrukcji

If...else

w

nawiasy. Postępowanie takie jest podwójnie

uzasadnione. Po pierwsze - zapewnia lepszą czytelność programu. Po drugie -
umożliwia dopisanie drugiego warunku bez konieczności wprowadzania
jakichkolwiek zmian w pierwszym. Należy podkreślić, że - w przeciwieństwie do
języka C - Pascal nie wymaga ujmowania wyrażeń warunkowych w nawiasy.
Dlatego też poniższy zapis jest formalnie poprawny:

If x=1 then y:=z;

Jednak już dwa (lub więcej) wyrażenia warunkowe w pojedynczej instrukcji

If

wymagają nawiasów:

If (x=1) or (x*2=4) then y:=z;

Jeśli instrukcja

If

zostałaby pierwotnie zapisana bez nawiasów, tak jak

w pierwszym przykładzie, to dodając drugie wyrażenie warunkowe należałoby
również pamiętać o ujęciu w nawiasy pierwszego wyrażenia. Pascal nie zabrania
stosowania nawiasów przy pojedynczych wyrażeniach, dlatego można od
początku, konsekwentnie ujmować w nawiasy wszystkie - również pojedyncze -
wyrażenia warunkowe.

Bloki begin...end

Inna przyjęta przez autora konwencja odnosi się do wszelkich instrukcji,
zawierających blok programu, ograniczony parą

begin...end

. W szczególności

jest to instrukcja warunkowa

If...then

. Słowo

begin

umieszczane jest w tym

samym wierszu, co instrukcja. W przypadku instrukcji warunkowej oznacza to, że

begin

znajdzie się w tym samym wierszu, co

If

. Pascal nie nakłada żadnych

ograniczeń co do rozmieszczenia słów kluczowych, a zatem

begin

można

umieścić w dowolnym miejscu - w tym samym wierszu, co

if

, w wierszu poniżej

albo nawet pięć wierszy niżej. W każdym przypadku kompilator wygeneruje
identyczny kod. Oto przykład zapisu zgodnego z konwencją, proponowaną przez
autora:

if (x=1) then begin

y:=z;

closefile;

Konwencje

99

end;

Opinie na temat zapisywania tego rodzaju instrukcji są bardzo zróżnicowane.
Niektórzy programiści woleliby zapisać tę samą instrukcję warunkową
następująco:

if (x=1) then

begin

y:=z;

closefile;

end;

Metoda ta wiąże się jednak z poświęceniem dodatkowego wiersza, co bywa
szczególnie uciążliwe podczas edycji programu na ekranie. Problem wydaje się
istotny z uwagi na ( przyjmowany domyślnie) mały rozmiar okna edytora Delphi.
Ponadto, zapis ze słowem

begin

w oddzielnym wierszu, budzi wątpliwości co do

wymaganego wcięcia tekstu. Czy słowo

begin

, które jest tylko ogranicznikiem

bloku, należy rozpocząć w tej samej kolumnie, co

If

? Czy też może powinno być

przesunięte w prawo względem

If

, gdyż zawarty w bloku fragment programu jest

uzależniony od

If

? A co począć z fragmentem programu między

begin

a

end

?

Czy ma być zapisany równo z

begin

, czy z

If

? Proponowany zapis, w którym

begin

znajduje się w tym samym wierszu, co

If

, eliminuje problem wcięcia.

Słowo

end

pełni oczywistą rolę terminatora instrukcji

If

. Wreszcie, fragment

programu wykonywany warunkowo, jest przesunięty względem

If

, a nie

begin

,

co uwypukla jego powiązanie z warunkiem.

Niektórzy programiści rozpoczynają słowa

begin

i

end

dużymi literami. Należy

jednak zwrócić uwagę, że wszystkie wyrazy pisane wielką literą wyróżniają się
w tekście programu. Nie ma to chyba uzasadnienia w przypadku zwykłych
ograniczników bloku, które nie są nawet bezpośrednio tłumaczone na kod
maszynowy. Duże litery należy zarezerwować dla identyfikatorów, wymagających
szczególnej uwagi (takich jak stałe), a nie słów

begin...end

, występujących

w każdym programie bardzo licznie.

Komentarze

Object Pascal dopuszcza stosowanie trzech sposobów zapisu komentarzy: (*...*),
{...} i //. Do oznaczania zwykłych komentarzy - wyjaśniających działanie części
programu - najlepiej stosować symbol {...}. Symboli (*...*) można wówczas
używać w procesie testowania programu, do chwilowego wyłączania niektórych
fragmentów. Tak zaznaczone fragmenty łatwo można odszukać i ponownie
uaktywnić albo definitywnie usunąć. Dla komentarzy, opisujących pojedynczy
wiersz programu, zarezerwowany jest symbol //.

100

Część I

Od przyjętych zasad oznaczania komentarzy trzeba odstąpić, jeśli komentarze mają
być zagnieżdżone albo zawierać jeden z wymienionych wyżej zarezerwowanych
symboli. Kompilator zasygnalizuje błąd, jeśli w tekście komentarza, rozpoczętego
znakiem {, napotka ponownie ten sam lewy nawias. Jeśli komentarz musi zawierać
nawiasy {}, to należy go oznaczyć np. symbolami (* i *).

Obiekty związane z serwerem bazy danych

Stosowanie stałych zasad nazewnictwa obiektów serwera bazy danych pozwala
uniknąć wielu stresów. Tworzenie dużych baz danych przypomina pisanie dużych
programów - im stosowane nazwy obiektów są czytelniejsze, tym mniejsze jest
prawdopodobieństwo pogubienia się w

gąszczu elementów. Konsekwentnie

nazywane obiekty stają się swoistymi drogowskazami - pomagają w poruszaniu się
po bazie danych.

Konsekwentne nazewnictwo nie tylko upraszcza administrowanie bazą danych -
ułatwia również tworzenie czytelnych zapytań. Język SQL ma przecież z założenia
przypominać naturalny język mówiony, a jednocześnie pozostawać językiem
strukturalnym. Zrozumiałe i konsekwentnie dobrane nazwy podnoszą czytelność
programów, zapisanych w języku SQL.

Podobnie jak w przypadku elementów języka Object Pascal, także i tutaj wszelkie
proponowane konwencje są wyłącznie sugestiami autora. Czytelnicy powinni
stosować takie zasady nazewnictwa, jakie im najbardziej odpowiadają.
Konsekwencja w stosowaniu przyjętych zasad jest znacznie ważniejsza niż wybór
jakichkolwiek konkretnych reguł.

UWAGA:

W dalszej części niniejszej sekcji wielokrotnie natrafić można na sugestie
stosowania w ramach jednej nazwy dużych i małych liter; ma to służyć oddzieleniu
poszczególnych wyrazów. Dlatego należy - w

miarę możliwości - tak

skonfigurować serwer, aby rozróżniał on w nazwach duże i małe litery.

Niektóre serwery (np. InterBase) nie dają takiej możliwości. Stosowanie różnej
wielkości liter w

nazwach traci wówczas sens. Wprawdzie pisane przez

użytkownika skrypty SQL są bardziej czytelne, jednak forma zapisu nazw może
zostać całkowicie zignorowana przez serwer. Serwer bazy danych może nie
zapamiętywać i nie respektować nazw zawierających zarówno duże, jak i małe
litery. Nawet jeśli np. nazwy kolumn tabeli zapisane są dużymi i małymi literami,
serwer może po każdym dostępie do bazy zwracać te same nazwy zapisane
wyłącznie dużymi literami. W takich przypadkach lepiej od razu zapisać nazwy
dużymi literami, a do oddzielania wyrazów stosować znak podkreślenia (_).

Konwencje

101

Serwery

Praktyka dowodzi, że konsekwencja w nazewnictwie zasobów baz danych, takich
jak serwery, jest nie mniej ważna niż konsekwencja w nazewnictwie obiektów,
udostępnianych przez te zasoby. Autorzy systemów baz danych, zarządzający
wieloma podobnymi serwerami, mogą uniknąć pomyłek, stosując jednolite
nazewnictwo serwerów.

W prezentowanej tutaj konwencji, nazwy serwerów składają się z ośmiu znaków
i są zapisywane dużymi literami. Pierwsze trzy znaki identyfikują typ serwera:
SQL oznacza serwer Sybase lub Microsoft SQL Server, ORA - Oracle Server,
SQA - SQL Anywhere, itd. Kolejne trzy znaki służą do rozróżnienia serwerów
przeznaczonych do tworzenia aplikacji (development), testowania i właściwych
serwerów użytkowych (działających na rzeczywistych danych, na rzecz
rzeczywistych użytkowników). Oznaczenia tych serwerów to odpowiednio
„DEV”, „TST” i „PRO”. Ostatnie dwa znaki przeznaczone są na numer kolejny
z zakresu od 1 do 99 (numer zerowy jest zarezerwowany - zob. następny akapit).
Numeracja umożliwia założenie wielu wersji tego samego serwera.

Omówione zasady najlepiej zilustruje przykład. Załóżmy, że mamy serwer Sybase,
który jako jedyny służy do tworzenia aplikacji. Serwer ten nosił będzie nazwę
SQLDEV01. Analogicznie, użytkowa wersja tego serwera nazywać się będzie
SQLPRO01.

WSKAZÓWKA:

Zerowy numer kolejny dobrze jest zarezerwować dla specjalnych zastosowań.
Można na przykład utworzyć tymczasowy serwer Oracle, używany do budowy
aplikacji i nazwany ORADEV00. Podobnie, lokalny serwer Sybase, działający na
komputerze typu laptop, można nazwać SQLDEV00; z serwera tego z założenia
korzystał będzie tylko właściciel laptopa. Zarezerwowanie numeru zerowego dla
specjalnych zastosowań okazuje się bardzo przydatne w praktyce.

UWAGA:

Umieszczanie numeru w nazwach serwerów może się wydawać zbędne. Po co
właściwie tworzyć więcej niż jeden egzemplarz serwera określonego typu?
Doświadczeni administratorzy baz danych znają odpowiedź na to pytanie.
Zarządzając zbiorem serwerów, prawie zawsze stanąć można przed koniecznością
utworzenia kilku serwerów użytkowych lub przeznaczonych do budowania lub
testowania aplikacji . Serwery można podzielić ze względu na stosowane
aplikacje, jednostki organizacyjne, które z nich korzystają, wreszcie w celu
poprawy wydajności aplikacji. Może się także okazać, że bezpieczniej jest
przeprowadzać wszelkie zmiany i uaktualnienia na oddzielnych serwerach, bez
narażania właściwych serwerów użytkowych.

102

Część I

Administrator każdego systemu zarządzania bazą danych co jakiś czas zmuszony
jest do przeprowadzania uaktualnienia systemu operacyjnego albo oprogramo-
wania serwera bazy danych. Oczywiście przeprowadzanie takich zmian wymaga
wielkiej ostrożności, gdyż nie może doprowadzić do awarii działających
systemów. Dlatego przed uaktualnieniem serwera bazy danych zawsze testuje się
wszelkie zmiany i nowe wersje oprogramowania. Najczęściej administrator
przygotowuje nowy komputer, instaluje na nim nowy serwer bazy danych, po
czym kopiuje dane ze starego serwera na nowy. Eliminuje to możliwość
zakłócenia pracy działającego serwera podczas wprowadzania zmian w oprogra-
mowaniu systemowym. Bardzo często administratorzy uaktualniają najpierw
własne serwery, używane do budowy lub testowania aplikacji, a następnie
zamieniają je rolami z dotychczasowymi serwerami użytkowymi. Załóżmy, że
administrator bazy danych Oracle chce przeprowadzić uaktualnienie serwera
użytkowego ORAPRO01, instalując na nim nową wersję systemu zarządzania bazą
danych Oracle. W takim przypadku należy:

1. Zainstalować nową wersję Oracle na serwerze do tworzenia aplikacji,

ORADEV01.

2. Skopiować rzeczywiste dane na uaktualniony serwer.

3. Po przetestowaniu uaktualnionego serwera z istniejącymi systemami, zmienić

jego nazwę na ORAPRO02 (gdyż ORAPRO01 nadal istnieje i działa), po czym
nakazać wszystkim rzeczywistym aplikacjom korzystanie z

ORAPRO02

w miejsce ORAPRO01. W środowisku UNIX zmiany takiej można dokonać za
pośrednictwem mechanizmów nazewnictwa hostów, np. DNS.

4. Po uruchomieniu nowego serwera użytkowego można zmienić nazwę

dotychczasowego - ORAPRO01 - na ORADEV01, gdyż teraz będzie on
używany do tworzenia aplikacji.

5. Ostatnim etapem jest uaktualnienie nowego serwera do tworzenia aplikacji

(ORADEV01, poprzednio ORAPRO01).

Opisana powyżej procedura jest najbezpieczniejszym, znanym autorowi, sposobem
uaktualnienia oprogramowania systemowego. Alternatywą może być jedynie
założenie całkowicie nowego serwera bazy danych. Procedurę uaktualnienia
znacznie upraszcza stosowanie omówionych wcześniej konwencji nazewnictwa
serwerów. (Oczywiście podczas uaktualniania systemu nie można obyć się bez
prawidłowo wykonanych kopii bezpieczeństwa).

Bazy danych

Bazy danych, w rozumieniu przyjętym w niniejszej książce, są zbiorami tabel - nie
są tożsame z tabelami. Nazwy baz danych należy zapisywać małymi literami.
Konsekwencja w zapisie jest w tym przypadku szczególnie istotna, gdyż niektóre

Konwencje

103

serwery baz danych w standardowej konfiguracji biorą pod uwagę wielkość liter
przy rozróżnianiu nazw. Pierwsze trzy znaki nazwy mogą stanowić prefiks,
identyfikujący system, do którego należy dana baza. Jeśli z bazy korzysta kilka
oddzielnych aplikacji, to jej nazwa powinna mieć bardziej ogólny charakter. Na
ogół celowe jest rozróżnienie baz danych nadrzędnych od baz transakcyjnych.
Nadrzędna (ang. master) baza danych zawiera tablice, których zawartość zmienia
się stosunkowo rzadko, i w których wyszukuje się nazwy i inne informacje
o charakterze opisowym. Transakcyjna (ang. transactional) baza danych
przechowuje bardziej ulotne dane - jej zawartość może zmieniać się z dnia na
dzień. Dane transakcyjne są na ogół wprowadzane z klawiatury przez użytkownika
albo pobierane z zewnętrznych urządzeń. Niekiedy bazy nadrzędne i transakcyjne
tworzone są jako oddzielne obiekty, czasami zaś połączone są w jedną bazę
danych. W

tym pierwszym przypadku celowe jest nadanie obu bazom

odpowiednich, różnych nazw.

UWAGA:

Niektóre platformy systemów zarządzania bazami danych (np. InterBase) nie
dopuszczają odwołań pomiędzy tabelami, należącymi do różnych baz danych.
W szczególności oznacza to, że z tabeli transakcyjnej, należącej do jednej bazy
danych, nie można odwołać się do tabeli , znajdującej się w innej, nadrzędnej
bazie danych. Dlatego, przystępując do planowania organizacji baz danych, należy
upewnić się, czy stosowany system zarządzania bazami dopuszcza odwołania do
zewnętrznych tabel. Jeśli system nie pozwala na stosowanie takich odwołań, to
sugerowane powyżej oddzielenie nadrzędnych i transakcyjnych baz danych nie
będzie możliwe.

Niekiedy ostatni znak (lub ostatnie dwa znaki) nazwy bazy danych przeznacza się
na numer kolejny. Pozwala to na tworzenie podobnych nazw wielu wersji tej samej
bazy. Powyższa metoda bywa jednak rzadko stosowana w praktyce. W omawianej
konwencji nadrzędna baza danych systemu finansowo- księgowego mogłaby nosić
nazwę

fknad0

.

fk

identyfikuje bazę danych jako należąca do systemu

finansowo-księgowego,

nadrz

oznacza, że jest to baza nadrzędna, a cyfra 0

wskazuje, że jest to pierwsza z grupy potencjalnie kilku podobnych baz danych.

Należy ponownie zwrócić uwagę na ograniczenie długości nazwy do ośmiu
znaków. Istotnym powodem dobrowolnego zastosowania się do tego ograniczenia
jest możliwość nadania skryptowi SQL, przeznaczonemu do tworzenia bazy
danych, tej samej nazwy, co samej bazie. Jeśli nazwa będzie ograniczona do ośmiu
znaków, to nawet skrypt rezydujący w systemie nie dopuszczającym długich nazw
plików, będzie mógł nosić nazwę identyczną z nazwą bazy danych. Krótkie nazwy
plików są wygodne również dlatego, że nie trzeba ich zmieniać wraz z ewentualną
zmianą platformy. Dlatego wskazane jest ograniczenie długości nazw plików

104

Część I

również wówczas, gdy przechowywane są one na lokalnym dysku (co wiąże się
z możliwością stosowania długich nazw w podsystemie Win32s).

Pliki danych

Większość korporacyjnych systemów zarządzania bazami danych rozróżnia
definicje baz danych od urządzeń, w których dane są fizycznie przechowywane.
Jest to realizowane za pośrednictwem konstrukcji programowych znajdujących się
pomiędzy bazami danych a napędami dysków, na których te bazy są składowane.
System SQL serwer odwołuje się do tych konstrukcji jako do urządzeń logicznych
natomiast w Oracle obiekty takie nazywa się plikami danych (ang. data files). Pliki
danych odwołują się bezpośrednio do napędów dyskowych. Z kolei bazy danych
zawierają odwołania do plików danych. Dzięki przyjęciu takiego rozwiązania,
możliwe jest przechowywanie jednej bazy danych na kilku różnych napędach,
a nawet na kilku różnych serwerach; nie wymaga to żadnych dodatkowych
zabiegów. Omawiane podejście zapewnia jednolity interfejs, przeznaczony do
tworzenia i rozszerzania baz danych, niezależny od ich fizycznej lokalizacji.

Na ogół urządzeniom logicznym i plikom danych nadaje się nazwy podobne do
nazw skojarzonych z nimi baz danych. Reguła ta wynika ze stosowanej przez
autora zasady przechowywania w każdym pliku danych tylko jednej bazy.
W ramach każdej nazwy, pierwsze trzy znaki identyfikują przeznaczenie
urządzenia. Dalej następuje numer sekwencyjny, określający pozycję pliku
w grupie podobnych plików danych. Nazwę urządzenia kończy rozszerzenie DAT
(dane). Należy zwrócić uwagę, że pliki urządzeń są widoczne również poza
serwerem bazy danych - z poziomu systemu operacyjnego. Nadanie wszystkim
plikom danych tego samego rozszerzenia ułatwia odnalezienie ich pośród wielu
innych plików w tym samym katalogu.

Omawianą konwencję najlepiej zilustruje przykład. Załóżmy, że mamy plik
urządzenia na którym umieściliśmy dane z bazy danych o nazwie

medical

.

Można wtedy pierwsze urządzenie danych nazwać

meddat00

.dat. Podobnie,

pierwsze urządzenie z

protokołem (log device) może otrzymać nazwę

medlog00

.

dat

. Pierwsze trzy znaki identyfikują bazę danych, obsługiwaną

przez urządzenie, kolejne trzy - właściwą funkcję urządzenia, a

numer

sekwencyjny określa pozycję pliku wśród podobnych plików urządzeń.

UWAGA:

SQL Server pozwala nadawać plikom urządzeń zarówno nazwy logiczne, jak
i fizyczne. Omawiana powyżej konwencja dotyczy nazw fizycznych. Jako nazwy
logicznej można użyć nazwy fizycznej, pozbawionej rozszerzenia.

Konwencje

105

Projektanci baz danych często dokładnie definiują miejsce fizycznego
przechowywania poszczególnych tabel i indeksów; kierują się przy tym względami
wydajności systemu. W przypadku systemu SQL Server służy do tego mechanizm
segmentów (

segments

), a

w

środowisku Oracle - mechanizm przestrzeni

tablespace

. Plik urządzenia logicznego, który ma być używany wyłącznie

przez dany

segment

bądź przestrzeń

tablespace

, powinien nosić

odpowiednią nazwę. Na przykład, plik skojarzony z segmentem

ksiega-

przychodowrozch

mógłby nosić nazwę

kprdat00.dat

. Powyższym

zasadom przyświeca idea łatwego rozpoznawania danych, skojarzonych z danym
plikiem urządzenia, wprost z

poziomu systemu operacyjnego. Ułatwia to

odtwarzanie stanu bazy po wszelkich awariach i sporządzanie kopii zapasowych.

Tabele

Nazwy tabel należy zapisywać wyłącznie dużymi literami. Tabele są kluczowymi
elementami bazy danych, a zapis dużymi literami wyróżni je w tekście poleceń
SQL. Wprawdzie większość współczesnych systemów zarządzania bazami
jednakowo traktuje nazwy zapisane dużymi i

małymi literami, jednak

proponowany tutaj zapis nazw tabel spowoduje ich wyróżnienie w skryptach SQL
i procedurach pamiętanych.

Same nazwy powinny być jak najprostsze, opisowe i składać się z jednego lub
dwóch słów, nie przekraczających w sumie długości ośmiu znaków. Nie zaleca się
stosowania jakichkolwiek numerów sekwencyjnych. Stosowanie powyższych
zasad ma przyczynić się do uproszczenia zapytań SQL. Skomplikowane nazwy
tabel są trudne do odczytania i zapamiętania. Najlepiej sprawdzają się zatem
identyfikatory jednowyrazowe. Oto przykłady prawidłowych nazw tabel:
FAKTURY, ZAMOWIEN, KLIENT.

Również w tym przypadku należy zwrócić uwagę na ograniczenie długości nazwy
do ośmiu znaków. Ograniczenie to pozwoli na nadawanie skryptom SQL nazw
identycznych z nazwami tworzonych przez nie tabel - niezależnie od stosowanego
systemu operacyjnego.

WSKAZÓWKA:

Nadając tabelom nazwy proste i logiczne, autor systemu bazy danych daje
użytkownikom szansę tworzenia ich własnych zapytań SQL. Dostępnych jest wiele
narzędzi do wizualnego konstruowania zapytań. Użytkownicy będą mogli z nich
skorzystać, jeśli tylko nazwy tabel nie będą miały zbyt „komputerowego”
charakteru.

106

Część I

Indeksy

W wielu dialektach SQL zapytania nie mogą zawierać bezpośrednich odwołań do
indeksów. Dlatego nazewnictwo indeksów jest stosunkowo mało istotnym
zagadnieniem. Można, na przykład, nadawać indeksom nazwy identyczne
z nazwami tabel, na bazie których powstały. Taka nazwa powinna być uzupełniona
numerem, określającym pozycję danego indeksu względem innych - pierwszy
indeks tabeli KLIENT może nazywać się KLIENT01, drugi - KLIENT 02, i tak
dalej. Liczby w nazwie odpowiadają numerowi przypisywanemu przez Sybase
SQL Server; dzięki nim łatwiej jest pisać efektywne zapytania, wymuszające
stosowanie konkretnego indeksu.

Perspektywy (ang. views)

Perspektywy należy nazywać tak samo, jak tabele. W

zapytaniach SQL

perspektywy i tabele pełnią bowiem tę samą rolę. Niektórzy programiści
wyróżniają perspektywy przez dodanie do nazwy liter

V

lub

VW

. Nie jest to jednak

konieczne.

Procedury i funkcje pamiętane

Nazwy procedur i funkcji pamiętanych dobrze jest zapisywać małymi literami.
Ułatwi to odróżnienie ich od nazw tabel i innych obiektów w zapytaniach SQL.
Wielkość liter w nazwach zależy na ogół od preferencji programisty, gdyż wiele
współczesnych serwerów SQL nie rozróżnia dużych i małych liter w nazwach.
W każdym przypadku zróżnicowanie nazw obiektów przez stosowanie różnych
wielkości liter poprawia czytelność zapytań.

Niektórzy programiści dodają litery

sp

na początku lub na końcu nazwy procedury

pamiętanej. Na ogół nie jest to potrzebne. Procedury pamiętanej niemal nigdy nie
używa się w tym samym kontekście, co jakiegokolwiek innego obiektu, np. tabeli.
Rzadko na przykład spotyka się zapis

SELECT * FROM nazwaprocedury

,

a już nigdy -

EXECUTE nazwatabeli

. Osoby, które regularnie stosują

polecenie

SELECT

z nazwą procedury pamiętanej, używanej w tym samym

kontekście, co nazwa tabeli (co jest dozwolone np. na platformie InterBase), mogą
zdecydować się na dodawanie

sp

do nazw procedur pamiętanych; w innym

przypadku nie ma takiej potrzeby.

Konwencje

107

OSTRZEŻENIE:

W przypadku platform Sybase oraz Microsoft SQL Server, procedury pamiętane,
których nazwy rozpoczynają się od ciągu znaków

sp_

, przechowywane są

w nadrzędnej (

master

) bazie danych. Istnieje wiele powodów, dla których należy

unikać przechowywania obiektów użytkownika w bazie danych typu

master

.

Dlatego, decydując się na dodatkowy wyróżnik nazw procedur pamiętanych,
należy dodawać

_sp

na końcu nazwy.

Tworząc nazwy procedur pamiętanych, można stosować z powodzeniem te same
zasady, które obowiązywały w nazewnictwie modułów (units) języka Object
Pascal. Pierwszy znak identyfikuje zatem aplikację, do której należy procedura. Po
nim następuje trzy- lub sześcioliterowy ciąg, opisujący ogólne i specyficzne
funkcje procedury. Nazwę kończy jedno- albo dwucyfrowy numer kolejny wersji.

Zatem procedura, która sporządza listę na podstawie tabeli CALLS w systemie
zarządzania wynajmem (Rental Maintenance Management System), nazywałaby
się

RCALLST0

. Litera R identyfikuje system, do którego należy procedura, CAL

wskazuje na związek procedury z tabelą CALLS, LST oznacza, że procedura
sporządzi listę na podstawie tabeli, a cyfra 0 wskazuje, że jest to pierwsza
procedura z serii kilku podobnych.

UWAGA:

Systemy Sybase i Oracle dopuszczają nadawanie jednej bazowej nazwy kilku
procedurom pamiętanym. W systemie Oracle wybór właściwej procedury realizuje
się wówczas za pośrednictwem mechanizmu przeciążania. W przypadku systemu
Sybase za nazwą procedury umieszcza się średnik i numer kolejny procedury
zapamiętanej pod daną nazwą. Należy unikać stosowania powyższych
mechanizmów. Bywają one trudne do opanowania i potencjalne korzyści z ich
stosowania nie rekompensują związanych z nimi utrudnień i pomyłek.

Pakiety

Pakiety, będące zbiorami procedur i funkcji pamiętanych, powinny być nazywane
podobnie jak te procedury i funkcje. Nazwy należy zapisywać małymi literami.
Pierwszy znak identyfikuje aplikację, do której należy pakiet. Po nim następuje
trzy- lub sześcioliterowy ciąg, opisujący ogólne i specyficzne funkcje pakietu.
Nazwa kończy się literą

p

, zajmującą miejsce numeru kolejnego wersji procedury.

108

Część I

Reguły

Jeśli stosowany serwer obsługuje reguły (ang. rules), to należy nadawać im nazwy
o charakterze opisowym i stosować zarówno duże, jak i małe litery. Należy także
zdecydować, czy nadawane nazwy mają określać zbiór danych, który reguła
wyklucza, czy też zbiór, który reguła dopuszcza., Jeśli stosowane nazwy mają
określać zbiór danych dopuszczalnych, to reguła wykluczająca wprowadzenie
wartości zerowej nazywałaby się NonZero. Analogicznie reguła, wymuszająca
wpisanie w pole Płeć jednej z dwóch wartości: K albo M, mogłaby się nazywać
KobietaMezczyzna. Zapytania SQL rzadko zawierają bezpośrednie odwołania do
reguł, dlatego też ich nazwy nie mają większego znaczenia. Reguły należą ponadto
do obiektów, które rzadko tworzone są przy pomocy oddzielnych skryptów SQL.
Nie ma zatem powodu, by ograniczać długość ich nazw do ośmiu znaków.

Wartości domyślne

Jeśli stosowany serwer dopuszcza stosowanie obiektów, reprezentujących wartości
domyślne kolumn, to w ich nazwie należy zawrzeć identyfikator pola, któremu
odpowiadają (jeśli odpowiadają tylko jednemu polu), a także wpisywaną przez nie
wartość domyślną. Nazwy powinny być zapisywane zarówno małymi, jak i dużymi
literami. Na przykład, wartość domyślna, skojarzona z polem Sex i automatycznie
wpisująca w to pole F, powinna nazywać się SexFemale. Zapytania SQL rzadko
zawierają bezpośrednie odwołania do wartości domyślnych, dlatego też ich nazwy
są mało istotne. Wartości domyślne należą do obiektów, których na ogół nie
tworzy się przy pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by
ograniczać długość ich nazw do ośmiu znaków.

Domeny

Domeny (definiowane przez użytkownika typy danych) pełnią rolę zbliżoną do
typów danych w języku Object Pascal. Dlatego można stosować do nich podobne
reguły nazewnictwa. Nazwa domeny powinna pochodzić od nazwy kolumny,
której zawartości domena dotyczy. Ponadto na początku nazwy domeny należy
umieścić literę T, podobnie jak w nazwach typów danych języka Object Pascal. Na
przykład, domena definiująca kolumnę CustomerNo, nosić będzie nazwę
TCustomerNo. Taka nazwa niesie informację, że domena definiuje kolumnę
CustomerNo, a ponadto pozwala w poleceniu

CREATE

TABLE

odróżnić domenę

od wbudowanych typów danych. Domeny należą do obiektów, które rzadko
tworzone są przy pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by
ograniczać długość ich nazw do ośmiu znaków.

Konwencje

109

Więzy i wyjątki

Więzy i wyjątki powinny nosić nazwy o formie zbliżonej do komunikatów. Nazwy
takie pozwalają na szybką identyfikację problemu, który spowodował naruszenie
więzów albo wygenerowanie wyjątku. U źródeł przyjęcia takiej konwencji
nazewnictwa leży konieczność poinformowania użytkownika o problemie za
pośrednictwem samej tylko nazwy obiektu - w przypadku niektórych narzędzi nie
można bowiem liczyć na przekazanie pełnego komunikatu z

serwera (w

szczególności dotyczy to komunikatów, dotyczących naruszenia więzów).
Narzędzia te zwracają ponadto nazwy zapisane dużymi literami, niezależnie od
formy, w jakiej przechowywane są one w bazie danych. Należy zatem unikać
stosowania w nazwach różnej wielkości liter. Przykładowo ograniczenie klucza
obcego, zapewniające wprowadzenie poprawnego numeru klienta, mogłoby nosić
nazwę

INVALID_CUSTOMER_NO

. Jeśli nastąpi naruszenie ograniczenia,

a narzędzie po stronie użytkownika przekazuje z serwera przynajmniej nazwy
naruszonych więzów, to użytkownik uzyska podstawową informację o źródle
problemu. Ta sama zasada powinna obowiązywać w nazewnictwie wyjątków,
chociaż w tym przypadku można spodziewać się, że narzędzie interfejsu front-end
wyświetli opis wyjątku, a nie jego nazwę. Więzy i wyjątki również należą do
obiektów, które rzadko tworzone są przy pomocy oddzielnych skryptów SQL. Nie
ma zatem powodu, by ograniczać długość ich nazw do ośmiu znaków.

Generatory i sekwencje

Podobnie jak nazwy domen, także nazwy generatorów i sekwencji powinny
pochodzić od nazw obsługiwanych kolumn. Na końcu nazw można dodać ciąg
znaków

GEN

albo

SEQ

. Generator, obsługujący kolumnę CustomerNo, będzie więc

nosił nazwę CustomerNoGEN. Sekwencja, skojarzona z kolumną OrderNo,
nazywać się będzie OrderNoSEQ. Generatory i sekwencje należą do obiektów,
których na ogół nie tworzy się przy pomocy oddzielnych skryptów SQL. Nie ma
zatem powodu, by ograniczać długość ich nazw do ośmiu znaków.

Kursory

Nazwy kursorów odpowiadają zazwyczaj nazwom tabel, na których operują.
Celowe jest ponadto rozróżnienie kursorów, które umożliwiają uaktualnianie
danych od kursorów, które takiej możliwości nie dają. Rozróżnienie takie można
uzyskać dodając do właściwego identyfikatora słowo

UPDATE

(uaktualnienie)

albo

SELECT

(selekcja).Taj więc kursor zadeklarowany dla tabeli TENANT,

umożliwiający uaktualnienia i

usuwanie rekordów mógłby nazywać się

TENANT_UPDATE. Z

kolei kursor odwołujący, wskazujący na tabelę

110

Część I

PROPERTY, i

nie pozwalający na uaktualnienia danych, nosiłby nazwę

PROPERTY_SELECT.

Procedury zdarzeń (triggers)

Nazwy procedur zdarzeń powinny zawierać identyfikatory skojarzonych z nimi
tabel oraz poleceń SQL, które powodują ich uaktywnienie. Procedura zdarzenia
może być uaktywniana w

trakcie wykonywania komend SQL

INSERT,

UPDATE albo DELETE

, a zatem lista komend uaktywniających, zawarta

w nazwie, będzie stanowiła kombinację słów Insert, Update i Delete. I tak
procedura zdarzenia uaktywniana po dodaniu lub aktualizacji wiersza w tabeli
TENANT będzie nazywał się TENANTInsertUpdate, natomiast inna, uaktywniana
po usunięciu rekordu z

tabeli WORDERS, mogłaby nosić nazwę

WORDERSDelete.

Jeśli serwer pozwala zdecydować, czy procedura zdarzenia (trigger) ma być
uaktywniana przed czy po jednym z wymienionych zdarzeń, to nazwa może
dodatkowo zawierać modyfikator Before (przed) albo After (po). Na przykład
nazwa PROPERTYBeforeDelete (albo PROPERTY_BEFORE_DELETE) będzie
identyfikowała procedure zdarzenia, uaktywnianą przed wykonaniem polecenia

DELETE

na tabeli PROPERTY.

Niektóre platformy pozwalają określić, czy procedura zdarzenia odnosi się do
wiersza czy taż do wyrażenia. W takich przypadkach nazwę można uzupełnić literą

R

albo

S

, np. PROPERTY_BEFORE_ DELETE_S. Taki zapis identyfikuje typ

procedury zdarzenia i skojarzoną z nim tabelę.

Procedury zdarzeń (triggers) należą do obiektów, które rzadko tworzone są przy
pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by ograniczać długość
ich nazw do ośmiu znaków.

Kolumny

Kolumny są najczęściej spotykanymi elementami zapytań SQL, dlatego
szczególnie istotne jest nadawanie im nazw o charakterze opisowym. W zapisie
nazw kolumn należy stosować zarówno duże, jak i małe litery. Nazwy te powinny
być łatwe do wymówienia i zapamiętania. Jeśli konfiguracja serwera zakłada brak
rozróżnienia między dużymi a

małymi literami, to poszczególne wyrazy

w nazwach kolumn powinny być oddzielone znakiem podkreślenia. Nie należy
nadmiernie skracać nazw kolumn - ktoś, kto za kilka lat zajmie się konserwacją
odpowiedniego programu w języku SQL, z pewnością doceni pełne, zrozumiałe
nazwy kolumn. Nazwa nie powinna pozostawiać wątpliwości co do roli danej
kolumny w bazie danych. Kolumny, które reprezentują te same jednostki w bazie
danych, takie jak

CustomerNo

(numer klienta), powinny nazywać się tak samo

Konwencje

111

we wszystkich tabelach. Decydując się na skracanie jakiegoś elementu nazwy, np.

Number

albo

Address

, należy zachować konsekwencję. Słowa

Number

nie

należy zapisywać raz jako No w nazwie

CustomerNo

, a raz jako Num, w nazwie

OrderNum

. Jako przykłady dobrze skonstruowanych nazw kolumn wymienić

można:

OrderNo, ShippingAddress, SampleWeight

czy

AverageWellDepth.

WSKAZÓWKA:

Jedną z ważniejszych korzyści, płynących ze stosowania opisowych nazw kolumn,
jest możliwość bezpośredniego wykorzystania etykiet, automatycznie wygene-
rowanych przez narzędzie programistyczne. Jeśli na przykład na formularz Delphi
przeciągnięte zostanie pole tabeli, to na formularzu generowana jest automatycznie
etykieta odpowiedniej kolumny. Etykieta zawiera od razu nazwę pola w bazie
danych. Jeśli nazwa ta jest zrozumiała, to prawdopodobnie automatycznie
wygenerowana etykieta będzie czytelna także dla użytkowników programu - nie
będzie trzeba ręcznie wpisywać nowej, bardziej opisowej. A zatem opisowe nazwy
kolumn nie tylko ułatwiają orientację w schemacie bazy danych - przyspieszają
także pracę nad aplikacją.

W tablicy 4.2 zebrano konwencje nazewnictwa obiektów serwera, omówione
w niniejszym rozdziale.