bazy, POLITECHNIKA ŚLĄSKA Wydział Mechaniczny-Technologiczny - MiBM POLSL, Inżynierskie, Semestr 3, Bazy danych, Od starosty, BAZY DANYCH, BAZY DANYCH x

Pobierz dokument
bazy.politechnika.slaska.wydzial.mechaniczny.doc
Rozmiar 82 KB

Ograniczenie specjalizowanych aplikacji operujących na dedykowanych strukturach plików:

separacja i izolacja danych - każdy program (aplikacja) operuje na osobnym zestawie danych, dane te są zapisywane w formacie właściwym dla danej aplikacji (tym samym każda aplikacja może korzystać z danych zapisanych w innym formacie), użytkownicy jednej aplikacji nie mają dostępu do danych z których mogą korzystać inne aplikacje

powielanie danych - te same dane przechowywane w wielu miejscach jednocześnie, korzystają z nich różne aplikacje i te same dane mogą być- zapisane w różnych formatach, np.: daty, liczby czy łańcuchy tekstowe
struktura danych jest zdefiniowana w aplikacji która z niej korzysta tym samym próba zmiany (rozszerzenia) formatu danych wymaga zmiany aplikacji
celem gromadzenia danych jest wyszukiwanie informacji drogą zapytań; zbiór zapytań w dedykowanych aplikacjach jest zbiorem zamkniętym tym samym próba analizy danych w sposób inny niż zdefiniowane danej aplikacji wymaga zmiany aplikacji

Aplikacje dedykowane mają również zalety:

możliwość bardzo szybkiego dostępu do danych znacznie przekraczająca parametry bazy danych

Podejście charakterystyczne dla baz danych.

0x01 graphic

W bazach danych jedną z charakterystycznych cech jest oddzielenie opisów struktury danych od konkretnej aplikacji tym samym opis struktury danych staje się informacją przechowywaną niezależnie od programu i informacja ta może być przechowywana wraz z danymi.

Systemy baz danych stanowią odpowiedz na konieczność kontroli dostępu do danych, ich zawartości wykraczającą poza kontrolę którą mogły zapewnić dedykowane aplikacje.

W systemach baz danych występują dwa typy języków:

język DDL (język do definiowania struktury danych; język ten pozwala na określenie typu danych, ich struktury i dziedziny danych)

język DML (język do manipulowania na danych, język tworzenia zapytań)

Bazy danych zapewniają następujące usługi:

system zabezpieczeń - daje on dostęp do danych i informacji tylko określonym użytkownikom na określonym poziomie szczegółowości
kontrola integralności danych (ich kompletność i ich poprawność)
kontrola jednoczesnego dostępu do danych przez wielu użytkowników (w taką procedurę może być wbudowana hierarchia użytkowników, np.: niektórzy mogą wprowadzać nowe dane i usuwać stare, inni mogą je tylko przeglądać)
odtwarzanie stanu systemu sprzed awarii

Wady baz danych:

Złożoność - (korzystanie z bazy danych powoduje że każdorazowo taki system ma dostęp do szeregu usług nawet takich które w danym zastosowaniu nie są potrzebne)
rozmiar
dodatkowe koszty sprzętu (mogą one wynikać- z podwyższonej złożoności oprogramowania bazy danych, konieczności zabezpieczenia fizycznego danych, np.: dodatkowe dyski)
koszt konwersji danych (mogą obejmować - konieczność- przetworzenia istniejących zapisów do nowego formatu, koszt zamiany struktury istniejących danych oraz kontroli integralności uzyskanych danych)
szybkość działania systemu baz danych z wyjątkiem wybranych funkcji tj. indeksowanie jest z reguły niższa niż systemów dedykowanych

Role użytkowników systemów baz danych:

administrator bazy danych (projektuje on strukturę baz danych, przydziela uprawnienia poszczególnym użytkownikom,
programiści aplikacji (budują oni procedury pozwalające na pozyskiwanie informacji z danych, a procedury te budowane są w języku DML)
”użytkownicy naiwni” (są to wszyscy użytkownicy bazy danych którzy dostęp do danych i informacji uzyskują za pośrednictwem mechanizmu perspektyw)

Cele architektury ASCI-SPARC:

wszyscy użytkownicy powinni mieć dostęp do tych samych danych
perspektywa konkretnego użytkownika nie powinna odzwierciedlać zmian wnoszonych do perspektyw innych użytkowników
użytkownik nie musi znać szczegółów technicznych zapisu danych w bazie
administrator bazy danych może zmieniać strukturę zapisu danych w systemie bez naruszania perspektyw poszczególnych użytkowników
wewnętrzna struktura bazy danych jest niezależna od sposobu jej zapisania w systemie komputerowym
administrator bazy danych może modyfikować strukturę pojęciową bazy danych bez odzwierciedlania tego w perspektywach użytkowników

Powyższy schemat składa się z trzech poziomów, a mianowicie z:

poziomu zewnętrznego - perspektywy użytkownika, użytkownicy ,,naiwni”
poziom pojęciowy - schemat logiczny
poziom wewnętrzny - zapisać w efektywny sposób dane zgodnie z modelem na którym będą działać założone wcześniej perspektywy

Architektura systemu zarządzania bazą danych z wielodostępem:

zdalne przetwarzanie - jest to rozwiązanie wychodzące z użycia charakteryzujące się tym że system zarządzania bazą danych, dane oraz oprogramowanie aplikacji realizujących poszczególne perspektywy wszystko to jest zapisane na centralnym komputerze dołączone są terminale za pośrednictwem których użytkownicy dostają dostęp do danych
architektura serwera plików - dane z których mogą korzystać- użytkownicy za pośrednictwem swoich stacji roboczych. Baza danych zapisana jest na serwerze plików na poszczególnych stacjach roboczych zainstalowane są systemy zarządzana bazą danych jako odrębne kopie oraz programy realizujące poszczególne perspektywy. Wszystkie stacje robocze są połączone z serwerem plików za pośrednictwem sieci komputerowej
architektura klient - serwer

Wady (serwera plików):

znaczne natężenie ruchu w sieci
konieczne jest instalowanie kopii systemu zarządzania bazą danych na każdej stacji roboczej
takie rozwiązanie utrudnia współdzielenie danych, kontrole ich poprawności, odtwarzanie stanu systemu sprzed awarii
Architektura klient - serwer (serwer aplikacji)

Zalety:

ułatwiony dostęp do istniejącej bazy danych
usprawniony dostęp do danych - lepsze wykorzystanie przepustowości sieci
możliwie oszczędności na sprzęcie komputerowym
ułatwione administrowanie bazą danych

Grupy informacji:

informacje stanowiące o istnieniu przedsiębiorstwa (dokumentacja wewnętrzna, dane personalne, opis zdarzeń gospodarczych itp.)
informacje stanowiące o konkurencyjności na rynku (np. dane o technologiach, konstrukcji itp.)

informacje dotyczące kontroli dostępu do informacji (np. klucze kryptologiczne, zbiory haseł, konfiguracja systemu komputerowego

Informacja powinna zawierać:

czas tworzenia
czas odbioru
temat
treść
dane nadawcy

Ochrona informacji i polityka bezpieczeństwa

najczęściej 90% decyzji podejmuje 5% kadry
sprzątaczka (20%) ma dostęp do prawie takiej samej ilości informacji jak

zarząd 35%

administrator systemu (75%) może wiedzieć jeśli zechce prawie tyle samo co

kierownik działu (85%)

kierownik działu (85%) nie zna wszystkich informacji w dziale

Konieczne jest w każdym przypadku opracowanie i przestrzeganie właściwych metod:

kontrolowania
klasyfikacji
opracowanie informacji

0x01 graphic

Opis procesów pracy:

Do opisów procesów pracy stosuje się m.in. dwie odmiany systemów: IDEFO i DFD. System IDEFO i DFD powstały w latach 70-tych na potrzeby sił powietrznych USA. W systemach IDEFO występują następujące elementy opisu procesu:
czynność (określona zawsze przy pomocy czasownika)
wejście (może być informacja lub obiekt materialny, jak np. część do transportu czy obróbki) INPUT
wyjście (może być informacja lub obiekt fizyczny) OUTPUT
sterowanie (to informacja służąca do przetworzenia wejścia w wyjście) CONTROL
mechanizm (jest zawsze elementem fizycznym który umożliwia realizację działania) MECHANIK. W systemach IDERO mechanizm może ale nie musi być precyzowany.

0x01 graphic

W systemach IDERO opis procesów pracy jest realizowany na szeregu płaszczyznach. Poczynając od szczebla najwyższego jakim jest dana instytucja. Poszczególne warstwy opisują coraz niższe szczebla hierarchii dochodząc do poziomu konkretnych stanowisk roboczych.

Modele DFD opisują wyłącznie część informacyjną procesów pracy. Zapis tych modeli składa się z następujących elementów:

obiekty wewnętrzne
składnice danych
procesy
strumienie danych

Obiekty wewnętrzne wyznaczają otoczenie modelowego procesy pracy. Budowa modeli DFD wymaga stosowania się do pewnych reguł takich jak:

strumienie danych muszą kończyć się lub zaczynać albo kończyć i zaczynać procesem
strumienie danych opatrzone dwoma strzałkami oznaczają przesyłanie w obu kierunkach informacji o ściśle takim samym formacie, jeżeli formaty są różne to w modelu umieszcza się symbole dwóch różnych strumieni informacji

Modele DFD budowane są również na różnych poziomach. Uogólnienia tym górnym tylko obiekty na najniższym poziomie takiej struktury mają swoje odzwierciedlenie rzeczywiście przesyłanych w strumieniach informacji, procesach pracy czy obiektach zewnętrznych. Na każdym poziomie szczegółowości modelu istnieją ograniczenia co do ilości procesów które mogą być w niej przedstawiane. Takich procesów powinno być nie mniej niż 4 i nie więcej niż 8. jeżeli w modelu konieczne jest odwołanie się do elementów fizycznych to mogą one wystąpić w postaci przypisów w dołączonych konkretnych procesów, wyjątkowo w postaci obiektów zewnętrznych. Każdy proces musi mieć zarówno wejście jaki wyjście przy czym nie mogą występować procesy tylko 1 we i 1 wy.

Modelowanie:

Złożenie modelu logicznego stanowiącego podstawę projektu bazy danych wymaga założenia zbioru encji wraz z ich atrybutami a następnie określeniu ich powiązania.

Przechodząc do definicji związku pomiędzy encjami należy wyróżnić dwa typy encji:

mocne których istnienie encji nie wymaga istnienia odpowiednich elementów innych encji
słabe - których istnienie jest uzależnione od występowania powiązanych z nimi encji mocnych

Poszczególne encje w ramach danego modelu mają szereg atrybutów, które można podzielić na proste i złożone:

Atrybuty proste.
Atrybuty złożone - to takie które składają się z szeregu niezależnych elementów.

Atrybuty mają być pojedyncze i złożone.

Atrybuty pojedyncze - dla danej encji może mieć tylko pojedynczą wartość w przeciwnym przypadku mamy możliwość zapisania wielu atrybutów, wartości dla danej encji (kropka).

Atrybuty pochodne - to takie, których wartości wyznaczane są na podstawie innych atrybutów w tym na podstawie atrybutów innej encji.

Tworzenie modelu graficznego w tym graficznej reprezentacji poszczególnych encji umożliwia już na wczesnym etapie budowy bazy danych uzgodnienia z użytkownikiem bazy danych poprawnego widzenia świata.

Powiązania wstępne pomiędzy encjami mogą również mieć atrybuty. W ogólnym przypadku należy dążyć do unikania tworzenia modeli, których powiązania mają swoje atrybuty, takie modele poddają się trudniej reprezentacji w postaci modeli reprezentacyjnych.

Pod pojęciem klucza rozumiemy pewien zbiór identyfikujący relacje. Taki zbiór pozwala na jednoznaczne identyfikowaniu poszczególnych elementów danej relacji który ma być używany jako klucz być jednocześnie minimalnych zbiorem.

Minimalnym to znaczy takim którego żaden podzbiór nie jest zbiorem identyfikującym relacje. Dana relacja może mieć jednocześnie wiele różnych zbiorów identyfikujących. Zbiory takie nazywamy kluczami kandydującymi. Z pośród nich wybiera się jeden klucz noszący nazwę klucza relacji. Wybór klucza relacji podyktowany jest względami związanych z usprawnieniem operowania na danych i jego przydatności.

Związki - związek określa fakt istnienia pewnego rodzaju połączenia pomiędzy elementami różnych typów encji. Związek określany jest przez jego stopień. Stopniem związku nazywamy powiązania różnych typów encji, których elementy można w danym związku jednocześnie wystąpić. Każde powiązanie musi nosić indywidualną nazwę

Reprezentacja powiązań przy pomocy sieci schematycznych:

Ponieważ poszczególne elementy różnych obrazów encji mogą pozostawać z sobą w związkach to fakty takie należy zapisać. Zapis ten wymaga rozważania cech danego powiązania właściwych dla danego modelu świata.

Tworzenie sieci schematycznej i przedyskutowanie jej struktury z użytkownikiem pozwala na wykrycie szeregu reguł, które w następnym etapie projektu mogły nie być w sposób czytelny sformułowane.

W powiązaniach pomiędzy encjami mogą występować powiązania rekursyjne (należy ich unikać ponieważ baza danych może dawać nie jednoznaczne wyniki dla takich samych zapytań).

Przy powiązaniach pomiędzy encjami należy określić typ powiązań. Pod pojęciem typu powiązań będziemy rozumieć 1 z 3 przypadków:

1 : N (człowiek wiele adresów)
1 : 1
N : N (wiele języków programowania i wiele jeżyków danych)

Tworząc modele baz danych należy unikać tworzenia modeli których występują powiązania 1:1. W przypadku N:N najczęściej konieczne będzie tworzenie wiele typów encji.

Pobierz dokument
bazy.politechnika.slaska.wydzial.mechaniczny.doc
Rozmiar 82 KB