1. System zarządzania bazą danych, jego przykładowa architektura, funkcje DBMS, f-cje poszczególnych modułów.

Baza danych jest modelem pewnego aspektu rzeczywistości danej organizacji. Tę rzeczywistość nazywamy obszarem analizy (OA). Bazę danych możemy uważać za zbiór danych, których zadaniem jest reprezentowanie pewnego OA. Dane to fakty. Dana, jednostka danych, jest jednym symbolem lub zbiorem symboli, którego używamy, aby reprezentować jakąś „rzecz”.

Dane w bazie danych są traktowane jako trwałe. Przez trwałość rozumiemy, że dane są przechowywane przez pewien czas. Ten czas nie musi być bardzo długi. Termin „trwałość” jest używany do rozróżnienia bardziej trwałych danych od danych, które są tymczasowe.

Baza danych składa się z dwóch części: intensjonalnej i ekstensjonalnej. Część intensjonalna bazy danych jest zbiorem definicji, które opisują strukturę danych bazy danych. Część ekstensjonalna bazy danych jest łącznym zbiorem danych w bazie danych. Część intensjonalną bazy danych nazywamy schematem bazy danych. Tworzenie schematu bazy danych nazywamy projektowaniem bazy danych.

Bazy danych charakteryzują się czterema podstawowymi własnościami:

• Niezależność aplikacji i danych.  

• Abstrakcyjna reprezentacja danych.  

• Różnorodność sposobów widzenia danych.  

• Fizyczna i logiczna niezależność danych.

W pewnym uproszczeniu przez bazę danych rozumiemy uporządkowany zbiór danych, a przez system bazy danych - bazę danych wraz z oprogramowaniem umożliwiającym operowanie na niej. Baza danych jest przechowywana na nośnikach komputerowych. Precyzując definicję bazy danych można powiedzieć, że baza danych jest abstrakcyjnym, informatycznym modelem wybranego fragmentu rzeczywistości.

Fragment rzeczywistości może być rozumiany jako:

• rzeczywistość fizyczna - taka, którą postrzegamy naszymi organami percepcji

• rzeczywistość konceptualna - istniejąca najczęściej w wyobraźni pewnych osób; przykładem tej rzeczywistości może być projekt nowego samolotu firmy Boeing, który istnieje tylko w wyobraźni konstruktorów.

Poprawne (z punktu widzenia człowieka) operowanie na bazie danych wiąże się z właściwą interpretacją danych, które zostały w niej zapisane. W związku z tym konieczny jest opis semantyki (znaczenia) danych, przechowywanych w bazie.

System bazy danych służy więc do modelowania rzeczywistości (fragmentu). W systemach baz danych rzeczywistość opisuje się za pomocą modelu danych. Przez model danych rozumiemy zbiór abstrakcyjnych pojęć umożliwiających reprezentację określonych własności tego świata.

Zbiór pojęć użyty do opisu własności tego konkretnego fragmentu świata rzeczywistego, istotnych z punktu widzenia danego zastosowania tworzy schemat bazy danych.

Baza danych jest modelem logicznie spójnym służącym określonemu celowi. W związku z tym baza danych nie może (nie powinna) przyjąć stanu, który nie jest nigdy osiągalny w modelowanej rzeczywistości.

Można więc powiedzieć, że każda baza danych posiada:

• źródło danych

• użytkowników

• związki z reprezentowaną rzeczywistością.

Baza danych to dane i tzw. schemat bazy danych. Dane opisują cechy (własności) modelowanych obiektów. Nie jest jednak możliwa ich interpretacja bez użycia schematu. Schemat jest opisem struktury (formatu) przechowywanych danych oraz wzajemnych powiązań między nimi.

System Zarządzania Bazą Danych (SZBD)

System Zarządzania Bazą Danych DBMS (Database Management System) jest to zestaw programów umożliwiających tworzenie i eksploatację bazy danych. System zarządzania bazą danych jest oprogramowaniem ogólnego przeznaczenia. System bazy danych składa się z bazy danych, systemu zarządzania bazą danych i ewentualnie z zestawu aplikacji wspomagających pracę poszczególnych grup użytkowników.

Czego oczekuje się od systemu DBMS:

1. Umożliwienia użytkownikowi utworzenia nowej bazy danych i określenia jej schematu (logicznej struktury danych) za pomocą specjalizowanego języka definiowania danych (data-definition language).

2. Zapewnienia możliwości przechowywania ogromnej ilości danych przechowywanej przez długi czas chroniąc je przed przypadkowym, lub niepowołanym dostępem, a także umożliwiając efektywny dostęp do danych z poziomu języka zapytań i operacji na danych

3. Sterowania jednoczesnym dostępem do danych przez wielu użytkowników, z zapewnieniem bezkolizyjności oraz ochrony danych przed przypadkowym uszkodzeniem.

Architektura systemu DBMS

Na samym dole widzimy element reprezentujący miejsce składowania danych. Zauważmy, że ten element służy nie tylko do zapisu danych, ale także metadanych, które opisują strukturę danych. Na przykład, jeśli rozważany DBMS jest relacyjny, to metadane obejmują nazwy relacji, nazwy atrybutów relacji i typy poszczególnych atrybutów ( np. całkowity lub znakowy ).

Często system DBMS obsługuje indeksy danych. Indeks jest taką strukturą danych, która pomaga w szybkim odnajdywaniu właściwych danych, a posługuje się przy tym ich wartościami; najbardziej popularny przykład indeksu umożliwia odnalezienie właściwej krotki relacji, mającej zadane wartości pewnych atrybutów. Na przykład relacja obejmująca numery kont i bilans może mieć indeks założony na numerach kont, wówczas odnalezienie bilansu konta o podanym numerze odbywa się błyskawicznie. Indeksy są przechowywane razem z danymi, a informacja o tym, który atrybut ma założone indeksy, należy do metadanych.

Na rysunku można także dostrzec moduł zarządzania pamięcią, który

ma za zadanie wybierać właściwe dane z pamięci i w razie potrzeby

dostosować je do wymagań modułów z wyższych poziomów systemu.

Moduł zarządzania pamięcią składa się z dwóch części: modułu zarządzania buforami oraz modułu zarządzania plikami.

1. Moduł zarządzania plikami przechowuje dane o miejscu zapisania plików na dysku i na polecenie modułu zarządzania buforami przesyła zawartość bloku lub bloków, gdzie jest zapamiętany żądany plik.

2. Moduł zarządzania buforami obsługuje pamięć operacyjną. Moduł zarządzania plikami przekazuje bloki danych z dysku, a moduł zarządzania buforami wybiera w pamięci operacyjnej strony, które zostaną przydzielone dla wybranych bloków. Blok z dysku może być przez chwile przechowywany w pamięci operacyjnej, ale musi zostać przesłany z powrotem na dysk, gdy tylko pojawi się potrzeba zapisania w to miejsce pamięci innego bloku. Powrót bloku na dysk może nastąpić również w wyniku żądania modułu obsługi transakcji.

Widać tam także składową, którą nazwaliśmy procesorem zapytań, mimo, że taka nazwa może wprowadzać w błąd, bowiem obsługuje on nie tylko zapytania, ale również aktualizacje danych oraz metadanych. Jego zadanie polega na znalezieniu najlepszego sposobu wykonania zadanych operacji i na wydaniu poleceń do modułu zarządzania pamięcią, który je wykona.

Typowy DBMS stwarza użytkownikowi sposobność łączenia jednego lub więcej zapytań, bądź modyfikacji, w transakcję, która stanowi nieformalną grupę operacji przeznaczonych do wykonania razem w jednym ciągu, jako duża operacja jednostkowa. Moduł zarządzania transakcjami odpowiada za spójność systemu. Musi on gwarantować, że kilka jednocześnie przetwarzanych zapytań nie będzie sobie nawzajem przeszkadzać oraz, że żadne dane nie

zostaną utracone, nawet jeśli nastąpi awaria systemu. W tym celu dokumentuje wszystkie operacje, tzn. rozpoczęcie każdej transakcji, zmiany w bazie danych dokonane przez transakcje oraz zakończenie transakcji. Zapis taki nazywa się logiem. Log jest przechowywany w pamięci stałej, tzn. na nośniku danych jakim jest dysk, który zapewni przetrwanie danych w przypadku awarii zasilania.

Zasadnicze przetwarzanie transakcji odbywa się w pamięci operacyjnej, ale dane o przebiegu jej wykonania są natychmiast

zapisywane na dysku. A więc log wszystkich operacji jest ważnym czynnikiem zapewniającym systemowi trwałość. Moduł zarządzania transakcjami współdziała z modułem obsługi zapytań, ponieważ musi

mieć dostęp do szczegółów dotyczących tych danych, na których przetwarza się bieżące zapytanie. Może się zdarzyć, że część przetwarzania będzie musiała zostać opóźniona, aby nie powstał konflikt.

Transakcja jest atomową jednostką pracy, taką że baza danych jest w stanie spójnym przed i po zakończeniu transakcji. Inaczej mówiąc, jeśli dana transakcja jest wykonana poprawnie, zmiany, które wprowadziła, będą pamiętane w bazie danych. W przeciwnym przypadku, wszystkie zmiany wprowadzone przez transakcje będą anulowane ( wycofane).

U góry rysunku można zobaczyć trzy rodzaje wejść do systemu DBMS:

1. Zapytania. Są to zapytania o dane. Mogą one być sformułowane dwojako:

• Poprzez interfejs zapytań bezpośrednich. Na przykład relacyjny DBMS umożliwia wprowadzenie zapytań w SQL, które są następnie przekazywane do modułu przetwarzania danych, który z kolei tworzy odpowiedź

• Poprzez interfejsy programów użytkowych. Typowy DBMS umożliwia programiście tworzenie programu użytkowego, który poprzez wywołania procedur DBMS tworzy zapytania do bazy danych. Na przykład agent posługujący się systemem rezerwacji lotniczych uruchamia program użytkowy, który tworzy zapytanie bazy danych dotyczące dostępności rejsów. Zapytania mogą być formułowane dzięki specjalizowanemu interfejsowi, który na ogół składa się z formularzy z pustymi polami, przeznaczonymi do wypełnienia konkretnymi danymi, np. nazwą miasta, terminem itp.. nie można w ten sposób zadać zupełnie dowolnego pytania, ale jest znacznie łatwiej sformułować zupełnie typowe zapytanie poprzez taki interfejs, niż formułować zapytanie bezpośrednio w języku SQL

2. Aktualizacje. Są to operacje zmiany danych. Tak jak w przypadku zapytań można je wprowadzić do systemu poprzez interfejsy zapytań bezpośrednich lub poprzez interfejsy programów użytkowych.

3. Modyfikacje schematu. Polecenia tego rodzaju wydaje specjalnie uprawniona osoba nazywana administratorem bazy danych, której wolno zmieniać schemat bazy danych i tworzyć nowe bazy danych. Na przykład, jeśli agencje rządowe wezwą banki do udokumentowania wypłaty odsetek zgodnie z numerami ubezpieczenia społecznego klientów, to bank może zażądać dodania do relacji opisującej klientów nowego atrybutu o nazwie np. nrUbezpieczenia.

Funkcje systemu zarządzania bazą danych

• przechowywanie danych w co wchodzi tworzenie i utrzymywanie struktur danych,

• zapewnianie mechanizmów bezpieczeństwa i prywatności,

• umożliwianie równoczesnego, kontrolowanego korzystania z bazy danych wielu użytkownikom,

• umożliwianie wprowadzania i ładowania danych,

• umożliwianie wydobywania i operowania na przechowywanych danych,

• zapewnianie integralności rekordów bazy danych,

• udostępnianie wydajnych mechanizmów indeksowania pozwalających na szybkie przeszukiwanie i odnajdywanie interesujących nas danych,

• zapewnianie ochrony przechowywanych danych przed ewentualną utratą, na skutek przyczyn niekoniecznie zależnych od człowieka, za pomocą metod tworzenia kopii bezpieczeństwa i procedur odtwarzania

2. Języki stosowane w bazach danych

Języki stosowane w bazach danych

Języki, które stosuje się do projektowania i wypełniania bazy danych można podzielić na cztery różne grupy:

• język definiowania danych (Data Definition Language - DDL), który umożliwia definiowanie struktury danych przechowywanych w bazie, czyli tworzenie schematu implementacyjnego

• język manipulowania danymi (Data Manipulation Language - DML), który umożliwia wypełnienie, modyfikowanie i usuwanie informacji z bazy danych

• język sterowania danymi (Data Control Language - DCL), który umożliwia sterowania transakcjami (np. zatwierdzanie lub wycofywanie)

• język zapytań (Query Language), który umożliwia pobieranie z bazy informacji zgodnych z podanymi warunkami

• Jądro systemu zarządzania bazą danych ( funkcje)

Jądro systemu zarządzania bazą danych

Funkcje jądra Systemu Zarządzania Bazą Danych (SZBD) określają następujące kategorie działań:

• Organizacja plików.

• Mechanizmy dostępu.

