IV. Systemy informatyczne

1. Systemy informatyczne i etapy ich projektowania

2. Bazy danych

3. Systemy zarządzania bazami danych

4. Projektowanie tablic i relacji w bazach danych

5. Komponenty systemu bazy danych

6. Oprogramowanie bazy danych do tworzenia baz danych

1. Systemy informatyczne i etapy ich projektowania

System informatyczny - uporządkowany zestaw wzajemnie powiązanych składników, współpracujących dla wykonania jakiejś funkcji, pozwalający na rozwiązanie problemów i osiągnięcie założonych celów.

Cykl życia systemu można podzielić na kilka etapów (wg dr T.):

1. Zainicjowanie (stadium wstępne)

• Przyjęcie realizacji systemu

• Wstępny szkic systemu

Studium wykonalności, identyfikacja procedur, systemy alternatywne

• Opis istniejących metod programowania

• Wykaz alternatyw sprzętu, oprogramowania

• Określenie wykonalności

• Wykaz kombinacji sprzętu i oprogramowania

• Analiza systemu

• Pełna analiza istniejącego systemu

• Analiza potrzeb użytkowników, ustalenie ograniczeń

• Spotkanie z użytkownikiem dla określenia potrzeb projektu

• Projektowanie, system idealny/wykonalny

• Stworzenie projektu na podstawie potrzeb

• Wybór strategii, pakiety, generatory, języki nieproceduralne, prototypowanie

• Specyfikacja, logika przetwarzania, projektowanie zbiorów, wejścia/wyjścia systemu

• Tworzenie specyfikacji dla wybranej strategii projektowej

• Programowanie

• Tworzenie specyfikacji programu, modułów, harmonogramów

• Testowanie

• Testy jednostkowe, testy modułów złożonych, testy użytkowe

• Szkolenie

• Planowanie, realizacja

• Instalacja

• Planowanie, gromadzenie danych

• Użytkowanie

• Bieżąca eksploatacja i modyfikacja

Schematyczne przedstawienie cyklu życia systemu (wg dr Pirianowicza).




Najbardziej ogólnym modelem cyklu życia oprogramowania jest model spiralny.


(przepraszam wszystkich za mój mierny talent plastyczny )

Każda pętla spirali składa się z czterech podstawowych etapów:

• Analiza ryzyka - omówienie ogólnej opcji budowy systemu oraz analizowanie związanego z tym ryzyka

• Tworzenie oprogramowania - budowa kolejnej wersji systemu według zasad modelu wodospadu

• Testowanie przez klienta - ocena kolejnej wersji systemu przez klienta

• Planowanie kolejnej wersji - ustalenie celów produkcji kolejnej wersji systemu

Poniżej przedstawiony jest model wodospadu (kaskadowy) pokazujący kolejne etapy tworzenia oprogramowania.




1. Opracowanie koncepcji - ogólne określenie wymagań, decyzje strategiczne dotyczące oprogramowania

2. Określenie wymagań - określa się cele oraz szczegółowe wymagania wobec tworzonego systemu

3. Projektowanie - szczegółowy projekt według wymagań, jego wynik - odpowiednia specyfikacja systemu

4. Kodowanie - tworzenie (implementacja) w wybranym języku poszczególnych modułów

5. Opracowanie dokumentacji - dokumentacja dla użytkownika, przebiega równolegle z produkcją oprogramowania

6. Testowanie - testowanie modułów, podsystemów, całego systemu, na podstawie testów opracowanych podczas projektowania i opisanych w specyfikacji

7. Instalacja

8. Konserwacja

2. Bazy danych

W skład systemu bazy danych wchodzą:

• baza danych - dane uporządkowane, pamiętane w urządzeniach pamięciowych systemu komputerowego

• system zarządzania bazą danych - program umożliwiający dostęp do danych, modyfikację, dopisywanie itp.

