#189
9. Atrybuty pól

Od dawna twierdziłem, że drobne szczegóły mają na ogół największe znaczenie
Sherlock Holmes "Przygody Sherlocka Holmesa"
=====================================

Pola są fundamentem bazy danych. To one reprezentują podstawowe cechy tematów, jakimi zajmuje się dana organizacja. To one przechowują dane, które są następnie odczytywane i prezentowane w formie informacji - informacji kluczowych dla codziennego funkcjonowania i rozwoju organizacji. To one stanowią najczęściej pomijany, niedoceniany i zaniedbywany element bazy danych! Wprowadzaniu strukturalnej i logicznej integralności poszczególnych pól poświecą się zazwyczaj zbyt mało czasu, a czasem nie poświęca się go w ogóle.
Wiele się pisze i mówi o integralności danych, ale jakże mało się w tej dziedzinie robi. Spora grupa użytkowników istniejących baz sądzi, że jeśli będą uważnie wprowadzać nowe dane i zakupią "idiotoodporne" aplikacje bazodanowe, wówczas nic złego nie może się stać. To niedbalstwo wynika z utartego poglądu, zgodnie z którym wprowadzanie integralności danych jest zbyt pracochłonne. Zauważmy jednak, że ci sami ludzie, którzy nie mają czasu na definiowanie odpowiednich reguł poprawności, tracą go mnóstwo na naprawianie swoich nie przemyślanych struktur - zazwyczaj trwa to dwa do trzech razy dłużej, niż zaprojektowanie poprawnej bazy danych "od zera".
W tym rozdziale dowiesz się, jak wprowadzać integralność danych przez definiowanie atrybutów każdego pola w tworzonej bazie. Zaczniemy od szczegółowego omówienia wszystkich atrybutów, po czym przejdziemy do opisu wywiadów, jakie powinieneś przeprowadzić z pracownikami i kierownictwem organizacji. Wywiady te pomogą Ci w ustalaniu odpowiedniej specyfikacji dla każdego z pól.

Dlaczego atrybuty pól są ważne

W przeciwieństwie do ogólnie przyjętych poglądów, czas jaki zużyjesz na definiowanie atrybutów pól w projektowanej bazie jest inwestycją w przyszłą stabilność
#190
i efektywność tej bazy - w żadnym wypadku nie można go wiec nazwać czasem straconym. Co więcej, stratą czasu byłoby pominiecie lub nawet częściowe zaniedbanie tego procesu, ponieważ utworzona wówczas baza wymagałaby poważnych poprawek, a dostarczane przez nią informacje byłyby nieprecyzyjne lub nawet błędne.
Istnieje kilka powodów, dla których atrybuty pól mają duże znaczenie:
• Atrybuty stanowiÄ… podstawÄ™ do wprowadzenia integralnoÅ›ci na poziomie pól. Spójność i wiarygodność danych przechowywanych w poszczególnych polach można zagwarantować tylko przez poprawne zdefiniowanie atrybutów tych pól.
• Poprawne zdefiniowanie atrybutów pól zwiÄ™ksza ogólnÄ… integralność danych. PamiÄ™taj, że istniejÄ… cztery poziomy integralnoÅ›ci danych; jednym z nich jest integralność na poziomie pól. Ma ona (do pewnego stopnia) wpÅ‚yw na integralność na poziomie tabel, wprowadzonÄ… we wczeÅ›niejszej fazie procesu projektowania.
• Definiowanie atrybutów pól obliguje CiÄ™ do uzyskania gÅ‚Ä™bszego zrozumienia rodzajów i sposobu wykorzystywania danych, które bÄ™dzie przechowywać projektowana baza. Wiedza ta umożliwia Ci osÄ…dzenie, czy pewne dane sÄ… rzeczywiÅ›cie konieczne, oraz jak zdefiniować obsÅ‚ugujÄ…ce je struktury.
• Atrybuty pól majÄ… znaczenie podczas implementowania bazy w programie SZRBD. W fazie implementacji bÄ™dziesz mógÅ‚ wykorzystywać zdefiniowane wczeÅ›niej atrybuty jako podstawÄ™ do okreÅ›lenia wÅ‚aÅ›ciwoÅ›ci każdego z pól. PeÅ‚na lista atrybutów pól uÅ‚atwi osobie tworzÄ…cej aplikacjÄ™ bazodanowÄ… wprowadzenie odpowiednich reguÅ‚ poprawnoÅ›ci dla danych umieszczanych w bazie; reguÅ‚y te bÄ™dÄ… wynikać ze zdefiniowanych przez Ciebie atrybutów.
Pamiętaj, że stopień spójności, poprawności i dokładności danych przechowywanych w bazie jest wprost proporcjonalny do ilości pracy włożonej w definiowanie atrybutów pól. Jeśli funkcjonowanie organizacji, dla której projektujesz bazę danych, w dużym stopniu zależy od odczytywanych z tej bazy informacji, wówczas nie możesz zaniedbać tego etapu.
Integralność na poziomie pól
Dane pole cechuje integralność, jeśli zdefiniowano dla niego pełny zestaw atrybutów. Atrybuty gwarantują, że:
• tożsamość i cel każdego pola sÄ… oczywiste oraz że każde pole wystÄ™puje we wÅ‚aÅ›ciwych tabelach,
• definicje pól sÄ… spójne w caÅ‚ej strukturze bazy,
• wartoÅ›ci pól sÄ… poprawne i logiczne,
• rodzaje dozwolonych operacji na wartoÅ›ciach danego pola sÄ… jasno okreÅ›lone.
#191
Integralność wynikająca z wprowadzenia odpowiednich atrybutów, w połączeniu z integralnością będącą skutkiem spełnienia przez każde pole kryteriów pola doskonałego, stanowi gwarancje optymalności struktur pól. Jeśli na etapie definiowania poszczególnych pól pamiętałeś o egzekwowaniu ich zgodności z cechami pola doskonałego, wówczas określanie atrybutów powinno być proste.
Jeśli nadal nie jesteś pewien, czy któreś z pól spełnia warunki pola doskonałego, masz teraz okazję do ponownego przeanalizowania jego struktury. Jeśli stwierdzisz, że nie spełnia ono wymaganych warunków, wykorzystaj poznane wcześniej techniki do wprowadzenia odpowiednich poprawek, po czym uaktualnij listę struktur tabel. Dopiero wtedy możesz przystąpić do definiowania atrybutów poszczególnych pól. Dla wygody przypomnijmy cechy pola doskonałego:
Cechy pola doskonałego
• Reprezentuje cechÄ™ tematu danej tabeli.
• Zawiera pojedynczÄ… wartość.
• Nie można go rozbić na mniejsze części skÅ‚adowe.
• Nie zawiera wartoÅ›ci wyliczonej.
• Jest unikatowe w caÅ‚ej strukturze bazy danych.
• Ma identyczne cechy we wszystkich tabelach, w których siÄ™ pojawia.

Przekrój przez pole

Atrybuty pola to zbiór cech określających każdą jego własność. Cechy te dzielą się na trzy kategorie: atrybuty ogólne, atrybuty fizyczne oraz atrybuty logiczne. Istnieje też czwarta, oddzielna kategoria: specyfikacja. Takie pogrupowanie atrybutów ułatwia ich późniejszą obróbkę oraz umożliwia skoncentrowanie się na pojedynczym aspekcie analizowanego pola.
Oto cechy należące do każdej z czterech wymienionych kategorii:
• Atrybuty ogólne: nazwa pola, tabela-matka, oznaczenie, pozostaÅ‚e tabele, alias(y), opis.
• Atrybuty fizyczne: typ danych, dozwolone znaki, dÅ‚ugość, liczba miejsc dziesiÄ™tnych, maska wprowadzania, format wyÅ›wietlania. ; :
• Atrybuty logiczne: typ klucza, unikatowość, wartość wymagana, wartoÅ›ci zerowe, reguÅ‚a wprowadzania, dozwolone porównania, dozwolone operacje, źródÅ‚o wartoÅ›ci, wartość domyÅ›lna, zakres wartoÅ›ci.
• Specyfikacja: typ specyfikacji, oparte o istniejÄ…cÄ… specyfikacjÄ™, specyfikacja źródÅ‚owa.
#192
Rysunek 9.1 pokazuje przykładowy formularz służący do definiowania atrybutów pól. Zajmiemy się teraz szczegółowym omówieniem wszystkich jego elementów. W dalszej części książki opisując definiowanie atrybutów pól będziemy zawsze korzystać z przedstawionego tu formularza.

