Bazy danych.

Baza danych to wielowymiarowy zbiór danych, charakteryzujący się systemem wielu wewnętrznych powiązań między elementami , tak że przechowywaną informację można prezentować z różnych perspektyw.

Najwcześniejsze znane użycie terminu baza danych miało miejsce w listopadzie 1963, kiedy odbyło się sympozjum pod nazwą "Development and Management of a Computer-centered Data Base"^[1], sponsorowane przez System Development Corporation

Pierwszy system zarządzania baz danych został opracowany w latach sześćdziesiątych XX wieku. Pionierem był Charles Bachman. Wczesne opracowanie Bachmana pokazywały, że jego celem było bardziej efektywne użycie nowych urządzeń bezpośredniego dostępu do składowanych danych, które wtedy zaczynały być dostępne. Jak dotąd, przetwarzanie danych było oparte na kartach dziurkowanych i taśmach magnetycznych. Oznaczało to szeregowy dostęp do danych, co pociągało za sobą użycie innych algorytmów niż dla dostępu swobodnego.

W 1970 E. F. Codd zaproponował relacyjny model danych. Krytykował on istniejące modele danych za mieszanie abstrakcyjnego opisu struktury informacyjnej z opisami mechanizmów fizycznego dostępu. Jednak przez dłuższy czas model relacyjny pozostawał tylko w sferze rozważań akademickich.

Jednym z pierwszych implementacji modelu relacyjnego były: Ingres Michaela Stonebrakera z Berkeley i System R z IBM. Oba były prototypami badawczymi, ogłoszonymi w ciągu roku 1976.

Pierwsze komercyjne rozwiązania, Oracle i DB2 nie były dostępne aż do roku około 1980.

Natomiast pierwszym udanym produktem tego typu dla mikrokomputerów był dBASE dla systemów operacyjnych CP/M i PC-DOS/MS-DOS.

Podczas lat osiemdziesiątych XX wieku, aktywność badaczy skupiała się na rozproszonych bazach danych i maszyn bazodanowych (ang. database machines) ale te wysiłki nie miały większego odzwierciedlenia w ofertach rynkowych.

Inną ważną ideą był funkcyjny model danych, ale oprócz specjalnych zastosowań w genetyce, biologii molekularnej i wykrywaniu nadużyć finansowych, także nie miały szerszych zastosowań.

Historycznie w miarę rozszerzania się możliwości i zastosowań sprzętu komputerowego, najpierw każdą aplikację implementowano jako oddzielny system z własnym zestawem danych np. przygotowywanie listy płac.

W późniejszym okresie powstał system indeksowy, który pozwalał na interakcyjne odczytywanie danych.

Pojedyncze zautomatyzowane systemy wykorzystywały dane w sposób nieefektywny (różne działy tej samej firmy nie mogły współdzielić informacji) informacja była powielana a jakakolwiek zmiana wymagała korekt w różnych węzłach.

W systemie zintegrowanym:

• wykorzystuje się dane pochodzące z jednego źródła,

• kontrolę nad informacją ma administrator bazy danych,

• administrator wie jakie dane są dostępne, jakie są potrzeby poszczególnych działów firmy. Administrator może ograniczać lub rozszerzać dostęp dookreślonych danych

• następuje szybki rozwój zawartości baz danych, powstają problemy prawne i etyczne wykorzystywania informacji (firmy ubezpieczeniowe, urzędy bezpieczeństwa, organizacje handlowe, służba zdrowia)

Zróżnicowanie uprawnień dostępu odbywa się poprzez stworzenie schematów i podschematów bazy danych.

Np.

• rekord opisujący studenta Politechniki zawiera : nazwisko, imię, datę urodzenia, adresy, numery telefonów, dane dotyczące postępów w nauce,

• każdy rekord dotyczący studenta jest dowiązany do rekordu z informacjami o prowadzącym zajęcia dydaktyczne,

• rekord dotyczący pracownika prowadzącego zajęcia zawiera dane identyfikacyjne i adresowe, dane dotyczące historii zatrudnienia, wynagrodzeń finansowych.

Sekcja rejestracji studentów nie ma możliwości dostępu do danych związanych z zatrudnieniem awansami i wynagrodzeniami pracownika, natomiast kwestura nie ma dostępu do danych studentów, których kształci dany pracownik.