Rozróżniamy kilka typów baz danych w zależności od modelu danych, czyli zbioru zasad posługiwania się danymi w bazie. W modelu danych można wyszczególnić trzy części:

1. Definicja danych - zbiór reguł określających strukturę danych

2. Operowanie danymi - jest to zbiór reguł dotyczących procesu dostępu do danych i ich modyfikacji

3. Integralność danych - jest to zbiór reguł określających, które stany bazy danych są poprawne

Rozróżniamy następujące typy baz danych (modele danych):

1. Hierarchiczny model danych.

• opiera się na strukturze drzewa np. UCZELNIA → WYDZIAŁY → INSTYTUTY

• obecnie nie używany - jego główną wadą jest możliwość tworzenia relacji tylko jeden do wielu co może prowadzić do dublowania danych (instytut międzywydziałowy).

2. Sieciowy model danych.

• modyfikacja hierarchicznego modelu danych

• dane można przedstawić w postaci grafów

• obecnie nie używany

3. Relacyjny model danych

4. Obiektowy model danych

5. Relacyjno - obiektowy model danych

Na podstawie wykładów dr T.:

Obecnie najczęściej wykorzystywanym modelem jest model relacyjny - opracowany w latach 1970-1980 przez Codd'a. Model ten jest oparty na zaczerpniętej z teorii mnogości terminologii i pojęciu relacji będącej podzbiorem iloczynu kartezjańskiego listy dziedzin. Dziedzina jest zbiorem wartości. Iloczyn kartezjański dziedzin zapisywany D1xD2x...xDn (n dziedzin). Natomiast v1, v2, ... , vn jest to zbiór krotek takich, że v1 należy do D1, v2 należy do D2, vn należy do Dn. Elementy relacji są nazywane krotkami. Relację można przedstawić jako tablicę, której każdy wiersz jest krotką, a każda kolumna odpowiada jednej składowej. Kolumnom często zostają nadane nazwy i zamiennie są określane jako atrybuty. Zbiór nazw atrybutów relacji nazywa się schematem relacji. Dla relacji R zawierającej atrybuty A1, A2, ..., An schemat relacji ma postać: R(A1, A2, ..., An).

Zerżnięte z internetu:

Niezwykłość relacyjnego modelu danych polega na tym, że swoje powstanie zawdzięcza głównie jednej osobie - E . F. Coddowi. W 1970 r. E. F. Codd opublikował pracę, która położyła fundament pod najbardziej popularny ze współczesnych modeli danych. Od 1968 do 1988 r. Codd opublikował ponad 30 prac na temat relacyjnego modelu danych. Codd traktuje swoje prace wydane przed 1979 r. jako pierwszą wersję relacyjnego modelu danych (Codd, 1990).

Na początku 1979 r. na konferencji Australian Computer Society w miejscowości Hobert w Tasmanii Codd przedstawił pracę pod tytułem Extending the relational database model to capture more meaning. Rozszerzoną wersję relacyjnego modelu danych, którą sformułował w swojej pracy, Codd nazwał RM/T (T od Tasmania).

Cele

Codd powołuje się na trzy problemy, którym poświęca swoją teoretyczna 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.