• Zarządzanie transakcjami: kontrola współbieżności i spójności.

• Zarządzanie słownikami.

• Zarządzanie zapytaniami.

• Sporządzanie kopii zapasowych (ang. backup) i odtwarzanie.

SCHEMAT SLAJDY

Organizacja plików dotyczy sposobu, w jaki układa się dane w fizycznych urządzeniach przechowywania danych, z których najważniejszymi są urządzenia dyskowe. Organizacje plików i dostępów są wewnętrznie powiązane. Poniżej zostaną omówione dwa główne typy plików systemu relacyjnego: pliki sekwencyjne i pliki haszowane.

Podstawową postacią organizacji plików sekwencyjnych jest plik nieuporządkowany. W tej postaci pliku rekordy są ustawiane w pliku w porządku ich wstawiania. Wstawianie do pliku nieuporządkowanego jest bardzo proste. Wyszukanie rekordu wymaga natomiast liniowego przeszukania całego pliku, rekord po rekordzie. Dlatego do pliku o N rekordach średnio trzeba będzie przeszukać N/2 rekordów.

Z tego powodu większość systemów stara się utrzymywać pewną postać sekwencyjnej organizacji pliku. W sekwencyjnym pliku uporządkowanym rekordy są uporządkowane według wartości jednego lub więcej pól. W praktyce dotyczy to zazwyczaj klucza głównego pliku.

Ogólnie rzecz biorąc, oznacza to, że chociaż wstawianie wiąże się z większą ilością przetwarzania niż w przypadku pliku nieuporządkowanego, wyszukiwanie może być zrealizowane za pomocą bardziej efektywnych algorytmów dostępu. Jednym z najbardziej znanych algorytmów jest algorytm wyszukiwania binarnego, którego działanie polega na ciągłym zmniejszaniu obszaru wyszukiwania o połowę.

Klucz główny to jedna lub więcej kolumn tabeli, w których wartości jednoznacznie identyfikują każdy wiersz tabeli.

Pliki haszowane dostarczają bardzo szybkiego dostępu do rekordów na podstawie określonego kryterium. Plik haszowany musi być zadeklarowany za pomocą tak zwanego klucza haszowania. To oznacza, że w pliku może być tylko jeden porządek haszowania. Wstawianie rekordu do pliku haszowanego oznacza, że klucz rekordu jest przekazywany do funkcji haszującej. Funkcja haszująca tłumaczy logiczną wartość klucza na fizyczną wartość klucza - względny adres bloku.

Powyżej zostały omówione pewne mechanizmy dostępu, które są wewnętrznie powiązane z leżącą u ich podstaw organizacją plików. Dlatego, na przykład, dostęp sekwencyjny jest możliwy dla plików sekwencyjnych, a dostęp haszowany - dla plików haszowanych. Poniżej zostanie omówiony mechanizm dostępu, który jest dodawany do bazy danych, aby usprawnić jej działanie bez wpływu na strukturę przechowywania danych - indeks.

Podstawowa idea indeksu polega na zastosowaniu dodatkowego pliku o dwóch polach, dodawanego do systemu baz danych. Pierwsze pole indeksu zawiera posortowaną listę logicznych wartości kluczy, drugie pole - listę adresów bloków dla wartości kluczy. Główny problem polega na utrzymaniu odpowiednio małego indeksu, tak aby mógł być przechowywany w pamięci głównej. Na indeksie wykonujemy przetwarzanie używając algorytmu, takiego jak wyszukiwanie binarne. Wyszukiwanie binarne jest szybkim algorytmem przeszukiwania posortowanej listy wartości kluczy.

4. Transakcje, ich funkcje i cechy.

W praktyce większość indeksów w SZBD jest implementowana za pomocą pewnych postaci B-drzew. Termin B-drzewo jest skrótem od „drzewo wyważone” i oznacza hierarchiczną strukturę danych.

W systemie baz danych z wieloma użytkownikami transakcjami nazywamy procedury, które wprowadzają zmiany do bazy danych lub które wyszukują dane w bazie danych. Transakcja może być zdefiniowana jako logiczna jednostka pracy. Każda transakcja powinna mieć właściwości: niepodzielność, spójność, izolacji i trwałości (czasami używany skrót to ACID):

• Niepodzielność. Skoro transakcja składa się ze zbioru akcji, menedżer transakcji powinien zapewnić, że albo cała transakcja zostanie wykonana, albo w ogóle nic.

• Spójność. Wszystkie transakcje muszą zachowywać spójność i integralność bazy danych. Operacje wykonywane na przykład przez transakcję modyfikującą nie powinny pozostawiać bazy danych w stanie niespójnym lub niepoprawnym

• Izolacja. Jeżeli transakcja modyfikuje dzielone dane, to te dane mogą być tymczasowo niespójne. Takie dane muszą być niedostępne dla innych transakcji dopóty, dopóki transakcja nie zakończy ich używać. Menedżer transakcji musi dostarczać iluzji, że dana transakcja działa w izolacji od innych transakcji.

• Trwałość. Gdy transakcja kończy się, wówczas zmiany dokonane przez nią powinny zostać w pełni utrwalone. To znaczy, nawet w wypadku awarii sprzętu lub oprogramowania powinny one zostać zachowane.

5. Modele danych i ich niezależność.

Modele danych

Każda baza danych, a także każdy SZBD muszą się stosować do zasad określonego modelu danych. W literaturze baz danych termin modelu danych używany jest w odniesieniu do architektury danych oraz zintegrowanego zbioru wymagań w odniesieniu do danych. Model danych w sensie architektury danych jest zbiorem ogólnych zasad posługiwania się danymi. Rozróżniamy trzy generacje architektonicznych modeli danych:

• Proste modele danych. W tym podejściu obiekty są reprezentowane za pomocą struktury rekordów zgrupowanych w strukturach plików.

• Klasyczne modele danych. Są to hierarchiczne, sieciowe i relacyjne modele danych. Hierarchiczny model danych jest rozszerzeniem opisanego wyżej modelu prostego natomiast sieciowy model jest rozszerzeniem podejścia hierarchicznego. Relacyjny model danych jest następcą modeli hierarchicznego oraz sieciowego.

• Semantyczne modele danych. Głównym problemem związanym z klasycznymi modelami danych, jest to, że zachowują one podstawową orientację opartą na rekordach. Semantyczne modele danych próbują dostarczyć bardziej znaczących sposobów reprezentowania znaczenia informacji, niż jest to możliwie przy modelach klasycznych. Pod wieloma względami obiektowy model danych może być uważany za semantyczny model danych.

Model danych jako projekt rozumiany jest jako zintegrowany, niezależny od implementacji zbiór wymagań dotyczący danych dla pewnej aplikacji. Mówimy więc o modelu danych do przetwarzania zamówień, modelu danych do księgowania rachunków itp.

Podstawowym celem baz danych jest zapewnienie niezależności danych, czyli: odporność programów użytkowych na zmiany struktury pamięci i strategii dostępu.

Rozróżniamy 2 typy niezależności danych:

• Fizyczna niezależność danych oznacza, że rozmieszczenie fizyczne i organizacja danych mogą być zmieniane bez zmiany programów użytkowych jak i globalnej struktury logicznej danych. Niezależność fizyczna wyraża się w tym, że w wyniku zmian struktury pamięci zmienia się jedynie definicja odwzorowania między poziomem pojęciowym a poziomem fizycznym.

2 Logiczna niezależność danych oznacza, że globalna struktura logiczna danych może być zmieniana bez zmiany programów użytkowych (zmiany nie mogą oczywiście usunąć danych, z których te programy korzystają). Niezależność logiczna wyraża się tym, że w wyniku zmian na poziomie pojęciowym zmienia się tylko definicja odwzorowania między poziomem pojęciowym a poziomem zewnętrznym - umożliwia zachowanie programów użytkowych w nie zmienionej postaci.

Reprezentacja danych:

• poziom pojęciowy - jest on abstrakcyjnym, lecz wiernym opisem pewnego wycinka rzeczywistości.

• poziom wewnętrzny - określa sposoby organizacji danych w pamięci zewnętrznej.

• poziom zewnętrzny - odnosi się do sposobu w jaki dane są widziane przez poszczególne grupy użytkowników.

Schemat kanoniczny jest próbą opisu wewnętrznych właściwości danych. Jeżeli System Zarządzania Bazą Danych korzysta z niego, który nie zmienia się bez względu na rodzaj zastosowanego sprzętu, oprogramowania czy fizycznej struktury danych, to można mówić o prawdziwej niezależności danych. W praktyce nie stosuje się go.

SCHEMAT SLAJDY

Schemat kanoniczny jest jako model danych, przedstawiający wewnętrzną strukturę danych. Tym samym niezależny jest od poszczególnych dziedzin stosowania danych, jak również od mechanizmów związanych z oprogramowaniem lub sprzętem, które to wykorzystywane są do reprezentowania oraz zachowywania danych.

Statyczna i dynamiczna niezależność danych:

o wiązaniu dynamicznym mówimy w trakcie wyszukiwania danych. Schemat lub fizyczna organizacja może być wtedy modyfikowana w dowolnym momencie - daje ono dynamiczną niezależność danych. Statyczna niezależność danych wymaga aby przeprowadzenie zmian w schemacie ogólnym, podschemacie lub fizycznej reprezentacji, zakończyło się zanim dowolny program użytkowy używający tych danych zostanie wykonany.

6. Architektura dwuwarstwowa.

ARCHITEKTURA DWUWARSTWOWA

W myśl tej koncepcji systemy oparte na tej architekturze podzielono na dwie części. Z jednej strony została wydzielona pewna część systemu (inaczej mówiąc proces) odpowiedzialna za przechowywanie danych i zachowanie ich pełnej spójności.

Z drugiej strony wydzielono pewne aplikacje czy procesy , które pobierają dane od użytkownika wyświetlają je i przetwarzają , a następnie albo przesyłają je do serwera w celu zapamiętania, albo generują pewne zapytania w celu uzyskania konkretnych informacji z komputera-serwera.

W ten sposób cały proces przetwarzania danych mamy podzielony na dwie części. Z jednej strony mamy serwer, który przechowuje dane, ale potrafi także je wyszukiwać z przechowywanej bazy na podstawie zapytań poszczególnych komputerów (klientów), a z drugiej strony mamy aplikacje klienta, które tak naprawdę nic nie muszą wiedzieć o fizycznej strukturze danych przechowywanych na serwerze o sposobie ich zarządzania o liczbie użytkowników, a muszą jedynie umieć wysłać zapytanie do bazy , wyświetlić informacje na ekranie lub wysłać do serwera polecenie aktualizujące dane.

+ architektura klient/serwer

7. Architektura dwu i pół warstwowa

ARCHITEKTURA DWU I PÓŁ WARSTWOWA

Powstała idea przeniesienia pewnej warstwy funkcjonalnej, czyli sposobów zarządzania i przetwarzania informacjami na stronę serwera tak, aby aplikacje klienckie dostały jedynie pewną listę funkcji, operacji, żądań jakie mogą realizować, a nie miały bezpośredniego dostępu do danych. Takie umieszczenie po stronie serwera było możliwe dzięki temu, że wiele serwerów baz danych wyposażono w mechanizm zwany procedurami wbudowanymi i trigerami, czyli pewnymi procedurami, które uruchamiają się automatycznie przy zachodzeniu pewnych zjawisk.

Trigery powodują np., że przy zmianie pewnych danych inne się uaktualniają; gdy usuwamy z naszej bazy informacje o kliencie, to chcemy usunąć wszystkie zamówienia jakie on złożył itd. Procedury te powinny uruchamiać się automatycznie, bez ingerencji użytkownika.

W takiej architekturze mamy zatem do czynienia z aplikacją kliencką, która nie odwołuje się bezpośrednio do bazy danych, ale jedynie wywołuje pewne operacje w serwerze danych, który bądź udostępnia pewne dane bądź realizuje wywołane procedury bazodanowe.

Drugim elementem są zaimplementowane w bazie danych reguły biznesowe wspólne dla wszystkich aplikacji klienckich. Wymiana takiej reguły powoduje, że sposób funkcjonowania aplikacji klienta zmieni się dla każdego klienta jednocześnie. Taką aplikację z warstwą kliencką i warstwą serwera bazy danych, który nie ogranicza się tylko do przechowywania danych, ale również realizuje funkcje biznesowe nazywamy często architekturą dwu i pół warstwową.

8. Architektura trójwarstwowa.

ARCHITEKTURA TRÓJWARSTWOWA

Jednak istnieją pewne wady tej architektury. Język procedur wbudowanych i trigerów jest dość skomplikowany, a najczęściej jest to "dialekt" języka SQL z pewnymi rozszerzeniami dotyczącymi przetwarzania instrukcji strukturalnych. Niestety każdy producent serwerów baz danych lansuje nieco odmienny format tego języka i trudno znaleźć dwie identyczne pod tym względem bazy danych.

