modelowanie bazodanowe - wyk adstaff.uz.zgora.pl/garkit/mbd/wyklad.pdf · ... wstęp system...

Modelowanie bazodanowe - Wykład

Grzegorz Arkit

Wydział Matematyki, Informatyki i EkonometriiUniwersytet Zielonogórski

15 grudnia 2013

G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 1 / 77

Literatura

Literatura

Podstawy baz danych, Tadeusz Pankowski, Wydawnictwo NaukowePWN, 1992InterBase 6, Language Reference, Inprise/Borland, 1999 (dostępnypublicznie)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ępnypublicznie)inne źródła internetowe oraz materiały własne prowadzącego


Wykład I - Wstęp Przypomnienie wiadomości z teorii baz danych

Relacyjny model danych

Model relacyjnyW najprostszym ujęciu w modelu relacyjnym dane grupowane są w relacje,które reprezentowane są przez tablice. Kolumny opisują atrybuty a wierszedane.

Pomiędzy atrybutami w danej relacji mogą zachodzić zależności funkcyjne.



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, Access155 Excel, Pascal

WYPOŻYCZENIA (nr czytelnika, książka) - 1PNnr czytelnika książka

128 Pascal128 Access155 Excel155 Pascal



Przykłady:nazwisko, imiona – nie jest w 1PN,czy adres jest wartości elementarną?



Druga postać normalna (2PN, 2NF)Każda kolumna zależy funkcyjnie od klucza(każdego).

ZaliczeniaPrzedmiot, NrStudenta, TypOceny, Ocena, StudentKlucz: Przedmiot, NrStudentStudent zależy funkcyjnie od NrStudentaRozkład: względem zależności funkcyjnej NrStudent → StudentR1: Przedmiot, NrStudenta, TypOceny, OcenaR2: NrStudenta, Student



Trzecia postać normalna (3PN, 3NF)Gdy każdy atrybut niekluczowy jest bezpośrednio zależny od klucza (nie mazależności tranzytywnych).

imię nazwisko miejsce urodzenia powiatEmil Zając Pszczyna pszczyńskiZofia Zima Pszczyna pszczyńskiEulalia Jańska Szczebrzeszyn zamojski

Klucz: imię i nazwisko, ale jest zależność Miejsce urodzenia –> Powiat.



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, KodZależności: MU→ K, K→MKlucz: MU, KUDla zależności K→M, K jest nadkluczem.UWAGA: nie do końca właściwy, bo nie zawsze jednej ulicy w mieścieodpowiada jeden kod.



Dekompozycja

odnalezienie nietrywialnej zależności funkcyjnej: A1A2...An →B1B2...Bm, która narusza BCNF – tzn. A1A2...An nie jest nadkluczem,dodanie do prawej strony wszystkich atrybutów zależnych funkcyjnieod A1A2...An – w ten sposób powstaje nowa relacja,druga relacja będzie się składała z atrybutów A1A2...An oraz zpozostałych (poza B1B2...Bm) atrybutów relacji.


Wykład I - Wstęp System zarządzania bazą danych

System zarządzania bazą danych

System zarządzania bazą danych (SZBD, ang. Database ManagementSystem, DBMS) – oprogramowanie bądź system informatyczny służący dozarzą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.



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.



Dodatkowe (praktyczne) mechanizmy

wyzwalacze,procedury i funkcje operujące na danych,mechanizmy określania uprawnień do danych,perspektywy.



Rodzaje baz danych

lokalne (DBase, Paradox, Access, SQLite)bazy klient–serwerklastry bazodanowe (mirror, split) – replikacja



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 SQLServerExpress, DB2 Express (?) - darmowe wersje korporacyjnych bazdanych, ale z ograniczeniami na ilość używanych zasobów komputerai/lub ograniczeniami na wielkość bazy,komercyjne - lokalne: MS Access, Paradox,komercyjne – serwerowe: Oracle, MS SQL Server, DB2, itd...


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)



DML - Data Manipulation Language

INSERTUPDATEDELETE

Służą do manipulowania danymi w obrębie pojedyńczej tabeli.



DDL - Data Definition Language

CREATEALTERDROP

Służą do zarządzania obiektami bazy danych takimi jak tablice,perspektywy, indeksy, klucze, procedury, funkcje, pakiety i wiele innych.



DCL - Data Control Language

GRANTREVOKE