Definicja danych

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 (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 modelu danych z myślą o konkretnym zadaniu.

Schematem relacji nazywamy zbiór

R = {A _{1 ,} A _{2 ,.......,} A _n}
gdzie A _{1 ,} A ₂ , ..., A _n są atrybutami ( nazwami kolumn ).
Każdemu atrybutowi przyporządkowana jest dziedzina DOM ( A) czyli dopuszczalny zbiór 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 ₁, t ₂ , ... , 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.

Relacje

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 p. 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 i wiersza w relacji powinno zawierać wartość atomową. To znaczy, zbiór wartości nie jest dozwolony na jednym polu relacji.

Klucze główne

Każda relacja musi mieć klucz główny. Dzięki temu możemy zapewnić, aby wiersze nie powtarzały się w relacji.

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

W każdej relacji może istnieć wiele kluczy kandydujących. Klucz kandydujący to kolumna lub zbiór kolumn, które mogą występować jako jednoznaczny identyfikator wierszy w tabeli. Klucz główny jest wybierany ze zbioru kluczy kandydujących. Każdy klucz kandydujący, a więc także każdy klucz główny, musi mieć dwie właściwości. Musi być jednoznaczny i nie może mieć wartości null. Po pierwsze, z definicji każdy klucz kandydujący musi być jednoznacznym identyfikatorem. Dlatego nie może być żadnych powtarzających się układów wartości w kolumnach kluczy kandydującego lub głównego. Po drugie, wartość klucza głównego musi być określona dla każdego wiersza w tabeli.

Klucze obce

Klucze obce są sposobem łączenia danych przechowywanych w różnych tabelach.

Def. 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.

Dziedziny

Podstawową jednostką danych w relacyjnym modelu danych jest element danych. Mówimy. że takie elementy danych są nierozkładalne lub atomowe. Zbiór takich elementów danych tego samego typu nazywamy dziedziną. Dziedzinami są więc zbiory wartości, z których pochodzą elementy pojawiające się w kolumnach tabeli.

Wartości null

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ą (prawda, fałsz, nieznane). W logice dwuwartościowej jeżeli zdanie 1 jest prawdziwe i zdanie 2 jest prawdziwe, to ich połączenie spójnikiem “i" jest również prawdziwe. W logice trójwartościowej, jeśli zdanie 1 jest prawdziwe, a zdanie 2 ma wartość nieznaną, to ich połączenie spójnikiem “i” ma wartość nieznaną. Wprowadza to dodatkowe komplikacje przy przetwarzaniu zapytań w systemach relacyjnych. Niektórzy twierdzą, że jest to niepotrzebne.

 Operowanie danymi

Jest to druga z trzech części relacyjnego modelu danych: część, która ma do czynienia z operowaniem danymi.

Operowanie danymi ma cztery aspekty:

Jak wstawiamy dane do relacji?

2. Jak usuwamy dane z relacji?

3. Jak poprawiamy dane w relacji?

4. Jak wyszukujemy dane w relacji?

Kiedy Codd na początku zaproponował relacyjny model danych, najwięcej uwagi skupił na ostatnim aspekcie operowania danymi - wyszukiwaniu danych. Wyszukiwanie w relacyjnym modelu danych jest wykonywane przy użyciu zbioru operatorów znanych jako algebra relacyjna.

Algebra relacyjna

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.

Rzut

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

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).

Przecięcie

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

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.
 

Operacje dynamiczne na relacjach

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

