SBD wykład 2
Niezależność dzieli się na:
Fizyczna niezależność danych - oznacza, że rozmieszczenie fizyczne i organizacje danych mogą być zmieniane bez zmiany programów użytkowych jak i globalnej struktury logicznej danych. Niezależność ta 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.
Logiczna niezależność danych - oznacza, że globalna struktura logiczna danych może być zmieniona bez zmiany programów użytkowych (zmiany nie mogą oczywiście usunąć danych, z których program korzysta). Niezależność ta wyraża się tym, że w wyniku zmian na poziomie pojęciowym zmienia się tylko definicja odwzorowania między poziomem pojęciowym a zewnętrznym - umożliwia zachowanie programów użytkowych w niezmienionej postaci.
Reprezentacja danych:
poziom pojęciowy -abstrakcyjny, lecz wierny opisem pewnego wycinka rzeczywistości
poziom wewnętrzny - (dot. aplikacji) 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.
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.
Statyczne i dynamiczne niezależności danych
O wiązaniu dynamicznym mówimy w trakcie wyszukiwania danych. Schematyczna lub fizyczna organizacja może być wtedy modyfikowana w dowolnym momencie - daje ona dynamiczną niezależność danych. Statyczna niezależność danych wymaga, aby przeprowadzenie zmian w schemacie ogólnym zakończyło się zanim dowolny program użytkowy używający tych danych został wykonany.
3 rodzaje danych:
Dane zagregowane - treść danej mającej nazwę definiuje się tylko raz. Każdy programista odwołujący się do określonej danej musi zakładać tę samą treść danej.
Dane elementarne - definiuje się tylko raz. Programista odwołujący się do tych danych musi zakładać tę samą ich treść. Z tego samego zbioru danych elementarnych mogą być utworzone różne rekordy lub segmenty.
Dane subelementarne - treści tych danych mających nazwę mogą być różne w różnych programach użytkowych. I tak np.: jeden program może odwoływać się do siedmiocyfrowych a inny do ośmiocyfrowych danych elementarnych.
Historyczny przegląd danych:
Architektura dwuwarstwowa
System oprogramowania na tej architekturze podzielono na 2 części:
Z jednej strony została wydzielona pewna część systemu, inaczej mówiąc, proces odpowiedzialny 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ą do serwera w celu zapamiętania albo generują pewne zapytania w celu uzyskania konkretnych informacji z komputera-serwera.
Proces przetwarzania danych podzielony jest na 2 części:
Z jednej strony mamy serwer (przechowywane dane, wyszukiwanie ich itp.) z przechowywaniem bazy na podstawie zapytań poszczególnych komputerów (klientów) a z drugiej strony mamy aplikacje.
Architektura klient/serwer
Jej przesłanką jest podział wykonywanych zadań pomiędzy kilka procesów znajdujących się w sieci. Każdy procesor jest dedykowany do określonego zbioru zadań, które jest w stanie wykonywać najefektywniej, co w rezultacie daje zwiększenie wydajności i skuteczności systemu jako całości.
Rozdzielenie wykonywanych zadań pomiędzy procesory jest dokonywane poprzez protokół usług - jeden procesor, jeden klient zaleca pewną usługę drugiemu procesorowi zwanemu serwerem, który ma tę usługę zrealizować.
Najbardziej powszechną implementacją architektury klient/serwer jest odseparowanie części aplikacji będącej interfejsem użytkownika od części odpowiadającej za dostęp do danych.
Typowym rozwiązaniem jest kilka komputerów pracujących w sieci. W takiej konfiguracji mamy komputer (maszynę użytkową) wyposażony w serwer bazy danych, czyli pewne oprogramowanie umożliwiające przechowywanie i zarządzanie danymi.
Z drugiej strony mamy aplikacje klienta, posadowioną najczęściej w środowisku graficznym typu Windows, realizującą komunikację z użytkownikiem, tzn. prezentującą dane, pozwalającą wprowadzać i uaktualniać informacje.
Zastosowanie środowiska graficznego znacznie wzbogaciło możliwości prezentacyjne a jednocześnie pozwoliło na bardzo naturalną komunikację z użytkownikiem z wykorzystaniem wykresów, map cyfrowych, a także z wykorzystaniem rozwiązania multimedialnego, co pozwala na przechowywanie w bazie danych obrazów i dźwięków.
Zalety i wady:
Tworząc system klient/serwer musimy zastanowić się nad tym, co zyskujemy a co tracimy.
Zyski: duża elastyczność całego systemu, gdyż możemy pracować z różnymi środowiskami graficznymi równocześnie, możemy operować danymi w sposób spójny a jednocześnie niezależny od bż struktury.
Zarządzając z kolei samym serwerem danych jesteśmy uniezależnieni od konkretnych użytkowników, problemy związane ze wspólnym dostawcą, możemy skoncentrować się na samej strukturze informacji, na strukturach biznesowych, na współbieżności i intensywności.
Wady: Tracimy unikalność.
Po 1 - stopień kompilacji jest dużo większy niż pojedynczy pakiet programów przystosowanych do pracy na komputerach pracujących w jakiejkolwiek sieci. Przy pisaniu programów musimy zapewnić mechanizmy kontroli spójności, wielodostępu, co przy rozległych systemach nie jest sprawą trywialną.
Po 2 - pisząc aplikacje klienckie musimy zapewnić ich właściwe komunikowanie się z serwerem bazy danych.
Aplikacja kliencka nie ma bezpośredniego dostępu do danych elementarnych a jedynie za pomocą specjalnego języka (najczęściej SQL) komunikuje się z serwerem zadając pytanie, nanosząc pewne poprawki.
Przy architekturze klient/serwer musimy pamiętać też o odpowiednich połączeniach sieciowych - o pewnych standardach porozumienia się komputera z różnymi systemami.
W arch. kl/serw zakłada się, że poszczególne komponenty środowiska mogą pochodzić od różnych dostawców. Wynika to ze specjalności firm produkujących poszczególne komponenty systemów informatycznych. Jeżeli jakaś firma specjalizuje się w środowisku graficznym to niekoniecznie musi być najlepsza w produkcji serwerów bazy danych i odwrotnie.
Na poziomie serwera bd najczęściej jest język SQL, chociaż każdy z serwerów operuje pewnymi rozszerzeniami. Nie korzystanie z tych rozszerzeń powoduje, że tracimy pewną możliwość, która jest zaimplementowana bardzo wydajnie i decyduje o wyższości danego serwera nad innymi. Korzystanie z tych rozszerzeń powoduje często mniejszą skalowalność.
Komunikacja
Sam SQL nie oferuje określonych standardów, a jest kwestią samego łącza. Powstaje problem jak spowodować, aby aplikacja kliencka pracująca w systemie Windows mogła wymieniać dane z serwerem bd. Jednym z rozwiązań jest standard ODBC (Open Data Connecting), który zapewnia jednolity sposób wymiany bazy pomiędzy aplikacją kliencką i serwera. Obejmuje on nie tylko sam format zapytań i format ich przekazywania, ale również sposób odbierania otrzymanych danych i określania statusu, czyli wyniku wykonywania operacji bazodanowych.
Powoduje to z jednej strony, że aplikacje przestrzegające standardu „rozumieją się” i właściwie razem funkcjonują. Rozwiązanie to ma wadę, że aplikacje przystosowując się do standardu często muszą rezygnować ze swoich oryginalnych rozwiązań, często bardzo wydajnych i pożytecznych. Zdarza się, że ODBC w pewnych sytuacjach nie jest najwydajniejszym sposobem połączenia z bd.
Producenci środowisk tworzenia aplikacji klienckich bardzo często dostarczają w ramach swoich produktów specjalne dedykowane sterowniki (połączenia) do niektórych serwerów bd. Taki sterownik jest przeznaczony tylko do jednej bd.
Rozwarstwienie
Środowisko kl/serw z jednej strony elastyczne i wydajne ma swoje ograniczenia. Okazuje się, że tworzenie bardzo dużych systemów, gdzie aplikacja kliencka musi realizować bardzo dużo f-cji, w których mamy do czynienia nie z jednym a z wieloma serwerami danych rozproszonymi miedzy oddziaływaniem danej organizacji, zaczyna nastręczać trudności. Wiąże się to z tym, że musimy zapewnić wydajność wykonywania pewnych operacji.
Pojawiła się tendencja do wydzielania pewnych płaszczyzn przetwarzania. Jeżeli przyjrzymy się strukturze informacji w organizacji czy firmie, to okaże się, że możemy tę informację podzielić na pewne warstwy.
Z jednej strony mamy samą strukturę informacji, czyli fizycznie rzecz ujmując strukturę bazy danych - tj. strukturę tablic, rekordów, listę pól, typy wartości, jakie mogą przyjmować dane. Na tą strukturę nakłada się tzw. warstwa reguł biznesowych - tj. pewnych zależności pomiędzy danymi: właściwe dla konkretnej organizacji lub właściwe w danym okresie istnienia organizacji. Taką regułą może być np.: algorytm naliczania oprocentowania dla kredytów, sposób udzielania zniżek na bilety lotnicze itp. Są to więc pewne algorytmy nie związane w sposób bezpośredni z danymi, ale ich sprecyzowanie jest konieczne dla prawidłowego funkcjonowania firmy. Trzecia warstwa - warstwa prezentacyjna - określa sposób wprowadzania i wyświetlania danych. Określa ona np.: czy pewne dane przedstawiamy w postaci listy czy pól do wprowadzania i wyświetlania danych, czy też dana ma mieć strukturę D-M-R(Dzień-Miesiąc-Rok) czy R-M-D.
Sama struktura informacji narzuca nam podejście wielowarstwowe do tworzenia systemów informatycznych.
Wyłoniła się pewna warstwa, która nie dotyczy ani samej struktury ani sposobu jej prezentacji. Natomiast dotyczy reguł zarządzania tą informacją. Powstała wobec tego idea, która zakłada umieszczenia tychże reguł biznesowych w odpowiednim miejscu, czy też na odpowiedniej płaszczyźnie architektury kl/serw.
W przypadku typowej arch. kl/serw mamy do czynienia z arch. dwuwarstwową (warstwa klienta i serwera) reguły biznesowe najczęściej są umieszczane w aplikacji klienckiej.
Reguły, że na każde zamówienie musi być jedna fa, która musi być w 3 kopiach itd., umieszczono w aplikacji klienta.
Z drugiej strony mając serwer bd i funkcjonujące aplikacje stajemy przed problemem tworzenia nowych aplikacji tworzących czy gromadzących nowe informacje w oparciu o bd.
Nowe rozwiązanie - architektura dwu i pół warstwowa
Powstała idea przeniesienia pewnej warstwy funkcjonalnej, czyli sposobu zarządzania i przetwarzania informacji na stronie serwera tak, aby aplikacje klienckie dostały jedynie pewną listę f-cji, 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 bd 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ę nakładają, gdy usuwamy z naszej bd informacje o kliencie to chcemy usunąć wszystkie zamówienia, jakie złożył itp. 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 bd, ale jedynie wywołuje pewne operacje w serwerze danych, który bądź udostępnia pewne dane bądź realizuje wywołane procedury bazodanowe.