Stąd też istnieje groźba przepisywania od nowa procedur w przypadku zmiany serwera bazy danych. Nie jest to szczególnie skomplikowane, gdyż większość procedur ma podobne mechanizmy ale różnią się składnią.

Ponadto często reguły biznesowe są bardziej skomplikowane niż te podane jako przykłady i do ich realizacji nie zawsze najodpowiedniejszy jest język procedur wbudowanych serwera. Wygodniejsze okazują się języki trzeciej generacji.

Stąd istnieje potrzeba wprowadzania kodu poza strukturą serwera bazy danych. Rodzi się więc pojęcie trzeciej warstwy, warstwy która byłaby niezależna zarówno od serwera jak też od aplikacji klienckiej, a która odpowiadałaby za przetwarzanie funkcjonalne samej informacji.

W ten sposób aplikacja kliencka nie komunikowałaby się z bazą danych, a nawet nie musiałaby wiedzieć o jego istnieniu, a komunikowałaby się jedynie z pewnym komputerem, na którym zainstalowany byłby; tzw. serwer aplikacji. Wykonywałby on procedury na żądanie aplikacji klienckiej, a one odwoływałyby się do bazy danych. Mógłby on także oprócz odwoływania się do bazy samodzielnie realizować pewne operacje.

Mógłby on dokonywać pewnych obliczeń numerycznych, a nawet inicjować realizowanie pewnych operacji bazodanowych na kilku serwerach baz danych jednocześnie. Warstwa aplikacyjna jest wtedy odpowiedzialna za spójność danych posadowionych na kilku serwerach oraz za to, aby aplikacja kliencka nie "wnikała" w to gdzie fizycznie posadowione są dane, do których się odwołuje. W ten sposób warstwa środkowa (aplikacyjna) stanowiłaby odrębną płaszczyznę programową w architekturze klient/serwer, z własnym językiem (środowiskiem) programistycznym.

Widać więc, że w łatwy sposób posługując się architekturą klient/serwer możemy przeskalować swoje myślenie od poziomu prostego systemu do modelu trójwarstwowego, za pomocą którego tworzymy duże systemy informatyczne.
W architekturze trójwarstwowej istnieje szereg standardów komunikowania się między warstwami.

Tak jak mechanizm ODBC stosowany jest w architekturze dwuwarstwowej, tak tu możemy mówić o standardzie RPC, czyli zdalnym wywoływaniu procedur. Jest to jeden ze standardów przetwarzania rozproszonego, kiedy aplikacja kliencka wywołując procedurę przekazuje parametry i inicjuje wykonanie procedury na innym komputerze, który z kolei wykonując pewne obliczenia zwraca wyniki do procedury, która wywołała je z aplikacji klienckiej.

9. Modele systemów zarządzania bazami danych - model hierarchiczny a model sieciowy

Modele systemów zarządzania bazami danych (modele baz danych)

Hierarchiczny

Obiektowy

Relacyjny

Sieciowy

Hierarchiczny model danych został opracowany w wyniku analizy istniejących implementacji. Model ten używa dwóch struktur, którymi są: typy rekordów i związki nadrzędny-podrzędny. Typ rekordów jest nazwany strukturą danych, złożoną ze zbioru nazwanych pól. Każde pole jest używane do przechowywania prostego atrybutu i jest mu przyporządkowany typ danych.

Powiązanie nadrzędny-podrzędny jest związkiem jeden-do-wiele między dwoma typami rekordów. Mówimy, że typ rekordu po stronie jeden związku jest nadrzędnym typem rekordu; rekord po stronie wiele jest podrzędnym typem rekordu.

A więc, schemat hierarchiczny jest złożony z wielu typów rekordów, powiązanych ze sobą za pomocą związków nadrzędny-podrzędny. Zauważmy, że schemat ten ma wiele podobieństw do relacyjnego modelu danych. Zasadniczymi różnicami są:

• Struktury danych są inne: w hierarchicznym modelu danych mamy typy rekordów; w relacyjnym modelu mamy relacje i związki.

• Związki są inaczej implementowane; w hierarchicznym modelu danych przez powiązania nadrzędny-podrzędny; w relacyjnym modelu danych przez klucze obce.

W hierarchicznym modelu danych operowanie danymi jest wykonywane przez wbudowane funkcje dostępu do baz danych w wybranym języku programowania (tak zwanym języku gospodarza).

Istnieje wiele wewnętrznych więzów integralności w modelu hierarchicznym, które są zawsze obecne, gdy tworzymy schemat hierarchiczny. Przykładami takich więzów są:

• Nie mogą istnieć żadne wystąpienia rekordów, z wyjątkiem rekordu korzenia (najwyższego w hierarchii), bez powiązania z odpowiednim wystąpieniem rekordu nadrzędnego. Oznacza to, że:

- Nie można wstawić rekordu podrzędnego dopóty, dopóki nie zostanie powiązany z rekordem nadrzędnym.

- Usunięcie rekordu nadrzędnego powoduje automatyczne usunięcie wszystkich powiązanych z nim rekordów podrzędnych.

• Jeżeli podrzędny typ rekordu ma związane dwa
  lub więcej nadrzędnych typów rekordów, to
  rekord podrzędny musi zostać powielony dla
  każdego rekordu nadrzędnego.

W hierarchicznym modelu bazy danych (HMBD) dane mają strukturę, którą można przedstawić jako odwrócone drzewo. Jedna z tabel pełni rolę „korzenia” drzewa, a pozostałe mają postać „gałęzi” biorących swój początek w korzeniu. Rysunek przedstawia diagram struktury HMBD.

rys

Diagram modelu hierarchicznego. (Baza danych pośredników. W przykładzie każdy pośrednik pracuje dla kilku muzyków i ma pewną liczbę klientów, którzy zamawiają u niego obsługę muzyczną różnych imprez. Klient zawiera umowę z muzykiem przez pośrednika i u tego właśnie pośrednika uiszcza należność za usługę.).

W hierarchicznym modelu bazy danych dane mają strukturę odwróconego drzewa, podobnie jak struktura drzewa katalogowego w systemie DOS® czy Windows®. W modelu tym tabela nadrzędna powiązana jest z wieloma tabelami podrzędnymi, natomiast jedna tabela podrzędna powiązana może być tylko z jedną tabelą nadrzędną. Na przykład:

Schemat hierarchicznego modelu bazy danych

Relacje w HMBD są reprezentowane w kategoriach „ojciec/syn”. Oznacza to, że tabela nadrzędna (ojciec) może być powiązana z wieloma tabelami podrzędnymi (syn), lecz pojedyncza tabela podrzędna może mieć tylko jedną tabelę nadrzędną. Aby uzyskać dostęp do danych w modelu hierarchicznym, użytkownik zaczyna od korzenia i przedziera się przez całe drzewo danych, aż do interesującego go miejsca. Oznacza to, że użytkownik musi dobrze znać strukturę bazy danych.

Zaletami tego modelu danych jest szybkie przywoływanie potrzebnych danych oraz automatycznie wbudowana integralność odwołań.

Największym problemem modelu hierarchicznego jest nadmiarowość danych ze względu na niezdolność do obsługi złożonych relacji.

Hierarchiczny model danych był z powodzeniem stosowany w systemach zapisu taśmowego, wykorzystywanych w komputerach typu „mainframe” do późnych lat siedemdziesiątych, i zdobył dużą popularność w firmach polegających na tych systemach.

Pomimo tego, że HMBD zapewniał szybki, bezpośredni dostęp do danych i znajdował zastosowanie w rozwiązaniu wielu problemów, narastała potrzeba wprowadzenia nowego modelu danych nie wymagającego wprowadzania tak dużej nadmiarowości danych zaburzających integralność bazy.

10. Nowe wymagania dotyczące modeli baz danych.

11. Modele systemów zarządzania bazami danych - model relacyjny

Relacyjny model danych jest modelem danych zorientowanym na wartości. Nie wprowadza możliwości przyporządkowania jednoznacznego identyfikatora każdemu obiektowi w bazie danych.

Dlatego dwie identyczne krotki w relacyjnym modelu danych wskazują na ten sam obiekt. Dwa identyczne rekordy w obiektowej bazie danych mogą odwoływać się do dwóch różnych obiektów dzięki wprowadzeniu jednoznacznego identyfikatora generowanego przez system

Wszystkie obiekty muszą mieć własność hermetyzacji. Jest to proces umieszczania danych i procesu w jednym opakowaniu w ramach zdefiniowanego interfejsu i udostępniania go z zewnątrz w sposób kontrolowany przez ten interfejs. Hermetyzacja przejmuje się niejawnie w definicję obiektu, ponieważ wszystkie operacje na obiektach muszą być wykonywane przez zdefiniowane procedury dołączone do obiektów.

Klasa obiektów jest zgrupowaniem podobnych obiektów. Używamy jej do określenia wspólnych dla grupy obiektów atrybutów, metod i związków. Obiekty są więc instancjami pewnej klasy. Mają one te same atrybuty i metody. Innymi słowy, klasy obiektów definiują schemat bazy danych - główny temat dziedziny projektowania baz. Obiekty definiują zawartość bazy danych - główny temat dziedziny implementacji baz danych.

Tak więc bazy danych zastosowano w nowych dziedzinach, formułując nowe, wymagania związane z

zarządzaniem danymi.

Przykładami takich wymagań są:

• Dane niejednorodne Tradycyjne modele danych operują na jednorodnych zbiorach obiektów, charakteryzujących się niewielką liczbą typów i dużą liczbą wystąpień każdego typu. Nowe zastosowania baz danych wymagają natomiast różnorodnej kolekcji projektowanych obiektów, które charakteryzuje duża liczba typów oraz stosunkowo mała liczba wystąpień każdego typu.

• Długie łańcuchy znakowe o zmiennej długości (variable length & long strings). Zapis informacji multimedialnej w postaci cyfrowej zawiera długie łańcuchy znakowe, przy czym długość tych łańcuchów jest zmienna. Tradycyjne bazy danych głównie pracują na formatowanych liczbach, krótkich łańcuchach i rekordach o ustalonym formacie.

• Obiekty złożone (complex objects). Cechują się one hierarchiczną strukturą danych. Często muszą być traktowane jako niepodzielne jednostki danych, mieć charakter abstrakcyjny. Konwencjonalne modele danych nie zapewniają takiego poziomu abstrakcji.

• Wielowersyjność (version control). W wielu współczesnych zastosowaniach potrzebne jest zachowanie poprzednich lub alternatywnych wersji obiektu dla prześledzenia historii procesu (back tracking) lub jego odtworzenia (recovering). Tradycyjne bazy danych reprezentują dane aktualne; stare wersje danych nie są zachowywane lub nie są bezpośrednio dostępne dla użytkownika.

• Ewolucja schematu (scheme evolution). Bazy danych wspomagające projektowanie, z reguły podlegają modyfikacji schematu, w miarę ewoluowania projektowanych przedmiotów. Schemat w konwencjonalnych bazach danych nie podlega tak szybkim zmianom.

• Obiekty równoważne (equivalent objects). Projektowany obiekt można rozpatrywać z różnych punktów widzenia, co odpowiada istnieniu w bazie danych jego różnych reprezentacji. W przypadku zmiany wprowadzonej do jednej reprezentacji obiektu, system zarządzania bazą powinien dokonać odpowiednich zmian we wszystkich pozostałych reprezentacjach danego obiektu. Tradycyjne bazy danych nie mają mechanizmów do modelowania semantyki obiektów równoważnych.

• Długie transakcje (long transactions). Transakcja jest sekwencją operacji zapisywania i odczytu, która nie narusza integralności bazy danych. W tradycyjnych bazach danych transakcje są zazwyczaj krótkie i dotyczą jednego rekordu lub określonej grupy rekordów. Inna sytuacja powstaje w bazach danych wspomagających projektowanie. Projektowanie i testowanie jednego obiektu może trwać tygodnie przed ostatecznym wprowadzeniem tego obiektu do bazy danych. Dlatego w przypadku odrzucenia danej wersji projektu, system zarządzania bazą danych powinien być zdolny do przywrócenia odpowiednio wczesnego stanu transakcji, by można było iteracyjnie powtórzyć dany etap projektowania.

Tradycyjne modele danych, w tym najbardziej popularny model relacyjny, nie były w stanie sprostać lub w efektywny sposób spełniać tych wymagań. Dlatego też, w drugiej połowie lat 80-tych, popularność w systemach informatycznych zyskuje podejście obiektowe.

Szczególne znaczenie w rozwoju systemów obiektowych ma dynamiczny rozwój języków programowania opartych na pojęciu obiektu. Początku tego trendu w programowaniu należy szukać w latach powstania języka Simula (1966 r.) oraz jego następcy - języka Smalltalk. Większość obecnych obiektowych baz danych używa języka C++ (1980 r.) jako podstawę opisu języka baz danych.

Powstaje więc kilka kierunków rozwoju baz danych.

Po pierwsze - dalszy rozwój systemów opartych o relacyjny model danych. Prawdopodobnie będzie jeszcze długo w powszechnym użyciu, ze względu na:

• ich obecne bardzo duże rozpowszechnienie,