Służa do zarządzania uprawnieniami użytkowników w odniesieniu do samejbazy (np. możliwość tworzenia obiektów) jak i w odniesieniu do obiektów(np. możliwość odczytania danych z tablicy lub ich modyfikowania).



Języki proceduralne

Pozwalają budować procedury i/lub funkcje operujące na danych (np.zbudować uporządkowaną alfabetycznie listę nazwisk powiązanych z danymutworem, lub zebrać kilka operacji na danych w jeden blok widziany jakoatomowa operacja z punktu widzenia użytkownika).



DQL - Data Query Language

Komedna SELECT służąca do pobierania danych z tablic bazy danych.



Szczegóły na temat używania poszczególnych komend SQL można znaleźćw wymienionej literaturze.


Wykład II - Modelowanie bazodanowe - podstawowe pojęcia

Modelowanie danychW inżynierii oprogramowanie jest procesem tworzenia modelu danych dlasystemu informacyjnego poprzez zastosowanie formalnych technikmodelowania danych. Jest procesem używanym do definiowania ianalizowania danych wymaganych do obsługi procesów biznesowychbędących w zakresie systemu informacyjnego w danej organizacji.



Model danychJest zapisem (w systemie informacyjnym) informacji o obiektach (wraz zich własnościami) oraz relacji zachodzących pomiędzy tymi obiektami.



Model (schemat) koncepcyjnyObejmuje budowę modelu świata rzeczywistego wyrażonego w postaciokreślonych wymagań dotyczących danych.



Model logicznyOpisuje dane w postaci obiektów wraz z określonymi własnościami(zapisanymi za pomocą określonych typów danych) oraz relacje pomiędzynimi. 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 tomodel relacyjny.



Model fizycznyObrazuje fizyczny układ danych w docelowym systemie przeznaczonym doprzechowywania danych (w naszym przypadku w systemie RDBMS). Modelfizyczny może być powiązany z konkretnym rodzajem bazy danych, ale niemusi.



W przypadku mniejszych systemów modele koncepcyjny i logicznyzazwyczaj są tożsame. W modelowaniu bazodanowym zakładamy, że wiemyjakie dane są w danej strukturze potrzebne do obsługi procesówbiznesowych.



Encja (ang. entity)w bazach danych to reprezentacja wyobrażonego lub rzeczywistego obiektu(grupy obiektów) stosowana przy modelowaniu danych podczas analizyinformatycznej. Formalnie jest to pojęcie niedefiniowalne, a podstawowącechą encji jest to, że jest rozróżnialna od innych encji.



Relacja pomiędzy encjamiOpisuje w jaki sposób dane mogą zależeć od siebie w modelu relacyjnym.

artysta→ tworzy →

← jest tworzony ← utwór



Identifying relationjeżeli jest, to referencja w tablicy podrzędnej będzie elementem jej kluczagłównego.

W najnowszych systemach (np. Oracle SQL Developer Data Modeler odwersji 3.3) relacja w modelu logicznym mogą posiadać dodatkowe atrybuty(np. relacja pomiędzy przepisem a składnikiem może zawierać jednostkę iilość produktu użytego w danym przepisie).


Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych

Notacje w schematach relacyjnych



IDEF1X Relationship Cardinality Syntax



Bachman

Identifying – pionowa kreska przy „wiele”.



Barker notations

Identifying – pionowa kreska przy „wiele”.



Data Architect - notacja „kurzej” stopki – kółko (lub nic gdy nie jestwymagana), pionowa kreska gdy jest wymagana.



Reverse engineeringTechnika odwracania, inżynieria odwrotna, inżynieria wsteczna,programowanie zwrotne to proces badania produktu (urządzenia, programukomputerowego) w celu ustalenia jak on dokładnie działa, a także w jakisposób i jakim kosztem został wykonany. W przypadku modelowaniabazodanowego jest proces przejścia z modelu znajdującego się na niższympoziomie abstrakcji do modelu na wyższym poziomie abstrakcji.Najczęściej wykorzystywane do utworzenia modelu fizycznego na podstawieistniejącej bazy danych (np. w celu udokumentowania istniejącej bazydanych)


Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Narzędzia

Planowane narzędzia do użyciaOracle SQL Developer data ModelerOpen ModelSphereVisual Paradigm for UML Community EditionArgoUML-DB

