Modelowanie bazodanowe - Uniwersytet Zielonogórski

Transkrypt

Modelowanie bazodanowe - Wykład
Grzegorz Arkit
Wydział Matematyki, Informatyki i Ekonometrii
Uniwersytet Zielonogórski
15 grudnia 2013
G. Arkit (WMIiE)
Modelowanie bazodanowe (W)
15 grudnia 2013
1 / 77
Literatura
Literatura
Podstawy baz danych, Tadeusz Pankowski, Wydawnictwo Naukowe
PWN, 1992
InterBase 6, Language Reference, Inprise/Borland, 1999 (dostępny
publicznie)
Firebird 2.5 Language Reference Update, Paul Vinkenoog, 2011
(dostępny publicznie)
Databases - a first course, John Carter, 2001 (Chapter 3: Entity relationship modelling dostępny opublicznie)
SQL i PL/SQL – podstawy, Andrzej Klusiewicz, 2013 (dostępny
publicznie)
inne źródła internetowe oraz materiały własne prowadzącego
G. Arkit (WMIiE)
15 grudnia 2013
2 / 77
Wykład I - Wstęp
Przypomnienie wiadomości z teorii baz danych
Relacyjny model danych
Model relacyjny
W najprostszym ujęciu w modelu relacyjnym dane grupowane są w relacje,
które reprezentowane są przez tablice. Kolumny opisują atrybuty a wiersze
dane.
Pomiędzy atrybutami w danej relacji mogą zachodzić zależności funkcyjne.
G. Arkit (WMIiE)
15 grudnia 2013
3 / 77
Wykład I - Wstęp
Pierwsza postać normalna (1PN, 1NF)
Każda wartość jest atomowa (elementarna).
WYPOŻYCZENIA (nr czytelnika, lista książek)
nr czytelnika lista książek
128
Pascal, Access
155
Excel, Pascal
WYPOŻYCZENIA (nr czytelnika, książka) - 1PN
nr czytelnika książka
128
Pascal
128
Access
155
Excel
155
Pascal
G. Arkit (WMIiE)
15 grudnia 2013
4 / 77
Wykład I - Wstęp
Przykłady:
nazwisko, imiona – nie jest w 1PN,
czy adres jest wartości elementarną?
G. Arkit (WMIiE)
15 grudnia 2013
5 / 77
Wykład I - Wstęp
Druga postać normalna (2PN, 2NF)
Każda kolumna zależy funkcyjnie od klucza(każdego).
Zaliczenia
Przedmiot, NrStudenta, TypOceny, Ocena, Student
Klucz: Przedmiot, NrStudent
Student zależy funkcyjnie od NrStudenta
Rozkład: względem zależności funkcyjnej NrStudent → Student
R1: Przedmiot, NrStudenta, TypOceny, Ocena
R2: NrStudenta, Student
G. Arkit (WMIiE)
15 grudnia 2013
6 / 77
Wykład I - Wstęp
Trzecia postać normalna (3PN, 3NF)
Gdy każdy atrybut niekluczowy jest bezpośrednio zależny od klucza (nie ma
zależności tranzytywnych).
imię
Emil
Zofia
Eulalia
nazwisko
Zając
Zima
Jańska
miejsce urodzenia
Pszczyna
Pszczyna
Szczebrzeszyn
powiat
pszczyński
pszczyński
zamojski
Klucz: imię i nazwisko, ale jest zależność Miejsce urodzenia –> Powiat.
G. Arkit (WMIiE)
15 grudnia 2013
7 / 77
Wykład I - Wstęp
Postać normalna Boyce’a-Code’a(PNBC, BCNF)
Schemat w PNBC gdy z istnienia nietrywialnej zależności X → A wynika,
że X jest nadkluczem.
Atrybuty: Miasto, Ulica, Kod
Zależności: MU→ K, K→M
Klucz: MU, KU
Dla zależności K→M, K jest nadkluczem.
UWAGA: nie do końca właściwy, bo nie zawsze jednej ulicy w mieście
odpowiada jeden kod.
G. Arkit (WMIiE)
15 grudnia 2013
8 / 77
Wykład I - Wstęp
Dekompozycja
odnalezienie nietrywialnej zależności funkcyjnej: A1 A2 ...An →
B1 B2 ...Bm , która narusza BCNF – tzn. A1 A2 ...An nie jest nadkluczem,
dodanie do prawej strony wszystkich atrybutów zależnych funkcyjnie
od A1 A2 ...An – w ten sposób powstaje nowa relacja,
druga relacja będzie się składała z atrybutów A1 A2 ...An oraz z
pozostałych (poza B1 B2 ...Bm ) atrybutów relacji.
G. Arkit (WMIiE)
15 grudnia 2013
9 / 77
Wykład I - Wstęp
System zarządzania bazą danych
System zarządzania bazą danych (SZBD, ang. Database Management
System, DBMS) – oprogramowanie bądź system informatyczny służący do
zarządzania bazą danych. System zarządzania bazą danych może być
również serwerem bazy danych (SBD) lub też może udostępniać bazę
danych lokalnie – na określonym komputerze.
G. Arkit (WMIiE)
15 grudnia 2013
10 / 77
Wykład I - Wstęp
Niezbędne mechanizmy
środki do administrowania zapisanymi na nośnikach zbiorami danych,
środki zapewniające integralność i bezpieczeństwo danych,
środki pozwalające na odtworzenie zawartości bazy danych po awarii,
narzędzia programistyczne wykorzystujące język programowania i API,
dostęp do danych poprzez język zapytań bazy danych np. SQL,
wielodostępność danych, np. poprzez transakcje,
środki pozwalające na autoryzację dostępu do danych,
środki do zarządzania metadanymi,
środki optymalizujące wykorzystanie pamięci operacyjnej,
środki optymalizujące czas dostępu do danych, np. indeksy,
środki do pracy w środowisku rozproszonej bazy danych.
G. Arkit (WMIiE)
15 grudnia 2013
11 / 77
Wykład I - Wstęp
Dodatkowe (praktyczne) mechanizmy
wyzwalacze,
procedury i funkcje operujące na danych,
mechanizmy określania uprawnień do danych,
perspektywy.
G. Arkit (WMIiE)
15 grudnia 2013
12 / 77
Wykład I - Wstęp
Rodzaje baz danych
lokalne (DBase, Paradox, Access, SQLite)
bazy klient–serwer
klastry bazodanowe (mirror, split) – replikacja
G. Arkit (WMIiE)
15 grudnia 2013
13 / 77
Wykład I - Wstęp
Najczęściej stosowane rozwiązania bazodanowe
darmowe – lokalne: SQLite, rzadziej Dbase, Open/Libre Office Base,
JavaDB,
darmowe – serwerowe: MySQL (serwisy WWW), PostgreSQL, Firebird,
darmowe – serwerowe (komercyjne): Oracle Express, MS SQLServer
Express, DB2 Express (?) - darmowe wersje korporacyjnych baz
danych, ale z ograniczeniami na ilość używanych zasobów komputera
i/lub ograniczeniami na wielkość bazy,
komercyjne - lokalne: MS Access, Paradox,
komercyjne – serwerowe: Oracle, MS SQL Server, DB2, itd...
G. Arkit (WMIiE)
15 grudnia 2013
14 / 77
Wykład I - Wstęp
Podstawy języka SQL
Grupy komend języka SQL
DML - Data Manipulation Language (INSERT, UPDATE, DELETE)
DDL - Data Definition Language (CREATE, ALTER, DROP)
DCL - Data Control Language (GRANT, REVOKE)
języki proceduralne (PL/SQL)
DQL - Data Query Language (SELECT)
G. Arkit (WMIiE)
15 grudnia 2013
15 / 77
Wykład I - Wstęp
DML - Data Manipulation Language
INSERT
UPDATE
DELETE
Służą do manipulowania danymi w obrębie pojedyńczej tabeli.
G. Arkit (WMIiE)
15 grudnia 2013
16 / 77
Wykład I - Wstęp
DDL - Data Definition Language
CREATE
ALTER
DROP
Służą do zarządzania obiektami bazy danych takimi jak tablice,
perspektywy, indeksy, klucze, procedury, funkcje, pakiety i wiele innych.
G. Arkit (WMIiE)
15 grudnia 2013
17 / 77
Wykład I - Wstęp
DCL - Data Control Language
GRANT
REVOKE
Służa do zarządzania uprawnieniami użytkowników w odniesieniu do samej
bazy (np. możliwość tworzenia obiektów) jak i w odniesieniu do obiektów
(np. możliwość odczytania danych z tablicy lub ich modyfikowania).
G. Arkit (WMIiE)
15 grudnia 2013
18 / 77
Wykład I - Wstęp
Języki proceduralne
Pozwalają budować procedury i/lub funkcje operujące na danych (np.
zbudować uporządkowaną alfabetycznie listę nazwisk powiązanych z danym
utworem, lub zebrać kilka operacji na danych w jeden blok widziany jako
atomowa operacja z punktu widzenia użytkownika).
G. Arkit (WMIiE)
15 grudnia 2013
19 / 77
Wykład I - Wstęp
DQL - Data Query Language
Komedna SELECT służąca do pobierania danych z tablic bazy danych.
G. Arkit (WMIiE)
15 grudnia 2013
20 / 77
Wykład I - Wstęp
Szczegóły na temat używania poszczególnych komend SQL można znaleźć
w wymienionej literaturze.
G. Arkit (WMIiE)
15 grudnia 2013
21 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia
Modelowanie danych
W inżynierii oprogramowanie jest procesem tworzenia modelu danych dla
systemu informacyjnego poprzez zastosowanie formalnych technik
modelowania danych. Jest procesem używanym do definiowania i
analizowania danych wymaganych do obsługi procesów biznesowych
będących w zakresie systemu informacyjnego w danej organizacji.
G. Arkit (WMIiE)
15 grudnia 2013
22 / 77
Model danych
Jest zapisem (w systemie informacyjnym) informacji o obiektach (wraz z
ich własnościami) oraz relacji zachodzących pomiędzy tymi obiektami.
G. Arkit (WMIiE)
15 grudnia 2013
23 / 77
Model (schemat) koncepcyjny
Obejmuje budowę modelu świata rzeczywistego wyrażonego w postaci
określonych wymagań dotyczących danych.
G. Arkit (WMIiE)
15 grudnia 2013
24 / 77
Model logiczny
Opisuje dane w postaci obiektów wraz z określonymi własnościami
(zapisanymi za pomocą określonych typów danych) oraz relacje pomiędzy
nimi. Sposób organizacji danych, typy danych oraz relacje pomiędzy nimi są
opisane w sposób przewidziany dla danego rodzaju modelu logicznego
(model relacyjny, model obiektowy itp). W naszym przypadku będzie to
model relacyjny.
G. Arkit (WMIiE)
15 grudnia 2013
25 / 77
Model fizyczny
Obrazuje fizyczny układ danych w docelowym systemie przeznaczonym do
przechowywania danych (w naszym przypadku w systemie RDBMS). Model
fizyczny może być powiązany z konkretnym rodzajem bazy danych, ale nie
musi.
G. Arkit (WMIiE)
15 grudnia 2013
26 / 77
W przypadku mniejszych systemów modele koncepcyjny i logiczny
zazwyczaj są tożsame. W modelowaniu bazodanowym zakładamy, że wiemy
jakie dane są w danej strukturze potrzebne do obsługi procesów
biznesowych.
G. Arkit (WMIiE)
15 grudnia 2013
27 / 77
Encja (ang. entity)
w bazach danych to reprezentacja wyobrażonego lub rzeczywistego obiektu
(grupy obiektów) stosowana przy modelowaniu danych podczas analizy
informatycznej. Formalnie jest to pojęcie niedefiniowalne, a podstawową
cechą encji jest to, że jest rozróżnialna od innych encji.
G. Arkit (WMIiE)
15 grudnia 2013
28 / 77
Relacja pomiędzy encjami
Opisuje w jaki sposób dane mogą zależeć od siebie w modelu relacyjnym.
artysta
→ tworzy →
← jest tworzony ←
G. Arkit (WMIiE)
utwór
15 grudnia 2013
29 / 77
Identifying relation
jeżeli jest, to referencja w tablicy podrzędnej będzie elementem jej klucza
głównego.
W najnowszych systemach (np. Oracle SQL Developer Data Modeler od
wersji 3.3) relacja w modelu logicznym mogą posiadać dodatkowe atrybuty
(np. relacja pomiędzy przepisem a składnikiem może zawierać jednostkę i
ilość produktu użytego w danym przepisie).
G. Arkit (WMIiE)
15 grudnia 2013
30 / 77
Notacje w schematach relacyjnych
G. Arkit (WMIiE)
15 grudnia 2013
31 / 77
G. Arkit (WMIiE)
15 grudnia 2013
32 / 77
G. Arkit (WMIiE)
15 grudnia 2013
33 / 77
IDEF1X Relationship Cardinality Syntax
G. Arkit (WMIiE)
15 grudnia 2013
34 / 77
Bachman
Identifying – pionowa kreska przy „wiele”.
G. Arkit (WMIiE)
15 grudnia 2013
35 / 77
Barker notations
Identifying – pionowa kreska przy „wiele”.
G. Arkit (WMIiE)
15 grudnia 2013
36 / 77
G. Arkit (WMIiE)
15 grudnia 2013
37 / 77
G. Arkit (WMIiE)
15 grudnia 2013
38 / 77
Data Architect - notacja „kurzej” stopki – kółko (lub nic gdy nie jest
wymagana), pionowa kreska gdy jest wymagana.
G. Arkit (WMIiE)
15 grudnia 2013
39 / 77
Reverse engineering
Technika odwracania, inżynieria odwrotna, inżynieria wsteczna,
programowanie zwrotne to proces badania produktu (urządzenia, programu
komputerowego) w celu ustalenia jak on dokładnie działa, a także w jaki
sposób i jakim kosztem został wykonany. W przypadku modelowania
bazodanowego jest proces przejścia z modelu znajdującego się na niższym
poziomie abstrakcji do modelu na wyższym poziomie abstrakcji.
Najczęściej wykorzystywane do utworzenia modelu fizycznego na podstawie
istniejącej bazy danych (np. w celu udokumentowania istniejącej bazy
danych)
G. Arkit (WMIiE)
15 grudnia 2013
40 / 77
Narzędzia
Planowane narzędzia do użycia
Oracle SQL Developer data Modeler
Open ModelSphere
Visual Paradigm for UML Community Edition
ArgoUML-DB
Narzędzia pozwalają używać kilku notacji
Pozostałe darmowe narzędzia pozwalają zazwyczaj na modelowanie
konkretnych baz danych na poziomie modelu fizycznego.
G. Arkit (WMIiE)
15 grudnia 2013
41 / 77
Praktyczne elementy projektowania BD
Nazewnictwo obiektów
Przedrostki określające rodzaj obiektu:
TB - tablica
PRC - procedura
TG - trigger
itd....
Nazwy obiektów: liczba mnoga czy pojedyncza?
Nazwy kluczy obcych: mianownik czy dopełniacz?
Nazwy kluczy głównych: ID czy ID_tablica?
G. Arkit (WMIiE)
15 grudnia 2013
42 / 77
Praktyczne elementy projektowania BD
Nazewnictwo obiektów
Przedrostki określające fragment funkcjonalny schematu
ST - student
RK - rekrutacja
PL - plan zajęć
itd....
Należy pamiętać o ograniczeniach na długość nazw (np. Oracle - 30
znaków).
G. Arkit (WMIiE)
15 grudnia 2013
43 / 77
Przydatne funkcje bazodanowe
Ograniczenie danych widzianych przez użytkownika
Updatable views
ograniczenie przez where (w niektórych bazach danych przez „with
check”)
aby były „updatable” - kolumna z tabeli 1:1 na kolumnę w view
aby można było robić insert w view muszą być wszystkie pola not null
z tabeli
with check option - aby spowodować kontrolę danych przy insert i
update (czy po zmianie dane będą zgodne z definicją perspektywy)
G. Arkit (WMIiE)
15 grudnia 2013
44 / 77
Firebird
mogą być proste albo przez trigger – dodanie triggera do view blokuje
automatyczny zapis do tabeli – trzeba wykonać w triggerze odpowiednią
komendę SQL,
PosgreSQL
simple view is automatically updatable , view + „rule” (create rule
"_insert" as on insert to uzytk_v do instead . . . ).
Oracle
simple view is automatically updatable, CREATE OR REPLACE TRIGGER
order_info_insert INSTEAD OF INSERT ON order_info
Uprawnienia: wystarczy nadać uprawnienia dla view – inaczej byłoby to bez
sensu bo user i tak miałby bezpośredni dostęp do danych więc ograniczenie
byłoby niepotrzebne.
G. Arkit (WMIiE)
15 grudnia 2013
45 / 77
Do czego można zastosować:
dane osobowe – przechowywane w jednej tabeli, ale różne grupy
użytkowników mogą widzieć tylko dane dla swoje grupy: student,
pracownik, kandydat itp...
do podziału danych na jednostki (w strukturze hierarchicznej)
przy wykorzystaniu wyzwalaczy - można robić np. insert do jednej
perspektywy z podziałem danych na dwie tabele.
G. Arkit (WMIiE)
15 grudnia 2013
46 / 77
Wyzwalacze - kontrola poprawności danych
Wyzwalacze pozwalają na wygenerowanie zdefiniowanego przez
użytkownika błędu (innego niż standardowe błędy SQL). Możemy np.
sprawdzić czy sala w danym terminie jest zajęta i przy próbie wpisania
jeszcze jednej rezerwacji wygenerować odpowiedni błąd. Oczywiście
wszystkie wymienione konstrukcje można stosować także procedurach.
G. Arkit (WMIiE)
15 grudnia 2013
47 / 77
Wyzwalacze - kontrola poprawności danych
Firebird
tworzymy wyjątek: create exception nazwa ’tekst’
wywołujemy: exception nazwa
lub wywołujemy : exception nazwa ’custom msg’
PostgreSQL
raise exception ’tekst’;
Oracle
Raise_Application_Error(numer, ’tekst’), numer = -20000 .. -20999
G. Arkit (WMIiE)
15 grudnia 2013
48 / 77
Funkcje (procedury) zwracające zestawy rekordów
mogą okazać się pomocne w sytuacjach, kiedy “normalne” (za pomocą
komendy SELECT) pobranie danych z bazy jest niemożliwe lub wymaga
zbudowania skomplikowanego zapytania. Za pomocą takich funkcji możemy
np. z podanego kodu XML pobrać w postaci zestawu rekordów dane o
ustalonej strukturze.
G. Arkit (WMIiE)
15 grudnia 2013
49 / 77
Firebird
CREATE OR ALTER PROCEDURE pl_enum (parametry wejściowe)
returns (pola+typy)
as
begin
......
– przypisanie wartości do zmiennych
suspend;
......
end
Wywołanie
Jak normalną tabelę tylko, że z parametrami:
SELECT ... FROM pl_enum(.......);
G. Arkit (WMIiE)
15 grudnia 2013
50 / 77
PosgteSQL
CREATE OR REPLACE FUNCTION funkca1(parametry)
RETURNS SETOF record AS
$BODY$
DECLARE rr
record;
begin
for rr in
select ......
loop
return next rr;
end loop;
return ;
end;
$BODY$
LANGUAGE plpgsql VOLATILE SECURITY DEFINER;
G. Arkit (WMIiE)
15 grudnia 2013
51 / 77
Wywołanie
Przy wywołaniu trzeba podać nazwy i typy kolumn:
select
... from pl_jednostki_tablicy(’sala_vd’) as (id_jedn d_
G. Arkit (WMIiE)
15 grudnia 2013
52 / 77
Oracle
Najpierw typ zwracanego rekordu:
CREATE OR REPLACE TYPE ret_id
id integer
);
AS OBJECT (
Potem zbiór rekordów:
CREATE OR REPLACE TYPE ret_id_set;
G. Arkit (WMIiE)
15 grudnia 2013
53 / 77
Funkcja:
CREATE OR REPLACE FUNCTION get_id_list(pStr IN varchar2)
RETURN ret_id_set PIPELINED IS
ret ret_id := ret_id(0);
BEGIN
...
PIPE ROW(ret);
.....
RETURN ;
END;
Wywołanie
SELECT id FROM TABLE(get_id_list(pR_IDs))
G. Arkit (WMIiE)
15 grudnia 2013
54 / 77
Temporary tables
Temporary tables
Postgresql
Tabele tymczasowe są tworzone tylko na czas sesji - po zakończeniu sesji
tablica jest kasowana. Po commit tabela może być nienaruszona, można
skasować jej zawartość lub usunąć całkowicie.
G. Arkit (WMIiE)
15 grudnia 2013
55 / 77
Temporary tables
Firebird
Globalna – ma zdefiniowane na stałe metadane (nie trzeba jej tworzyć za
każdym razem), ale zawartość jest kasowana po zakończeniu transakcji lub
połączenia (w zależności od tego jak jest zdefiniowana).
CREATE GLOBAL TEMPORARY TABLE
...
[ON COMMIT <DELETE | PRESERVE> ROWS]
Oracle
Analogicznie hak Firebird
G. Arkit (WMIiE)
15 grudnia 2013
56 / 77
Tablice nadmiarowe
Tablice nadmiarowe
Przechowują dane, które mogą być obliczone na podstawie innych danych,
ale ich bezpośrednie obliczanie w trakcie działania aplikacji mocno obciąża
bazę danych. Dlatego są one budowane w trakcie działania aplikacji:
aktualizacja następuje okresowo (job),
aktualizacja następuje po zmianie określonej wartości (np. nazwiska
osoby).
G. Arkit (WMIiE)
15 grudnia 2013
57 / 77
SELECT z wyniku innego SELECT’a
select . . . .. from (select . . . ... )
grupowanie wcześniej pogrupowanych wartości (np. średnia z sumy)
użycie wyliczonych wartości w kilku innych wyrażeniach
G. Arkit (WMIiE)
15 grudnia 2013
58 / 77
Metody dostępu do bazy danych z poziomu aplikacji
A. użytkownik aplikacji jest jednocześnie użytkownikiem bazy danych
(DBUSER)
B. aplikacja ma własny system użytkowników (APPUSER)
G. Arkit (WMIiE)
15 grudnia 2013
59 / 77
Zalety i wady DBUSER konta APPUSER:
+ użytkownik może samodzielnie pobierać dane w celu stworzenia np.
jednorazowych raportów (chociażby do Excela)
+ jednostki (użytkownicy) mogą samodzielnie wykonywać na swoje
potrzeby oddzielne, potrzebne tylko im moduły
+/- projektując aplikację z DBUSER trzeba całą logikę zawrzeć w
bazie danych (przynajmniej jeżeli chodzi o kontrolę uprawnień i
integralność danych)
- nieświadomy użytkownik może obciążyć bazę niezoptymalizowanymi
zapytaniami
- komendy SQL (UPDATE, DELETE) nie pytają o potwierdzenie
modyfikacji danych – można zmodyfikować dużą ilość danych (np.
budując nieprawidłowy warunek WHERE)
G. Arkit (WMIiE)
15 grudnia 2013
60 / 77
Zalety i wady APPUSER konta DBUSER:
+ użytkownik może wykonywać tylko operacje dopuszczone przez
projektanta aplikacji
+ część logiki można zawrzeć w aplikacji
- nie ma możliwości bezpośredniego dostępu do danych, więc
nietypowe raporty i zestawienia musi wykonywać administrator
- mimo wszystko użytkownik, żeby połączyć się z bazą danych musi
przesłać do niej dane logowania (DBUSER) – gdzieś to trzeba zapisać
(czyli istnieje możliwość złamania zabezpieczenia)
+ w przypadku aplikacji webowych (zwłaszcza na serwerach
zewnętrznych) nie ma możliwości zbudowania systemu userów
bazodanowych, więc zostaje tylko opcja z APPUSER
G. Arkit (WMIiE)
15 grudnia 2013
61 / 77
Przydatne fragmenty modeli bazodanowych
System zarządzania użytkownikami
W tej części przedstawimy przydatne rozwiązania, które można wykorzystać
we własnych modelach baz danych. Pierwszym z nich będzie model
zarządzania użytkownikami systemu opartego o bazę danych - model ten
można wykorzystać zarówno w systemach gdzie użytkownik aplikacji jest
jednocześnie użytkownikiem bazodanowym, jak i w systemach gdzie obie te
grupy są rozdzielone.
Model załączony jest w oddzielnym pliku (model_1.jpg).
G. Arkit (WMIiE)
15 grudnia 2013
62 / 77
Użyte typy danych (domeny):
d_ids, d_ref, d_ref_null – oparte na typie bigint domeny służące w
do tworzenia referencji (kluczy głównych i obcych, ostatia dopuszcza
wartości puste),
d_sys_name – domena tekstowa (30 znaków) która służy do
zapisywania w tabelach nazw obiektów bazodanowych, z kontrolą czy
dana nazwaz może być identyfikatorem,
d_nazwa, d_nazwa_krotka, d_opis – typy tekstowa o określonej z
góry długości,
d_calkowita – wartość całkowita,
d_logiczna – wartość logiczna (TRUE/FALSE lub 0/1 w zależności od
tego co oferuje silnik danej bazy).
G. Arkit (WMIiE)
15 grudnia 2013
63 / 77
Jednostki
Przyjęto, że w modelu występuje hierarchiczny model podziału jednostek;
każda jednostka może mieć tylko jedną jednostkę nadrzędną, i tylko jedna
jednostka może być na szczycie hierarchii (jest tylko jedna jednostka bez
jednostki nadrzędnej). Zawsze występuje przynajmniej jedna jednostka
(root), której nie można usunąć z systemu (można tylko zmienić jej opis).
Ważne: tablice opisane w modelu powinny odzwierciedlać bieżący stan w
organizacji - jeżeli z jakichś względów potrzebne jest np. zachowanie historii
zmian w strukturze, to powinniśmy zrobić to za pomocą oddzielnych tablic.
Ponieważ nie wszystkie silniki bazodanowe oferują wbudowaną obsługę
struktur hierarchicznych, dodatkowo stworzono tablicę jedn_zalezn która
zawiera wszystkie pary jednostka-nadrzędna–jednostka-podrzędna (zarówno
zależność bezpośrednia jak i zależność pośrednia). Ze względów
praktycznych przyjęto, że w tablicy tej występują też wszystkie pary
jednostka–jednostka.
G. Arkit (WMIiE)
15 grudnia 2013
64 / 77
Zabezpieczenia:
nie można usunąć jednostki ze szczytu hierarchii (root),
po utworzeniu jednostki dodajemy zależności: jednostka–jednostka
oraz pary jednostka–jednostka nadrzędna
przy zmianie jednostki nadrzędnej (przeniesienie jednostki w
strukturze) kasujemy wpisy o zależnościach i tworzymy nowe, kontrola
czy nie powstają cykle
nie można modyfikować rekordów w tablicy z zależnościami (tylko
INSERT I DELETE),
G. Arkit (WMIiE)
15 grudnia 2013
65 / 77
Poziomy uprawnień
Opisują do jakich obiektów bazodanowych użytkownik ma dostęp – w
przypadku modelu APPUSR=DBUSER, odpowiadają one rolom. Oznacza
to, że modyfikując dane opisujące poziom uprawnień modyfikujemy też role
bazodanowe (wymaga to odpowiednich uprawnień administracyjnych na
poziomie bazy danych, nie można też wtedy zmienić nazwy poziomu,
ponieważ bazy zazwyczaj nie dopuszczają zmian nazwy roli).
Obiekty bazodanowe, do których dostęp chcemy kontrolować, zebrane są w
tablicy obiekt, wraz z podanym typem obiektu (tablica, perspektywa i
procedura/funkcja). Ważną grupę stanowią obiekty, w których dane będą
dzielone ze względu na jednostki – są to perspektywy pobierające dane z
tablic bazowych; jeżeli umożliwiają one modyfikowanie danych to
traktujemy jej jak tablice (tablice dzielone), w przeciwnym wypadku jak
właściwe perspektywy (tylko odczyt). Typy obiektów są ustalone
(typ_obiektu - tablicy tej nie można modyfikować w żaden sposób
(read-only), podobnie zresztą jak tablicy z rodzajami uprawnień (upraw).
G. Arkit (WMIiE)
15 grudnia 2013
66 / 77
Tablica typ_obiektu_upraw opisuje jakie uprawnienia można nadawać
obiektom danego typu. Dodatkowo występuje tablica
obiekt_wyklucz_upraw, która dla danego obiektu pozwala wyłączyć
kontrolę konkretnego uprawnienia.
Tablica poziom_obiekt pozwala nadać uprawnienia do obiektu dla
określonego poziomu uprawnień (UWAGA: w sytuacji, gdy
APPUSER=DBUSER powoduje to nadanie/odebranie uprawnień dla
określonej roli).
G. Arkit (WMIiE)
15 grudnia 2013
67 / 77
Użytkownicy
Dane o użytkownikach zebrane są w tablicy uzytk. Należy pamiętać, że w
modelu APPUSER = DBUSER, dane te przekładają się na użytkowników
bazodanowych, co pociąga za sobą konieczność dbania o odpowiednie
konstruowanie nazw, a także dopilnowanie, żeby użytkownik dokonujący
zmian miał odpowiednie uprawnienia (podobnie jak przy poziomach
uprawnień).
Każdy użytkownik może być powiązany z różnymi poziomami uprawnień, z
których wynikają jego uprawnienia, ale może mieć też nadane dodatkowe
indywidualne uprawnienia dla wybranych obiektów (tablica uzytk_obiekt).
Aby uprościć sprawdzanie uprawnień, należy utworzyć perspektywę (np.
efektywne_uprawnienia, w której będą zebrane wszystkie uprawnienia
użytkownika (te wynikające z poziomów uprawnień oraz te nadane
indywidualnie). W przypadku rozbudowanych systemów z dużą ilością
uprawnień można rozważyć stworzenie “materialized view” lub nawet
tablicy, w której dane będą aktualizowane na życzenie lub w określonych
odstępach czasowych (np. w nocy).
G. Arkit (WMIiE)
15 grudnia 2013
68 / 77
Podziały danych
W strukturze hierarchicznej występuje nie tylko podział uprawnień do
operowania na wybranych danych. Dane te należy podzielić także ze
względu na miejsce w strukturze organizacyjnej. Np. dziekanat konkretnego
wydziału uczelni widzi tylko dane swoich studentów. Oczywiście nie należy
tworzyć oddzielnych tablic dla każdego dziekanatu, tylko podzielić dane
istniejące w konkretnej tablicy za pomocą perspektywy lub perspektyw;
najlepsza opcją jest zastosowanie jednej perspektywy, która będzie zwierała
dane widoczne przez jednego użytkownika (w przypadku konieczności
zmian dokonujemy ich w jednym miejscu).
G. Arkit (WMIiE)
15 grudnia 2013
69 / 77
Podziały danych
Po pierwsze musimy określić w jaki sposób będą dzielone dane dla
poszczególnych podziałów: tablica podzial i tablica podzial_jedn. Druga z
tych tablic opisuje jakie jednostki wchodzą w skład danego poziomu; ważne
jest pole czy_podrzedne - mówi nam ono, że oprócz danej jednostki do
poziomu wchodzą wszystkie jednostki podrzędne danej jednostki - dzięki
temu, po dodaniu jednostki nie musimy się przejmować dodaniem jej do
odpowiednich poziomów.
Użytkownik jest zawsze przypisany do jednego podziału danych.
G. Arkit (WMIiE)
15 grudnia 2013
70 / 77
Tablice dzielone
W rzeczywistości są to perspektywy (jedna dla jednej tablicy) w których
wyświetlane są dane przewidziane dla danego poziomu; w zależności od
rodzaju danych mogą być one przeznaczone tylko do odczytu (faktyczne
perspektywy) lub mogą aktualizowane (updatable view).
Podział danych na jednostki może być takim jak dla całego podziału, do
którego przypisany jest użytkownik, może też być określony indywidualnie
dla konkretnej tablicy (perspektywy).
Ze względu na dużą ilość możliwości definiowana widzialności danych w
danej tablicy dzielonej, należy utworzyć perspektywę, która będzie zbierała
dane o elementach danej tablicy dzielonej. Podobnie jak w przypadku
poziomów uprawnień, w przypadku rozbudowanych systemów z duża ilością
uprawnień można rozważyć stworzenie “materialized view” lub nawet
tablicy, w której dane będą aktualizowane na życzenie lub w określonych
odstępach czasowych (np. w nocy).
G. Arkit (WMIiE)
15 grudnia 2013
71 / 77
Dane domyślne
Do prawidłowej pracy systemu potrzebne jest stworzenie pewnych
podstawowych obiektów w podanej strukturze:
podstawowy poziom uprawnień - poziom, który zawiera uprawnienia,
które musi posiadać każdy użytkownik systemu (np. uprawnienia
connect czy uprawnienia select dla wybranych tablic)
użytkownik-administrator - użytkownik, który ma uprawnienia do
wykonywania czynności administracyjnych w systemie; użytkownik taki
musi posiadać, dodatkowe uprawnienia na poziomie RDBMS, aby móc
np. dodać użytkownika czy też zmienić mu hasło.
G. Arkit (WMIiE)
15 grudnia 2013
72 / 77
Kolizje wykorzystania zasobów
Np. tablice obiekt i rezerwacje. W tej drugiej są kolumny określające, kiedy
dany obiekt jest zajęty (od-do w postaci timestamp, lub od-do i
dzień/data).
Możemy zastosować dwa podejścia: kontrola możliwości wykonania operacji
rezerwacji a potem wpisanie rezerwacji lub kontrola poprawności wykonania
operacji po jej wykonaniu.
Każda z tych metod ma swoje wady.
G. Arkit (WMIiE)
15 grudnia 2013
73 / 77
Jeżeli sprawdzamy możliwość wykonania rezerwacji przed jej wykonaniem,
to w systemach wielodostępnych, musimy zapewnić, żeby do czasy
wykonania właściwej operacji rezerwacji, stan danych się nie zmienił. Efekt
ten można osiągnąć np. stosując odpowiednie poziomy izolacji transakcji
(repeatable read) lub inne mechanizmy blokowania tablic (danych).
Niestety w systemach wielodostępnych może powodować to znaczne
spowolnienie działania.
W drugim podejściu kontrolę wykonujemy tuż po wykonaniu operacji
(trigger after insert or update) i jeżeli wystąpi kolizja, generujemy błąd, co
spowoduje wycofanie transakcji. Niestety takie podejście też nie jest
pozbawione wad. Po pierwsze nadal istnieje ryzyko powstania kolizji
(mniejsze, ale zawsze) w przypadku systemów wielodostępnych. Po drugie,
kontrola jest wykonywana po zapisaniu danych w bazie, co powoduje, że
wykorzystywane są mechanizmy bazy danych (np. temporary table spaces,
redo-logi itp) Podejście to jest jednak dużo łatwiejsze w implementacji.
G. Arkit (WMIiE)
15 grudnia 2013
74 / 77
Wersjonowanie rekordów
Pojęcie to występuje zwłaszcza w hurtowniach danych ale jest też istotne w
tradycyjnym modelowaniu bazodanowym.
Najczęściej są to sytuacje, kiedy pewne rekordy muszą zostać ukryte w
bazie, gdyż już z nich nie korzystamy, ale ze względu na integralność bazy
nie mogą być one usunięte (dane archiwalne). W takim przypadku
zazwyczaj wystarczy dodanie pola (aktywny, archiwum, widoczny itp.),
które steruje widocznością obiektu w aplikacji
Druga najczęstsza sytuacja, to kontrola zmian danych wykonywanych przez
użytkowników - w tym wypadku wystarczy stworzyć kopię wybranej tablicy
z dodatkowymi polami przeznaczonymi na czas i rodzaj zmiany oraz kto
wykonał daną zmianę. Natomiast w tablicy podstawowej (bazowej) należy
dodać wywołania wyzwalaczy (trigger) - należy pamiętać aby ustawić je w
odpowiedniej kolejności.
G. Arkit (WMIiE)
15 grudnia 2013
75 / 77
Tam gdzie potrzebna jest nam bardziej rozbudowana struktura
wersjonowania rekordów, należy ją po przewidzieć na etapie projektowania i
odpowiednio zaimplementować.
Możemy np. potrzebować historii zmian w strukturze organizacyjnej danej
instytucji, łącznie z np. powstaniem jednostek poprzez połączenie innych
jednostek (w tym także z jednej jednostki poprzez zmianę nazwy)m podział
jednostki na kilka innych itd. Co więcej może zaistnieć sytuacja, kiedy
będziemy musieli się odwołać do tych danych.
Sytuacja przykładowa: wydział zmienił nazwę, a następnie zgłosił się
absolwent, który prosi o wydanie suplementu. Oczywiście na suplemencie
taki musi być wydrukowany wydział jaki kończył student.
G. Arkit (WMIiE)
15 grudnia 2013
76 / 77
Jeden model bazy na różnych platformach
Jeden model bazy na różnych platformach
różnice w typach danych (np. brak typu logicznego w niektórych
systemach: FB, Oracle),
Oracle - brak domen (są typy ale ich wykorzystanie do budowania
tablic jest mało przydatne),
różnice w SQL - SELECT praktycznie bez zmian w różnych bazach,
tam gdzie się nie da ujednolicić należy zastosować perspektywy,
brakujące elementy - tablica DUAL, wybrane funkcje występujące w
jednej bazie należy stworzyć w drugiej (o ile są potrzebne),
bardziej skomplikowane operacje - procedury )sposób wywołania
procedur z poziomu języków programowania jest zazwyczaj
ujednolicony dla różnych baz danych
G. Arkit (WMIiE)
15 grudnia 2013
77 / 77

Modelowanie bazodanowe - Uniwersytet Zielonogórski

Transkrypt

Podobne dokumenty

Załącznik nr 1 do Umowy PRZEDMIOT ZAMÓWIENIA

modelowanie 3D

Szymon Jaroszewicz Modelowanie różnicowe W praktyce, celem

Specjalność: INŻYNIERIA MASZYN BUDOWLANYCH i SYSTEMÓW

Modelowanie komputerowe układów złożonych, prof. dr hab. Adam

MODELOWANIE I PROJEKTOWANIE W PROGRAMIE SKETCHUP

KarieraInformatyka-StartUp-IT

Hasło indeksowanie

Wstęp - Neuroinf.pl

Dazzling Design