• zaufanie jakim cieszą się wśród użytkowników,

• doprowadzoną do perfekcji technologię dotyczącą w szczególności ochrony danych i optymalizacji zapytań,

• prostotę i elastyczność relacyjnego modelu danych.

Drugi kierunek rozwoju baz danych to obiektowo - relacyjne bazy danych. Ich twórcy starają się zachować jak najwięcej z modelu relacyjnego (aby wykorzystać osiągnięcia relacyjnych baz danych), a jednocześnie wprowadzać pewne aspekty obiektowe. Przedstawicielem tego kierunku jest standard SQL3.

Trzecim kierunkiem rozwoju, najbardziej obiecującym, to obiektowe bazy danych. Standardem takich baz jest ODMG (Object Database Management Group), organizacja skupiająca firmy tworzące obiektowe bazy danych. ODMG stworzyła standardy takich baz, najnowszą z wersji jest ODMG 2.0. Elementami tego standardu są: ODL (Object Definition Language - Język definiujący obiekty), OQL (Object Query Language - Obiektowy język zapytań) oraz tzw. wiązania do trzech języków programowania: C++, Smalltalk i Java.

Relacyjny model bazy danych (RMBD)

Twórcą relacyjnego modelu danych jest E. F. Codd. W 1970 roku opublikował pracę, która położyła fundament pod najbardziej ze współczesnych modeli danych. Od 1968 do 1988 r. Codd opublikował ponad 30 prac na temat relacyjnego modelu danych. Codd powołuje się na trzy problemy, którym poświęca swoją teoretyczną pracę. Po pierwsze, twierdzi, że wcześniejsze modele danych traktowały dane w niezdyscyplinowany sposób. Jego model, przy użyciu ścisłych narzędzi matematycznych, zwłaszcza teorii zbiorów, wprowadza zdyscyplinowany sposób posługiwania się danymi.

Codd oczekiwał, że w wyniku stosowania ścisłych metod zostaną osiągnięte dwie podstawowe korzyści. Po pierwsze, zostanie poprawiony możliwy do uzyskania poziom niezależności między programami a danymi. Po drugie, wzrośnie wydajność tworzenia oprogramowania.

Zgodnie z teorią model danych w relacyjnych bazach danych składa się z trzech podstawowych elementów:

• Relacyjnych struktur danych

• Operatorów relacyjnych umożliwiających tworzenie, przeszukiwanie i modyfikację bazy danych

• Więzów integralności jawnie lub niejawnie określających wartości danych

Podstawową strukturą danych jest relacja będąca podzbiorem iloczynu kartezjańskiego dwóch wybranych zbiorów reprezentujących dopuszczalne wartości. W bazach danych relacja przedstawiana jest w postaci tabeli. Relacja jest zbiorem krotek posiadających taką samą strukturę, lecz różne wartości.

Każda krotka odpowiada jednemu wierszowi tablicy. Każda krotka posiada co najmniej jeden atrybut odpowiadający pojedynczej kolumnie tablicy. Każda relacja (tablica) posiada następujące własności:

• krotki (wiersze) są unikalne

• atrybuty (kolumny) są unikalne

• kolejność krotek (wierszy) nie ma znaczenia

• kolejność atrybutów (kolumn) nie ma znaczenia

• wartości atrybutów (pól) są atomowe

Każda krotka odpowiada jednemu wierszowi tablicy. Każda krotka posiada co najmniej jeden atrybut odpowiadający pojedynczej kolumnie tablicy. Każda relacja (tablica) posiada następujące własności:

• krotki (wiersze) są unikalne

• atrybuty (kolumny) są unikalne

• kolejność krotek (wierszy) nie ma znaczenia

• kolejność atrybutów (kolumn) nie ma znaczenia

• wartości atrybutów (pól) są atomowe

Dokumentacja systemów zarządzania bazami danych posługuje się najczęściej terminologią tabela, wiersz i kolumna, a nie terminologią relacyjną. Wynika to z tego, że operacje na relacjach są opisywane za pomocą matematycznych operacji na zbiorach i relacjach, które są ścisłe, ale trudno zrozumiałe dla przeciętnego użytkownika. Natomiast posługiwanie się tabelami, wierszami i kolumnami jest mniej formalne i ścisłe, ale bardziej przejrzyste. W dalszej części będzie stosowana zarówno jedna jak i druga terminologia.

Tabela może reprezentować:

• zbiór encji wraz z atrybutami

• zbiór powiązań pomiędzy encjami wraz z ich atrybutami

• zbiór encji wraz z atrybutami i ich powiązania z innymi encjami (wraz z atrybutami)

Każdy wiersz w tabeli reprezentuje pojedynczą encję, powiązanie lub encję wraz z powiązaniami. W tabeli nie powinny powtarzać się dwa identyczne wiersze - zabezpieczenie przed tym powtórzeniem jest realizowane poprzez pola kluczowe. Wiersze w odróżnieniu od kolumn są dynamiczne - działanie bazy danych polega na dopisywaniu, modyfikacji i usuwaniu wierszy.

W przypadku projektowania tabeli w bazie danych należy stosować się do następujących wskazówek:

• Używaj nazw opisowych do nazwania kolumn tabeli. Kolumny nie powinny mieć znaczenia ukrytego, ani reprezentować kilku atrybutów (złożonych w pojedynczą wartość).

• Bądź konsekwentny w stosowaniu liczby pojedynczej lub mnogiej przy nazywaniu tabeli.

• Twórz tylko te kolumny, które są niezbędne do opisania modelowanej encji lub powiązania - tabele z mniejszą ilością kolumn są łatwiejsze w użyciu.

• Utwórz kolumnę pól kluczowych dla każdej tabeli.

• Unikaj powtarzania informacji w bazie danych (normalizacja).

Baza danych jest faktycznie zbiorem struktur danych służących do organizowania i przechowywania danych. W każdym modelu danych i w konsekwencji w każdym SZBD (SZBD - System Zarządzania Bazą Danych) musimy mieć do dyspozycji zbiór reguł określających wykorzystanie takich struktur danych w aplikacjach baz danych. Tworząc definicję danych używamy wewnętrznych struktur danych z myślą o konkretnym zadaniu.

Jest tylko jedna struktura danych w relacyjnym modelu danych - relacja. W związku z tym, że pojęcie relacji jest matematyczną konstrukcją, relacja jest tabelą, dla której jest spełniony następujący zbiór zasad:

1. Każda relacja w bazie danych ma jednoznaczną nazwę. Według Codda dwuwymiarowa tabela jest matematycznym zbiorem, a matematyczne zbiory muszą być nazywane jednoznacznie.

2. Każda kolumna w relacji ma jednoznaczną nazwę w ramach jednej relacji. Każda kolumna relacji jest również zbiorem i dlatego powinna być jednoznacznie nazwana.

3. Wszystkie wartości w kolumnie muszą być tego samego typu. Wynika to z punktu 2.

4. Porządek kolumn w relacji nie jest istotny. Schemat relacji - lista nazw jej kolumn - jest również matematycznym zbiorem. Elementy zbioru nie są uporządkowane.

5. Każdy wiersz w relacji musi być różny. Innymi słowy, powtórzenia wierszy nie są dozwolone w relacji.

6. Porządek wierszy nie jest istotny. Skoro zawartość relacji jest zbiorem, to nie powinno być określonego porządku wierszy relacji.

7. Każde pole leżące na przecięciu kolumny/wiersza w relacji powinno zawierać wartość atomową. To znaczy, zbiór wartości nie jest dozwolony na jednym polu relacji.

W swojej pracy na oznaczenie elementów swojego modelu danych Codd użył terminologii matematycznej. Kolumny tabeli to były atrybuty. Wiersze tabeli to były krotki. Liczba kolumn w tabeli to stopień tabeli. Liczba wierszy w tabeli to liczebność tabeli.

Każda relacja musi mieć klucz główny. Dzięki temu możemy zapewnić, aby wiersze nie powtarzały się w relacji. Klucz główny to jedna lub więcej kolumn tabeli, w których wartości jednoznacznie identyfikują każdy wiersz tabeli.

Klucze obce są sposobem łączenia danych przechowywanych w różnych tabelach. Klucz obcy jest kolumną lub grupą kolumn tabeli, która czerpie swoje wartości z tej samej dziedziny co klucz główny tabeli powiązanej z nią w bazie danych.

W systemach relacyjnych wprowadzono specjalną wartość, aby wskazać niepełną lub nieznaną informację - wartość null. Ta wartość, różna od zera i spacji, jest szczególnie użyteczna przy powiązaniu kluczy głównego i obcego. Pojęcie wartości null nie jest jednak do końca akceptowane. Codd utrzymuje, że wprowadzenie wartości null do systemu relacyjnego zmienia konwencjonalną logikę dwuwartościową (prawda, fałsz) na logikę trójwartościową (prawa, fałsz, nieznane).

Schemat relacji jest to zbiór

R = {A 1 , A 2 ,......., A n}

gdzie A 1 , A 2 , ..., A n są atrybutami ( nazwami kolumn ).

Każdemu atrybutowi przyporządkowana jest dziedzina DOM ( A), czyli zbiór dopuszczalnych wartości.  

 

Dziedziną relacji o schemacie R = {A 1 , A 2 ,......., A n}

nazywamy sumę dziedzin wszystkich atrybutów relacji: DOM ( R) = DOM ( A1) ჈DOM ( A2) ჈...჈DOM ( An)

Relacja o schemacie R = {A 1 , A 2 ,......., A n} jest to skończony zbiór r = { t 1, t 2 , ... , t m }

odwzorowań t i: RႮ DOM ( R) takich, że dla każdego j, 1<= j <= n , t i ( A j )჎ DOM ( A j)

Każde takie odwzorowanie nazywa się krotką (lub wierszem). Krotka odpowiada wierszowi w tabeli.

System zarządzania relacyjną bazą danych, w skrócie SZRBD, to program wykorzystywany do tworzenia i modyfikowania relacyjnych baz danych. Służy również do generowana aplikacji, z której będzie korzystał użytkownik gotowej bazy.

Oczywiście jakość danego SZRBD zależy od stopnia, w jakim implementuje on relacyjny model logiczny. Nawet „prawdziwe” SZRBD niekiedy diametralnie odbiegają od siebie w tej kwestii, a pełnej implementacji RMBD nadal nie udało się nikomu osiągnąć. Mimo to obecne SZRBD są potężniejsze i wszechstronniejsze niż kiedykolwiek.

Systemy zarządzania relacyjnymi bazami danych były wytwarzane przez sporą liczbę producentów oprogramowania od wczesnych lat siedemdziesiątych. Programy te działały na różnych platformach sprzętowych i pod różnymi systemami operacyjnymi. Istnieją implementacje SZRBD na praktycznie dowolny komputer.

Przez pewien czas po stworzeniu modelu relacyjnego SZRBD były pisane tylko na komputery mainframe. Dwoma takimi programami, napisanymi we wczesnych latach siedemdziesiątych, były System R, opracowany przez IBM w laboratorium badawczym w San Jose, oraz INGRES (interaktywny System Obsługi Grafiki; ang. Interactive Graphics Retrieval System), powstały na Uniwersytecie Berkeley. Oba te systemy przysłużyły się znacząco do upowszechnienia modelu relacyjnego.

W miarę jak zalety RMBD stawały się coraz wyraźniejsze, wiele organizacji zaczęło powoli przechodzić z modeli hierarchicznych i sieciowych na model relacyjny, stwarzając tym samym popyt na lepsze i większe programy SZRBD. Lata osiemdziesiąte były okresem burzliwego rozwoju komercyjnych systemów zarządzania dla komputerów mainframe, jak np. Oracle korporacji Oracle, czy DB2 IBM.

Systemy zarządzania relacyjnymi bazami danych mają za sobą długą historię, a rola odgrywana przez nie w obsłudze danych zarówno w dużych, jak i małych organizacjach jest trudna do przecenienia. Należy oczekiwać, że w niedługiej przyszłości wpływ tych programów na nasze życie ulegnie dalszemu zwiększeniu na skutek integracji ich możliwości z architekturą sieci Internet.

Model został oparty na dwóch gałęziach matematyki - teorii mnogości i rachunku predykatów pierwszego rzędu. W RMBD dane przechowywane są w tabelach. Każda tabela składa się z rekordów oraz pól. Fizyczna kolejność pól i rekordów w tabeli jest całkowicie bez znaczenia. Każdy rekord jest wyróżniany przez jedno pole zawierające unikatową wartość. Te dwie cechy RMBD umożliwiają trwanie danych niezależnie od sposobu, w jaki przechowuje je komputer.

12. Algebra relacyjna - podstawowe operacje

Algebra relacyjna jest zbiorem ośmiu operatorów. Każdy operator bierze jedną lub więcej relacji jako argument i produkuje jedną relację jako wynik. Trzema głównymi operatorami algebry relacyjnej są: selekcja (ograniczenie), rzut (projekcja) i złączenie. Dzięki tym trzem operatorom możemy wykonać większość operacji na danych wymaganych od systemu relacyjnego. Istnieją również dodatkowe operatory - iloczyn, suma, przecięcie, różnica i iloraz.