Narzędzia pozwalają używać kilku notacjiPozostałe darmowe narzędzia pozwalają zazwyczaj na modelowaniekonkretnych baz danych na poziomie modelu fizycznego.


Praktyczne elementy projektowania BD Nazewnictwo obiektów

Przedrostki określające rodzaj obiektu:TB - tablicaPRC - proceduraTG - triggeritd....

Nazwy obiektów: liczba mnoga czy pojedyncza?Nazwy kluczy obcych: mianownik czy dopełniacz?Nazwy kluczy głównych: ID czy ID_tablica?


Praktyczne elementy projektowania BD Nazewnictwo obiektów

Przedrostki określające fragment funkcjonalny schematuST - studentRK - rekrutacjaPL - plan zajęćitd....

Należy pamiętać o ograniczeniach na długość nazw (np. Oracle - 30znaków).


Przydatne funkcje bazodanowe Ograniczenie danych widzianych przez użytkownika

Updatable views

ograniczenie przez where (w niektórych bazach danych przez „withcheck”)aby były „updatable” - kolumna z tabeli 1:1 na kolumnę w viewaby można było robić insert w view muszą być wszystkie pola not nullz tabeliwith check option - aby spowodować kontrolę danych przy insert iupdate (czy po zmianie dane będą zgodne z definicją perspektywy)



Firebirdmogą być proste albo przez trigger – dodanie triggera do view blokujeautomatyczny zapis do tabeli – trzeba wykonać w triggerze odpowiedniąkomendę SQL,

PosgreSQLsimple view is automatically updatable , view + „rule” (create rule"_insert" as on insert to uzytk_v do instead . . . ).

Oraclesimple view is automatically updatable, CREATE OR REPLACE TRIGGERorder_info_insert INSTEAD OF INSERT ON order_info

Uprawnienia: wystarczy nadać uprawnienia dla view – inaczej byłoby to bezsensu bo user i tak miałby bezpośredni dostęp do danych więc ograniczeniebyłoby niepotrzebne.



Do czego można zastosować:dane osobowe – przechowywane w jednej tabeli, ale różne grupyuż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 jednejperspektywy z podziałem danych na dwie tabele.


Przydatne funkcje bazodanowe Wyzwalacze - kontrola poprawności danych

Wyzwalacze pozwalają na wygenerowanie zdefiniowanego przezuż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 wpisaniajeszcze jednej rezerwacji wygenerować odpowiedni błąd. Oczywiściewszystkie wymienione konstrukcje można stosować także procedurach.


Przydatne funkcje bazodanowe Wyzwalacze - kontrola poprawności danych

Firebirdtworzymy wyjątek: create exception nazwa ’tekst’wywołujemy: exception nazwalub wywołujemy : exception nazwa ’custom msg’

PostgreSQLraise exception ’tekst’;

OracleRaise_Application_Error(numer, ’tekst’), numer = -20000 .. -20999


Przydatne funkcje bazodanowe Funkcje (procedury) zwracające zestawy rekordów

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 wymagazbudowania skomplikowanego zapytania. Za pomocą takich funkcji możemynp. z podanego kodu XML pobrać w postaci zestawu rekordów dane oustalonej strukturze.



FirebirdCREATE OR ALTER PROCEDURE pl_enum (parametry wejściowe)returns (pola+typy)asbegin

......– przypisanie wartości do zmiennychsuspend;......

end

WywołanieJak normalną tabelę tylko, że z parametrami:

SELECT ... FROM pl_enum(.......);



PosgteSQLCREATE OR REPLACE FUNCTION funkca1(parametry)

RETURNS SETOF record AS$BODY$DECLARE rr

record;begin

for rr inselect ......

loopreturn next rr;

end loop;return ;

end;$BODY$

LANGUAGE plpgsql VOLATILE SECURITY DEFINER;



WywołaniePrzy wywołaniu trzeba podać nazwy i typy kolumn:

select ... from pl_jednostki_tablicy(’sala_vd’) as (id_jedn d_ref_null);



OracleNajpierw typ zwracanego rekordu:

CREATE OR REPLACE TYPE ret_id AS OBJECT (id integer

);

Potem zbiór rekordów:

CREATE OR REPLACE TYPE ret_id_set;



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łanieSELECT id FROM TABLE(get_id_list(pR_IDs))


Przydatne funkcje bazodanowe Temporary tables