Warstwowa struktura baz danych

• Kontakt użytkownika z bazą danych odbywa się w sposób interakcyjny poprzez warstwę aplikacji. Oprogramowanie tej warstwy zapewnia komunikowanie się z użytkownikiem np. poprzez dialog pytanie-odpowiedź lub poprzez wypełnienie formularza, zapewnia ono również wygodną dla użytkownika prezentację danych

• Właściwe operacje na danych realizuje system zarządzania bazą danych DBMS (Database management system) który:

• zwalnia użytkownika z konieczności określania miejsca przechowywania poszukiwanych danych w przypadku rozproszonych (na różnych komputerach) baz danych;

• umożliwia kontrolę dostępu do bazy danych według zasad narzucanych przez różne podschematy,

• umożliwia wprowadzanie zmian w bazie bez konieczności wprowadzania zmian do aplikacji (np. dodanie do rekordu dodatkowego pola)

• upraszcza zadanie opracowania oprogramowania aplikacyjnego, dzięki braku potrzeby wchodzenia w szczegóły złożonej struktury bazy danych, uwzględniania wskaźników i ścieżek zapasowych.

DBM zawiera podprogramy, które można wykorzystać w aplikacji jako narzędzia abstrakcyjne, przekształcające polecenia wyrażane w terminach pojęciowego spojrzenia na bazę danych na terminy związane z rzeczywistą organizacją bazy.

Relacyjny Model bazy danych

Model relacyjny to model baz danych oparty na postulatach relacyjności. Twórcą teorii relacyjnych baz danych jest nieżyjący już Edgar Frank Codd. Postulaty te zostały opublikowane po raz pierwszy w „A Relational Model of Data for Large Shared Data Banks”.

• Baza danych opisuje obiekty zwane encjami.

• Dane przechowywane są w prostokątnych tablicach zwanych relacjami, Relacja jest zbiorem R krotek.

• Pojedynczy wiersz w relacji nazywa się krotką.

• Kolumny w relacji opisują wyspecyfikowane właściwości obiektów, encji i noszą nazwę atrybutów,

• Niech S={A₁ , A ₂, ...A_n} będzie zbiorem nazw atrybutów nosi on nazwę schematu relacji (np. S={IdPrac,Nazwisko, Adres, PESEL})

