Zgryźliwość kojarzy mi się z radością, która źle skończyła.
Rozdział 16.
Architektura baz danych widziana od strony Delphi
C:\Dokumenty\Roboczy\Delphi 4 dla kazdego\16.doc 681
Rozdzia³ 16. ¨ Architektura baz danych widziana od strony Delphi 681
W tym rozdziale zapoznasz się z programowaniem baz danych w Delphi. Jeżeli wcześniej nie miałeś styczności z programowaniem baz danych, na pierwszy rzut oka zagadnienie to może wydać się przytłaczające. Postaram się wyeliminować wszelkie nieścisłości przez zaprezentowanie klarownego wizerunku labiryntu znanego jako programowanie baz danych. Nasze rozważania zaczniemy od ogólnego spojrzenia na architekturę baz danych od strony Delphi. Następnie zajmiemy się niektórymi z komponentów dostępu do baz danych.
Nie miej złudzeń: programowanie baz danych jest naprawdę sprawą skomplikowaną. Z mojej strony otrzymasz stojącą na wysokim poziomie wiedzę z zakresu programowania baz danych w Delphi, nie ma tutaj jednak mowy o zagłębianiu się w każdy szczegół.
Nie wszystkie pojęcia i komponenty omawiane w tym rozdziale odnoszą się do każdej wersji Delphi. Wersja Professional posiada większe możliwości bazodanowe w porównaniu z wersją Standard, z kolei wersja Client/Server przewyższa je obie pod tym względem.
PodstawyZ programowaniem baz danych wiąże się cały zbiór specjalistycznych określeń: BDE, klient, serwer, ODBC, alias, SQL, zapytanie, procedura zapamiętana i wiele innych. Dobrą wiadomością jest to, że po zapoznaniu się z tymi terminami okazują się one całkiem proste. Zacznijmy od rozważań na temat samych baz danych. Kiedy słyszysz termin baza danych prawdopodobnie wyobrażasz sobie dane zapisane w formie tabeli. Tabela ta zawiera prawdopodobnie takie pola jak Imię, Nazwisko, Numer Telefonu itp. Pola wypełnione są danymi tworzącymi indywidualne rekordy w pliku bazy danych.
Jeżeli takie wyobrażenie przychodzi Ci do głowy na myśl o bazie danych, nie jesteś zbyt daleki od prawdy, chociaż określenie to nie jest to również całkowicie poprawne. Termin baza danych służy do określenia systemu obejmującego w sposób całościowy tworzenie i utrzymywanie danych. Prawdą jest, że baza może sprowadzać się do jednej tabeli, z drugiej jednak strony rzeczywiste implementacje baz danych zawierają dziesiątki lub nawet setki tabel z tysiącami lub milionami rekordów. Tabele te mogą zawierać jeden lub więcej indeksów. Kompletne rozwiązanie bazy danych SQL typu klient/serwer może również składać się z licznych zapytań i procedur zapamiętanych (niektóre z tych terminów zostaną omówione w dalszej części rozdziału). Jak więc widzisz, baza danych to coś więcej niż tylko tabela z danymi.
Zatrzymajmy się przez chwilę przy tabelach na nich i omówmy związane z nimi podstawowe zagadnienia. Tabela składa się przynajmniej z dwóch elementów: pól i rekordów. Pola są indywidualnymi kategoriami danych w tabeli. Przykładowo, tabela zawierająca spis adresów mogłaby składać się z takich pól jak Imie, Nazwisko, Adres, NumerTelefonu itd. Pola są również określane mianem kolumn. Rekordem w takim przypadku jest pełny adres osoby: imię, nazwisko, adres i inne. Rekordy są również nazywane wierszami.
Baza danych to po prostu zbiór danych, mimo tego dosyć często bazy danych są wyświetlane w formie przypominającej arkusz kalkulacyjny. Nagłówki kolumn wskazują nazwy pól. Każdy wiersz w tabeli reprezentuje kompletny rekord. Przykładowa baza danych w takim formacie przedstawiona została na rysunku 16.1.
Rysunek 16.1.
Typowa tabela bazy danych
Wskaźnik do bieżącego rekordu w ramach bazy danych nazywany jest kursorem.
Polecenie odczytu danych z tabeli odnosi się do jej bieżącego rekordu; podobnie – polecenie zapisania określonych danych (pochodzących na przykład z formularza edycyjnego) spowoduje zapis do bieżącego rekordu. Status bieżącego rekordu ulega przemieszczeniu do innych rekordów w następstwie poruszania się po tabeli, wstawiania lub usuwania rekordów itp.
Mówiąc, że kursor jest wskaźnikiem nie mam tutaj na myśli wskaźnika (ang. pointer) w sensie Object Pascala. Stwierdzam jedynie, że jest to element informujący o bieżącej pozycji rekordu.
Określona ilość danych zawracanych przez bazę danych nazywana jest zbiorem danych (ang. dataset)
Zbiór danych może być czymś więcej niż tylko zestawem danych zawartych w tabeli – może on być bowiem np. rezultatem zapytania zawierającym dane zebrane z wielu tabel. Przykładowo załóżmy, że posiadasz bazę danych zawierającą nazwiska i adresy klientów, ich zamówienia, oraz szczegóły każdego z tych zamówień. Dane te mogą być przechowywane w tabelach o nazwach Klienci, Zamówienia i Szczegóły Zamówień. Przyjmijmy teraz, że żądasz szczegółów dotyczących 10 ostatnich zamówień złożonych przez firmę X Dane zawierające te informacje mogą pochodzić z tabel Klienci, Zamówienia i Szczegóły Zamówień; mimo, że dane pochodzą z kilku różnych tabel, prezentowane są w postaci pojedynczej tabeli (której struktura nie znajduje odzwierciedlenia w żadnej z tabel źródłowych – przyp. red.).
Lokalne bazy danychNajprostszy typ bazy danych to lokalna baza danych. Lokalna baza danych jest bazą rezydującą na pojedynczym komputerze. Wyobraź sobie, że posiadasz program, który musi przechowywać listę nazwisk i adresów. Do przechowania tego typu danych można stworzyć bazę lokalną. Jej budowa oparta zostałaby prawdopodobnie na jednej tabeli, do której dostęp miałby jedynie Twój program; nikt inny nie posiadałby dostępu do niej. Wszelkie zamiany byłyby zapisywane bezpośrednio do bazy danych. Zwykle lokalnymi bazami danych są bazy tworzone przez takie aplikacje jak Access, dBASE, czy Paradox.
Bazy danych typu klient/serwerInnym sposobem implementacji bazy danych jest baza danych typu klient/serwer. Sama baza danych jest tworzona i utrzymywana na serwerze plików, dostęp zaś do niej posiada jeden lub więcej użytkowników (klientów) zazwyczaj rozproszonych po sieci. Ponieważ na ogół żaden z użytkowników‑klientów nie jest (a przynajmniej – nie musi być) świadom istnienia pozostałych, powstaje problem poprawnej obsługi bazy danych w warunkach jednoczesnych żądań kilku użytkowników – z którym to zadaniem uporać się musi właśnie serwer.
Użytkownicy baz typu klient/serwer niemal nigdy nie współpracują z bazą danych w sposób bezpośredni. Zamiast tego kontaktują się z nią poprzez aplikacje umieszczone na ich lokalnych komputerach. Aplikacje te, noszące nazwę aplikacji-klientów, zapewniają przestrzeganie określonych reguł i powstrzymywanie się od wykonywania operacji, które w tych warunkach nie powinny być przeprowadzane, pod groźbą uszkodzenia bazy.
Jedno‑, dwu‑ i wielowarstwowa architektura bazy danychLokalne bazy danych zazwyczaj nazywane są jednowarstwowymi bazami danych. Jednowarstwowa baza danych to tak baza w której dowolne zmiany – takie jak edycja danych, wstawianie lub usuwanie rekordów – wykonywane są natychmiastowo. Program posiada jedno bezpośrednie połączenie z bazą danych.
Serwery baz danych
Ponieważ zajmujemy się bazami danych typu klient/serwer, zatrzymajmy się na chwilę przy serwerach baz danych. Serwery baz danych dzielą się na kilka kategorii. Producentami najbardziej popularnych są między innymi InterBase (będący własnością firmy Borland), Oracle, Sybase, Informix i Microsoft. Kiedy pewna firma zakupuje serwer bazy danych, oprócz niego kupuje również licencję określającą maksymalną liczbę użytkowników, jaka może korzystać z serwera. Licencjonowani użytkownicy są często określani mianem stanowisk (ang. seats). Powiedzmy, że firma zakupuje serwer InterBase oraz licencję na 50 stanowisk. Jeżeli firma ta rozwinie się do tego stopnia, że dostępu do bazy danych wymagać będzie 75 użytkowników, firma będzie musiała rozszerzyć (czytaj – dokupić) licencję na dodatkowe 25 stanowisk. Inne rozwiązanie baz danych typu klient/serwer opiera się na połączeniach. Firma może zakupić licencję na 50 równoczesnych połączeń. W samej firmie może być 1000 użytkowników bazy danych, ale tylko 50 z nich może jednocześnie połączyć się z bazą danych. Bez wątpienia, rynek serwerów baz danych stanowi ogromny biznes
W dwuwarstwowej bazie danych aplikacja-klient porozumiewa się z serwerem bazy danych poprzez sterowniki bazy danych. Zarządzanie połączeniami bierze na siebie serwer, natomiast aplikacja-klient w większym stopniu odpowiada za wpisywanie do bazy prawidłowych informacji. Spory ciężar jest nakładany na aplikację-klienta, która musi zapewnić utrzymanie integralności bazy danych.
W wielowarstwowej architekturze typu klient/serwer, aplikacja-klient porozumiewa się z jedną lub kilkoma aplikacjami‑serwerami, które z kolei porozumiewają się z serwerem bazy danych. Owe pośrednie poziomy komunikacji nazywane są aplikacjami-serwerami, ponieważ udostępniają one określone usługi na rzecz aplikacji‑klientów. Jedna z aplikacji-serwerów może działać jako dostawca danych, reagujący na żądania danych zgłaszane przez klientów i przekazujący je do bazy danych. Inna aplikacja-serwer może zajmować się jedynie zagadnieniami związanymi z ochroną danych.
Aplikacje-klienci pracują na maszynach lokalnych; aplikacja-serwer jest zwykle umieszczana na serwerze, sama baza danych może znajdować się na jeszcze innym serwerze. Ideą architektury wielowarstwowej jest to, że zadania spełniane przez aplikacje-klientów mogą być bardzo ograniczone ze względu na fakt, iż większość pracy wykonują za nie aplikacje-serwery. Pozwala to na tworzenie tzw. aplikacji typu cienki-klient (ang. thin-client).
Innym powodem do zastosowania architektury wielowarstwowej jest zarządzanie zasobami programistów. Aplikacje-klienci mogą być tworzone przez mniej doświadczonych programistów, ponieważ aplikacje te współpracują z aplikacją-serwerem, która sama kontroluje bazę danych. Aplikacja-serwer może zostać napisana przez bardziej doświadczonego programistę, który zna zasady na jakich musi opierać się baza danych. Ujmując to inaczej, aplikacja-serwer jest tworzona przez programistów których zadaniem jest ochrona danych przed możliwymi uszkodzeniami powodowanymi przez niedoskonałe aplikacje-klientów.
Chociaż zawsze istnieją pewne wyjątki, większość lokalnych baz danych korzysta z architektury jednowarstwowej. Bazy danych typu klient/serwer oparte są na architekturze dwuwarstwowej lub wielowarstwowej.
Jaki ma to wpływ na Ciebie? Większość aplikacji jakie będziesz pisał na potrzeby baz danych typu klient/serwer będą aplikacjami-klientami. Chociaż może zdarzyć się tak, że staniesz się jedynym z kilku programistów, którzy otrzymają zadanie stworzenia aplikacji od strony serwera lub aplikacji warstwy pośredniej, ja będę jednak raczej obstawiał za tym, że w głównym stopniu będziesz tworzył aplikacje-klientów. Jako twórca oprogramowania nie możesz porozumiewać się z serwerami baz danych w sposób bezpośredni. O tym, jak aplikacja Delphi komunikuje się z bazą danych, mowa jest w następnej sekcji.
Borland Database EngineAby umożliwić dostęp do lokalnych baz danych jak i do baz typu klient/serwer, Delphi udostępnia mechanizm BDE (Borland Database Engine). Jest to zbiór bibliotek DLL oraz narzędzi umożliwiających dostęp do szeregu różnorodnych baz danych.
Porozumienie się z bazą danych typu klient/serwer wymaga posiadania Delphi w wersji Client/Server. Razem z tą wersją dostarczane są sterowniki połączeń SQL używane przez BDE do porozumiewania się z bazami danych klient/serwer. Związek między aplikacją, BDE i bazą danych przedstawiony został na rysunku 16.2.
Rysunek 16.2.
Relacja między
bazą danych,
BDE i aplikacją
Sterowniki BDE
Rzeczą oczywistą jest, że między formatami baz danych i ich interfejsami API zachodzą znaczne różnice. Z tego powodu BDE dostarcza zbiór sterowników umożliwiających aplikacji porozumiewanie się z różnymi typami baz danych. Sterowniki dokonują translacji poleceń baz danych wysokiego poziomu (takich jak open lub post) na polecenia specyficzne dla danego typu bazy. Dzięki temu aplikacja może łączyć się z bazą danych bez znajomości szczegółów jej funkcjonowania.
To, jakie sterowniki znajdują się w Twoim systemie, zależy od posiadanej przez Ciebie wersji Delphi. Wszystkie wersje Delphi udostępniają sterownik pozwalający na łączenie się z lokalnymi bazami danych typu Paradox i dBASE. Sterownik ten, o nazwie STANDARD, udostępnia wszelkie niezbędne środki do pracy z wymienionymi lokalnymi bazami danych.
Wersja Client/Server zawiera sterowniki pozwalające na łączenie się z bazami takimi jak Sybase, Informix, InterBase i inne.
Aliasy BDEW celu uzyskania dostępu do określonej bazy danych mechanizm BDE korzysta z tzw. aliasów. Jest to jeden z terminów który z początku może wydawać się niezrozumiały. Przy omawianiu BDE terminy alias i baza danych są często stosowane zamiennie.
Alias BDE to zbiór parametrów, które opisują połączenie z bazą danych.
Sięgając w głąb, niewiele można powiedzieć na temat aliasów. W swojej najprostszej formie, alias informuje BDE o typie sterownika jakiego należy użyć oraz o lokalizacji plików bazy danych na dysku. Są to rzeczy, które będziesz konfigurował w przypadku aliasów lokalnych baz danych. Jeżeli chodzi o bazy danych typu klient/serwer, alias zawiera również inne dane, takie jak maksymalny rozmiar danych BLOB, maksymalna liczba wierszy, tryb otwarty, czy nazwa użytkownika. Po utworzeniu aliasu dla bazy danych można używać go we własnych programach Delphi do wyboru określonej bazy danych. Jak tworzyć aliasy BDE dla własnych baz danych dowiesz się w dalszej części tego rozdziału w sekcji „Tworzenie a...