Temporary tables

PostgresqlTabele tymczasowe są tworzone tylko na czas sesji - po zakończeniu sesjitablica jest kasowana. Po commit tabela może być nienaruszona, możnaskasować jej zawartość lub usunąć całkowicie.


Przydatne funkcje bazodanowe Temporary tables

FirebirdGlobalna – ma zdefiniowane na stałe metadane (nie trzeba jej tworzyć zakażdym razem), ale zawartość jest kasowana po zakończeniu transakcji lubpołączenia (w zależności od tego jak jest zdefiniowana).

CREATE GLOBAL TEMPORARY TABLE...[ON COMMIT <DELETE | PRESERVE> ROWS]

OracleAnalogicznie hak Firebird


Przydatne funkcje bazodanowe 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ążabazę 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. nazwiskaosoby).


Przydatne funkcje bazodanowe 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


Przydatne funkcje bazodanowe Metody dostępu do bazy danych z poziomu aplikacji

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)



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 swojepotrzeby oddzielne, potrzebne tylko im moduły+/- projektując aplikację z DBUSER trzeba całą logikę zawrzeć wbazie danych (przynajmniej jeżeli chodzi o kontrolę uprawnień iintegralność danych)- nieświadomy użytkownik może obciążyć bazę niezoptymalizowanymizapytaniami- komendy SQL (UPDATE, DELETE) nie pytają o potwierdzeniemodyfikacji danych – można zmodyfikować dużą ilość danych (np.budując nieprawidłowy warunek WHERE)



Zalety i wady APPUSER konta DBUSER:+ użytkownik może wykonywać tylko operacje dopuszczone przezprojektanta aplikacji+ część logiki można zawrzeć w aplikacji- nie ma możliwości bezpośredniego dostępu do danych, więcnietypowe raporty i zestawienia musi wykonywać administrator- mimo wszystko użytkownik, żeby połączyć się z bazą danych musiprzesłać do niej dane logowania (DBUSER) – gdzieś to trzeba zapisać(czyli istnieje możliwość złamania zabezpieczenia)+ w przypadku aplikacji webowych (zwłaszcza na serwerachzewnętrznych) nie ma możliwości zbudowania systemu userówbazodanowych, więc zostaje tylko opcja z APPUSER


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 modelzarządzania użytkownikami systemu opartego o bazę danych - model tenmożna wykorzystać zarówno w systemach gdzie użytkownik aplikacji jestjednocześnie użytkownikiem bazodanowym, jak i w systemach gdzie obie tegrupy są rozdzielone.Model załączony jest w oddzielnym pliku (model_1.jpg).



