SBD - wykład 3
Dok. Architektury dwu i pół warstwowej
2 elementem są zaimplementowane w bd reguły biznesowe wspólne dla wszystkich aplikacji klienckich. Wymiana takiej reguły powoduje, że sposób funkcjonowania aplikacji klienckiej zmieni się dla każdego klienta jednocześnie.
Istnieje potrzeba wprowadzenia kodu poza strukturą serwera bd. Rodzi się więc pojęcie trzeciej 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 bd, a nawet nie musiałaby wiedzieć o jej istnieniu a komunikowałaby się jedynie z pewnym komputerem, na którym zainstalowane byłyby tzw. serwery aplikacji. Wykonywałby on procedury na żądanie aplikacji klienckiej a one odwoływałyby się do bd. Mógłby on także prócz odwołania się do bd samodzielnie realizować pewne operacje. Mógłby on dokonać pewnych obliczeń numerycznych a nawet inicjować realizowanie pewnych operacji bazodanowych na kilku serwerach bd jednocześnie. Warstwa aplikacyjna jest wtedy odpowiedzialna za spójność danych posadowionych za 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łyby odrębną płaszczyznę programową w architekturze kl/serw z własnym językiem (środowiskiem programistycznym).
Tak jak mechanizm ODBC stosowana jest w architekturze dwuwarstwowej tak i tu (arch. 2,5 warstw.) możemy mówić o standardzie RPC(Remote Proceder Control-sterowanie na odległość), czyli zdalnym wywołaniu 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.
Modele systemów zarządzania bazą danych (modele bazy danych)
HIERARCHICZNY (HMD)
OBIEKTOWY (OMD)
RELACYJNY (RMD)
SIECIOWY (SMD)
HMD został opracowany w wyniku analizy istniejących implementacji. Model ten używa dwóch struktur: typy rekordów i związki nadrzędny-podrzędny (jeden-do-wielu). Typ rekordów jest nazywany 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-wielu między dwoma typami rekordów. Mówimy, że typ rekordów po stronie „jeden” związku jest nadrzędnym typem rekordu, a rekord po stronie „wiele” jest podrzędnym typem rekordu.
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. Schemat ten ma wiele podobieństw do relacyjnego md.
Różnice:
struktury danych są inne (HMD-typy rekordów, RMD- relacje i związki)
związki są inaczej implementowane (HMD-powiązania, RMD-klucze obce)
W HMD operowanie danymi jest wykonywane przez wbudowane f-cje dostępu do bd w wybranym języku programowania (tzw. Jęz. Gospodarza).
Istnieje wiele wewnętrznych więzów integralności w HMD , które są zawsze obecne gdy tworzymy schemat hierarchiczny.
Przykłady tych związków:
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, natomiast 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.
POŚREDNICY
TERMINARZ KLIENCI
MUZYCY ROZMOWY ROZLICZENIA
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 niego uiszcza należność za usługę.)
Problemem modelu hierarchicznego jest nadmiarowość danych.
OMD różny jest od RMD. Modele obiektowe wywierają wpływ na rozwój systemu informatycznego.
Język Simula - pierwszy język. Który wprowadził pojęcie struktur danych i procedur.
Niedawno (od ok. 10 lat) zastosowano obiektowość w dziedzinie bd. Główną różnicą między obiektowymi językami programowania a bd jest to, że obiektowe bd wymagają istnienia trwałych obiektów.
W obiektowych językach programowane obiekty istnieją tylko przez krótki czas przy wykonywaniu programu.
W obiektowych bd obiekty pozostają zapisane w pamięci pomocniczej przed i po wykonaniu programów.
Często stwierdza się, że model relacyjny był odpowiedni dla zastosowania tradycyjnego jak zastosowanie bankowe.
Istotną zaletą modelów obiektowych jest wyższy poziom abstrakcji.
Model obiektowy dotyczy głównie struktur danych przechowywanych w obiektowej bd. Wyznacza on bazę intelektualną i pojęciową określającą budowę struktur danych oraz komunikację pomiędzy ludźmi.
Filarami, na których opiera się każdy model obiektowy są pojęcia:
złożone obiekty
tożsamość
powiązania
klasy i typy
hierarchia (lub inna struktura) dziedziczenia
metody
komunikaty
hermetyzacja
przesłanianie
polimorfizm
Cel nadrzędny obiektów: -lepsze dopasowanie modeli pojęciowych i relacyjnych systemów do wrodzonych instynktów własności psychologicznych, mentalnych mechanizmów percepcji i rozumienia świata.
Obiekt jest pakietem danych i procedur. Dane są trzymane w atrybutach obiektu. Procedury są definiowane za pomocą metod obiektu. Metody są uaktywniane przez komunikaty przekazywania między obiektami.
Obiekt md powinien dostarczać środków do realizacji tożsamości obiektów (jest to możliwość rozróżnienia dwóch obiektów o tych samych cechach).
RMD jest md zorientowanym na wartości. Nie wprowadza możliwości przyporządkowania jednoznacznego identyfikatora każdemu obiektowi w bd. Dlatego dwie identyczne krotki w relacyjnym md wskazują na ten sam obiekt. Dwa identyczne rekordy w obiektowej bd 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.
Tak więc bd zastosowano w nowych dziedzinach, formułując nowe wymagania związane z zarządzaniem danymi. Przykłady takich wymagań:
dane niejednorodne (nonhomogeneous data); tradycyjne md operują na jednorodnych zbiorach obiektów charakteryzujących się niewielką liczbą typów i dużą liczbą wystąpień każdego typu. Nowe zastosowanie bd 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 multimedialnych w postaci cyfrowej zawiera długie łańcuchy znakowe, przy czym długość ich jest zmienna. Tradycyjnie bd 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 md 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 (recorvering). Tradycyjne bd reprezentują dane aktualne, stare wersje danych nie są zachowywane lub nie są bezpośrednio dostępne dla użytkownika.
Ewolucja schematu (scheme evolution) bd wspomagają projektowanie, z reguły podlegają modyfikacji schematu w miarę ewoluowania projektowanych przedmiotów.
Obiekty równoważne (equivalent objects); projektowany obiekt można rozpatrywać z różnych punktów widzenia co odpowiada istnieniu w bd jego różnych reprezentacji. W przypadku zmiany wprowadzonej do jednej reprezentacji obiektu, system zarządzania bd powinien dokonać odpowiednich zmian we wszyskich pozostałych reprezentacjach danego obiektu. Tradycyjne bd nie mają mechanizmów do modelowania semantyki obiektów równoważnych.
Długie transakcje (long transactions); transakcja-sekwencja operacji zapisywania i odczytu, która nie narusza integralności bd. W tradycyjnych bd transakcje są zazwyczaj krótkie i dotyczą jednego rekordu lub określonej grupy rekordów. Inna sytuacja powstaje w bd wspomagających projektowanie.
PROJEKTOWANIE I TESTOWANIE
Tradycyjne md zyskały w połowie lat 80-tych podejście obiektowe.
Powstało więc kolka kierunków rozwoju bd.
Po 1 - dalszy rozwój systemów opartych o relacyjny md. Prawdopodobnie będzie jeszcze długo w powszechnym użyciu ze względu na:
ich obecne bduż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 md
Drugi kierunek rozwoju bd to obiektowo-relacyjne bd. Ich twórcy starają się zachować jak najwięcej z modelu relacyjnego (by wykorzystać osiągnięcia relacyjnych bd) a jednocześnie wprowadzać pewne aspekty obiektowe. Przedstawicielem tego kierunku jest standard SQL3.
Trzecim kierunkiem rozwoju, najbardziej obiecującym, są obiektowe bd. Standardem takich baz jest ODMG (Object Database Managment Group), organizacja skupionej firmy tworząca obiektowe bd. ODMG stworzyło standardy takich baz, a są to: ODL (Object Definition Language)..
RMBD - twórcą był E.F. Codd; w 1970 r. opublikował on swoją pracę. 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 zastosowania ścisłych metod zostaną osiągnięte dwie podstawowe korzyści: po 1 - zostanie poprawiony możliwy do uzyskania poziom niezależności między programami a danymi.
BUDOWA RMD:
relacyjne struktury danych
operatory relacyjne umożliwiające tworzenie przeszukiwań i modyfikację bd
więzy integralności jawnie lub niejawnie określających wartośc danych
Podstawową strukturą danych jest relacja w postaci tabeli. Relacja jest zbiorem krotek posiadających taką samą strukturę lecz różne wartości.
Krotka - każda krotka odpowiada jednemu wierszowi tablicy, posiada co najmniej jeden atrybut odpowiadający pojedynczej kolumnie tablicy.
Każda relacja (tablica) posiada własności:
krotki (wiersze) i atrybuty (kolumny) są unikalne
kolejność krotek (wierszy) i atrybutów (kolumn) nie ma znaczenia
wartości atrybutów (pól) są atomowe
Tabela może reprezentować :
zbiór encji wraz z atrybutami
zbiór powiązań pomiędzy encjami wraz z ich 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 tablicy nie powinny powtarzać się dwa idntyczne wiersze - zabezpieczenia przed tym powtórzeniem jest realizowane poprzez pola kluczowe. Wiersze w odróżnieniu od kolumn są dynamiczne - działanie bd polega na dopisywaniu, modyfikacji i usuwaniu wierszy.
W przypadku projektowania tablicy w bd należy stosować się do następujących wskazówek:
używaj nazw opisowych do nazwania kolumn tablicy, kolumny nie powinny mieć znaczenia ukrytego ani reprezentowania kilku atrybutów (złożonych z pojedynczych wartości)
bądź konsekwentny w stosowaniu lp. lub lmn. Przy nazywaniu tablicy
twórz tylko te kolumny, które są niezbędne do opisywania modelowania encji lub powiązania tabeli z mniejszą ilością kolumn, są łatwiejsze w użyciu
twórz kolumny pól kluczowych dla każdej tablicy
unikaj powtarzania informacji w bd (normalizacja)