Selekcja. Selekcja jest operatorem, który bierze jedną relację jako swój argument i produkuje w wyniku jedną relację. Selekcja może być uważana za “poziomą maszynę do cięcia", gdyż wydobywa z wejściowej relacji wiersze, które pasują do podanego warunku, i przekazuje je do relacji wynikowej.

Operator selekcji ma składnię:

RESTRICT <nazwa tabeli>

[WHERE <warunek>] Ⴎ <tabela wynikowa>

np.: RESTRICT Studenci WHERE Wiek >= 18 Ⴎ Poborowi

Rzut. Operator rzutu bierze jedną relację jako swój argument i produkuje jedną relację wynikową. Rzut jest “pionową maszyną do cięcia”

Operator projekcji ma składnię:

PROJECT <nazwa tabeli>

[<lista kolumn>] Ⴎ <tabela wynikowa>

np.: PROJECT Studenci (Nazwisko) Ⴎ Lista

Suma. Suma (჈) jest operatorem, który bierze dwie zgodne relacje jako swoje argumenty i produkuje jedną relację wynikową. Zgodne, czyli tabele mają te same kolumny określone na tych samych dziedzinach (uwzględnia wszystkie wiersze z obu tabel w tabeli wynikowej).

Operator sumy ma składnię:

<tabela 1> UNION <tabela 2> Ⴎ <tabela wynikowa>

Przecięcie. Przecięcie (Ⴧ) ma działanie przeciwne działaniu sumy (uwzględnia w tabeli wynikowej tylko wiersze wspólne dla obu tabel).

Operator przecięcia ma składnię:

<tabela 1> INTERSECTION <tabela 2> Ⴎ <tabela wynikowa>

Złączenie.

Złączenia oparte są na relacyjnym operatorze iloczynu kartezjańskiego (Ⴤ), to znaczy z dwóch relacji będących argumentami złączenia produkowana jest jedna relacja wynikowa będąca wszystkimi możliwymi kombinacjami wierszy z wejściowych tabel.

Operator iloczynu kartezjańskiego ma składnię:

PRODUCT <tabela 1> WITH <tabela 2> Ⴎ <tabela wynikowa>

Rozróżnia się:

Równozłączenie, które jest iloczynem kartezjańskim po którym wykonywana jest selekcja. Onacza to, iż łączy się dwie tabele, ale tylko dla wierszy, w których wartości w kolumnach złączenia są takie same. Kolumnami złączenia może być klucz główny jednej tabeli i klucz obcy drugiej tabeli.

Składnia równozłączenia jest następująca:

EQUIJOIN <tabela 1> WITH <tabela 2> Ⴎ <tabela wynikowa>

Złączenie naturalne, które jest iloczynem kartezjańskim po którym wykonywana jest selekcja oraz rzut, w którym nie bierze się pod uwagę kolumn złączenia.

Składnia złączenia naturalnego jest następująca:

JOIN <tabela 1> WITH <tabela 2> Ⴎ <tabela wynikowa>

Może jeszcze istnieć złączenie zewnętrzne, w którym brane są pod uwagę wszystkie wiersze z jednej (złączenie lewostronne lub prawostronne) lub obu relacji (złączenie obustronne), bez względu na to czy mają swoje odpowiedniki.

Różnica W wypadku tego operatora (-) istotna jest kolejność określania argumentów. Produkuje on te wiersze, które są w pierwszej tabeli i jednocześnie nie będące w tabeli drugiej.

Operator różnicy ma składnię:

<tabela 1> DIFFERENCE <tabela 2> Ⴎ <tabela wynikowa>

Algebra relacyjna jest proceduralnym językiem zapytań, ponieważ ma własności domknięcia, to znaczy wynik zastosowania jednego operatora relacyjnego może być przekazany jako argument wejściowy kolejnemu operatorowi relacyjnemu. W związku z tym dowolny ciąg instrukcji algebraicznych można zastąpić jednym wyrażeniem zagnieżdżonym.

Operacje dynamiczne na relacjach

Istnieją trzy podstawowe operacje dynamiczne potrzebne do wspomagania działań wyszukiwania:

• wstawianie (INSERT)

• usuwanie (DELETE)

• modyfikacja (UPDATE)

INSERT (<wartość>,<wartość>,...) INTO <nazwa tabeli>
DELETE <nazwa tabeli> WITH <warunek>
UPDATE <nazwa tabeli> WHERE <warunek> SET <nazwa kolumny> = <wartość>

Podczas modyfikacji trzeba uważać, żeby nie naruszyć żadnych więzów integralności określonych w schemacie relacji.

13. Integralność danych

Mówimy, że baza danych ma właściwość integralności, kiedy istnieje odpowiedniość między faktami przechowywanymi w bazie danych a światem rzeczywistym modelowanym przez tą bazę. Tą właśnie integralność zapewniają reguły integralności, które można podzielić na dwa rodzaje: integralność encji oraz integralność referencyjną.

Integralność encji dotyczy kluczy głównych. Mówi ona, że każda tabela musi mieć klucz główny i, że kolumna lub kolumny wybrane jako klucz główny powinny być jednoznaczne i nie zawierać wartości null. Wynika stąd, że w tabeli są zabronione powtórzenia wierszy.

Integralność referencyjna dotyczy kluczy obcych. Mówi ona, że wartość klucza obcego może się znajdować tylko w jednym z dwóch stanów.

Wartość klucza obcego odwołuje się do wartości klucza głównego w tabeli w bazie danych. Czasami wartość klucza obcego może być null, co oznacza że nie ma związku między reprezentowanymi obiektami w bazie danych albo że ten związek jest nieznany.

Utrzymywanie integralności referencyjnej, oprócz określenia czy klucz obcy jest null czy nie, obejmuje również określenie więzów propagacji. Mówią one co powinno się stać z powiązaną tabelą, gdy modyfikujemy wiersz lub wiersze w tabeli docelowej.

Są trzy możliwości, które określają co się będzie działo z docelowymi i powiązanymi krotkami dla każdego związku między tabelami w naszej bazie:

• Ograniczone usuwanie (Restricted). Podejście ostrożne - nie dopuszcza do usuwania rekordu nadrzędnego, jeśli istnieją rekordy podrzędne.

• Kaskadowe usuwanie (Cascades). Podejście ufne - przy usuwaniu rekordu nadrzędnego usuwa także rekordy podrzędne.

• Izolowane usuwanie (Isolated). Podejście wyważone - usuwa jedynie rekord nadrzędny.

Oprócz wewnętrznej integralności bazy danych można do schematu relacji dodać dodatkową integralność, przez dołączenie ciągu definicji więzów, zapisanych w postaci wyrażeń algebry relacyjnej lub rachunku relacyjnego. Najczęściej stosuje się do tego zagnieżdżone wyrażenia algebry relacyjnej.

14. Modelowanie danych - typy związków

Modelowanie danych

Diagramy związków encji (ang. entity relationship diagramming; nazywa się je również diagramami ER) są metodą modelowania danych. Obrazują podstawowe składniki bazy danych i związki między nimi w trakcie jej projektowania.

Diagram ER jest często nazywany semantycznym modelem danych. Słowo model wskazuje, że ze świata rzeczywistego będziemy pobierać tylko te dane, które są istotne dla tworzenia systemu komputerowego.

Semantyczny charakter diagramu ER wiąże się z uwzględnianiem znaczenia składników diagramu.

W przypadku diagramu ER, encje są zazwyczaj opisywane rzeczownikami, atrybuty- przymiotnikami i rzeczownikami, a związki - czasownikami. Ponieważ encje są powiązane ze sobą za pomocą związków, jakie tworzą, znaczenie każdej z nich wynika z jej kontekstu, tak jak znaczenie wyrazu w zdaniu z kontekstu, w jakim został użyty.

Pierwsza próba utworzenia modelu danych polega na rozpatrzeniu pomysłów i zorientowaniu się, jak różne elementy informacji mają się względem siebie. Kolejne modyfikacje diagramu ER umożliwiają ulepszanie projektu do chwili, aż będzie możliwe utworzenie z niego bazy danych. Semantyczne modelowanie danych daje sposobność przedstawiania i modyfikowania projektu.  

Diagramy związków encji

 


Encja to zbiór obiektów, istniejących niezależnie i jednoznacznie zdefiniowanych, które mogą być reprezentowane za pomocą jednakowej struktury. Termin encja używany jest zarówno w znaczeniu typ encji, czyli zbiór encji o tych samych własnościach, jak i instancja encji, czyli konkretny egzemplarz encji. W diagramie ER encje o podobnej strukturze są grupowane w zbiory, którym nadaje się nazwy. Nazwy te są umieszczane na diagramie i reprezentują wiele instancji modelowanych obiektów, z których każdy ma identyczną strukturę rekordu.

Przykładowo, encjami w diagramie przedstawionym na rysunku będą KLIENT, WYPOZYCZ, KASETA, FILM.

Przykład systemu pozwalającego na zapisywanie informacji o wypożyczonych kasetach video Po opracowaniu diagramu, nazw encji używa się w relacyjnej bazie danych jako nazw tabel. Encje powiązane są związkami oraz scharakteryzowane pewną liczbą właściwości lub atrybutów.

Atrybuty zawierają opisy cech encji. Z powodów związanych z samą strukturą relacyjnych baz danych, ich typ musi być liczbą całkowitą, liczbą rzeczywistą, datą, wartością logiczną, itd.

Poniższy rysunek przedstawia encję KLIENT z zestawionymi wszystkimi jego atrybutami, takimi jak numer klienta, jego imię, nazwisko, data urodzenia, nazwa ulicy, numer telefonu, numer dowodu, data zapisu oraz miejsce przewidziane na wprowadzenie dodatkowych uwag o kliencie.

Atrybuty stają się nazwami kolumn w tabelach odpowiadających encjom, gdy diagram zostaje przetłumaczony na relacyjną bazę danych. Czasami trudno jest podjąć decyzję, czy coś jest encją, czy atrybutem, np. KLIENT może być atrybutem encji FIRMA

Ogólna zasada w takim przypadku polega na rozpoznaniu, co ma być przechowywane i czy jest do tego potrzebna cała nowa encja, czy też wystarczy tylko atrybut w pewnej encji. Z atrybutem jest zawsze związana tylko jego wartość, podczas gdy z encją można związać cały zbiór informacji.

Dwie encje można często połączyć w jedną, gdy różnią się tylko kilkoma atrybutami. Przy takim połączeniu niektóre instancje encji nie mają przypisanych wartości do niektórych swoich atrybutów. Istnieje specjalna wartość używana w takich przypadkach, która nazywa się wartością pustą (oznaczana przez null), różna od spacji czy zera. Oznacza ona wartość albo nieznaną albo niestosowaną w danej sytuacji.

Połączenie dwóch podobnych rodzajów encji w jedną ma uzasadnienie wtedy, kiedy dzięki temu zostaje uproszczony model i baza danych. Trzeba pamiętać, że im więcej encji, tym bardziej skomplikowany system. Za uproszczenie modelu płaci się zwykle zwiększoną pamięcią, jak również utratą zdolności odróżnienia rzeczywiście różnych encji.

Ten konflikt między kosztem, a prostotą jest bardzo trudny do pogodzenia podczas projektowania systemu, ponieważ zależy w dużej mierze od sposobu użycia danych po zainstalowaniu systemu dla użytkowników. Jest to jedno z zagadnień, z którymi projektanci bazy danych mają najwięcej kłopotów.

Należy pamiętać, że wartością każdego atrybutu musi być wartość prostego typu danych, aby można było bezpośrednio przejść od diagramu do relacyjnej bazy danych. W przypadku związania z encją zbioru wartości, zbiór ten musi być reprezentowany jako osobna encja.

Atrybuty mogą opisywać dana encję lub reprezentować związki danej encji z innymi.

Klucz jest to atrybut lub zbiór atrybutów dla danego typu encji, których wartości jednoznacznie identyfikują każdą instancję encji. W składa klucza mogą wchodzić atrybuty określające związki danej encji z innymi. Na diagramie atrybuty klucza mogą być zaznaczane przez umieszczenie gwiazdki lub pogrubione.

W początkowej fazie tworzenia modelu danych nie należy stosować tzw. atrybutów wyliczanych. Są to atrybuty definiowane za pomocą innych atrybutów, np. wiek na podstawie daty urodzenia.

Związki zachodzące pomiędzy encjami

 Związek jest to uporządkowana lista encji, w której poszczególne encje mogą występować wielokrotnie. Związki określają wzajemne relacje między zbiorami egzemplarzy encji, wchodzących w skład związku. Taka relację nazywa się instancją związku. Związek można formalnie zapisać przy użyciu notacji relacyjnej, jako:

Z(E1,....,En)

Przykładowo, klient może dokonywać wielokrotnie wypożyczenia kaset - każdemu więc klientowi jest przyporządkowany zbiór kaset. Na rysunku poniżej słowo WYPOŻYCZA, umieszczone w ramce, symbolizuje związek między encjami.