wstawianie(INSERT),usuwanie(DELETE) i modyfikowanie(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.

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. Utrzymywania integralności referencyjnej oprócz określenie 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:
1.Ograniczone usuwanie(Restricted). Podejście ostrożne - nie dopuszcza do usuwania rekordu nadrzędnego, jeśli istnieją rekordy podrzędne.
2.Kaskadowe usuwanie(Cascades). Podejście ufne - przy usuwaniu rekordu nadrzędnego usuwa także rekordy podrzędne.
3.Izolowane usuwanie(Isolated). Podejście wyważone - usuwa jedynie rekord nadrzędny.

 Zatwierdzanie zmian w bazie danych

Instrukcje INSERT, DELETE, UPDATE nie dokonują same trwałych zmian w bazie danych. Aby zmiany wprowadzone przez nie utrwalić, należy wykonać instrukcję COMMIT.

Można również zrezygnować z wprowadzania zmian do bazy danych, wycofując je za pomocą instrukcji ROLLBACK.

3. Projektowanie tablic i relacji w bazach danych

Definicje:

• Zbiór identyfikujący relacji - jest to zbiór atrybutów relacji jednoznacznie definiujący każdą krotkę relacji.

• Kluczem K relacji nazywamy minimalny zbiór identyfikujący, tzn. taki, że żaden jego podzbiór właściwy nie jest zbiorem identyfikującym. Jeden z kluczy nazywamy głównym.

• Klucz składający się z jednego atrybutu nazywamy kluczem prostym, z więcej niż z jednego atrybutu - złożonym.

• Zależność funkcjonalna - atrybut B relacji R jest zależny funkcjonalnie od atrybutu A tej relacji, jeżeli każdej wartości atrybutu A odpowiada co najwyżej jedna wartość atrybutu B (może być, że żadna tzn. NULL).

• Pełna zależność funkcjonalna - atrybut A jest w pełni zależny funkcjonalnie od zbioru atrybutów X, gdy jest zależny funkcjonalnie od całego zbioru, a nie od podzbioru atrybutów z X

• Przechodnia zależność funkcjonalna. Niech X, Y, Z będą rozłącznymi podzbiorami atrybutów w relacji R. Podzbiór Z jest przechodnio zależny funkcjonalnie od X, jeżeli Y jest zależny funkcjonalnie od X, Z jest zależny funkcjonalnie od Y, natomiast Y nie jest zależny funkcjonalnie od Z lub X nie jest zależny funkcjonalnie od Y.

Wykład z baz danych:

Pierwszym etapem projektowania struktury bazy danych jest ustalenie atrybutów i powiązań na podstawie dokumentów, wywiadów itp. Otrzymujemy w ten sposób dane nieuporządkowane.

Drugim etapem jest normalizacja. Polega ona na uporządkowaniu danych i doprowadzeniu do żądanej postaci normalnej.

Pierwsza postać normalna - charakteryzuje się tym, że na przecięciu wiersza i kolumny znajduje się co najwyżej jedna wartość.

Druga postać normalna. Relacja jest w drugiej postaci normalnej (2NF), jeżeli każdy atrybut nie wchodzący w skład klucza potencjalnego jest w pełni zależny funkcjonalnie od klucza (wszystkich kluczy potencjalnych).

Trzecia postać normalna. Relacja jest w trzeciej postaci normalnej, jeżeli jest w drugiej postaci normalnej i nie występuje w niej przechodnia zależność funkcjonalna.

Czwarta postać normalna. Relacja jest w czwartej postaci normalnej, jeżeli jest w trzeciej postaci normalnej i występuje w niej co najmniej jedna zależność wielowartościowa.

Normalizacja relacji ma na celu takie jej przekształcenie, by nie posiadała ona cech niepożądanych.

Dana jest relacja o schemacie R oraz trzy parami rozłączne i niepuste podzbiory X, Y, Z atrybutów z R takie, że X Y Z = R i podzbiór Y jest nietrywialnie wielowartościowo zależny od X.

Dana relacja R jest w czwartej postaci normalnej wtedy i tylko wtedy, gdy jest w trzeciej postaci normalnej i wielowartościowa zależność zbioru Y od X pociąga za sobą funkcjonalną zależność wszystkich atrybutów tej relacji od X.

Łatwo zauważyć, że tabela "Pracownicy" z definicji wielowartościowej zależności funkcjonalnej jest w trzeciej postaci normalnej, ale nie jest w czwartej postaci normalnej, ponieważ atrybuty "Dziecko" i "Wykład" nie są funkcjonalnie zależne od atrybutu "Nazwisko".

Jak wynika z definicja relacja, która zawiera trywialną wielowartościową zależność funkcjonalną jest w czwartej postaci normalnej. Stąd wniosek, że relację zawierającą nietrywialną wielowartościową zależność funkcjonalną należy podzielić na takie relacje, które będą zawierać tylko zależności trywialne.

W opisywanym przykładzie relację "Pracownicy" można podzielić na dwie relacje: "Dzieci" i "Wykłady", które będą zawierać tylko trywialną wielowartościową zależność funkcjonalną:









Piąta postać normalna




Dana relacja r o schemacie R jest w piątej postaci normalnej wtedy i tylko wtedy, gdy jest w czwartej postaci normalnej i w przypadku występowania w niej połączeniowej zależności funkcjonalnej *R[R₁, ..., R_m] zależność ta wynika z zależności atrybutów od klucza.

Wynika z tego, że w celu doprowadzenia pewnej relacji do piątej postaci normalnej konieczne jest podzielenie jej na takie relacje, które spełniać będą podany wyżej warunek.

4. Komponenty systemu baz danych

Do najpopularniejszych komponentów baz danych należą:

• tabele

• indeksy

• widoki

• procedury

• triggery

Tabele to miejsce, w których przechowywane są dane. Jest to podstawowy komponent każdej bazy danych.

Operacje na tabelach:

• Tworzenie tabeli - instrukcja CREATE TABLE

• Modyfikacja tabeli - instrukcja ALTER TABLE

• Usunięcie tabeli - instrukcja DROP TABLE

• Wpisanie danych do tabeli - instrukcja INSERT INTO

• Modyfikacja danych w tabeli - instrukcja UPDATE

• Usuniecie danych z tabeli - instrukcja DELETE

• Odczyt danych z tabeli - instrukcja SELECT

Indeksy mają przede wszystkim na celu przyspieszenie wyszukiwania i sortowania danych.

Operacje na indeksach:

• Tworzenie indeksu - instrukcja CREATE INDEX

• Usunięcie indeksu - instrukcja DROP INDEX

Widoki zwane również perspektywami można określić jako wirtualne tabele. Widok w rzeczywistości jest poleceniem SELECT języka SQL wykonywanym każdorazowo przy odwołaniu się do widoku. Do widoku odwołujemy się tak jak do tabeli.

Operacje na widokach:

• Utworzenie widoku - instrukcja CREATE VIEW

• Usunięcie widoku - instrukcja DROP VIEW

• Odczyt danych z widoku - instrukcja SELECT

Przykładowy widok:

CREATE OR REPLACE VIEW wlasciciele_samochodow AS

SELECT wlasciciele.nazwisko, samochody.nr_rejestracyjny

FROM wlasciciele, samochody

WHERE wlasciciele.id=samochody.id_wlasciciela

Aby widok skompilował się poprawnie w bazie muszą wcześniej zostać założone tabele wlasciciele z polami id i nazwisko oraz samochody z polami id_wlasciciela i nr_rejestracyjny. Wywołując zapytanie

SELECT * FROM wlasciciele_samochodow

uzyskujemy dokładnie taki sam efekt jak byśmy wpisali

SELECT wlasciciele.nazwisko, samochody.nr_rejestracyjny

FROM wlasciciele, samochody

WHERE wlasciciele.id=samochody.id_wlasciciela

Oczywiście wybierając dane z widoku możemy używać wszystkich składników SELECT'a jak przy wybieraniu z tabeli (przy wybieraniu danych widok traktujemy dokładnie tak samo jak tabelę) np.

SELECT * FROM wlasciciele_samochodow

WHERE nazwisko='KOWALSKI'

W ten sposób otrzymamy wszystkie samochody pana Kowalskiego.

Procedury składowane to przechowywane na serwerze zapytania (grupy zapytań) SQL które wywołujemy poprzez podanie nazwy procedury i ewentualnie parametrów.

Operacje na procedurach:

• Utworzenie procedury - instrukcja CREATE PROCEDURE

• Usunięcie procedury - instrukcja DROP PROCEDURE

• Wywołanie procedury - instrukcja EXECUTE

Poniżej kod procedury, która przenosi dane z tabeli wlasciciele do tabeli wlasciciele_archiwum i dopisuje jeszcze rok archiwum (tabela wlasciciele jak wyżej, tabela wlasciciele_archiwum zawiera pola jak tabela wlasciciele oraz dodatkowo rok_arch).

CREATE PROCEDURE archiwizuj(rok_arch IN NUMBER) IS

CURSOR cr_wlasciciele IS

SELECT *

FROM wlasciciele;

BEGIN

FOR cur IN cr_gr_kand LOOP

INSERT INTO wlasciciele_archiwum

VALUES (cur.id, cur.nazwisko, rok_arch);

END LOOP;

DELETE FROM WLASCICIELE;

COMMIT;

END;

Polecenie EXECUTE archiwizuj(2001) przepisze wszystkie dane z tabeli właściciele do tabeli wlasciciele_archiwum dodając rok 2001 i następnie usunie wszystkie dane z tabeli wlasciciele.

Triggery zwane wyzwalaczami to zapytania przechowywane na serwerze wykonywane automatycznie w momencie wystąpienia jakiegoś zdarzenia.

Operacje na triggerach:

• Utworzenie triggera - instrukcja CREATE TRIGGER

• Usunięcie triggera - instrukcja DROP TRIGGER

Załóżmy, że mamy tabelę osoby i w niej pola nazwisko oraz data w którym trzymamy datę dodania rekordu (wpisania osoby do bazy). Możemy datę za każdym razem podawać przy instrukcji INSERT, możemy też stworzyć triggera i nie przejmować się datą - będzie ona dodawana automatycznie. Trigger który to załatwi przedstawiony jest poniżej:

CREATE TRIGGER data

BEFORE INSERT ON osoby

FOR EACH ROW

BEGIN

SELECT SYSDATE INTO :NEW.data FROM dual;

END;

Teraz wpisujemy

INSERT INTO osoby(nazwisko)

VALUES (`Tomaszek');

Po wykonaniu

SELECT * FROM osoby

otrzymamy:

Nazwisko |Data

------------------

Tomaszek |10/01/02

5. Oprogramowanie bazy danych do tworzenia baz danych

W zależności od systemu zarządzania bazą danych istnieją różne narzędzia do tworzenia bazy danych. Jednak praktycznie każdy system zarządzania bazą danych posiada zaimplementowany język SQL - Structured Query Language czyli strukturalny język zapytań. Po raz pierwszy w swojej bazie danych zastosował go Oracle w 1979 r. W 1986 r. został on uznany za standard. W jego skład wchodzą następujące języki:

• język definiowania danych (ang. DDL - Data Definition Language) umożliwiający definiowanie struktury danych przechowywanych w bazie, czyli schematu bazy danych

• język manipulowania danymi (ang. DML - Data Manipulation Language) umożliwiający dodawanie, modyfikowanie i usuwanie informacji w bazie danych

• język sterowania danymi (ang. DCL - Data Control Language) umożliwiający sterowanie transakcjami

• język zapytań (ang. QL - Query Language) - umożliwiający pobieranie informacji z bazy danych.

Do listy języków można tu jeszcze dodać rozszerzenia proceduralne stosowane przez różne firmy produkujące SZBD: pl/pgsql w PostgreSQL, PL/SQL w Oracle i inne.

Podstawowe polecenia SQL'a

Należy zaznaczyć, że w różnych systemach zarządzania bazami danych niektóre polecenia mogą się różnić.

Pierwszym krokiem jest utworzenie nowej bazy danych. Wykonuje się to wydając komendę

CREATE DATABASE nazwa_bazy

W celu usunięcia bazy należy użyć instrukcji

DROP DATABASE nazwa_bazy

Podstawowym elementem bazy danych są tabele. Aby stworzyć tabelę należy wpisać:

CREATE TABLE nazwa_tabeli (

Pole1 typ_pola)

)

Typ_pola określa rodzaj danych jakie w polu mogą być przechowywane. Przykładowe typy pól to:

INTEGER - pole liczb całkowitych

NUMBER - pole liczbowe (również liczby rzeczywiste)

VARCHAR - pole znakowe (tekstowe)

TEXT - pole opisowe (memo)

DATETIME - pole daty i czasu

W zależności od systemu zarządzania bazą danych typy pól są różne. Dla większości typów po nazwie typu podaje się wielkość pola np.

CREATE TABLE tabela1 (

Imie VARCHAR(20),

Wiek INTEGER(3))

)

W ten sposób utworzymy tabelę zawierającą pola Imię w którym można przechowywać łańcuchy alfanumeryczne o rozmiarze nie większym niż 20 znaków oraz Wiek pozwalające na zapisanie maksymalnie trzycyfrowej liczby całkowitej.

W instrukcji CREATE TABLE obok typu pól mogą stać dodatkowe słowa kluczowe takie jak NOT NULL, PRIMARY KEY.

Modyfikacji tabeli dokonujemy przy użyciu polecenia

ALTER TABLE nazwa_tabeli ...

Np. aby zmienić typ pola Pole1 w tabeli nazwa_tabeli na NUMBER(7,2) wykonujemy

ALTER TABLE nazwa_tabeli MODIFY Pole1 NUMBER(7,2)

Przy użyciu polecenia ALTER TABLE możemy także tworzyć więzy integralności:

ALTER TABLE nazwa_tabeli ADD CONSTRAINT nazwa

FOREIGN KEY (pole1)

REFERENCES nazwa_drugiej_tabeli (pole2)

ON DELETE CASCADE

Usunięcie tabeli powoduje instrukcja

DROP TABLE nazwa_tabeli

Indeksy tworzymy w następujący sposób:

CREATE INDEX nazwa_indeksu ON nazwa_tabeli (Pole1 asc)

Usunięcie indeksu:

DROP INDEX nazwa_indeksu

Powyżej przedstawione polecenia są podstawowymi poleceniami służącymi do utworzenia struktury bazy danych. Takich poleceń jest więcej np. CREATE/DROP PROCEDURE, CREATE/DROP SEQUENCE, CREATE/DROP TRIGGER, CREATE/DROP VIEW jednak nie występują one we wszystkich systemach zarządzania bazami danych. Częściej używanymi poleceniami są polecenia do manipulacji na danych. Umożliwiają one wybieranie danych z bazy, wpisywanie i modyfikacje danych oraz usuwanie danych.

Polecenie do wybierania danych z bazy to SELECT. Jego składnia jest następująca:

SELECT lista_pól

FROM nazwa_tabeli

WHERE warunek

ORDER BY pole1

Na liście pól oprócz pól z bazy danych mogą znajdować się operacje arytmetyczne lub wywołania funkcji.

Modyfikację danych dokonujemy poleceniem UPDATE:

UPDATE nazwa_tabeli

SET

Pole1=Wartosc1,

Pole2=Wartosc2,

...

PoleN=WartoscN

WHERE

Warunek

Polecenie przypisze poszczególnym polom odpowiadające im wartości we wszystkich rekordach spełniających warunek znajdujący się po słowie WHERE. Jeżeli warunek zostanie pominięty zostaną zmodyfikowane wszystkie rekordy w tabeli.

Do wprowadzenia danych do tabeli służy polecenie INSERT INTO.

INSERT INTO nazwa_tabeli(Pole1, Pole2, ..., PoleN)

VALUES (Wartosc1, Wartosc2, …, WartoscN)

Polecenie dodaje nowy rekord do bazy i polom Pole1, Pole2, ..., PoleN przypisuje odpowiednio wartości Wartosc1, Wartosc2, ..., WartoscN.

Do usuwania danych z tabeli bazy danych służy polecenie DELETE.

DELETE FROM nazwa_tabeli

WHERE warunek

Polecenie usuwa wszystkie rekordy spełniające warunek występujący po WHERE. Jeżeli warunek zostanie pominięty zostaną usunięte wszystkie rekordy z tabeli.

1

---