• Przyjmijmy, że wartości atrybutów A₁, A₂, ....,A_n, należą odpowiednio do zbiorów D₁ , D₂ , ....., D_n zwanych dziedzinami (np. A₂ =Nazwisko, D_{2 =}{Baker, Clark, Smith} Tab.1

Wymagania, które musi spełniać tabela.

• Każda tabela należąca do bazy musi mieć unikatową nazwę,

• Każda kolumna tabeli ma unikatową nazwę,

• Bez znaczenia jest porządek kolumn w tabeli, nazwy kolumn determinują nazwę pól w wierszu,

• Wszystkie wartości w kolumnie muszą być tego samego typu,

• Nie jest dopuszczalne powtarzanie się wiersza, poszczególne wiersze muszą się różnić przynajmniej jednym polem,

• Kolejność wierszy w tabeli jest dowolna.

• Każda relacja zawiera klucz główny -- kolumnę (lub kolumny), której wartości jednoznacznie identyfikują wiersz (a więc w szczególności nie powtarzają się)(Np. PESEL). Wartością klucza głównego nie może być NULL.

• Do wiązania ze sobą danych przechowywanych w różnych tabelach używa się kluczy obcych. Klucz obcy to kolumna lub grupa kolumn tabeli, o wartościach z tej samej dziedziny co klucz główny tabeli z nią powiązanej.

Projektowanie relacyjne

Polega na zaprojektowaniu relacji tworzących bazę danych.

Jest to zadanie wymagające pewnego doświadczenia ponieważ jest w nim wiele subtelności, szczególnie kiedy baza podlega rozszerzeniu (rozbudowie).

Np. Jeżeli z każdym z pracowników z relacji (Tab.1) należy związać dodatkowe atrybuty:

• Nazwa Stanowiska,

• Kod stanowiska (IdStan),

• Kod posiadanych umiejętności,

• Dział w którym jest stanowisko,

• Data początku zatrudnienia,

• Data końca zatrudnienia

To dołączenie tych danych do relacji (Tab.1).

Daje nową relację (Tab.2)

Tab.2

Umieszczenie dodatkowych atrybutów dało nieefektywną relację która zawiera większą liczbę krotek dla tego samego pracownika zdeterminowaną okresem zatrudnienia, ponieważ wymagane jest powtórzenie krotek z Tab.1.

Problemem rozszerzonej relacji jest również usuwanie informacji z bazy danych.

Np. Jeżeli Joe Baker, jedyny pracownik na stanowisku D7 opuści firmę i zostanie usunięty z bazy (Tab.2) to zniknie również informacja o kodzie umiejętności D2, ponieważ kod ten jest związany z Bakerem.

Można spróbować usunąć fragment krotki, jest to jednak rozwiązanie które określa, że projekt relacji nie jest spójny.

Źródło problemów to połączenie kilku pojęć w jedną relację.

Poprawę sytuacji można uzyskać poprzez podział pojedynczej relacji w zbiór kilku relacji. Występują tu dwa przypadki:

• podział bez utraty informacji, kiedy dostępność informacji na skutek podziału nie ulega zmniejszeniu,

• podział z utratą informacji.

Informatyka cały czas zajmuje się badaniem właściwości relacji. Badania doprowadziły do powstania hierarchii klas relacji nazywanych postaciami normalnymi odpowiednio:

• pierwszą,

• drugą,

• trzecią,

• czwartą.

Im wyższa klasa danej relacji tym lepiej nadaje się ona do zastosowania w bazach danych.

Problem podziału relacji prześledźmy na przykładzie relacji Tab.2 wyróżniając trzy relacje pochodne:

• Pracownicy,

• Stanowiska,

• Zatrudnienie(historia).

Tab.3

Za pomocą trzech mniejszych relacji można uzyskać dowolną informację, którą można było uzyskać z jednej dużej relacji (np. można odnaleźć działy zatrudniające osobę

Operacje na relacjach

Relacyjny system baz danych udostępnia podprogramy do wykonywania operacji:

• „SELECT”- wyboru krotek mających określone właściwości i umieszczenia tych krotek w nowej relacji,

Relacja nowa←SELECT from Nazwa relacji where atrybut=”warunek”

• „PROJECT” - wyboru określonej kolumny atrybutu,

Relacja nowa←PROJECT Atrybuty from Nazwa relacji

• „JOIN” na dwóch relacjach daje ona w wyniku nową relację, której atrybuty są atrybutami pierwotnych relacji

Relacja nowa←JOIN Relacja A and Relacja B where warunek( relacje A,B)

Ilustracja zasady operacji „JOIN”

Wywoływanie podprogramów dokonywane jest z poziomu aplikacji za pomocą struktur syntaktycznych zgodnych ze składnią języka bazowego.

Przykłady operacji

• SELECT

• PROJECT

JOIN

Kilka słów o języku SQL

SQL- Structured Query Language, opracowany i wprowadzony przez firmę IBM. Istnieje standard języka opracowany przez American National Standards Institute.

• Zapytanie składające się z ciągu operacji SELECT, PROJECT i JOIN w języku SQL można wyrazić za pomocą jednej instrukcji.

• Instrukcje SQL nie określają żadnej konkretnej kolejności operacji koniecznych do uzyskania potrzebnej informacji.

Kilka przykładów

1. Instrukcja:

Select Nazwisko, Adres

From PRACOWNICY

Generuje listę pracowników znajdujących się w relacji PRACOWNICY

2. Instrukcja:

Select IdPrac, Nazwisko, Adres, PESEL

From PRACOWNICY

where Nazwisko = `Cheryl H. Clark'

Daje wszystkie informacje z krotki dotyczącej pracownika Cheryl H.

3.Instrukcja:

select PRACOWNICY.Nazwisko, ZATRUDNIENIE.DataPocz

from PRACOWNICY, ZATRUDNIENIE

where PRACOWNICY.IdPrac =ZATRUDNIENIE. IdPrac

Wyprowadza listę nazwisk pracowników wraz z datami zatrudnienia. (Jest to wynik operacji JOIN na relacjach PRACOWNICY i ZATRUDNIENIE , a następnie SELECT oraz PROJECT na odpowiednich atrybutach zgodnie z klauzulami where i select.

4.Instrukcja:

insert into PRACOWNICY

values (`42Z12','Antoni K. Kowalski',' Piastowska 13',`56010298765')

Dodaje krotkę do relacji PRACOWNICY.

5. Instrukcja

delete from PRACOWNICY

where nazwisko = `Antoni K. Kowalski'

Usuwa krotkę dotyczącą Kowalskiego.

6. Instrukcja

update PRACOWNICY

set Address = `Plac Grunwaldzki 13.'

Where nazwisko = `Antoni K. Kowalski'

Zmienia adres w krotce Kowalskiego

7. Instrukcja

select IdPrac, Dział

from ZATRUDNIENIE, STANOWISKA,

where ZATRUDNIENIE. IdSTAN = STANOWISKA. IdStan

And ZATRUDNIENIE. DataZak = `*'

Generuje numery identyfikacyjne pracowników wraz z nazwami działów.

Obiektowe Bazy Danych.

Składają się z obiektów, które są powiązane ze sobą w sposób oddający zależności zachodzące między nimi.

Np.

Rozpatrywana poprzednio baza danych zawiera trzy klasy (typy obiektów):

• PRACOWNICY pola (IdPrac, Nazwisko, Adres, PESEL)

• STANOWISKA pola (IdStan, Stanowisko, KodUmiejętności oraz Dział),

• Zatrudnienie pola (IdPrac, DataPocz, DataKon).

Każdy z powyższych obiektów musi zawierać metody służące do uaktualniania i wypisywania informacji o obiekcie, metody definiujące sposób reakcji obiektu na komunikaty dotyczące jego zawartości i związków z innymi obiektami.

Uzyskanie zatem obsługi np. historii zatrudnienia pracownika nie wymaga zatem pisania zewnętrznej procedury definiującej sposób uzyskania informacji.

Połączenia między obiektami w obiektowej bazie danych utrzymuje DBMS (Database Management System).

Podczas wstawiania nowego obiektu do bazy aplikacja określa z jakimi obiektami ma zostać powiązany, a DBMS tworzy zbiór wskaźników do zapamiętania tych związków.

Ponieważ w systemie programowania obiektowego obiekty tworzone są na czas trwania obliczeń a po ich zakończeniu ulegają destrukcji co jest nie do przyjęcia dla baz danych DBMS musi zapewnić trwałą pamięć dla tworzonych obiektów.

Obiektowe bazy danych są bardziej efektywne kiedy atrybuty mają charakter audio lub wideo.

Protokół Zatwierdzania i Wycofywania

(Commit/Rollback)

Pojedyncza transakcja może zawierać wiele kroków na poziomie bazy danych.

Np. Przelew pieniędzy pomiędzy kontami bankowymi wymaga zmniejszenia salda jednego konta i zwiększenia drugiego. Występuje zatem sytuacja odcinka czasu kiedy suma funduszy się nie zgadza, występuje zatem przez ten czas niespójność bazy danych ( to samo może występować w sytuacjach rezerwacji miejsc w komunikacji lotniczej).

Sytuację może skomplikować zawieszenie systemu, czy też awaria zasilania.

Zadaniem DBMS jest zapewnienie, ze wystąpienie takich zdarzeń nie pozostawi bazy w niespójnym stanie.

Najczęściej zabezpiecza się przed tym utrzymując w nieulotnej pamięci np. na dysku twardym dziennik (log) dokumentujący czynności wykonywane przez każdą transakcję, dopiero po dokonaniu zapisu w logu, kiedy system ma zapisane informacje (punkt zatwierdzenia), można powiedzieć, że czynności wykonane przez transakcję znajdą odzwierciedlenie w bazie danych.

Projektowanie Bazy Danych.

Nie ma ustalonych reguł postępowania, wypracowane jednak zostały pewne praktyczne techniki.

• Analiza zadania

• Sprecyzowanie listy tabel (relacji) i ich postaci

• Określenie dla każdej tabeli (relacji) klucza głównego oraz ustalenie związków między relacjami (ustalenie kluczy obcych),

• Analiza tabel (relacji) pod kątem normalizacji danych i jeżeli to potrzebne dokonanie normalizacji.

• Zdefiniowanie postaci fizycznej bazy danych,

Przeprowadzenie testów sporządzenie raportów dla przykładowych danych.

• Analiza wyników i wykonanie korekty ustaleń.

---