Przykładowe związki między encjami Klient i Kaseta

Związek WYPOŻYCZA ma przyporządkowaną literę N po stronie KLIENT, a literę M po stronie KASETA. Oznaczenie to określa liczebność związku i wskazuje (w tym przypadku), że każdy KLIENT mógł wypożyczyć dowolną liczbę KASET oraz, że każda z KASET może zostać wypożyczona kilkakrotnie dla różnych klientów. Mamy więc tu do czynienia ze związkiem wieloznacznym.

Większość związków to związki binarne, czyli dwuargumentowe, reprezentowane przez linię łączącą dwie encje. Rozróżnia się następujące rodzaje związków binarnych: jedno-jednoznaczne (jeden do jeden), jednoznaczne (wiele do jeden lub jeden do wiele) i wieloznaczne (wiele do wiele).

Związki jedno-jednoznaczne (jeden do jednego)

 Związki jedno - jednoznaczne charakteryzują się tym, że dla każdej instancji jednej z dwóch encji istnieje dokładnie jedna instancja drugiej encji, pozostająca z nią w rozważanym związku. Związki jedno - jednoznaczne rzadko występują w bazach danych, ponieważ istnieje tendencja, aby łączyć takie pary encji w jedną.

Aby rozpoznać tego typu związek, należy sprawdzić, czy dla każdej instancji jednej encji istnieje dokładnie jedna instancja encji po przeciwnej stronie związku, a następnie to samo powtórzyć dla drugiej. Przykładem tego typu związku mógłby być związek pomiędzy KLIENT a jego numerem identyfikacji PESEL, gdyby on występował w oddzielnej encji.

Związki jednoznaczne (jeden do wielu, lub wiele do jednego)

 Związki jednoznaczne są najczęściej spotykanymi związkami w typowych bazach danych. Dzieje się tak dlatego, ponieważ związek wieloznaczny można prawie zawsze uprościć, zamieniając go na dwa związki jednoznaczne.

Jednoznaczne związki są realizowane przez utworzenie atrybutu encji po stronie wieloznacznej (tzn. etykietowanej przez N), aby umieścić w nim klucz encji znajdującej się po stronie jednoznacznej (tzn. etykietowanej przez 1). Jednoznaczne związki są zawsze reprezentowane powiązaniem przez wartość klucza obcego w tabeli odpowiadającej encji po stronie wiele związku i klucza głównego w tabeli odpowiadającej encji po stronie jeden.

Związki wieloznaczne (wiele do wielu)

Związki wieloznaczne - przed zastąpieniem ich dwoma związkami jednoznacznymi - są bardzo powszechne w bazach danych. Encje KLIENT i KASETA na przykład są powiązane związkiem WYPOZYCZ na przedstawionym wcześniej rysunku. Litery N i M po obu stronach związku na tym rysunku oznaczają, że każdy klient może wypożyczyć wiele kaset. Po drugiej stronie związku, każda kaseta będzie wybrana przez wiele osób.

W praktyce, związki wieloznaczne sprawiają kłopot w relacyjnych bazach danych, ponieważ przy tłumaczeniu modelu do relacyjnej bazy danych atrybut używany do połączenia encji, tzn. klucz obcy, musi zawierać listę wartości dla każdej powiązanej instancji w innej encji. W naszym przykładzie - dla każdego klienta trzeba przechowywać listę kaset i podobnie, dla każdej kasety trzeba przechowywać listę klientów, którzy ją oglądali.

Wieloznaczny związek może być łatwo usunięty z modelu przez utworzenie nowej encji i zastąpienie wieloznacznego związku dwoma jednoznacznymi związkami.

Ta nowa encja spełnia funkcję pośrednika dla instancji obu encji i ponieważ używa dwóch związków jednoznacznych, łatwo ją przekształcić na dwa klucze obce w nowej encji. Jeżeli do naszego przykładu dodamy encję WYPOZYCZ, to każdy klient będzie miał przypisaną listę wypożyczeń, a każda KASETA będzie związana z kolei ze swoją listą klientów.

Specyficznym rodzajem związku jest związek rekurencyjny, zachodzący między tymi samymi encjami,

np.: Element urządzenia jest częścią elementu urządzenia.

W przypadku związków encji o większej niż dwa liczbie argumentów, należy je przekształcić na binarne związki jednoznaczne, korzystając z następujących reguł:

* Dla każdego związku o liczbie argumentów większej niż dwa Z(E1,..,En) n>2 wprowadza się nową encję E0 oraz n jednoznacznych związków binarnych Z1(E0,E1) łączących nową encję ze starymi. Klucz encji E0 jest sumą kluczy encji E1,...,En.

Dla każdego wieloznacznego związku binarnego Z(E1,E2) wprowadza się nową encję E0 oraz 2 związki jednoznaczne Z1(E0,E1) oraz Z2(E0,E2) łączące nowy zbiór encji ze starymi. Klucz encji E0 jest sumą kluczy encji E1 oraz E2.

Przekształcenie diagramów E-R w schematy relacyjne

 obowiązują następujące zasady:

• Dla każdej encji diagramu tworzona jest tabela, przy czym zalecane jest, aby nazwę encji zmienić na liczbę mnogą

• Identyfikujący atrybut encji staje się kluczem głównym tabeli

• Pozostałe atrybuty encji stają się niegłównymi atrybutami tabeli,

• Dla każdego związku jeden do wiele klucz główny tabeli strony jeden linii związku wstawiamy do tabeli strony wiele linii związku,

• Opcjonalność na stronie wiele linii związku określa, czy klucz obcy reprezentujący związek może być null, czy nie. Jeśli strona wiele jest wymagana, to klucz obcy nie może być null.

• Istniejące związki wiele do wiele musza być wcześniej rozłożone na jeden do wiele, natomiast związki jeden do jeden można zrealizować umieszczając atrybuty obu encji tego związku w jednej tabeli.

• Związek rekurencyjny jeden do wiele przekształca się w jedna tabelę z kluczem obcym, którego wartościami są wartości klucza głównego. Związek rekurencyjny wiele do wiele należy najpierw rozłożyć na związki jeden do wiele.

Modelowanie danych przy pomocy narzędzia CASE - ErWin

 Do modelowania danych, obok stosowanych diagramów związków encji, w postaci zbliżonej do diagramów opisujących schematy baz danych, można stosować tzw. narzędzia CASE o nazwie ErWin firmy Logic Works. Według konwencji ErWin, nazwa tabeli jest zapisywana nad ramką. Atrybuty encji są podzielone na atrybuty identyfikujące, to znaczy wchodzące w skład klucza, oraz atrybuty nieidentyfikujące, to znaczy nie wchodzące w skład klucza. Obie części rozdzielone są pozioma kreską.







Tabela według konwencji ErWin

Związek między dwiema encjami jest reprezentowany za pomocą linii, których położenie ErWin sam rozplanowuje na diagramie, umieszczając po stronie wiele czarne kółko.

Dla związku jednoznacznego ErWin sam wstawia identyfikator encji po stronie jeden do encji po stronie wiele i oznacza go jako (FK) - klucz obcy (Foreign Key)

Diagram związku identyfikującego encji w konwencji ErWin

Przy związku jedno-jednoznacznym czarne kółko oznacza stronę związku, do którego przechodzi identyfikator z drugiej strony związku, oraz pojawia się literka Z oznaczająca zero lub jeden, to znaczy, że każdy Nauczyciel należy do Pracowników, a każdy Pracownik jest Nauczycielem lub nim nie jest. ErWin rozróżnia encje niezależne i zależne, oraz związki identyfikujące i nieidentyfikujące.

• Encja niezależna jest to encja, której jednoznaczny identyfikator składa się wyłącznie z atrybutów opisujących encje, a więc nie zawiera atrybutu oznaczonego przez (FK). Jest ona rysowana jako ramka o ostrych rogach.

• Encja zależna jest to encja, której jednoznaczny identyfikator zawiera co najmniej jeden atrybut opisujący związek, a więc zawiera atrybut oznaczony przez (FK). Jest ona rysowana jako ramka o zaokrąglonych rogach.

• Związek identyfikujący jest to związek jednoznaczny, który wchodzi w skład jednoznacznego identyfikatora encji po swojej stronie wiele. Jest oznaczany linią ciągłą.

• Związek nieidentyfikujący jest to związek jednoznaczny, który nie wchodzi w skład jednoznacznego identyfikatora encji po swojej stronie wiele. Jest oznaczany linią przerywaną.

Diagram związku nieidentyfikującego encji w konwencji ErWin

Związki wieloznaczne muszą być reprezentowane za pomocą encji asocjacyjnych i odpowiednich par związków jednoznacznych identyfikujących encje asocjacyjne, np. związek wieloznaczny pomiędzy pracownikami i zajęciami (rysunek poniżej) należy zastąpić dwoma związkami jednoznacznymi:

Pracownik otrzymuje Przydział

Przydział dotyczy Zajęć (rys.następny):

Związki nieidentyfikujące dzielą się na dwa rodzaje, w zależności od tego, czy encja po stronie wiele jest egzystencjonalnie zależna od encji po stronie jeden, czy też nie.

Encja po stronie wiele jest egzystencjonalnie zależna od encji po stronie jeden jeśli dla każdej instancji encji po stronie wiele jest zawsze określona powiązana z nią związkiem instancja encji po stronie jeden. W przeciwnym przypadku encję po stronie wiele związku nazywamy egzystencjonalnie niezależną od encji po stronie jeden. Oznacza się to przy pomocy pustego rombu stawianego przy encji po stronie jeden.

Jeśli przyjmiemy, że w związku nieidentyfikującym przedstawionym na rysunku powyżej każdy Samochód ma przypisany Nr_modelu, to encja Samochody jest egzystencjonalnie zależna od encji Typy samochodów, jeśli nie (np. samochód jest składakiem), to jest ona egzystencjonalnie niezależna od encji Typy samochodów i w takim przypadku wartością klucza obcego Nr_modelu (FK) w encji po stronie wiele może być NULL

Diagramy w konwencji ErWin pozwalaja na wskazanie atrybutów, na których w bazie danych ma byc założony indeks unikatowy lub zwykły.

Klucz alternatywny to dowolny klucz encji, który nie został wybrany jako klucz główny. Oznaczany jest przez (AKn), gdzie n - kolejny numer klucza alternatywnego. Może to być np. Cena, o ile ceny samochodów nie powtarzają się.

15. Normalizacja baz danych - postacie normalne

Normalizacja

W swojej pracy na temat relacyjnego modelu danych E.F Codd sformułował pewne reguły projektowania relacyjnych baz danych. Te reguły zostały pierwotnie wyrażone jako trzy postacie normalne: pierwsza postać normalna, druga postać normalna i trzecia postać normalna. Proces kolejnego przekształcania projektu bazy danych przez te trzy postacie normalne jest znany jako normalizacja.

W połowie lat siedemdziesiątych spostrzeżono pewne braki w trzeciej postaci normalnej i zdefiniowano mocniejszą postać normalną, znaną jako postać normalna Boyce'a - Codda. Później Fagin przedstawił czwartą postać normalną (1977), a w roku 1979 piątą postać normalną.

Normalizacja jest procesem identyfikowania logicznych związków między elementami bazy i projektowania bazy danych, która będzie reprezentowała takie związki, by nie posiadała ona cech niepożądanych takich jak redundancja (powtarzanie się danych) oraz anomalii istnienia, wstawiania, usuwania i modyfikowania danych. Normalizacja składa się z następujących etapów:

• Zebrania zbioru danych,

• Przekształcenie nieznormalizowanego zbioru danych w tabele w pierwszej postaci normalnej,

• Przekształcenie tabel z pierwszej postaci normalnej w drugą postać normalną,

• Przekształcenie tabel z drugiej postaci normalnej w trzecią postać normalną; jeśli jeszcze w tej postaci występują anomalie danych, to należy:

• Przekształcić trzecią postać normalną w czwartą postać normalną,

• Przekształcić czwartą postać normalną w piątą postać normalną.

Relacja jest w pierwszej postaci normalnej (1NF), wtedy i tylko wtedy, gdy każdy atrybut niekluczowy jest funkcyjnie zależny od klucza głównego. Wartości atrybutów muszą być elementarne tzn. są to pojedyncze wartości określonego typu, a nie zbiory wartości.

Pierwsza postać normalna jest konieczna aby, tabelę można było nazwać relacją. Większość systemów baz danych nie ma możliwości zbudowania tabel nie będących w pierwszej postaci normalnej.

Relacja jest w drugiej postaci normalnej (2NF), wtedy i tylko wtedy, gdy jest w 1NF i każdy atrybut niekluczowy (nie należący do żadnego klucza) jest w pełni funkcyjnie zależny od klucza głównego. W celu sprowadzenia relacji do drugiej postaci normalnej, należy podzielić ją na takie relacje, których wszystkie atrybuty będą w pełni funkcjonalnie zależne od kluczy. Należy zauważyć, że relacja będąca w pierwszej postaci normalnej, jest równocześnie w drugiej postaci normalnej, jeśli wszystkie jej klucze potencjalne są kluczami prostymi.