Atrybuty pola

Atrybuty ogólne _______________________________________________________________
Nazwa pola: Tabela-matka:
Oznaczenie:
__________________________________________________________________________________
Pozostałe tabele: Alias(y):

__________________________________________________________________________________

Opis:

__________________________________________________________________________________

Atrybuty fizyczne_______________________________________________________________
Typ danych: Długość:
Dozwolone znaki: Liczba miejsc dziesiętnych:
|| Litery (A-Z) ||Dodatkowe (.,/$# %) Maska wprowadzania:
|| Cyfry (0-9) ||Specjalne (© ® ™ E) Format wyÅ›wietlania:
__________________________________________________________________________________

Atrybuty logiczne_______________________________________________________________
Typ klucza: ||Brak ||Podstawowy Dozwolone porównania:
|| Obcy ||Zastępczy ||To samo pole | ||= ||> ||>=
Unikatowość: ||Nieunikatowe ||Unikatowe ||Inne pola | ||nie= ||< ||<= Wartość wymagana: ||Nie ||Tak Dozwolone operacje:
Wartości zerowe: ||Dozwolone ||Zabronione ||To samo pole | ||+ ||x(razy)
Reguła wprowadzania:||Wprowadź teraz, modyfikacje dozwolone||Inne pola | ||- ||/(dziel) ||Wprowadź teraz, modyfikacje zabronione Źródło wartości:|| Użytkownik ||System
||Wprowadź później, modyfikacje dozwolone Wartość domyślna:
||Wprowadź później, modyfikacje zabronione Zakres wartości:
__________________________________________________________________________________

_ Specyfikacja __________________________________________________________________
Typ specyfikacji: ||Unikatowa ||Wzorzec ||Replika
Oparta na istniejÄ…cej specyfikacji: ||Nie ||Tak
Specyfikacja źródłowa:
__________________________________________________________________________________

Rysunek 9.1. Formularz do definiowania atrybutów pól
#193
Atrybuty ogólne

Atrybuty ogólne stanowią zbiór najbardziej podstawowych własności pola. Dostarczają one informacji o celu istnienia pola, o zawierającej je tabeli (lub tabelach), oraz o pseudonimach, które pole to może - w pewnych okolicznościach - przybrać.

Nazwa pola

Nazwa pola jest jego unikatowym identyfikatorem. Jest to najmniejsza ilość słów wymagana do opisania danego pola. Tworzeniem i poprawianiem nazw pól zajmowaliśmy się już wcześniej (w rozdziale 7), na tym etapie nie ma więc konieczności ich dalszego udoskonalania. Wystarczy, że wpiszesz ustaloną nazwę pola w odpowiednią rubrykę.

Oznaczenie

Oznaczenie jest alternatywną nazwą pola, która może je identyfikować w programie SZRBD. Przykładowo oznaczeniem pola "Ilość na stanie" może być samo słowo "Ilość". Oznaczenia stanowią zazwyczaj skrócone wersje nazw pól i wykorzystuje się je do zaoszczędzenia miejsca na formularzach lub raportach oraz w przypadkach, kiedy większość użytkowników bazy danych jest przyzwyczajona do używania własnych nazw.
Unikaj pokusy wykorzystywania oznaczenia jako "oficjalnej" nazwy pola. Każde pole powinno posiadać dokładną i precyzyjną nazwę. Skrócenie tej nazwy znacznie zwiększyłoby prawdopodobieństwo wystąpienia pomyłek i błędnych interpretacji, a tego właśnie staramy się uniknąć.
Oznaczenia wykorzystuje się zazwyczaj jedynie podczas tworzenia aplikacji obsługującej bazę danych. Czasem jednak ich użycie okazuje się konieczne również na etapie projektowania, ze względu na przyzwyczajenia pracowników organizacji. Pamiętaj jednak o różnicy między oznaczeniem a nazwą pola.

Tabela-matka

Każde pole reprezentuje pewną cechę tematu pewnej tabeli. Tabela ta jest określana jako tabela-matka tego pola i jest to jedyna tabela, w której pole to powinno się pojawić. (Może ono występować również w innych tabelach, pod warunkiem że łączy ze sobą tabele-podzbiory lub jest wykorzystywane do utworzenia relacji.)

Pozostałe tabele

Ta rubryka powinna zawierać nazwy pozostałych tabel, w których występuje dane pole. Pamiętaj, że mogą to być wyłącznie tabele znajdujące się w relacji z jego tabelą-matką. Przykładowo, tabelą-matką pola "ID pracownika" jest tabela "Pracownicy". Pole to pojawia się jednak również w tabeli-podzbiorze "Pracownicy (pół etatu)".
#194
W tym wypadku "ID pracownika" łączy tabelę podzbiór ("Pracownicy (pół etatu)") z tabelą-matką ("Pracownicy").

Alias(y)

Alias to nazwa, którą dane pole może przyjmować w pewnych bardzo rzadkich okolicznościach. Przykładem sytuacji wymagającej zdefiniowania aliasu jest konieczność utworzenia w którejś z tabel dwóch identycznych pól. Załóżmy, że członkowie organizacji są przyzwyczajeni do identyfikowania poszczególnych pracowników za pomocą ich numerów identyfikacyjnych (przechowywanych w polu "ID pracownika"). Rozważmy tabelę , JFilie", przedstawioną na rysunku 9.2 (jest to tylko fragment jej struktury).

Struktury tabel

Filie
ID filii
Nazwa filii.
ID pracownika I
D pracownika
Telefon filii

Rysunek 9.2. Tabela wymagająca powtórzenia jednego z pól

Każda filia posiada swojego prezesa oraz wiceprezesa. Obie te osoby muszą zostać wymienione w tabeli ze względu na zajmowane przez nie stanowiska. Każdy pracownik jest identyfikowany przez swój numer identyfikacyjny. Zakładając, że postępujemy zgodnie z zasadami poprawnego projektowania, tabela "Filie" nie może zawierać dwóch wystąpień pola "ID pracownika". Mimo wszystko organizacja wymaga od nas umieszczenia w tej tabeli identyfikatorów obu prezesów. Jedynym rozwiązaniem jest nadanie drugiemu wystąpieniu pola "ID pracownika" aliasu, na przykład "ID wiceprezesa". Po zastąpieniu nazwy jej aliasem struktura tabeli znów będzie poprawna: prezesa filii będzie reprezentować pole "ID pracownika", a wiceprezesa - pole "ID wiceprezesa". (Dla zachowania przejrzystości można również zastąpić pierwszą nazwę "ID pracownika" aliasem "ID prezesa", nie jest to jednak konieczne). Poprawioną tabelę widzimy na rysunku 9.3.

Mimo iż wykorzystanie aliasu w opisanych okolicznościach jest dopuszczalne, powinieneś zachować ostrożność, ponieważ aliasy sprawiają problemy w obsłudze i operacjach oraz mogą zaciemnić rzeczywiste znaczenie danego pola. To z kolei prowadzi do nieporozumień przy interpretacji danych. Temat ten rozwiniemy szerzej podczas omawiania relacji.
#195
Struktury tabel

Filie
ID filii
Nazwa filii
ID pracownika
ID wiceprezesa
Telefon filii

Rysunek 9.3. ZastÄ…pienie drugiego wystÄ…pienia nazwy "ID pracownika" przez alias "ID wiceprezesa"

Opis

Opis stanowi całościową interpretację znaczenia pola. Najważniejszą korzyścią z tworzenia opisów pól jest to, iż czynność ta obliguje Cię do starannego przemyślenia natury danych, jakie pola te mają przechowywać. Jeśli masz kłopoty ze sformułowaniem odpowiedniego opisu, może to oznaczać konieczność wprowadzenia pewnych poprawek do struktury bazy.
We wcześniejszej fazie procesu projektowania dowiedziałeś się, jak tworzyć poprawne opisy tabel. Istnieje również zestaw zasad związanych z formułowaniem opisów pól.

Zasady tworzenia opisów pól

• Użyj sformuÅ‚owania precyzyjnie okreÅ›lajÄ…cego cel istnienia danego pola. Opis pola powinien uzupeÅ‚niać jego nazwÄ™, definiujÄ…c przeznaczenie zawartych w nim danych. Powinien również omawiać rolÄ™ peÅ‚nionÄ… przez to pole w zawierajÄ…cej je tabeli lub jego zwiÄ…zek z jej tematem. Oto przykÅ‚ad poprawnie sformuÅ‚owanego opisu:
"'Miasto kli.' - miasto, w którym dany klient mieszka lub prowadzi interesy. Jest to integralny składnik pełnego adresu klienta".
• Postaraj siÄ™, aby opis byÅ‚ krótki i zwiÄ™zÅ‚y. Opis pola powinien być wolny od mylÄ…cych sformuÅ‚owaÅ„ lub niezrozumiaÅ‚ych wyrażeÅ„. Staraj siÄ™ oddać znaczenie danego pola, używajÄ…c jak najmniejszej iloÅ›ci słów. Jak zauważyliÅ›my przy okazji tworzenia opisów tabel, rozwlekÅ‚e sformuÅ‚owania mogÄ… być trudne w zrozumieniu,
• Unikaj opisywania samej tylko nazwy pola. Nie wyjaÅ›nia to w żaden sposób jego przeznaczenia. PamiÄ™taj, że opis pola powinien przede wszystkim dostarczać
#196
użytkownikowi pełnej interpretacji celu jego istnienia. Poniższe zdanie nie stanowi więc poprawnego opisu:

"'Nazwisko kli.' - nazwisko każdego z klientów".

Oto lepszy sposób na opisanie tego pola:

"'Nazwisko kli.' - aktualne nazwisko klienta, wykorzystywane przez nas w oficjalnej korespondencji i kontaktach z tym klientem".

• Unikaj stosowania żargonu technicznego, akronimów lub skrótów. Pomimo iż niektórzy czÅ‚onkowie organizacji mogÄ… je rozumieć, jest maÅ‚o prawdopodobne, że bÄ™dÄ… one przejrzyste dla wszystkich zainteresowanych osób. Opis pola powinien być zrozumiaÅ‚y dla każdego, kto go czyta. Unikaj wiÄ™c nastÄ™pujÄ…cych sformuÅ‚owaÅ„:

"'ID pracownika' - unikatowa liczba identyfikująca każdego pracownika w organizacji. Stanowi ona składnik NPU".

Nie ma prostego sposobu, żeby się dowiedzieć, co znaczy akronim "NPU". Można go, rzecz jasna, rozwinąć. Lepiej jednak zmienić formułę opisu.
• Nie umieszczaj w opisie informacji zależnych od implementacji. Nie ma powodu do umieszczania w opisie informacji o formularzach czy elementach kodu programu, w których pojawia siÄ™ dane pole. Informacje te znajdujÄ… zastosowanie dopiero przy implementacji gotowego projektu.
• Nie uzależniaj opisu któregoÅ› pola od opisów innych pól. Każdy opis powinien stanowić niezależnÄ… i odrÄ™bnÄ… caÅ‚ość. Zignorowanie tej zasady może prowadzić do zamieszania. Staraj siÄ™ wiÄ™c unikać opisów w rodzaju:

"'Minimalny stan' - najmniejsza liczba egzemplarzy danego produktu, poniżej której należy złożyć ponowne zamówienie. (Patrz opis pola "Ilość na stanie")".

• Nie używaj przykÅ‚adów. Jak wiesz z rozdziaÅ‚u 7, przykÅ‚ady wymagajÄ… informacji uzupeÅ‚niajÄ…cych. Dla zachowania zwiÄ™zÅ‚oÅ›ci i przejrzystoÅ›ci opisu dobrze jest wiÄ™c z nich zrezygnować.
Rysunek 9.4 pokazuje wypełnioną sekcję atrybutów ogólnych przedstawionego wcześniej formularza dla pola "ID pracownika".

Atrybuty fizyczne

Atrybuty fizyczne to elementy struktury pola. Na etapie projektowania bazy danych formułuje się je dość ogólnie, ponieważ ich implementacja zależy w znacznym stopniu od programu SZRBD. Definiując cechy fizyczne każdego z pól, możesz zagwarantować jednakową reprezentację identycznych pól w całej strukturze bazy oraz ułatwić późniejsze utworzenie aplikacji bazodanowej w programie SZRBD.
#197
Atrybuty ogólne _____________________________________________________________
Nazwa pola: IDpracownika Tabela-matka: Pracownicy
Oznaczenie: Pracownik #
_____________________________________________________________________________
Pozostałe tabele: Pracownicy (pół etatu) Alias(y):
Klienci
_____________________________________________________________________________
Opis: Unikatowa liczba identyfikująca każdego pracownika wewnątrz organizacji.Identyfikator ten jest przydzielony pracownikowi w dniu przyjęcia go do pracy 1 i pozostaje z nim przez cały okres zatrudnienia.

Rysunek 9.4. Sekcja atrybutów ogólnych dla pola "ID pracownika"

Typ danych

W rubryce "typ danych" powinieneś podać rodzaj wartości, jakie dane pole będzie przechowywać. Najczęstszymi typami danych są:
• Alfanumeryczny - dowolna kombinacja liter i cyfr oraz znaków dodatkowych i specjalnych. Znaki dodatkowe to na przykÅ‚ad kropka, przecinek, znak dolara, nawias czy wykrzyknik. Znaki specjalne to symbole takie jak R w kółku, TM czy Pi.
• Numeryczny - wyÅ‚Ä…cznie liczby; caÅ‚kowite lub rzeczywiste. Liczby poprzedzone zbÄ™dnymi zerami (na przykÅ‚ad 0000234) nie sÄ… dopuszczane.
• Data - każda poprawna data. Zakres dat uznawanych za poprawne zależy od programu SZRBD implementujÄ…cego bazÄ™ danych.
• Czas - każda poprawna godzina. Sposób wprowadzania czasu (dostÄ™pne formaty, system dwunaste- lub dwudziestoczterogodzinny itp.) zależy od programu SZRBD implementujÄ…cego bazÄ™ danych.

Dozwolone znaki

Ten atrybut mówi, jakie znaki można umieszczać w danym polu. Ograniczenie to poprawia integralność na poziomie pól i zapobiega wprowadzaniu bezsensownych danych. Można dopuścić lub zakazać użycia następujących grup znaków:
• Liter - wszystkich liter alfabetu, Å‚Ä…cznie ze znakami diakrytycznymi, np.: "Å›", "Å‚", "e" czy "ii".
• Cyfr-od 0 do 9.
• Znaków dodatkowych - wszystkich znaków nie bÄ™dÄ…cych literami ani cyframi, które można wprowadzić z klawiatury - na przykÅ‚ad wykrzyknika, przecinka czy znaku dolara. PrzykÅ‚ady znaków dodatkowych sÄ… podane na przedstawionym wczeÅ›niej formularzu atrybutów pola.
• Znaków specjalnych - wszystkich symboli, których nie można wprowadzić bezpoÅ›rednio z klawiatury bez użycia specjalnego oprogramowania. Znaki specjalne
#198
to na przykład R w kółku, TM czy Pi.Przykłady takich znaków znajdują się na przedstawionym wcześniej formularzu atrybutów pola.
Załóżmy, że pracujesz nad polem "Stan kli." i określasz typ przechowywanych w nich danych jako alfanumeryczny. Typ taki dopuszcza, z definicji, stosowanie cyfr. Jednak wprowadzenie cyfry do omawianego pola uczyniłoby jego wartość bezsensowną - w USA nie ma stanów, których nazwy zawierałyby cyfry. Chcesz więc, aby jedynymi znakami dopuszczalnymi w polu "Stan kli." były litery. (Kwestia poprawnej kombinacji liter zostanie szerzej omówiona podczas analizowania atrybutów logicznych pola).

Długość

Jest to maksymalna liczba znaków, jaką można wprowadzić do danego pola. Ilość ta zależy od programu SZRBD implementującego bazę danych. Maksymalną długość można odnieść do dowolnego typu danych, pamiętaj jednak, że niektóre programy SZRBD nie pozwalają na limitowanie długości pól numerycznych - długość ta wynika z typu przechowywanej liczby: liczba całkowita (integer), długa liczba całkowita (long integer), liczba rzeczywista (real) itp.

Liczba miejsc dziesiętnych

Jest to dopuszczalna liczba cyfr po przecinku w liczbie rzeczywistej. Określa ona wymaganą precyzję liczby. Wiele firm wymaga na przykład podawania wszystkich kwot pieniężnych z dokładnością do czwartego miejsca po przecinku.

Maska wprowadzania

Ten atrybut określa sposób, w jaki dane należy wprowadzać do pola. Umożliwia to zachowanie spójności między poszczególnymi rekordami. Istnieje wiele sposobów na wprowadzenie daty, jak chociażby "01/01/98", "01-01-98" czy "Ol-Sty-98". Aby uniknąć zamieszania, dobrze jest ustalić wymagany format podawania dat. Do tego właśnie służą maski wprowadzania.
Definiując maskę wprowadzania staraj się zachować możliwie największą ogólność, ponieważ sposób implementacji masek zależy od programu SZRBD. W przypadku daty przykładową maską może być "dd/mm/rr". Maska ta określa wymaganą kolejność elementów daty (dzień, miesiąc i rok), to, że elementy powinny być przedzielone slashami (/) oraz to, że każdy element może być reprezentowany najwyżej przez dwie cyfry.

Format wyświetlania

Ten element umożliwia określenie sposobu prezentacji zawartości danego pola. Wykorzystując formaty wyświetlania możesz zwiększyć przejrzystość wyprowadzanych danych. Kontynuując poprzedni przykład możemy zauważyć, że chociaż
#199
wszystkie daty wprowadzamy zgodnie z maską "dd/mm/rr", znacznie lepiej byłoby je wyświetlać w postaci sekwencji "1 stycznia 1998".
Definiując format wyświetlania staraj się zachować możliwie największą ogólność, ponieważ, tak jak w przypadku masek, jego implementacja zależy od programu SZRBD. Jeśli to konieczne, określ swoje wymagania pełnymi zdaniami. Załóżmy, że pracujesz nad polem "Nazwa firmy". Możesz zaznaczyć, że:

"Każde słowo powinno zaczynać się od dużej litery".

Rysunek 9.4 pokazuje wypełnioną sekcję atrybutów fizycznych przedstawionego wcześniej formularza dla pola "ID pracownika".

Atrybuty fizyczne
Typ danych: Długość: 4
Dozwolone znaki: Liczba miejsc dziesiętnych: 0
|| Litery (A-Z) || Dodatkowe (.,/$# %) Maska wprowadzania: ####
|| Cyfry (0-9) || Specjalne (©®™S) Format wyÅ›wietlania: 0000
(©®™S)-C w kółku,R w kółku,TM w indeksie górnym,symbol sigma
||-kratka(kwadracik
Rysunek 9.5. Sekcja atrybutów fizycznych dla pola "ID pracownika"

Atrybuty logiczne

Ta grupa cech opisuje logiczne własności pola. Atrybuty logiczne mówią, czy wartości danego pola powinny być unikatowe, kiedy należy je wprowadzać, kiedy można je modyfikować, jakie porównania i operacje można na nich przeprowadzać oraz jaki jest ich dozwolony zakres. Cechy te są bardzo ważne z punktu widzenia integralności danych.

Typ klucza

W tej rubryce powinieneś podać rolę pełnioną przez wartości w danym polu. Jak wiesz, wartości pola będącego kluczem podstawowym służą do identyfikowania każdego rekordu w tabeli, podczas gdy pola niekluczowe opisują jedynie cechy jej tematu. W rozdziale 10 dowiesz się więcej o kluczach obcych; powiemy również, kiedy dane pole należy oznaczyć jako klucz obcy na formularzu atrybutów pól.

Unikatowość

Ten atrybut mówi, czy wartości w danym polu mogą się powtarzać. Jeśli pole pełni funkcję klucza podstawowego, powinniśmy zakreślić kwadrat "unikatowe". W przeciwnym razie można zazwyczaj wybrać opcję "nieunikatowe". Zanim jednak dokonasz wyboru, zastanów się nad rodzajem wartości, jakie pole to będzie przechowywać i określ, czy wartości te będą mogły się powtarzać. Rozważmy dla przykładu tabelę "Wydziały" przedstawioną na rysunku 9.6.
#200
Struktury tabel

Wydziały
ID wydziału
Nazwa wydziału
ID pracownika

Rysunek 9.6. Czy wartości pola "ID pracownika" powinny być unikatowe?

W tym przypadku pole "ID pracownika" identyfikuje kierownika danego wydziału. Zakładając, że pojedyncza osoba może być w danej chwili kierownikiem tylko jednego wydziału, pole "ID pracownika" nie powinno zawierać powtarzających się wartości. Oznaczamy je więc na formularzu atrybutów pól jako "unikatowe".

Wartość wymagana

W tej rubryce zaznaczamy, czy użytkownik musi wpisać w dane pole jakąś wartość. Dla większości pól możesz zakreślić kwadrat "nie"; jeśli jednak któreś pole wchodzi w skład klucza podstawowego, wówczas musisz wybrać opcję "tak". Pamiętaj, że jedną z cech klucza podstawowego jest to, że zawsze musi on posiadać jakąś wartość. Kwadrat "tak" możesz zaznaczyć nawet wtedy, gdy dane pole jest polem niekluczowym - na przykład "Kod pocztowy kli." musi zawierać wartość, ponieważ kod ten jest wymagany do prowadzenia korespondencji z klientami.

Wartości zerowe

Jak pamiętasz z rozdziału 3, wartość zerowa ("Null") oznacza brak wartości lub wartość nieznaną. Atrybut "Wartości zerowe" decyduje o tym, czy dane pole może zawierać wartości zerowe. Jeśli mamy do czynienia z kluczem podstawowym lub zastępczym, wówczas należy - rzecz jasna - wybrać opcję "zabronione". (Kluczy zastępczych dotyczą te same zasady co kluczy podstawowych). Oprócz tego opcję "zabronione" należy zakreślić, jeśli w rubryce "Wartość wymagana" zaznaczyliśmy "tak"
Wartość "dozwolone" możemy zaznaczyć w przypadku pola takiego jak "Gmina kli.", ponieważ niektórzy klienci mogą nie wiedzieć, w jakich gminach mieszkają. Wartość pola może więc być tymczasowo nie znana - innymi słowy, klienci mogą być poproszeni o dostarczenie wymaganych informacji w późniejszym terminie. W większości przypadków jednak należy wybrać opcję "zabronione": podanie odpowiedniej wartości jest zazwyczaj konieczne.
#201
Pamiętaj, że wartość zerowa to nie to samo co "nic"; Null oznacza wartość brakującą lub nieznaną. Częstym błędem jest nie wypełnianie pól, które powinny zawierać sformułowania, takie jak "brak", "nie dotyczy", "brak odpowiedzi" itp. Jeśli wartości takie mogą się pojawić w którymś z pól, pamiętaj o umieszczeniu ich w spisie dopuszczalnych wartości dla tego pola. Nie szastaj wartościami zerowymi!

Reguła wprowadzania

Ten atrybut określa sposób wprowadzania i modyfikowania wartości w danym polu. Istnieją cztery możliwe opcje i tylko jedną z nich można zaznaczyć:
• Wprowadź teraz, modyfikacje dozwolone. Wartość pola musi zostać podana podczas tworzenia nowego rekordu. Wartość tÄ™ można zmieniać w dowolnej chwili.
• Wprowadź później, modyfikacje dozwolone. Wprowadzenie wartoÅ›ci do tego pola podczas tworzenia nowego rekordu jest opcjonalne. Nie oznacza to, że pole może zawierać wartość zerowÄ…; musisz je prÄ™dzej czy później wypeÅ‚nić. Po wypeÅ‚nieniu pola jego wartość może być dowolnie modyfikowana.
• Wprowadź teraz, modyfikacje zabronione. Wartość pola musi zostać podana podczas tworzenia nowego rekordu. WartoÅ›ci tej nie można modyfikować.
• Wprowadź później, modyfikacje zabronione. Wprowadzenie wartoÅ›ci do tego pola podczas tworzenia nowego rekordu jest opcjonalne. Nie oznacza to, że pole może zawierać wartość zerowÄ…; musisz je prÄ™dzej czy później wypeÅ‚nić. Po wprowadzeniu wartoÅ›ci nie można jej już jednak zmieniać.

Dozwolone porównania

Są to typy porównań, do jakich można wykorzystywać wartości danego pola. Istnieje sześć rodzajów porównań: równe (=), różne od (przekreślony znak równości), większe od (>), mniejsze od (<), większe lub równe (>=), oraz mniejsze lub równe (<=). Cecha "Dozwolone porównania" określa również, czy daną wartość można porównywać z innymi wartościami w tym samym polu oraz z wartościami innych pól w tabeli (lub w całej bazie danych) - opcje "To samo pole" i "Inne pola".
Atrybut ten umożliwia uniknięcia bezsensownych porównań. Załóżmy, że pracujesz nad polem "ID pracownika", zawierającego dane numeryczne. Pomimo iż porównanie "większy lub równy" jest dla takich danych zazwyczaj dopuszczalne, w tym wypadku jest ono jednak zbędne. Nie ma powodu dla przeprowadzania porównań w rodzaju:

"Czy wartość pola 'ID pracownika' w tabeli 'Pracownicy' jest większa lub równa wartości pola 'ID pracownika' w tabeli 'Pracownicy (Pół etatu)'?"

Podobnie nie ma sensu przeprowadzanie takich porównań pomiędzy różnymi rodzajami pól:
#202

"Czy wartość pola 'ID pracownika' w tabeli 'Pracownicy' jest większa lub równa wartości pola'Ilość na stanie'w tabeli'Produkty'?"

Celowe jest jednak wykorzystanie poniższego porównania do określenia, czy dany pracownik jest zatrudniony na cały etat, czy na pół etatu:

"Czy wartość pola 'ID pracownika' w tabeli 'Pracownicy' jest równa wartości pola 'ID pracownika' w tabeli 'Pracownicy (pół etatu)'?"

W pewnych wypadkach uzasadnione jest porównywanie ze sobą wartości pochodzących z różnych pól. Rozważmy pole "Data realizacji zamówienia". Poniższe porównanie ma sens:

"Czy aktualna wartość pola 'Data realizacji zamówienia' jest większa lub równa aktualnej wartości pola'Data złożenia zamówienia'?"

Rzecz jasna, data realizacji zamówienia nie powinna poprzedzać daty jego złożenia. Wykorzystując tę wiedzę, powinieneś zaznaczyć odpowiednie opcje w rubryce "Dozwolone porównania".
Pamiętaj, że do "Dozwolonych porównań", prawdopodobnie wrócisz później jeszcze raz, podczas wprowadzania relacji oraz reguł integralności.

Dozwolone operacje

Ten atrybut określa rodzaje operacji matematycznych, jakie można przeprowadzać na wartościach danego pola. Istnieją cztery możliwe operacje: dodawanie (+), odejmowanie (-), mnożenie (*) i dzielenie (/). (Można je również dowolnie łączyć.) Oprócz podania dozwolonych operacji należy określić, czy w operacjach tych dopuszczalne jest wykorzystywanie innych wartości z tego samego pola oraz wartości z pozostałych pól w bazie danych.
Wracając do przykładu z polem "ID pracownika", możemy stwierdzić, że przeprowadzanie jakichkolwiek operacji matematycznych z wykorzystaniem wartości tego pola nie ma sensu. Z drugiej strony, np. w przypadku "Daty realizacji zamówienia", niektóre operacje są celowe. Może na przykład zaistnieć potrzeba odjęcia "Daty złożenia zamówienia" od "Daty realizacji zamówienia" w celu obliczenia czasu, jaki upłynął między tymi dwoma zdarzeniami.
Określany na tym etapie zestaw dozwolonych operacji może jeszcze ulec zmianie podczas definiowania reguł integralności.
Ten atrybut mówi, skąd mają pochodzić wartości wprowadzane do danego pola. Albo będą one podawane ręcznie przez użytkownika, albo automatycznie, przez aplikację bazodanową (określaną w skrócie mianem "system"). Jeśli wybierzesz opcję "system", wówczas osoba konstruująca aplikację bazodanową będzie musiała podać
#203
pewien schemat, według którego aplikacja ta ma automatycznie generować nowe wartości.

Wartość domyślna

Wartość domyślna jest wykorzystywana w polach wymagających podania wartości, w przypadku gdy wartość ta nie jest dostępna w momencie tworzenia rekordu i kiedy wartości zerowe nie są dozwolone. Powinieneś rozważnie dobierać wartości domyślne - przede wszystkim muszą one mieć sens. "Polska" jest dobrą wartością domyślną dla pola "Państwo kli.", jeżeli większość klientów mieszka w tym właśnie kraju. Z drugiej strony, wartość domyślną "01/01/98" w polu "Data zatrudnienia" należy odrzucić, ponieważ jest ona całkowicie sztuczna i pozbawiona sensu. W tym wypadku lepiej jest tymczasowo skorzystać z wartości zerowej i wprowadzić odpowiednią datę zatrudnienia, kiedy tylko będzie ona dostępna.

Zakres wartości

Ten atrybut umożliwia nałożenie dodatkowych ograniczeń na wartości wprowadzane do pola. Dopuszczalny zakres można określić, podając jego dolne i górne ograniczenie ("1000 do 9999") lub wypisując wszystkie możliwe wartości ("Warszawa", "Kraków", "Wrocław", "Lublin"). Zakres wartości może należeć do jednej z trzech kategorii:
• Ogólny - wszystkie możliwe wartoÅ›ci, jakie mogÄ… wystÄ…pić w danym polu. PrzykÅ‚adowo, ogólny zakres wartoÅ›ci dla pola "MiesiÄ…c zÅ‚ożenia zamówienia" może stanowić listÄ™ wszystkich dwunastu nazw kolejnych miesiÄ™cy.
• IntegralnoÅ›ciowy - zbiór wartoÅ›ci oparty na roli danego pola w tworzeniu relacji miÄ™dzy tabelami. (TÄ… kategoriÄ… zajmiemy siÄ™ w rozdziale 10).
• Tematyczny - zbiór wartoÅ›ci wynikajÄ…cych z wymagaÅ„ stawianych przez organizacjÄ™. Organizacje czÄ™sto wymagajÄ… wprowadzenia dodatkowych ograniczeÅ„ do zbiorów dopuszczalnych wartoÅ›ci dla poszczególnych pól. PrzykÅ‚adowo, jeÅ›li dana organizacja prowadzi interesy wyÅ‚Ä…cznie na zachodnim wybrzeżu USA, jedynymi nazwami stanów, jakie bÄ™dzie można wprowadzić do pola "Stan kli.", bÄ™dÄ… "WA", "OR", "ID" i "MT". (Omówimy to szerzej w rozdziale 11).
Na tym etapie projektowania bazy danych interesują Cię tylko ograniczenia ogólne. Do atrybutu "Zakres wartości" wrócisz jeszcze dwa razy: podczas definiowania relacji między tabelami oraz przy wprowadzaniu reguł integralności.
Istnieją dwa słowa, których za wszelką cenę powinieneś unikać, definiując zakres wartości. Te słowa to "inne" oraz "różne". Oba sprawiają mnóstwo problemów; są nieprecyzyjne, więc nie posiadają praktycznego znaczenia, zawsze wymagają dodatkowych wyjaśnień, a ich użycie jest świadectwem lenistwa, ponieważ reprezentują zbiór wartości, dla których należałoby utworzyć odrębną tabelę. Obecność tych słów
#204
w opisie zakresu wartości pola oznacza konieczność ponownego przyjrzenia się temu polu, może ono bowiem wymagać dalszych modyfikacji.
Rysunek 9.7 pokazuje wypełnioną sekcje atrybutów logicznych przedstawionego wcześniej formularza dla pola "ID pracownika".

Atrybuty logiczne
|x|-kwadracik zaznaczony
|| -pusty
=/-rózny =przekreślone
| - oddzielenie
Typ klucza: || Brak || Podstawowy Dozwolone porównania:
|| Obcy || Zastępczy |X| To samo pole | |X|= ||> ||>=
Unikatowość:|| Nieunikatowe || Unikatowe || Inne pola | ||=/ ||< ||<=
Wartość wymagana: || Nie |X| Tak Dozwolone operacje:
Wartości zerowe: || Dozwolone|X| Zabronione || To samo pole | ||+ ||x
Reguła wprowadzania:|| Wprowadź teraz, modyfikacje dozwolone|| Inne pola| || ||
|| Wprowadź teraz, modyfikacje zabronione Źródło wartości: || Użytkownik || System
|| Wprowadź później, modyfikacje dozwolone Wartość domyślna:
|| Wprowadź później, modyfikacje zabronione Zakres wartości:

Rysunek 9.7. Sekcja atrybutów logicznych dla pola "ID pracownika"

Specyfikacja

Elementy w tej kategorii opisują ogólną specyfikację danego pola. Informacje tu zawarte pomagają w ujednolicaniu atrybutów podobnych do siebie pól.

Typ specyfikacji

Specyfikacja pola może należeć do jednej z trzech kategorii:
• Unikatowa. Ten rodzaj specyfikacji wykorzystywany jest tylko dla pola wskazanego przez "NazwÄ™ pola" w sekcji atrybutów ogólnych. Ustawienia wszystkich atrybutów odnoszÄ… siÄ™ bezpoÅ›rednio to tego pola.
• Wzorzec. Dana specyfikacja sÅ‚uży jako podstawa definiowania atrybutów innych pól w bazie danych. Utworzenie specyfiki wzorcowej umożliwia zachowanie spójnoÅ›ci atrybutów pól zawierajÄ…cych podobne wartoÅ›ci. Możesz, przykÅ‚adowo, utworzyć wzorcowÄ… specyfikacjÄ™ dla pola "Stan" i wykorzystać jÄ… przy definiowaniu atrybutów pól "Stan kli.", "Stan prac." oraz "Stan produc." Wszystkie trzy majÄ… identyczne przeznaczenie - przechowujÄ… nazwÄ™ któregoÅ› ze stanów USA; sÄ… jednak od siebie niezależne. Jedynym wymaganiem zwiÄ…zanym z tworzeniem specyfiki wzorcowej jest konieczność użycia ogólnej nazwy pola oraz zachowania możliwie dużej ogólnoÅ›ci przy definiowaniu poszczególnych atrybutów. Przyjrzyj siÄ™ przedstawionej na rysunku 9.8 wzorcowej specyfikacji dla pola "Stan".
#205
Atrybuty pola

Atrybuty ogólne _______________________________________________________________
Nazwa pola: Stan Tabela-matka:
Oznaczenie:
__________________________________________________________________________________
Pozostałe tabele: Alias(y):

__________________________________________________________________________________

Opis:Stan lub terytorium Stanów Zjednoczonych, w którym dana osoba lub organizacja zamieszkuje lub prowadzi interesy.

__________________________________________________________________________________

Atrybuty fizyczne_______________________________________________________________
Typ danych: Alfanumeryczny Długść: 2
Dozwolone znaki: Liczba miejsc dziesiętnych:nie dotyczy
|| Litery (A-Z) ||Dodatkowe (.,/$# %) Maska wprowadzania: AA
|| Cyfry (0-9) ||Specjalne (© ® ™ E) Format wyÅ›wietlania: duże litery
__________________________________________________________________________________

Atrybuty logiczne_______________________________________________________________
Typ klucza: |x|Brak ||Podstawowy Dozwolone porównania:
|| Obcy ||Zastępczy ||To samo pole | ||= ||> ||>=
Unikatowość: |x|Nieunikatowe ||Unikatowe ||Inne pola | ||=/ ||< ||<= Wartość wymagana: ||Nie |x|Tak Dozwolone operacje:
Wartości zerowe: ||Dozwolone |x|Zabronione ||To samo pole | ||+ ||x(razy)
Reguła wprowadzania:|x|Wprowadź teraz, modyfikacje dozwolone||Inne pola | ||- ||/(dziel) ||Wprowadź teraz, modyfikacje zabronione Źródło wartości:|x| Użytkownik ||System
||Wprowadź później, modyfikacje dozwolone Wartość domyślna:
||Wprowadź później, modyfikacje zabronione Zakres wartości: Skróty nazw stanów USA
__________________________________________________________________________________

_ Specyfikacja __________________________________________________________________
Typ specyfikacji: ||Unikatowa |x|Wzorzec ||Replika
Oparta na istniejÄ…cej specyfikacji: |x|Nie ||Tak
Specyfikacja źródłowa:
__________________________________________________________________________________

(©®™S)-C w kółku,R w kółku,TM w indeksie górnym,symbol sigma
|x|-kwadracik zaznaczony
|| -pusty
=/-rózny =przekreślone
| - oddzielenie

Rysunek 9.8. Źródłowa specyfikacja pola "Stan"

Zauważ, że wiele rubryk pozostało nie wypełnionych. Odpowiednie wartości wpiszesz dopiero w specyfikacjach opartych na powyższej specyfikacji źródłowej. Pozwoli Ci to na dokładne dopasowanie atrybutów do każdego z pól. Możesz również dowolnie modyfikować predefiniowane ustawienia. Przykładowo, atrybut "Zakres wartości" jest częstym obiektem poprawek odzwierciedlających zastosowanie danego pola.
#206
Replika. Dana specyfikacja stanowi kopię pewnej specyfikacji wzorcowej. Rubryki, które nie zawierały wartości w specyfikacji wzorcowej, tu zostały wypełnione danymi odpowiednimi dla opisywanego pola. Rysunek 9.9 przedstawia przykładową specyfikacje-replike dla pola "Stan prac.", opartą na specyfikacji "Stan".

Atrybuty pola

Atrybuty ogólne _______________________________________________________________
Nazwa pola: Stan.prac. Tabela-matka: Pracownicy
Oznaczenie:
__________________________________________________________________________________
Pozostałe tabele: Alias(y):

__________________________________________________________________________________

Opis:Stan lub terytorium Stanów Zjednoczonych, w którym dany pracownik zamieszkuje lub prowadzi interesy w naszym imieniu. Pole to wchodzi w skład pełnego adresupracownika

__________________________________________________________________________________

Atrybuty fizyczne_______________________________________________________________
Typ danych: Alfanumeryczny Długść: 2
Dozwolone znaki: Liczba miejsc dziesiętnych:nie dotyczy
|| Litery (A-Z) ||Dodatkowe (.,/$# %) Maska wprowadzania: AA
|| Cyfry (0-9) ||Specjalne (© ® ™ E) Format wyÅ›wietlania: duże litery
__________________________________________________________________________________

Atrybuty logiczne_______________________________________________________________
Typ klucza: |x|Brak ||Podstawowy Dozwolone porównania:
|| Obcy ||Zastępczy ||To samo pole | ||= ||> ||>=
Unikatowość: |x|Nieunikatowe ||Unikatowe ||Inne pola | ||=/ ||< ||<= Wartość wymagana: ||Nie |x|Tak Dozwolone operacje:
Wartości zerowe: ||Dozwolone |x|Zabronione ||To samo pole | ||+ ||x(razy)
Reguła wprowadzania:|x|Wprowadź teraz, modyfikacje dozwolone||Inne pola | ||- ||/(dziel) ||Wprowadź teraz, modyfikacje zabronione Źródło wartości:|x| Użytkownik ||System
||Wprowadź później, modyfikacje dozwolone Wartość domyślna: WA
||Wprowadź później, modyfikacje zabronione Zakres wartości: CA, ID, MT, OR, WA
__________________________________________________________________________________

_ Specyfikacja __________________________________________________________________
Typ specyfikacji: ||Unikatowa ||Wzorzec |X|Replika
Oparta na istniejÄ…cej specyfikacji: ||Nie |x|Tak
Specyfikacja źródłowa:
__________________________________________________________________________________

Rysunek 9.9. Specyfikacja-replika pola "Stan prac."
#207
Jak widać, atrybuty nie zdefiniowane w specyfikacji źródłowej (jak np. "Tabela--matka" lub "Wartość domyślna") posiadają już odpowiednie wartości. Ponadto niektóre rubryki uległy zmianom (np. "Opis" czy "Zakres wartości").

Oparta na istniejÄ…cej specyfikacji

Ta cecha mówi nam, czy któryś z atrybutów w danej specyfikacji stanowi kopię atrybutów innego pola. Jeśli typ specyfikacji został określony jako "Replika", wówczas musimy wybrać opcję "Tak". (Jak dowiesz się z rozdziału 10, istnieją sytuacje wymagające oparcia pewnych zestawów atrybutów na specyfikacjach "unikatowych"). W przeciwnym razie zazwyczaj należy zaznaczyć "Nie".

Specyfikacja źródłowa

W tej rubryce powinieneś wpisać nazwę specyfikacji wzorcowej, na której oparłeś zestaw atrybutów danego pola. (W pewnych przypadkach, opisanych w rozdziale 10, może się tu również znaleźć nazwa specyfikacji unikatowej.)
Rysunek 9.10 pokazuje wypełnioną sekcję specyfikacji przedstawionego wcześniej formularza dla pola "ID pracownika".

Specyfikacja
Typ specyfikacji: |x| Unikatowa || Wzorzec || Replika
Oparta na istniejÄ…cej specyfikacji: |x| Nie || Tak
Specyfikacja źródłowa:

Rysunek 9.10. Sekcja specyfikacji dla pola "ID pracownika"

Definiowanie atrybutów pól

Teraz, kiedy przypisałeś już wszystkie pola do odpowiadających im tabel i znasz funkcje poszczególnych atrybutów pól, możesz przystąpić do definiowania atrybutów dla każdego pola w projektowanej bazie danych. Proces ten może zabrać trochę czasu, pamiętaj jednak, że od tego zależy integralność na poziomie pól. Inwestujesz swój czas i wysiłek w zagwarantowanie bezbłędności struktury bazy. Rezultatem będzie efektywny i spójny projekt.
Aby upewnić się, że zdefiniowane atrybuty są poprawne, skorzystaj z pomocy pracowników i kierownictwa organizacji. Możesz od nich uzyskać cenne informacje, zwłaszcza przy określaniu atrybutów logicznych. Nie musisz, rzecz jasna, rozmawiać z każdym pracownikiem, ale postaraj się zebrać reprezentatywną grupę przedstawicieli organizacji, mających wiedzę o sposobie wykorzystywania przez nią danych. Ze względu na sporą ilość czasu, jaką zabiera omawiany etap, musisz odpowiednio rozplanować swoje spotkania.
#208
Przede wszystkim, nie spiesz się! Definiowanie atrybutów pól wymaga staranności i precyzji.
Za najlepsze podejście do opisywanego procesu uważam wstępne wypełnienie formularzy dla możliwie największej liczby pól, a następnie skonsultowanie się z członkami organizacji w celu ustalenia pozostałych atrybutów. Zacznij więc od przyjrzenia się każdemu polu w bazie danych i spróbuj samodzielnie określić jego atrybuty. Nie martw się, jeśli będą one niezbyt dokładne lub jeśli napotkasz trudności przy definiowaniu niektórych z nich - będziesz miał jeszcze sposobność przedyskutowania interesujących Cię atrybutów z uczestnikami organizowanych przez siebie wywiadów. Na wywiady te przyjdzie czas po samodzielnym przeanalizowaniu wszystkich pól.
Pierwszą sprawą, jaką powinieneś się zająć podczas spotkania wstępnego, jest wyjaśnienie jego uczestnikom, czym są atrybuty ogólne, fizyczne i logiczne. Upewnij się, że wszyscy rozumieją funkcje pełnione przez poszczególne atrybuty; im lepiej uczestnicy wywiadu zrozumieją temat dyskusji, tym więcej cennych informacji będziesz mógł od nich uzyskać. (Przy każdym kolejnym spotkaniu staraj się przypominać zebranym znaczenia poszczególnych atrybutów).
Następnie omów wszystkie zdefiniowane przez Ciebie do tej pory atrybuty. Spytaj uczestników dyskusji, czy proponowane ustawienia są poprawne. W niektórych przypadkach uzyskasz dodatkowe informacje, które mogą przesądzić o zmianie pewnych atrybutów. Przykładowo, jeden z uczestników wywiadu może sobie nagle przypomnieć, że dla omawianego pola zawsze istniał ustalony zestaw wartości. Wykorzystując tę informację, będziesz mógł wprowadzić odpowiednie poprawki do atrybutu "Zakres wartości". Pamiętaj o dokładnym omówieniu każdego atrybutu i, jeśli nikt nie zgłosi obiekcji, przejdź do następnego pola. Powtarzaj tę samą procedurę dla każdego pola w bazie danych.
Teraz dopiero możesz zacząć dyskusję na temat atrybutów, których nie byłeś w stanie określić samodzielnie. Staraj się zwracać do osób mających największą wiedzę o omawianym polu, ponieważ to one zazwyczaj znają prawidłowe wartości jego atrybutów logicznych. Po określeniu poprawnej wartości dla danego atrybutu, nanieś ją na formularz i przejdź do następnego pola. Powtarzaj tę samą procedurę aż do zdefiniowania wszystkich atrybutów dla każdego pola w bazie danych.
Powoli zbliżamy się do końca procesu projektowania bazy danych. W następnym rozdziale dowiesz się, jak wprowadzać relacje między tabelami. Relacje stanowią podstawę zdefiniowania perspektyw, które z kolei pozwalają na jednoczesne przeprowadzanie operacji na danych pochodzących z różnych tabel.
#209

Atrybuty pola

Atrybuty ogólne _______________________________________________________________
Nazwa pola: Opis produktu Tabela-matka: Produkty
Oznaczenie: Opis
__________________________________________________________________________________
Pozostałe tabele: Alias(y):

__________________________________________________________________________________

Opis: Szczegóły dotyczące danego produktu. Informacje te są przydatne przy sporządzaniu materiałów reklamowych i promocyjnych, które dostarczamy naszym klientom

__________________________________________________________________________________

Atrybuty fizyczne_______________________________________________________________
Typ danych: Alfanumeryczny Długość: 180
Dozwolone znaki: Liczba miejsc dziesiętnych: nie dotyczy
|| Litery (A-Z) |x|Dodatkowe (.,/$# %) Maska wprowadzania: nie dotyczy
|| Cyfry (0-9) |x|Specjalne (© ® ™ E) Format wyÅ›wietlania: nie dotyczy
__________________________________________________________________________________

Atrybuty logiczne_______________________________________________________________
Typ klucza: |x|Brak ||Podstawowy Dozwolone porównania:
||Obcy ||Zastępczy ||To samo pole | ||= ||> ||>=
Unikatowość: ||Nieunikatowe |x|Unikatowe ||Inne pola | ||=/ ||< ||<= Wartość wymagana: ||Nie |x|Tak Dozwolone operacje:
Wartości zerowe: ||Dozwolone |x|Zabronione ||To samo pole | ||+ ||x(razy)
Reguła wprowadzania:|x|Wprowadź teraz, modyfikacje dozwolone||Inne pola | ||- ||/(dziel) ||Wprowadź teraz, modyfikacje zabronione Źródło wartości:|x| Użytkownik ||System
||Wprowadź później, modyfikacje dozwolone Wartość domyślna: nie dotyczy
||Wprowadź później, modyfikacje zabronione Zakres wartości: nie dotyczy
__________________________________________________________________________________

_ Specyfikacja __________________________________________________________________
Typ specyfikacji: |x|Unikatowa ||Wzorzec ||Replika
Oparta na istniejÄ…cej specyfikacji: |x|Nie ||Tak
Specyfikacja źródłowa:
__________________________________________________________________________________
(©®™S)-C w kółku,R w kółku,TM w indeksie górnym,symbol sigma

Atrybuty logiczne
|x|-kwadracik zaznaczony
|| -pusty
=/-rózny =przekreślone
| - oddzielenie
Rysunek 9.11. Atrybuty pola "Opis produktu"
#210
STUDIUM PRZYPADKU

W poprzednim rozdziale przypisaliśmy wszystkie pola w bazie danych Krainy Rowerów Mike'a do odpowiadających im tabel. Czas na zdefiniowanie atrybutów dla poszczególnych pól. Zanim jednak ponownie spotkasz się z Mike'em i jego pracownikami, spróbuj określić możliwie najwięcej atrybutów samodzielnie. Żadna z projektowanych przez Ciebie tabel nie odbiega zbytnio od normy, a i same pola są stosunkowo proste, nie powinieneś wiec mieć z tym poważniejszych problemów. Rysunek 9.11 przedstawia listę atrybutów pola "Opis produktu" z tabeli "Produkty".

Czas teraz na spotkanie się z Mike'em i jego pracownikami w celu przedyskutowania określonych przez Ciebie atrybutów. Podczas spotkania okazuje się, że nikt nie zgłosił żadnych poprawek i wszyscy zgadzają się z Twoimi propozycjami. Masz jednak pytanie związane z polem "Kategoria" w tabeli "Produkty": nie jesteś pewien, co należy wpisać w rubryce "Zakres wartości". Odpowiedzi są mieszane: nikt nie jest w stanie podać pełnej listy kategorii. Decydujesz się więc na tymczasowe zastąpienie tego atrybutu ogólnym sformułowaniem. Rysunek 9.12 przedstawia poprawioną sekcję atrybutów logicznych pola "Kategoria".

Atrybuty logiczne_______________________________________________________________
Typ klucza: |x|Brak ||Podstawowy Dozwolone porównania:
||Obcy ||Zastępczy ||To samo pole | ||= ||> ||>=
Unikatowość: |x|Nieunikatowe ||Unikatowe ||Inne pola | ||=/ ||< ||<= Wartość wymagana: ||Nie |x|Tak Dozwolone operacje:
Wartości zerowe: ||Dozwolone |x|Zabronione ||To samo pole | ||+ ||x(razy)
Reguła wprowadzania:|x|Wprowadź teraz, modyfikacje dozwolone||Inne pola | ||- ||/(dziel) ||Wprowadź teraz, modyfikacje zabronione Źródło wartości:|x| Użytkownik ||System
||Wprowadź później, modyfikacje dozwolone Wartość domyślna: nie dotyczy
||Wprowadź później, modyfikacje zabronione Zakres wartości: każda poprawna nazwa kategorii
__________________________________________________________________________________

Rysunek 9.12. Sekcja atrybutów logicznych dla pola "Kategoria" w tabeli "Produkty"

Do spornego atrybutu wrócisz jeszcze podczas wprowadzania reguł integralności. Poradziwszy sobie chwilowo z problemem, możesz zakończyć wywiad i cały proces definiowania atrybutów pól.

Podsumowanie

Rozdział ten rozpoczęliśmy opisem roli pełnionej przez atrybuty pól. Wiesz już, jakie korzyści przynosi poprawne ich zdefiniowanie. Dowiedziałeś się, że atrybuty decydują o integralności na poziomie pól oraz poprawiają ogólną integralność danych.
#211
Wiesz również, że ich definiowanie obliguje Cię do bliższego przyjrzenia się sposobowi wykorzystywania danych przechowywanych w projektowanej bazie, co wpływa na lepsze zrozumienie jej struktury.
Następnie skoncentrowaliśmy się na opisie poszczególnych atrybutów. Omówiliśmy ich cztery podstawowe kategorie, oraz przedstawiliśmy przykładowy formularz służący do ich zapisywania. Dalej opisaliśmy każdą kategorię i atrybut z osobna. Wiesz teraz, że kategoria atrybutów ogólnych opisuje podstawowe cechy pola - między innymi jego opis, sformułowany w poprzednim rozdziale. Następnie przyjrzeliśmy się sekcji atrybutów fizycznych, opisujących strukturę analizowanego pola. Trzecią kategorią były atrybuty logiczne, które odnoszą się do wartości przechowywanych w tym polu. Poznałeś atrybuty, takie jak typ klucza, regułę wprowadzania oraz zakres wartości. Cały dział zamyka opis specyfikacji pola. Elementy tej sekcji służą wprowadzaniu i utrzymywaniu spójności i konsekwencji podczas definiowania atrybutów podobnych do siebie pól.
Rozdział zamykamy opisem sposobu definiowania atrybutów dla każdego pola w bazie danych. Dowiedziałeś się, że najlepszą metodą na zagwarantowanie poprawności i dokładności poszczególnych atrybutów jest skorzystanie z pomocy pracowników i kierownictwa organizacji. Powinieneś zacząć od własnego zdefiniowania możliwie największej ilości atrybutów, a następnie skonsultować się z członkami organizacji w sprawie pól, co do których masz wątpliwości.