ITA-101 Bazy danych
Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski
DODATEK A
Wersja 1.0
Podstawy
Spis treści
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 2/11
Informacje o module
Opis modułu
W tym module zajmiemy się zebraniem najważniejszych informacji na
temat baz danych niezbędnych do zrozumienia i pełnego wykorzystania
dalszych modułów. Zebrane, najważniejsze pojęcia nie zastępują pełnego
wykładu na ten temat i nie zwalniają Cię z przestudiowania wykładu lub
podręcznika z zakresu baz danych. Mają one jedynie na celu zebrad
i utrwalid najważniejsze elementy potrzebne do wykonywania kolejnych
modułów. Zazwyczaj pierwsze zajęcia laboratorium są zajęciami
organizacyjnymi.
Cel modułu
Celem modułu jest utrwalenie i sprawdzenie rozumienia podstawowych
pojęd z baz danych oraz przygotowanie do pracy z kolejnymi modułami
kursu.
Uzyskane kompetencje
Po zrealizowaniu modułu będziesz:
rozumiał czym jest baza danych,
rozumiał na czym polega model relacyjnej bazy danych,
umiał swobodnie poruszad się wśród podstawowych pojęd baz
danych.
Wymagania wstępne
Ten moduł nie ma wymagao wstępnych. Możesz od razu rozpocząd pracę
z tym modułem.
Mapa zależności modułu
Przed przystąpieniem do realizacji tego modułu nie jest wymagane
zapoznanie się z materiałem zawartym w innych modułach.
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 3/11
Przygotowanie teoretyczne
Podstawy teoretyczne
Na pewno pojęcie bazy danych nie jest dla Ciebie nowe. Pewnie każdy korzystał też z jakiejś bazy
danych. Czy jednak zastanawiałeś się, co to jest baza danych? Od kiedy ludzie posługują się bazami
danych? Właśnie na te i inne podstawowe pytania dotyczące pojęcia baz danych spróbujemy
odpowiedzied w tym module.
Zastanów się, co rozumiesz pod pojęciem bazy danych, co to takiego? Zapisz swoje określenie,
a następnie porównaj z naszym.
Bazą danych (ang. database) będziemy nazywad trwały, zamknięty i dobrze zorganizowany
magazyn danych. Baza danych charakteryzuje się trzema ważnymi cechami: trwałością,
ograniczonością (zamkniętością) i dobrą organizacją (co dla kogo jest dobre jest rzeczą dyskusyjną
– postaramy się jednak sprecyzowad, co dla nas będzie oznaczad dobra organizacja magazynu).
Trwałość bazy danych
Trwałośd oznacza, że dane zapisane w bazie danych są w niej zapisane w sposób nieulotny. Nie
można zbudowad bazy danych w pamięci operacyjnej komputera, gdyż po dołączeniu zasilania
dane w niej zapisane są tracone. Na trwały magazyn danych dobrze natomiast nadaje się kamieo
(zapisy dokonane w kamieniu przetrwały tysiące lat), papier (ten nie jest już tak trwały) czy dyski
magnetyczne lub inne nośniki magnetooptyczne. Trwałośd danych zapisanych w bazie danych jest
bardzo ważnym postulatem. Wszystkie współczesne systemy baz danych muszą go spełniad.
Ograniczoność bazy danych
Ograniczonośd oznacza, że w bazie danych nie można zapisad zupełnie dowolnych danych. Baza
oparta jest na pewnym modelu rzeczywistości (modelu danych). Modele te mogą byd bardzo różne
i niektóre z nich pokrótce omówimy w dalszej części. Model danych definiowany jest przez
projektanta bazy danych. Określa on, w jaki sposób dane występujące w rzeczywistości (np. dane
adresowe studentów) będą reprezentowane w bazie. Przyjęty model ogranicza więc (determinuje)
dane, które możemy trwale przechowywad w bazie.
Dobra organizacja bazy danych
Aby zbiór danych można było uważad za bazę danych, musi on byd odpowiednio zorganizowany.
Organizacja ta musi zapewniad możliwośd nie tylko sprawnego umieszczania danych w bazie, ale
również możliwośd odszukiwania i odczytywania danych już w niej zapisanych. Jeśli więc znalezienie
danych zapisanych w magazynie wymaga od nas miesiąca przeglądania zapisanych danych, to taki
magazyn nie może byd uznany za bazę danych.
Baza danych to oczywiście każdy magazyn danych spełniający powyższe warunki. Ludzkośd
dostrzegła potrzebę tworzenia baz danych już bardzo dawno. J. Diamond w swojej książce Guns,
Germs and Steel: The Fastest of Human Societies twierdzi, że bazy danych istniały od czasów, kiedy
cywilizacja umeryjska i egipska zaczęły korzystad z pisma klinowego i hieroglifów do zapisu
informacji w formie trwałej i możliwej do odczytania na każde żądanie. Stosowane w tamtych
czasach nośniki danych były mało wygodne. Nasza cywilizacja przez całe wieki budowała swoje bazy
danych wykorzystując jako trwały nośnik danych papier. Bazy „papierowe” mają jednak bardzo
wiele wad, takich jak duże rozmiary magazynu, trudności w wyszukiwaniu danych, brak
wielodostępu itd. Do budowy i obsługi baz danych nadają się natomiast znakomicie maszyny
cyfrowe. Dzisiaj mówiąc „baza danych” mamy w zasadzie na myśli komputerowe bazy danych.
W dalszej części naszych wykładów pod pojęciem bazy danych będziemy więc rozumieli bazę
zorganizowaną i zarządzaną z wykorzystaniem komputera.
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 4/11
Gdzie i w jakim celu stosuje się bazy danych
Bazy danych spotykamy właściwie na każdym kroku. Każdy na pewno korzystał z bazy papierowej
takiej jak encyklopedia, książka telefoniczna czy kartoteka w bibliotece. Bazy danych są też
powszechne w świecie informatyki. Większośd systemów informatycznych współpracuje z bazami
danych, gdyż muszą one przechowywad dane. Są aplikacje, których głównym zadaniem jest
przechowywanie, zarządzanie i udostępnianie danych. Potocznie są one nazywane bazami danych
lub, dla podkreślenia faktu istnienia odpowiednich dodatków ułatwiających pracę, aplikacjami
bazodanowymi. Należy jednak mied świadomośd, że znakomita większośd aplikacji to aplikacje,
które współpracują z bazami danych mniej lub bardziej skomplikowanymi.
Zastanowimy się teraz nad najważniejszymi cechami bazy danych, które powinna ona spełniad, aby
mogła sprostad stawianym przed nią dzisiaj wymaganiom.
Proponujemy, abyś przyjrzał się dowolnej bazie danych, z którą się spotkałeś, przeanalizował jej
cechy (te, które ma i które Twoim zdaniem powinna mied) i wypisał je. Następnie sprawdź, ile
z wypisanych przez Ciebie cech pokrywa się uznanymi przez nas za najważniejsze.
Zgodność z rzeczywistością
Postulat zgodności danych zapisanych w bazie z rzeczywistością jest jednym z ważniejszych
postulatów stawianych bazom danych. Na przykład, jeśli baza opisuje dane osobowe pracowników,
takie jak ich imię, nazwisko, telefon, adres zamieszkania, stanowisko itd., to postulat zgodności
z rzeczywistością oznacza, że w chwili, gdy pracownik zmienia stanowisko pracy (a tym samym
również telefon), to również w bazie danych dokonywane są odpowiednie zmiany danych.
Postulat zgodności z rzeczywistością oznacza, że dane zgromadzone w bazie są danymi
prawdziwymi, odpowiadającymi faktycznemu stanowi świata, którego dotyczą. Na pewno każdy
z nas spotkał się z bazą, która nie spełniała tego postulatu i przechowywała dane dawne już
nieaktualne.
Z takimi bazami często spotykam się dzisiaj zaglądając do oferty sklepów i firm internetowych.
Niezwykle rzadko zdarza się, aby dane podawane w bazach udostępnianych przez te podmioty były
prawdziwe. Najczęściej nie zgadzają się ani ceny towarów, ani ich dostępnośd w magazynie.
Powoduje to nie tylko stratę naszego czasu (bo i tak trzeba zadzwonid do „żywego człowieka”), ale
również utratę zaufania do firmy, która udostępnia bazę z danymi niezgodnymi z rzeczywistością.
Spełnienie postulatu zgodności z rzeczywistością nie jest łatwe. Trudności nie leżą w zasadzie po
stronie technicznej, ale po stronie ludzkiej. Nie można (jak na razie) całkowicie zautomatyzowad
procesów biznesowych i w każdym z nich niezbędnym ogniwem jest człowiek. Aby zapewnid
zgodnośd danych przechowywanych w bazie z danymi rzeczywistymi, trzeba opracowad i stosowad
w firmie odpowiednie procedury.
Na przykład w wypadku zmiany stanowiska przez pracownika, dział kadr mógłby (obowiązkowo)
przesyład odpowiednie zgłoszenie do operatora bazy (albo wprowadzad samodzielnie) z informacją
o zaistniałych zmianach. Sposób przesyłania takiego zgłoszenia, jego zawartośd, określenie
odpowiedzialności itd. powinien byd właśnie określony w takiej procedurze.
Problem aktualności danych w bazie jest jednym z trudniejszych problemów do rozwiązania,
szczególnie kiedy w przedsiębiorstwie działa wiele różnych systemów i baz danych. Dlatego też
obserwuje się dzisiaj silną tendencję do integracji różnych systemów w jeden spójny system, który
potrafiłby automatycznie wymieniad dane między swymi modułami (częściami). Rozwiązania tego
typu noszą nazwę rozwiązao EAI (ang. Enterprise Architecture Integration) i są oferowane
i rozwijane przez wiodących dostawców systemów bazodanowych.
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 5/11
Ilustracja fragmentu rzeczywistości
Projektując bazę danych należy pamiętad, że stanowi ona pewien model otaczającego nas świata.
Aby baza spełniała swoje zadania, musi byd ilustracją kompletnego i dobrze zdefiniowanego
fragmentu rzeczywistości. Można oczywiście zbudowad działającą bazę danych, która będzie
pozwalała na poprawne wprowadzanie, usuwanie i modyfikację danych, ale która nie będzie
związana ze światem rzeczywistym. Przydatnośd takiej bazy stoi oczywiście pod znakiem zapytania.
Aby spełnid ten postulat, należy prawidłowo zdefiniowad dziedzinę problemową, która będzie
modelowana za pomocą bazy oraz wykonad odpowiadający tej rzeczywistośd model logiczny bazy.
Określaniem wymagao i budową modelu logicznego bazy danych będziemy się zajmowad
w module 2.
Kontrola replikacji danych
Replikacja danych oznacza reprezentowanie w bazie tego samego faktu w wielu jej miejscach lub
w różnych formach. Na przykład baza danych zawierająca informacje o dostawach towarów może
przechowywad nazwę i adres dostawcy w specjalnej liście dostawców współpracujących z naszą
firmą oraz te same dane w wykazie zamówieo. Taka sytuacja jest zazwyczaj niepożądana. Może ona
prowadzid do:
niepotrzebnego zwiększenia miejsca zajmowanego przez bazę,
niepotrzebnego angażowania mocy obliczeniowych w przeprowadzanie operacji w wielu
miejscach (np. zmiana adresu dostawcy będzie musiała byd wykonana i na liście dostawcy
i przy każdym zamówieniu),
powstania błędów i niezgodności danych gromadzonych w bazie z danymi rzeczywistymi (np.
zapomnimy o zmianie adresu dostawcy przy zamówieniach z lipca).
Czasem jednak zachodzi potrzeba replikacji danych. Może ona wynikad ze względów
wydajnościowych lub ze względów bezpieczeostwa. Trzeba jednak zawsze pamiętad, że jeśli
decydujemy się na zastosowanie (dopuszczenie) replikacji, to zawsze należy poświęcid jej
szczególną uwagę, aby pozostawała pod kontrolą.
Spójny model danych
Baza danych powinna byd zbudowana na podstawie spójnego modelu. Spójny model danych
oznacza, że fragment rzeczywistości, którego dotyczy baza został zamodelowany w jednym
z możliwych modeli oraz że dane i pojęcia (np. pojęcie faktury) reprezentowane w bazie będą ze
sobą połączone tworząc jedną spójną logicznie całośd.
Spójny model należy zapewnid na etapie projektowania logicznego bazy, a jego wyegzekwowanie
w czasie eksploatacji bazy jest możliwe dzięki narzuceniu na bazę odpowiednich warunków
i więzów (np. związków, o których więcej w module 2).
Współbieżny dostęp do danych
Można sobie oczywiście wyobrazid bazę (a nawet znaleźd takie działające bazy), która będzie
umożliwiad dostęp w danej chwili tylko jednemu użytkownikowi. Taka cecha nie powinna nikogo
z nas dziwid, gdyż wiele baz papierowych, z których korzystamy działa w ten właśnie sposób. Nie
jest to jednak wygodne, w szczególności jeśli baza ma służyd wielu użytkownikom. Problem ten
zauważono już dawno i radzono sobie z nim powielając zbiory danych. Na przykład książka
telefoniczna jest drukowana w wielu tysiącach egzemplarzy, dzięki czemu z danych w niej
zawartych może jednocześnie korzystad wielu użytkowników. Nikogo jednak nie trzeba
przekonywad, jak wiele wad ma to rozwiązanie.
Systemy komputerowe pozwalają na dostęp do danych wielu użytkownikom jednocześnie.
Oczywiście udostępnienie danych wielu osobom na raz stwarza dodatkowe problemy związane
z zarządzaniem dostępem do tych danych i wymaga odpowiedniego zaprojektowania i organizacji
bazy danych.
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 6/11
Bezpieczeństwo danych
Bazy danych są dzisiaj obecne w bardzo wielu miejscach i instytucjach, wspomagają nasze życie
codzienne i biorą udział w licznych procesach biznesowych. Są w nich gromadzone informacje
finansowe, księgowe, dane osobowe, transakcje bankowe itp. Z oczywistych powodów wymagają
one ochrony. Dobra baza danych musi zapewniad odpowiednie mechanizmy identyfikacji,
uwierzytelnienia, autoryzacji, poufności, integralności i dostępności.
Rodzaje, klasyfikacja i przykłady SZBD
Sprostanie wymaganiom stawianym dzisiaj bazom danych nie jest łatwe, dlatego budowane są
złożone systemy zawierające zbiór gotowych narzędzi zapewniających odpowiedni dostęp,
manipulację i aktualizację do danych gromadzonych w systemach komputerowych. Narzędzia te to
Systemy Zarządzania Bazą Danych – w skrócie SZBD (ang. Database Management Systems –
DBMS).
Do najważniejszych cech charakteryzujących SZBD możemy zaliczyd:
operowanie na dużych i bardzo dużych zbiorach danych,
zarządzanie złożonymi strukturami,
działanie w długim cyklu życia.
Schemat SZBD wraz z otaczającym go środowiskiem pokazuje poniższy Rys. 1 System Zarządzania
Bazami Danych.
Menedżer plików
Aplikacja
Zapytanie
użytkownika
Definicja
schematu
SZBD
Menedżer bazy danych
Procesor zapytań
Kompilator definicji
schematu
Dane
Dane
Dane
Dane
Rys. 1 System Zarządzania Bazami Danych
SZBD składa się z:
menedżera bazy danych (ang. DB manager) – jego rola polega na zarządzaniu obiektami
bazy danych
procesora zapytao (ang. query procesor) – jego rola polega na przetwarzaniu zapytao
(poleceo) kierowanych do bazy danych,
kompilatora definicji schematu (ang. pattern compiler) – jego rola polega na przetwarzaniu
definicji obiektów znajdujących się w bazie na postad zrozumiałą dla menedżera bazy.
Jak widad na rys. 1.1, SZBD komunikuje się jednej strony z menedżerem plików (ang. file manager),
a z drugiej z warstwą wyższego poziomu. Menedżer plików jest odpowiedzialny za obsługę
fizycznych nośników danych – zna i rozumie sposób organizacji tych nośników (systemu plików).
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 7/11
W warstwie wyższego poziomu mogą natomiast znajdowad się aplikacje użytkownika (ang.
application), zapytania formułowane przez użytkownika (ang. user query), narzędzia do
definiowania schematu bazy danych (ang. pattern description) itp.
Na rynku dostępnych jest wiele Systemów Zarządzania Bazami Danych dostarczanych przez różnych
producentów. Do najważniejszych należą:
Oracle
MS SQL Server
DB2
Sybase
Informix
Adabase
ObjectStore
MS Access
oraz wiele innych.
Kryteria doboru SZBD
Wybór odpowiedniego systemu SZBD nie jest łatwy. Przed podjęciem decyzji warto jest rozważyd
wiele aspektów związanych zarówno z tym co baza danych ma robid, jak i innymi uwarunkowaniami
po stronie dostawcy systemu i jego użytkownika.
Do najważniejszych kryteriów doboru SZBD należą:
Wydajność (ang. performance) – określa, jak szybko system będzie reagował na wydawane
mu polecenia, ile jednocześnie będzie potrafił obsłużyd zleceo czy użytkowników.
Skalowalność (ang. scalability) – określa, jak zmieni się działanie systemu (jego wydajnośd),
jeśli wzrośnie liczba użytkowników lub danych. Cecha ta określa również możliwośd adaptacji
systemu do nowych warunków obciążenia i możliwośd jego rozbudowy w celu sprostania
nowym, większym obciążeniom.
Funkcjonalność (ang. functionality) – określa, jakie funkcje są dostępne w systemie. Warto
zwrócid uwagę zarówno na funkcje wykorzystywane przez użytkownika, jak i administratora
czy projektanta takiego systemu. Najczęściej brak odpowiednich funkcji – szczególnie
potrzebnych projektantom i administratorom pociąga za sobą koniecznośd dokupienia
dodatkowych narzędzi i zwiększa koszty systemu.
Zgodność ze standardami – oznacza spełnienie przez system pewnych zasad i reguł uznanych
za powszechne, czyli standardów (np. standard języka, standard protokołu, itp.). Spełnienie
powszechnie stosowanych standardów uniezależnia nas od dostawcy systemu i pozwala na
dokładanie do niego innych elementów proponowanych przez różnych dostawców
(oczywiście jeśli są godne ze standardem).
Łatwość użycia (ang. usability) – jest ważną cechą systemu. Zdarzają się systemy o bardzo
dobrych parametrach wydajnościowych lub dużej niezawodności, które jednak są tak trudne
w obsłudze, że użytkownicy z nich rezygnują. Ocena tej cechy zależy od użytkownika
systemu, jego przygotowania i doświadczenia. Jest więc cechą subiektywną i ten sam system
przez różnych użytkowników może byd zakwalifikowany jako łatwy lub trudny w użyciu.
Niezawodność (ang. reliability) – oznacza, jak często system przestaje działad. Oczywiście, im
większa niezawodnośd systemu, tym większe są jego koszty wytworzenia. Trzeba więc
wyważyd odpowiednią proporcję między niezawodnością systemu a potrzebami
użytkownika. Chod każdy chciałby, aby jego system działał bezbłędnie (był niezawodny) w jak
największym stopniu, to jednak często jesteśmy gotowi zaakceptowad przestój systemu
trwający godzinę w zamian za przystępną cenę.
Wspomaganie (ang. support) – oznacza zapewnienie odpowiedniej pomocy przez dostawcę
systemu. Z całą pewnością jest to bardzo ważna cecha systemu. Z pewnością warto zapłacid
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 8/11
wyższą cenę za produkt, którego producent zapewnia dobry i stabilny serwis. Nie ma
przecież systemów niezawodnych w stu procentach ani systemów, które nie kryją tajemnic
o sposobie ich użytkowania.
Środowisko (ang. environment) – określa, na jakim sprzęcie czy systemie operacyjnym będzie
działad nasz system.
Cena (ang. price) – oznacza nie tylko koszt zakupu systemu, ale również wszystkie pozostałe
koszty związane z wdrożeniem tego systemu oraz przewidywanymi kosztami jego
eksploatacji. Koszt zakupu jest często tylko elementem składowym ogólnej ceny systemu.
Użytkownicy baz danych i ich rola w systemie
Wśród najważniejszych grup użytkowników systemów SZBD możemy wyróżnid następujące grupy:
Administrator systemu (ang. system administrator) – jego zadaniem jest nadzór nad całym
systemem. To on definiuje bazy danych w systemie, zakłada użytkowników o charakterze
globalnym itp.
Administrator bazy danych (ang. database administrator) – administruje jedynie bazą, którą
ma pod swoją opieką. Ma on uprawnienia do zakładania i administrowania obiektami bazy
ale tylko w obrębie danej bazy danych.
Programista aplikacji (ang. application programmer) – jego rolą jest pisanie kodu, który
będzie wspomagał użytkowanie bazy (np. procedur składowanych).
Operator – czuwa nad codzienną eksploatacją bazy. Czuwa nad wykonaniem kopii
bezpieczeostwa i wykonuje inne proste, codzienne czynności admnistracyjne.
Użytkownik (ang. user) – to ktoś wykonujący czynności nie wchodzące w zakres obowiązków
pozostałych grup.
Modele struktury logicznej bazy danych
Modele struktury logicznej bazy danych mogą byd bardzo różne. Modele te starają się
odzwierciedlid rzeczywistośd, której baza dotyczy oraz mają zasadniczy wpływ na implementacje
i działanie bazy. Dzisiaj najpopularniejszym modelem stosowanym w SZBD jest model relacyjny.
Obok niego funkcjonują też inne modele – starszy model hierarchiczny i zyskujący sobie powoli
popularnośd model obiektowy.
Model hierarchiczny
Model hierarchiczny przypomina odwrócone drzewo. Jeden z elementów pełni role korzenia,
a pozostałe tworzą gałęzie i liście. W modelu tym występują związki między obiektami zwane
związkami ojciec-syn.
Związki takie charakteryzują się tym, że obiekt nadrzędny (ojciec) może pozostawad w związku
z wieloma innymi obiektami podrzędnymi (synowie), natomiast tylko z jednym obiektem
nadrzędnym w stosunku do niego (jego ojcem).
Rys. 2. Model hierarchiczny
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 9/11
Na Rys. 2 przedstawiono przykład modelu hierarchicznego dla bazy przechowującej informacje
o wykładach, wykładowcach oraz studentach uczęszczających na te wykłady.
Model hierarchiczny ma jednak wiele wad. Do najważniejszych należą:
niemożnośd zapisania w bazie danych, które nie mają ojca (np. wykładowcy, który w danym
roku nie prowadzi wykładów),
nadmiarowośd danych (np. dane o przedmiocie są wpisane w bazie dwa razy – w wykładach
i przedmiotach),
brak możliwości obsługi bardziej złożonych związków między obiektami (np. związków „wiele
do wiele”).
Zaletą tego modelu jest łatwośd (a co za tym idzie szybkośd) dojścia do szukanych danych (idziemy
od korzenia wzdłuż gałęzi aż do celu), ale pod warunkiem, że znamy strukturę tego modelu.
Model hierarchiczny stosowany jest dziś w systemach plików (struktura katalogów ma strukturę
drzewiastą) oraz w wielu popularnych aplikacjach (np. MS Outlook, Lotus Notes).
Model relacyjny
W celu wyeliminowania wad modelu hierarchicznego opracowano na początku lat
siedemdziesiątych nowy model zwany modelem relacyjnym. Podstawy teoretyczne dla modelu
relacyjnego opracował dr E. Codd pracując w firmie IBM i opublikował w roku 1970 w książce pod
tytułem Relacyjny model logiczny dla dużych banków danych. Model ten oparty jest na silnych
podstawach matematycznych, głównie teorii mnogości.
Idea modelu relacyjnego bazuje na pojęciu relacji – czyli tabeli. Wszystkie dane w tym modelu są
przechowywane w tabelach (relacjach). Tabele te mogą byd ze sobą powiązane tak zwanymi
związkami. Rysunek rys. 1.3 przedstawia przykład modelu relacyjnego. Zasadniczą wadą modeli
relacyjnych jest ich znaczna rozbieżnośd w stosunku do świata rzeczywistego, który mają
modelowad. Pozwalają za to na efektywne przechowywanie danych, obniżają redundancję danych
(powtarzalnośd) i pozwalają na łatwe wyszukiwanie danych.
Rys. 3. Model relacyjny
Bazy danych oparte na modelu relacyjnym są obecnie najbardziej rozpowszechnionym rodzajem
baz danych.
Model obiektowy
Obecnie technologią, która pozwala najlepiej odwzorowywad świat rzeczywisty w projektowaniu
oprogramowania, jest technologia obiektowa. O jej sukcesie świadczy popularnośd takich języków
programowania jak C++ czy Java. Technologia obiektowa jest obecnie dominującym narzędziem
przy tworzeniu dużych i złożonych projektów.
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 10/11
Obiektowośd nie ogranicza się jedynie do nowego sposobu organizacji kodu w językach
programowania. Jest ona pewną ideologią w informatyce, której cechą jest chęd dopasowania
modeli pojęciowych stosowanych w informatyce do modelu świata postrzeganego przez człowieka.
Jest to kolejny krok w ewolucji kontaktów człowiek-maszyna (a ściślej programista-komputer).
Śledząc, nawet pobieżnie, rozwój języków programowania widzimy, że ewolucja ta przebiega ciągle
w stronę ułatwiania życia człowiekowi. Wynika to z rozwoju technologii i związanego z tym
zwiększania złożoności modelowanych procesów. Bez wprowadzania nowych metod, wyższych
poziomów abstrakcji w projektowaniu i programowaniu , człowiek szybko staje się najsłabszym
ogniwem w procesie tworzenia oprogramowania.
Większośd producentów systemów relacyjnych baz danych wyposaża obecnie swoje produkty
w rozszerzenia obiektowe. Są one implementowane w różnym stopniu i zakresie. Obejmują takie
funkcje jak obsługa abstrakcyjnych typów danych, klas, przechowywanie obiektów, wyzwalacze,
procedury składowane. Podstawą takiego systemu jest najczęściej ten sam „silniczek”, jaki był
stosowany w wersji relacyjnej – dobry i sprawdzony, ale pisany z myślą o modelu relacyjnym, a nie
obiektowym. Systemy tego typu nie spełniają w pełni paradygmatu obiektowości, mogą byd
traktowane raczej jako rozszerzenie systemów relacyjnych o pewne atrakcyjne cechy umożliwiające
efektywne tworzenie aplikacji, a nie jako pełnowartościowe systemy obiektowe.
Systemy w pełni obiektowe zrywają natomiast z założeniami modelu relacyjnego i opierają się
w całości na technologii obiektowej. Zapewniają tradycyjną funkcjonalnośd bazy danych (trwałośd,
integralnośd danych, obsługę wielodostępu, odtwarzanie danych) przy zastosowaniu obiektowego
modelu danych. Wiele tego typu systemów obsługuje również bardziej zaawansowane funkcje jak
np. obsługa rozproszonych baz danych.
Systemy obiektowych baz danych są najlepiej dopasowane do potrzeb zorientowanych obiektowo
aplikacji przetwarzających duże ilości danych oraz obsługujących wielu użytkowników. Istniejące
rozwiązania obejmują różne zakresy funkcjonalności – od prostych systemów przeznaczonych do
obsługi małej liczby użytkowników, dostosowanych do jednego języka programowania, aż do
bardzo zaawansowanych rozwiązao, w których wydajny serwer obiektowej bazy danych jest
sercem całego systemu serwera aplikacji.
Należy jednak zwrócid uwagę, że systemy obiektowe ciągle stanowią przedmiot badao i nie
osiągnęły jeszcze pełnej dojrzałości.
Podsumowanie
Współczesne systemy informatyczne wykorzystują bazy danych, od małych baz budowanych
specjalnie na ich potrzeby, aż po duże i bardzo duże uniwersalne bazy i systemy baz danych.
W zasadzie trudno byłoby znaleźd program komputerowy, który nie korzystałby z baz danych.
Nie każdą strukturę przechowującą dane możemy jednak uznad za bazę danych. Baza danych musi
charakteryzowad się odpowiednimi cechami. Ponieważ dzisiaj przed bazami danych stawia się coraz
większe wymagania związane z wydajnością, bezpieczeostwem itd. Wymaganiom tym mogą
sprostad dopiero Systemy Zarządzania Bazami Danych, które są wyposażone w odpowiednie
mechanizmy zapewniające bezpieczeostwo, spójnośd, wydajnośd i łatwośd obsługi.
Modele baz danych są różne. Do najpopularniejszych należą model hierarchiczny, relacyjny
i obiektowy. Każdy z nich nadaje się do innych celów, a najbardziej rozpowszechnionym modelem
w bazach spotykanych w rozwiązaniach przemysłowych jest model relacyjnym. Nasze zajęcia
poświęcone są właśnie temu modelowi.
W.Dąbrowski, P.Kowalczuk, K.Markowski
Dodatek A
ITA-101 bazy danych
Podstawowe pojęcia
Strona 11/11
Uwagi dla studenta
W tym module nie jest przewidziane laboratorium. Jeśli chcesz się przekonad, czy jesteś gotowy do
wykonywania laboratoriów w kolejnych modułach, zastanów się i odpowiedz na następujące
pytania:
czy rozumiesz, czym jest baza danych,
czy potrafisz uzasadnid stosowanie baz danych do przechowywania danych zamiast
innych struktur,
czy umiesz wymienid podstawowe cechy baz danych,
czy rozumiesz założenia modelu relacyjnego?
Jeśli potrafisz na te pytania odpowiedzied twierdząco, to jesteś przygotowany do dalszej drogi przez
świat baz danych. Jeśli nie, to zapoznaj się ponownie z uwagami i poradami zawartymi w tym
module. Upewnij się, że rozumiesz omawiane w nich zagadnienia. Jeśli masz trudności ze
zrozumieniem tematu zawartego w uwagach, przeczytaj ponownie informacje z tego rozdziału
i zajrzyj do notatek z wykładów.
Dodatkowe źródła informacji
1. Jeffrey D. Ullman, Jennifer Widom, Podstawowy wykład z systemów baz danych, WNT, 2000
Książka zawiera pełny akademicki wykład z baz danych. Znajdziesz w niej szerokie
omówienie wszystkich przedstawianych w tym module pojęd wraz z licznymi
przykładami. Jeśli jesteś zainteresowany odrobiną teorii i chciałbyś dogłębnie
zrozumied jak działają bazy danych to jest to książka dla Ciebie.
2. Rebeca R. Riordan, Projektowanie relacyjnych baz danych, Microsoft Press, 2000
Książka poświęcona jest praktycznym aspektom projektowania relacyjnych baz
danych w środowisku aplikacji firmy Microsoft. Rebeca Riordan znana jest
z łatwego i zrozumiałego języka i łatwości tłumaczenia zagadnieo trudnych. Ten
swój talent wykorzystuje również w tej pozycji. Jeśli nie interesuje Cię zgłębianie
teoretycznych podstaw działania baz danych, a bardziej nastawiony jesteś na
praktyczne wykorzystanie wiedzy, to jest to książka dla Ciebie.
3. C.J.Date, Wprowadzenie do systemów baz danych, WNT, 2000
Jest to pełny podręcznik do wykładu z baz danych znanego i cenionego na całym
świecie autora. Znajdziesz w nim szersze spojrzenie na problematykę budowy
i modelowania baz danych. Polecamy ją wszystkim, którzy chcieliby poszerzyd
swoje wiadomości z tego zakresu.
Wyszukiwarka
Podobne podstrony:
ITA 101 Modul 03
ITA 101 Modul 02
ITA 101 Modul 06
ITA 101 Modul 13
ITA 101 Modul 11
ITA 101 Modul 04
ITA 101 Modul 09
ITA 101 Modul 08
ITA 101 Modul 07
ITA 101 Modul 10
ITA 101 Modul 12
ITA 101 Modul 01
ITA 101 Modul 05
ITA 101 Modul 02 v2
więcej podobnych podstron