Dana relacja jest w trzeciej postaci normalnej (3NF), wtedy i tylko wtedy, jeśli jest ona w drugiej postaci normalnej i każdy jej atrybut niekluczowy (nie wchodzący w skład żadnego klucza potencjalnego) jest bezpośrednio zależny (a nie przechodnio funkcjonalnie zależny) od klucza głównego. Aby przejść z drugiej postaci normalnej do trzeciej postaci normalnej usuwamy zależności przechodnie między danymi. Aby to zrobić, w każdej tabeli, dla każdej pary niekluczowych elementów danych sprawdzamy, czy wartość pola A zależy od wartości pola B. Jeśli tak, to przenosimy powiązane elementy do oddzielnej tabeli.

Podział relacji w trzeciej postaci normalnej

Istota procesu normalizacji polega na tym, że:

• Wszystkie elementy danych w tabeli muszą całkowicie zależeć od całego klucza.

• W tabeli nie mogą wystąpić powtarzające się grupy danych,

• W tabeli nie powinny występować zależności przechodnie między danymi.

Proces przekształcania nieznormalizowanego zbioru danych w pełni znormalizowaną bazę danych (w trzeciej postaci normalnej) nazywamy procesem rozkładu odwracalnego. Przy każdym kolejnym przekształceniu dzielimy strukturę danych na coraz więcej tabel (poprzez rzutowanie), bez straty podstawowych związków między elementami danych, a więc z możliwością odwrócenia operacji rozkładu.

Metoda rozkładu wymaga, aby cały zbiór danych był w pełni określony, zanim rozpocznie się proces ciągu rzutów, a ponadto, dla każdego zbioru danych proces ten jest czasochłonny i podatny na błędy. Metodą alternatywną do normalizacji jest metoda diagramów zależności.

Diagramy zależności są graficznym podejściem, polegającym na procesie akomodacji, w celu utworzenia logicznego schematu bazy danych.

Główną zaletą metody diagramów zależności jest to, że określa mechanizm przyrostowego projektowania bazy danych, a więc nie jest konieczny pełny zbiór danych przy rozpoczęciu procesu projektowania, a w trakcie trwania procesu można dodawać nowe elementy danych, dopóki wszystkie zależności nie będą w pełni udokumentowane (zdeterminowane).

Elementy danych rysuje się na diagramie w postaci owali lub kółek, natomiast zależności w postaci strzałek .

Diagram zależności funkcyjnej

Rozróżniamy zależności funkcyjne, łączące determinujący element danych z elementem zależnym (relacja jeden do jednego), oraz zależności niefunkcyjne. Mówimy, że element danych B jest niefunkcyjnie zależny od elementu danych A, jeżeli dla każdej wartości elementu danych A istnieje ograniczony zbiór wartości elementu danych B (relacja jeden do wiele).

Zależności niefunkcyjne lub wielowartościowe oznaczamy strzałkami z dwoma grotami, skierowanymi jak poprzednio, od determinującego elementu danych do zależnego. Zależności między dwoma elementami danych można rysować tylko w jedną stronę, przy czym zależność może być funkcyjna (jednowartościowa) w jednym kierunku, ale wielowartościowa w drugim kierunku. W takich przypadkach należy zawsze wybrać kierunek zależności funkcyjnej. Przy zależnościach funkcyjnych lub niefunkcyjnych w obu kierunkach, kierunek nie gra roli.

Mogą również istnieć zależności przechodnie, to znaczy takie, w których A determinuje B, B determinuje C, ale A determinuje również C. Należy je uprościć do łańcucha: A do B oraz B do C

Diagram zależności przechodniej

 

Czasami do zdeterminowania jakiegoś elementu danych potrzeba kilku elementów. Taką grupę determinujących elementów nazywamy złożonym związkiem determinującym. Zależność funkcyjną rysuje się od najbardziej zewnętrznego owalu.

Proces przekształcania diagramu zależności w zbiór struktur tabel lub schemat relacyjny nazywamy akomodacją, przy czym obowiązują tu reguły Boyce'a - Codda:

• Każdy funkcyjnie determinujący element staje się kluczem głównym tabeli

• Wszystkie bezpośrednio zależne od niego elementy danych stają się niegłównymi atrybutami tabeli

Diagram zależności może służyć do identyfikacji kluczy kandydujących. Klucz kandydujący jest to element danych, który może pełnić funkcję klucza głównego. W diagramie zależności klucze kandydujące są reprezentowane przez determinujące elementy danych.

Relacja jest w postaci normalnej Boyce'a-Codda, gdy każdy funkcyjnie determinujący element staje się kluczem kandydującym, z których jeden pełni funkcje klucza głównego.

Najważniejszymi z postaci normalnych są trzecia postać normalna oraz postać normalna Boyce'a - Codda. Trzecią postać normalną da się uzyskać dla dowolnego schematu bazy danych nie tracąc, ani własności zachowywania zależności, ani własności odwracalności. Schemat może być w trzeciej postaci normalnej i nie mieć postaci normalnej Boyce'a - Codda. Każdy schemat w postaci normalnej Boyce'a - Codda jest natomiast w trzeciej postaci normalnej.

niepełne!!! reszta na slajdzie

16. Projektowanie relacyjnej bazy danych - etapy (fazy) projektowania

Projektowanie relacyjnych baz danych składa się z trzech faz: analizy wymagań, modelowania danych i normalizacji.

• Faza analizy wymagań zakłada wgłębienie się w sposób funkcjonowania obsługiwanej organizacji, przeprowadzenie rozmów z jej pracownikami i kierownictwem, w celu dokonania oceny aktualnie wykorzystywanego systemu i poczynienia prognoz na przyszłość oraz dokonanie całościowej oceny wymagań informacyjnych organizacji.

• Faza modelowania danych polega na tworzeniu „zrębów struktury” nowej bazy danych. Pomocne stają się tu takie metody modelowania danych, jak tworzenie tzw. diagramów związków encji (ang. entity relationship diagramming; nazywa się je również diagramami ER), analiza zależności semantycznych, czy analiza obiektowa. Każda z tych metod stanowi sposób wizualnej reprezentacji różnych aspektów projektowanej struktury, jak tabel czy relacji oraz ich cech i atrybutów.

W skład modelowania danych wchodzi również definiowanie pól i przypisywanie ich odpowiednim tabelom, przypisanie tabelom kluczy podstawowych, wprowadzenie kolejnych poziomów integralności danych oraz zdefiniowanie poszczególnych relacji za pomocą odpowiednich kluczy obcych.

Kiedy podstawowe struktury tabel są już gotowe, a relacje zostały zdefiniowane zgodnie z przyjętym modelem danych, baza danych jest gotowa do przejścia przez fazę normalizacji.

• Normalizacja jest procesem, w którym następuje rozkład dużych tabel na mniejsze, w celu wyeliminowania redundantnych i powtarzających się danych oraz uniknięcia problemów związanych z wstawianiem, modyfikowaniem i usuwaniem rekordów.

Podczas fazy normalizacji sprawdza się zgodność struktur bazy danych z postaciami normalnymi oraz poddaje się je poprawkom, jeśli zgodność ta nie jest zachowana.

Postać normalna to zestaw kryteriów, które musi spełniać dana tabela, aby mogła być uznana za poprawną i nie przyczyniała się do powstawania błędów. Istnieje kilka różnych postaci normalnych; każda z nich związana jest z eliminowaniem pewnego typu problemów.

Obecnie stosowane postacie normalne to: pierwsza postać normalna, druga postać normalna, trzecia postać normalna, czwarta postać normalna, piąta postać normalna, postać normalna Boyce'a-Codda oraz postać normalna klucza/domeny.

Analiza wymagań

• Formułowanie definicji celu i założeń wstępnych

Pierwszą fazą tworzenia projektu bazy danych jest zdefiniowanie celu oraz założeń wstępnych. „Definicja celu” mówi, po co projektujemy bazę danych, oraz co stanowi punkt odniesienia dla jej twórcy. Określając cel, jakiemu ma służyć baza danych, ułatwiamy tworzenie właściwego projektu i umożliwiamy przechowywanie w gotowej bazie właściwych danych. Oprócz definicji celu na tym etapie należy również sformułować założenia wstępne. Są to wymagania, jakie powinny spełniać dane przechowywane w bazie.

Warunki te powinny uzupełniać definicję celu i pomagać w tworzeniu poszczególnych elementów bazy danych.

Istnieją dwie oddzielne grupy ludzi, którzy mają wpływ na definicję celu i założeń wstępnych.

Pierwsza z nich, składająca się z twórcy bazy danych, właściciela lub dyrektora organizacji, której baza ta ma służyć, oraz członków kierownictwa tejże organizacji, jest odpowiedzialna za definicję celu.

Druga, złożona z twórcy bazy, kierownictwa organizacji oraz przyszłych użytkowników bazy, powinna zająć się sformułowaniem założeń wstępnych.

• Analiza istniejącej bazy danych

Drugą fazą procesu projektowania jest analiza istniejącej bazy danych, jeśli takowa istnieje. W zależności od organizacji, będzie to zazwyczaj baza „spadkowa” lub baza tradycyjna.

Stara baza danych, użytkowana od wielu lat, to baza „spadkowa” (czasem nazywana bazą odziedziczoną). Z kolei baza tradycyjna to luźny zbiór formularzy, teczek, notatek i tym podobnych.

Niezależnie od typu i stanu istniejącej bazy danych, dokładne przyjrzenie się jej strukturze udzieli cennych informacji na temat sposobu wykorzystywania danych przez organizację. Co więcej, analiza ta pozwoli na zrozumienie sposobu, w jaki dane są gromadzone i prezentowane użytkownikom.

• Tworzenie struktur danych

Tworzenie struktur danych jest trzecim etapem procesu projektowania bazy. Należy zdefiniować tabele i pola, wskazać pola kluczowe oraz określić atrybuty każdego z pól.

Tabele są pierwszą strukturą, jaką należy zaprojektować. Tematy, którym mają one być poświęcone, wynikają z założeń wstępnych, zdefiniowanych w pierwszej fazie procesu projektowania oraz z wymagań informacyjnych, ustalonych w fazie drugiej.

Po ustaleniu odpowiednich tematów, należy dla każdego z nich utworzyć tabelę, a następnie przypisać wszystkie pola z listy sporządzonej pod koniec ostatniego etapu do odpowiednich tabel.

Po zakończeniu tej czynności należy przeanalizować każdą tabelę i upewnić się, że reprezentuje ona tylko jeden temat i nie zawiera powtarzających się pól.

Następnie należy przeanalizować każde pole z osobna. Jeśli stwierdzono, że któreś z nich jest wielowartościowe lub segmentowe, trzeba je rozbić tak, aby wszystkie pola w tabeli zawierały pojedyncze wartości.

Pole nie reprezentujące tematu danej tabeli powinno zostać przesunięte do innej, bardziej odpowiedniej tabeli lub zostać usunięte z bazy.

Na koniec należy zdefiniować klucze podstawowe, które będą jednoznacznie identyfikować każdy rekord w poszczególnych tabelach.

Ostatnim krokiem tego etapu jest definiowanie atrybutów dla każdego pola w bazie danych. Należy powtórnie przeprowadzić rozmowy z pracownikami i kierownictwem organizacji w celu ustalenia odpowiednich atrybutów dla poszczególnych pól.

Po zakończeniu tej procedury trzeba zdefiniować i udokumentować atrybuty każdego pola.

Definiowanie relacji

W czwartej fazie procesu projektowania należy zdefiniować relacje między poszczególnymi tabelami. Znowu więc trzeba przeprowadzić rozmowy z użytkownikami bazy, określić istniejące relacje, ustalić ich cechy oraz zagwarantować integralność na poziomie relacji.

Współpraca użytkowników przy określaniu relacji jest niesłychanie pomocna, ponieważ najprawdopodobniej projektantowi nie są znane wszystkie aspekty funkcjonowania danej organizacji.

Większość jej pracowników ma jednak dobre wyobrażenie o danych, na których operuje, i może z łatwością wskazać ewentualne relacje.

Kiedy relacje zostaną już ustalone, należy określić ich cechy. W zależności od typu danej relacji wchodzące w jej skład tabele trzeba połączyć, korzystając albo z klucza podstawowego, albo z tabeli łączącej.

Następnym krokiem powinno być zdefiniowanie typu i stopnia uczestnictwa tabel w poszczególnych relacjach; w większości przypadków cechy te będą w prosty sposób wynikać z rodzaju danych przechowywanych w każdej z tych tabel, czasami jednak trzeba będzie odwołać się do reguł integralności.

• Wprowadzenie reguł integralności

Wprowadzenie reguł integralności jest piątym etapem procesu projektowania bazy danych.