Użyte typy danych (domeny):d_ids, d_ref, d_ref_null – oparte na typie bigint domeny służące wdo tworzenia referencji (kluczy głównych i obcych, ostatia dopuszczawartości puste),d_sys_name – domena tekstowa (30 znaków) która służy dozapisywania w tabelach nazw obiektów bazodanowych, z kontrolą czydana nazwaz może być identyfikatorem,d_nazwa, d_nazwa_krotka, d_opis – typy tekstowa o określonej zgóry długości,d_calkowita – wartość całkowita,d_logiczna – wartość logiczna (TRUE/FALSE lub 0/1 w zależności odtego co oferuje silnik danej bazy).



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 jednajednostka może być na szczycie hierarchii (jest tylko jedna jednostka bezjednostki 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 worganizacji - jeżeli z jakichś względów potrzebne jest np. zachowanie historiizmian 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órazawiera wszystkie pary jednostka-nadrzędna–jednostka-podrzędna (zarównozależność bezpośrednia jak i zależność pośrednia). Ze względówpraktycznych przyjęto, że w tablicy tej występują też wszystkie paryjednostka–jednostka.



Zabezpieczenia:nie można usunąć jednostki ze szczytu hierarchii (root),po utworzeniu jednostki dodajemy zależności: jednostka–jednostkaoraz pary jednostka–jednostka nadrzędnaprzy zmianie jednostki nadrzędnej (przeniesienie jednostki wstrukturze) kasujemy wpisy o zależnościach i tworzymy nowe, kontrolaczy nie powstają cyklenie można modyfikować rekordów w tablicy z zależnościami (tylkoINSERT I DELETE),



Poziomy uprawnień

Opisują do jakich obiektów bazodanowych użytkownik ma dostęp – wprzypadku modelu APPUSR=DBUSER, odpowiadają one rolom. Oznaczato, że modyfikując dane opisujące poziom uprawnień modyfikujemy też rolebazodanowe (wymaga to odpowiednich uprawnień administracyjnych napoziomie 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ą wtablicy obiekt, wraz z podanym typem obiektu (tablica, perspektywa iprocedura/funkcja). Ważną grupę stanowią obiekty, w których dane będądzielone ze względu na jednostki – są to perspektywy pobierające dane ztablic bazowych; jeżeli umożliwiają one modyfikowanie danych totraktujemy jej jak tablice (tablice dzielone), w przeciwnym wypadku jakwł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).



Tablica typ_obiektu_upraw opisuje jakie uprawnienia można nadawaćobiektom danego typu. Dodatkowo występuje tablicaobiekt_wyklucz_upraw, która dla danego obiektu pozwala wyłączyćkontrolę konkretnego uprawnienia.Tablica poziom_obiekt pozwala nadać uprawnienia do obiektu dlaokreślonego poziomu uprawnień (UWAGA: w sytuacji, gdyAPPUSER=DBUSER powoduje to nadanie/odebranie uprawnień dlaokreślonej roli).



Użytkownicy

Dane o użytkownikach zebrane są w tablicy uzytk. Należy pamiętać, że wmodelu APPUSER = DBUSER, dane te przekładają się na użytkownikówbazodanowych, co pociąga za sobą konieczność dbania o odpowiedniekonstruowanie nazw, a także dopilnowanie, żeby użytkownik dokonującyzmian miał odpowiednie uprawnienia (podobnie jak przy poziomachuprawnień).Każdy użytkownik może być powiązany z różnymi poziomami uprawnień, zktórych wynikają jego uprawnienia, ale może mieć też nadane dodatkoweindywidualne 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 uprawnieniaużytkownika (te wynikające z poziomów uprawnień oraz te nadaneindywidualnie). W przypadku rozbudowanych systemów z dużą ilościąuprawnień można rozważyć stworzenie “materialized view” lub nawettablicy, w której dane będą aktualizowane na życzenie lub w określonychodstępach czasowych (np. w nocy).



Podziały danych

W strukturze hierarchicznej występuje nie tylko podział uprawnień dooperowania na wybranych danych. Dane te należy podzielić także zewzględu na miejsce w strukturze organizacyjnej. Np. dziekanat konkretnegowydziału uczelni widzi tylko dane swoich studentów. Oczywiście nie należytworzyć oddzielnych tablic dla każdego dziekanatu, tylko podzielić daneistniejące w konkretnej tablicy za pomocą perspektywy lub perspektyw;najlepsza opcją jest zastosowanie jednej perspektywy, która będzie zwieraładane widoczne przez jednego użytkownika (w przypadku koniecznościzmian dokonujemy ich w jednym miejscu).



Podziały danych

Po pierwsze musimy określić w jaki sposób będą dzielone dane dlaposzczególnych podziałów: tablica podzial i tablica podzial_jedn. Druga ztych tablic opisuje jakie jednostki wchodzą w skład danego poziomu; ważnejest pole czy_podrzedne - mówi nam ono, że oprócz danej jednostki dopoziomu wchodzą wszystkie jednostki podrzędne danej jednostki - dziękitemu, po dodaniu jednostki nie musimy się przejmować dodaniem jej doodpowiednich poziomów.Użytkownik jest zawsze przypisany do jednego podziału danych.



Tablice dzielone

W rzeczywistości są to perspektywy (jedna dla jednej tablicy) w którychwyświetlane są dane przewidziane dla danego poziomu; w zależności odrodzaju danych mogą być one przeznaczone tylko do odczytu (faktyczneperspektywy) lub mogą aktualizowane (updatable view).Podział danych na jednostki może być takim jak dla całego podziału, doktórego przypisany jest użytkownik, może też być określony indywidualniedla konkretnej tablicy (perspektywy).Ze względu na dużą ilość możliwości definiowana widzialności danych wdanej tablicy dzielonej, należy utworzyć perspektywę, która będzie zbieraładane o elementach danej tablicy dzielonej. Podobnie jak w przypadkupoziomów uprawnień, w przypadku rozbudowanych systemów z duża ilościąuprawnień można rozważyć stworzenie “materialized view” lub nawettablicy, w której dane będą aktualizowane na życzenie lub w określonychodstępach czasowych (np. w nocy).



Dane domyślne

Do prawidłowej pracy systemu potrzebne jest stworzenie pewnychpodstawowych obiektów w podanej strukturze:

podstawowy poziom uprawnień - poziom, który zawiera uprawnienia,które musi posiadać każdy użytkownik systemu (np. uprawnieniaconnect czy uprawnienia select dla wybranych tablic)użytkownik-administrator - użytkownik, który ma uprawnienia dowykonywania czynności administracyjnych w systemie; użytkownik takimusi posiadać, dodatkowe uprawnienia na poziomie RDBMS, aby mócnp. dodać użytkownika czy też zmienić mu hasło.


Przydatne fragmenty modeli bazodanowych Kolizje wykorzystania zasobów

Kolizje wykorzystania zasobów

Np. tablice obiekt i rezerwacje. W tej drugiej są kolumny określające, kiedydany obiekt jest zajęty (od-do w postaci timestamp, lub od-do idzień/data).Możemy zastosować dwa podejścia: kontrola możliwości wykonania operacjirezerwacji a potem wpisanie rezerwacji lub kontrola poprawności wykonaniaoperacji po jej wykonaniu.Każda z tych metod ma swoje wady.


Przydatne fragmenty modeli bazodanowych Kolizje wykorzystania zasobów

Kolizje wykorzystania zasobów

Jeżeli sprawdzamy możliwość wykonania rezerwacji przed jej wykonaniem,to w systemach wielodostępnych, musimy zapewnić, żeby do czasywykonania właściwej operacji rezerwacji, stan danych się nie zmienił. Efektten 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 znacznespowolnienie 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, cospowoduje wycofanie transakcji. Niestety takie podejście też nie jestpozbawione 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, żewykorzystywane są mechanizmy bazy danych (np. temporary table spaces,redo-logi itp) Podejście to jest jednak dużo łatwiejsze w implementacji.


Przydatne fragmenty modeli bazodanowych Wersjonowanie rekordów

Wersjonowanie rekordów

Pojęcie to występuje zwłaszcza w hurtowniach danych ale jest też istotne wtradycyjnym modelowaniu bazodanowym.Najczęściej są to sytuacje, kiedy pewne rekordy muszą zostać ukryte wbazie, gdyż już z nich nie korzystamy, ale ze względu na integralność bazynie mogą być one usunięte (dane archiwalne). W takim przypadkuzazwyczaj wystarczy dodanie pola (aktywny, archiwum, widoczny itp.),które steruje widocznością obiektu w aplikacjiDruga najczęstsza sytuacja, to kontrola zmian danych wykonywanych przezużytkowników - w tym wypadku wystarczy stworzyć kopię wybranej tablicyz dodatkowymi polami przeznaczonymi na czas i rodzaj zmiany oraz ktowykonał daną zmianę. Natomiast w tablicy podstawowej (bazowej) należydodać wywołania wyzwalaczy (trigger) - należy pamiętać aby ustawić je wodpowiedniej kolejności.


Przydatne fragmenty modeli bazodanowych Wersjonowanie rekordów

Wersjonowanie rekordów

Tam gdzie potrzebna jest nam bardziej rozbudowana strukturawersjonowania rekordów, należy ją po przewidzieć na etapie projektowania iodpowiednio zaimplementować.Możemy np. potrzebować historii zmian w strukturze organizacyjnej danejinstytucji, łącznie z np. powstaniem jednostek poprzez połączenie innychjednostek (w tym także z jednej jednostki poprzez zmianę nazwy)m podziałjednostki na kilka innych itd. Co więcej może zaistnieć sytuacja, kiedybę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 suplemencietaki musi być wydrukowany wydział jaki kończył student.


Przydatne fragmenty modeli bazodanowych 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órychsystemach: FB, Oracle),Oracle - brak domen (są typy ale ich wykorzystanie do budowaniatablic 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 wjednej bazie należy stworzyć w drugiej (o ile są potrzebne),bardziej skomplikowane operacje - procedury )sposób wywołaniaprocedur z poziomu języków programowania jest zazwyczajujednolicony dla różnych baz danych


modelowanie bazodanowe - wyk adstaff.uz.zgora.pl/garkit/mbd/wyklad.pdf · ... wstęp system...

Documents