Twórca bazy danych powinien przeprowadzić rozmowy z jej przyszłymi użytkownikami, ustalić ograniczenia, jakim mają podlegać dane, zdefiniować reguły integralności oraz wprowadzić tabele walidacji.

Sposób w jaki dana organizacja wykorzystuje swoje dane, dyktuje wiele ograniczeń, które będą musiały zostać uwzględnione podczas tworzenia bazy danych.

Rozmowy z pracownikami i kierownictwem pomogą ustalić wymagania, które powinny być spełniane przez dane oraz ich struktury. Pełną listę tych wymagań można traktować jako zestaw reguł integralności.

Następnie należy zdefiniować i zaimplementować tabele walidacji, o ile tylko okażą się one przydatne we wprowadzaniu reguł integralności. Na przykład jeżeli niektóre pola mogą przyjmować tylko kilka różnych wartości zdefiniowanych na podstawie wymagań użytkownika, tabele walidacji pomogą w zagwarantowaniu, że rzeczywiste wartości tych pól odpowiadają wartościom dozwolonym.

Ważne staje się tu wprowadzenie poziomu integralności danych, opartego na regułach integralności, ponieważ odnosi się on bezpośrednio do sposobu, w jaki dana organizacja wykorzystuje dane zawarte w bazie. Wraz z ekspansją tej organizacji jej wymagania informacyjne będą ulegać zmianie, a w ślad za nimi również reguły integralności.

Ustalanie reguł integralności jest procesem ciągłym.

• Definiowanie perspektyw

Definiowanie perspektyw to szósta faza procesu tworzenia bazy danych. Jeszcze raz koniecznym staje się skonsultowanie z pracownikami i kierownictwem organizacji i zdefiniowanie odpowiednich perspektyw w oparciu o przedstawione przez nich wymagania.

Trzeba ustalić żądane metody prezentowania danych użytkownikom bazy. Niektórzy pracownicy będą wymagali specjalnych sposobów wizualizacji, w zależności od wykonywanych przez siebie zadań. Przykładowo, pewne osoby mogą chcieć odczytywać dane z kilku tabel jednocześnie; innym wystarczy odwoływanie się do pojedynczych tabel.

Kiedy określi się wymagane sposoby prezentowania danych, należy je zdefiniować formalnie, jako perspektywy.

Każda perspektywa składa się z pól należących do jednej lub większej liczby tabel.

Po zdefiniowaniu wszystkich perspektyw trzeba jeszcze odpowiednio dobrać parametry każdej z nich tak, aby zwracały one tylko żądane rekordy.

• Kontrola integralności danych

Siódmą i ostatnią fazy procesu projektowania bazy danych jest kontrola struktury bazy pod kątem integralności zawartych w niej danych.

Przede wszystkim należy przyjrzeć się każdej tabeli z osobna i upewnić się, że spełnia ona odpowiednie kryteria poprawności; należy też sprawdzić w ten sposób każde z należących do niej pól.

Wszelkie nieścisłości i problemy powinny być teraz rozstrzygnięte i usunięte. Po wprowadzeniu odpowiednich poprawek należy sprawdzić integralność na poziomie tabel.

Następnie trzeba przejrzeć atrybuty wszystkich pól w bazie, wprowadzając konieczne poprawki i sprawdzając integralność na poziomie pól. To pozwoli upewnić się, że integralność wprowadzona na wcześniejszych etapach projektowania bazy została zachowana.

Należy sprawdzić poprawność każdej z relacji oraz jej typ, jak również rodzaj i stopień uczestnictwa wszystkich tabel w relacjach, w których skład wchodzą. Należy przeanalizować integralność na poziomie relacji, upewniając się, że współdzielone pola zawierają odpowiednie wartości oraz że wprowadzanie, modyfikowanie i usuwanie danych z powiązanych tabel nie sprawia żadnych problemów.

Na koniec trzeba ponownie przejrzeć listę reguł integralności, potwierdzając zgodność ograniczeń nakładanych przez nie na bazę danych z ustalonymi wcześniej wymaganiami. Jeśli podczas późniejszych faz procesu projektowania zauważono by konieczność wprowadzenia dodatkowych ograniczeń, należy je uwzględnić jako dodatkowe reguły integralności i dopisać do istniejącej listy.

Po zakończeniu procesu projektowania bazy danych struktura utworzonej bazy będzie gotowa do zaimplementowania w programie SZRBD. Po zaimplementowaniu bazy danych ostatnim etapem przed jej wdrożeniem do użytku jest przeprowadzenie fazy testowania.

17. Fizyczne projektowanie relacyjnej bazy danych

Fizyczne projektowanie relacyjnej bazy danych można podzielić na następujące etapy:

• Opracowanie modelu danych dla planowanego systemu bazy danych, z wykorzystaniem metody modelowania danych,

• Oszacowanie średniej i maksymalnej liczby instancji dla każdej encji. Maksymalna liczba instancji pozwala określić wielkość pamięci dyskowej potrzebnej na wszystkie tabele bazy danych, natomiast średnia liczba instancji pozwala ocenić możliwości modelu co do spełnienia wymagań dotyczących dostępu do danych.

• Przeprowadzenie analizy użycia, polegającej na zidentyfikowaniu podstawowych rodzajów transakcji wymaganych w systemie bazy danych. Transakcje są to ciągi operacji wstawiania, modyfikowania, wyszukiwania, przemieszczania i usuwania. Szybkość wykonywania operacji modyfikowania i wyszukiwania zależy od zmienności pliku. Zmienność encji lub pliku określana jest jako różnica między średnią a maksymalną liczbą instancji obliczoną dla encji.

• Stworzenie struktur dostępu do danych. Właściwości dostępu do danych w pliku zależą od rozmiaru i zmienności pliku.

• Przeprowadzenie analizy integralności, poprzez udokumentowanie więzów integralności encji, referencyjnych więzów integralności oraz więzów dziedziny. Każda aplikacja wymaga zazwyczaj dodatkowych więzów; więzów przejścia, dokumentujących przejście z jednego stanu bazy danych w drugi, lub więzów statycznych, wiążących się ze sprawdzeniem, że transakcja nie spowoduje przejście bazy danych w stan niepoprawny.

• Zdefiniowanie wydajności dostępu i wydajności modyfikowania, które na ogół są sprzeczne. Wydajność zależy istotnie od aplikacji. W celu poprawienia wydajności wykorzystywane są następujące opcje:

1. Tworzenie mechanizmów dostępu związanych z przechowywaniem. Do przechowywania danych w pamięci pomocniczej wykorzystywana jest sekwencyjność, haszowanie i klastry. Dostęp sekwencyjny zalecany jest dla małych tabel, średnich i dużych - jeśli dostęp musi być uzyskany do więcej niż 20% wierszy, oraz dowolnych tabel, gdy dostęp następuje przez zapytania o niskim priorytecie, lub realizowane za pomocą przetwarzania wsadowego. Pliki haszowane są budowane zwykle na kluczach głównych i stosowane jako główna ścieżka dostępu do pliku. Klastry są tworzone, aby ułatwić wykonywanie z góry ustalonych operacji złączeń danych.

2. Dodawanie indeksów. Indeks jest mechanizmem poprawienia szybkości dostępu do danych bez zmiany struktury ich przechowywania. Rozróżniamy dwa typy indeksów: główny i wtórny. Indeksy powinno się tworzyć zawsze na kluczach głównych (indeksy jednoznaczne) i obcych, a jedynie czasem na innych elementach danych, gdyż maja one negatywny wpływ na wydajność modyfikacji. Ogólną zasadą jest tworzenie indeksów na średnich i dużych tabelach w celu ułatwienia dostępu do małego procentu wierszy w tabeli.

3. Denormalizacja ma na celu przyśpieszenia wyszukiwania lub modyfikowania danych. Wprowadza ona kontrolowana redundancję, dlatego powinna być stosowana wyjątkowo, zwłaszcza dla dużych, często zmienianych plików.

4. Implementowanie więzów integralności. Stosowane są trzy sposoby. Wewnętrznie, to znaczy, że za pomocą prostych mechanizmów można określić integralność encji, referencyjną i dziedziny. Proceduralnie, to znaczy, że więzy są implementowane w językach trzeciej generacji, takich jak C lub Cobol. Nieproceduralnie , to znaczy, że więzy są utrzymywane niezależnie od programów użytkowych, w centralnym słowniku danych.

5. Wybór i wykorzystanie SZBD. Istnieją systemy które kompilują wszystkie zapytania uruchomione na bazie danych i przechowują w postaci gotowej do ponownego użycia, oraz systemy, które interpretują zapytania w czasie ich wykonywania. Wydajność tych systemów zależy od rodzaju zapytań.

18. Język SQL - interakcyjny, statyczny, dynamiczny

SQL jest używany na trzy sposoby:

• Interakcyjny lub samodzielny SQL używany jest do wprowadzania lub wyszukiwania informacji do/z bazy danych. Jeśli użytkownik poprosi o listę aktywnych kont w bieżącym miesiącu. Wynik może być wysyłany na ekran, skierowany do pliku albo wydrukowany,

• Statyczny SQL jest to stały kod SQL-a napisany przed wykonaniem programu. Są dwie wersje statycznego SQL-a. W zanurzonym SQL-u kod SQL-a znajduje się w źródłowym programie innego języka. Większość tych aplikacji jest napisana w języku C lub COBOL, natomiast odwoływania do bazy danych są w SQL-u. Inna wersja statycznego SQL-a to język modułowy. W tym przypadku moduły SQL-a są łączone z modułami kodu innych języków.

• Dynamiczny SQL jest to kod SQL-a generowany przez aplikację w czasie jej wykonywania. Jest używany zamiast statycznego SQL-a, gdy potrzebny kod nie może być określony podczas pisania programu. Ten rodzaj kodu SQL-a jest często generowany w odpowiedzi na działania użytkownika za pomocą takich narzędzi jak np. graficzne języki zapytań.

Język został po raz pierwszy zaimplementowany przez Oracle w 1979 roku, jednak nie był oficjalnie uznawany za standard do 1986, kiedy to został opublikowany częściowo przez ANSI (American National Standards Institute) i ISO (International Standards Organization). W 1989 zrewidowano standard SQL-a wprowadzając nowe elementy zwiększające integralność.

Do chwili pojawienia się standardu 86 wiele programów korzystało już z SQL-a. Dlatego też ISO dopasowało standard do istniejącego już na rynku. Zdefiniowano minimalny standard, dając wolną rękę twórcom programów SQL-a. W standardzie całkowicie pominięto pewne potrzebne funkcje, takie jak usuwanie obiektów i uprawnień.

Teraz, w dobie scalania się świata komputerowego, twórcy oprogramowania i użytkownicy chcieliby pracować z różnymi systemami baz danych w jednakowy sposób.

19. Standard SQL - 92 - typy danych

Spowodowało to żądanie standaryzacji programów, co dawniej zależało tylko od dobrej woli twórców programów. W dodatku wiele lat korzystania z języka i badań nad nim doprowadziło do tego, że wielu twórców chciało wprowadzić nowe elementy do SQL-a. Dlatego też powstał nowy standard: SQL 92.

SQL 92 jest nadzbiorem standardu 89. Jednym z braków starego standardu poprawionego w SQL-u 92 były definicje użytkowników, schematów i sesji. Poprzedni standard pozostawił je całkowicie uznaniu twórcom systemów.

Instrukcje SQL-a są pogrupowane według funkcji. Taki podział jest praktyczny w pewnych sytuacjach. W standardzie SQL-a najczęściej używa się trzech grup.

Są to:

• Język definicji danych (DDL), który zawiera wszystkie instrukcje do definiowania schematów i należących do nich obiektów. Najważniejsze instrukcje DDL służą do tworzenia różnych obiektów: CREATE SCHEMA, CREATE TABLE, CREATE VIEW, CREATE ASSERTION, CREATE DOMAIN.

Język „manipulowania” danymi (DML) zawierający wszystkie instrukcje do przechowywania, modyfikowania i wyszukiwania danych w tablicach. Najważniejsze instrukcje to: SELECT, INSERT, UPDATE i DELETE. SELECT jest używany do formułowania zapytań i prawdopodobnie jest najbardziej złożoną, pojedynczą instrukcją w SQL-u. Inne instrukcje operują na danych w tablicach.

Instrukcje Sterowania Danymi, które kontrolują uprawnienia użytkownika umożliwiające wykonywanie określonych akcji na obiektach w bazie danych (często w standardzie 92 uważa się tę część za fragment DDL). Podstawowe instrukcje to GRANT i REVOKE.

Inne kategorie standardu 92 to instrukcje transakcji, łączenia, sesji, dynamiczne i diagnostyczne. Głównym praktycznym znaczeniem podziału na kategorie jest to, że standard nie pozwala na mieszanie instrukcji DDL i DML w jednej transakcji (grupie instrukcji, która kończy się sukcesem lub porażką jako całość).

20. Rozkaz Create Table (opis, składnia, przykład)

21. Rozkaz SELECT (opis, składnia, przykład)

1

Made by Russo

ID Klienta

Imie

Nazwisko

Data ur.







---