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) Modelowanie bazodanowe (W) 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) Modelowanie bazodanowe (W) 15 grudnia 2013 3 / 77
Wykład I - Wstęp Przypomnienie wiadomości z teorii baz danych 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) Modelowanie bazodanowe (W) 15 grudnia 2013 4 / 77
Wykład I - Wstęp Przypomnienie wiadomości z teorii baz danych Przykłady: nazwisko, imiona nie jest w 1PN, czy adres jest wartości elementarną? G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 5 / 77
Wykład I - Wstęp Przypomnienie wiadomości z teorii baz danych 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) Modelowanie bazodanowe (W) 15 grudnia 2013 6 / 77
Wykład I - Wstęp Przypomnienie wiadomości z teorii baz danych Trzecia postać normalna (3PN, 3NF) Gdy każdy atrybut niekluczowy jest bezpośrednio zależny od klucza (nie ma zależności tranzytywnych). imię nazwisko miejsce urodzenia powiat Emil Zając Pszczyna pszczyński Zofia Zima Pszczyna pszczyński Eulalia Jańska Szczebrzeszyn zamojski Klucz: imię i nazwisko, ale jest zależność Miejsce urodzenia > Powiat. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 7 / 77
Wykład I - Wstęp Przypomnienie wiadomości z teorii baz danych 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) Modelowanie bazodanowe (W) 15 grudnia 2013 8 / 77
Wykład I - Wstęp Przypomnienie wiadomości z teorii baz danych Dekompozycja odnalezienie nietrywialnej zależności funkcyjnej: A 1 A 2...A n B 1 B 2...B m, która narusza BCNF tzn. A 1 A 2...A n nie jest nadkluczem, dodanie do prawej strony wszystkich atrybutów zależnych funkcyjnie od A 1 A 2...A n w ten sposób powstaje nowa relacja, druga relacja będzie się składała z atrybutów A 1 A 2...A n oraz z pozostałych (poza B 1 B 2...B m ) atrybutów relacji. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 9 / 77
Wykład I - Wstęp System zarządzania bazą danych 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) Modelowanie bazodanowe (W) 15 grudnia 2013 10 / 77
Wykład I - Wstęp System zarządzania bazą danych 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) Modelowanie bazodanowe (W) 15 grudnia 2013 11 / 77
Wykład I - Wstęp System zarządzania bazą danych Dodatkowe (praktyczne) mechanizmy wyzwalacze, procedury i funkcje operujące na danych, mechanizmy określania uprawnień do danych, perspektywy. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 12 / 77
Wykład I - Wstęp System zarządzania bazą danych Rodzaje baz danych lokalne (DBase, Paradox, Access, SQLite) bazy klient serwer klastry bazodanowe (mirror, split) replikacja G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 13 / 77
Wykład I - Wstęp System zarządzania bazą danych 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) Modelowanie bazodanowe (W) 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) Modelowanie bazodanowe (W) 15 grudnia 2013 15 / 77
Wykład I - Wstęp Podstawy języka SQL DML - Data Manipulation Language INSERT UPDATE DELETE Służą do manipulowania danymi w obrębie pojedyńczej tabeli. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 16 / 77
Wykład I - Wstęp Podstawy języka SQL 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) Modelowanie bazodanowe (W) 15 grudnia 2013 17 / 77
Wykład I - Wstęp Podstawy języka SQL 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) Modelowanie bazodanowe (W) 15 grudnia 2013 18 / 77
Wykład I - Wstęp Podstawy języka SQL 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) Modelowanie bazodanowe (W) 15 grudnia 2013 19 / 77
Wykład I - Wstęp Podstawy języka SQL DQL - Data Query Language Komedna SELECT służąca do pobierania danych z tablic bazy danych. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 20 / 77
Wykład I - Wstęp Podstawy języka SQL Szczegóły na temat używania poszczególnych komend SQL można znaleźć w wymienionej literaturze. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 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) Modelowanie bazodanowe (W) 15 grudnia 2013 22 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia 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) Modelowanie bazodanowe (W) 15 grudnia 2013 23 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Model (schemat) koncepcyjny Obejmuje budowę modelu świata rzeczywistego wyrażonego w postaci określonych wymagań dotyczących danych. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 24 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia 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) Modelowanie bazodanowe (W) 15 grudnia 2013 25 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia 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) Modelowanie bazodanowe (W) 15 grudnia 2013 26 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia 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) Modelowanie bazodanowe (W) 15 grudnia 2013 27 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia 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) Modelowanie bazodanowe (W) 15 grudnia 2013 28 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Relacja pomiędzy encjami Opisuje w jaki sposób dane mogą zależeć od siebie w modelu relacyjnym. artysta tworzy jest tworzony utwór G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 29 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia 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) Modelowanie bazodanowe (W) 15 grudnia 2013 30 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych Notacje w schematach relacyjnych G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 31 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 32 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 33 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych IDEF1X Relationship Cardinality Syntax G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 34 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych Bachman Identifying pionowa kreska przy wiele. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 35 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych Barker notations Identifying pionowa kreska przy wiele. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 36 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 37 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 38 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych Data Architect - notacja kurzej stopki kółko (lub nic gdy nie jest wymagana), pionowa kreska gdy jest wymagana. G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 39 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia Notacje w schematach relacyjnych 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) Modelowanie bazodanowe (W) 15 grudnia 2013 40 / 77
Wykład II - Modelowanie bazodanowe - podstawowe pojęcia 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) Modelowanie bazodanowe (W) 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) Modelowanie bazodanowe (W) 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) Modelowanie bazodanowe (W) 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) Modelowanie bazodanowe (W) 15 grudnia 2013 44 / 77
Przydatne funkcje bazodanowe Ograniczenie danych widzianych przez użytkownika 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) Modelowanie bazodanowe (W) 15 grudnia 2013 45 / 77
Przydatne funkcje bazodanowe Ograniczenie danych widzianych przez użytkownika 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) Modelowanie bazodanowe (W) 15 grudnia 2013 46 / 77
Przydatne funkcje bazodanowe 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) Modelowanie bazodanowe (W) 15 grudnia 2013 47 / 77
Przydatne funkcje bazodanowe 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) Modelowanie bazodanowe (W) 15 grudnia 2013 48 / 77
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 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) Modelowanie bazodanowe (W) 15 grudnia 2013 49 / 77
Przydatne funkcje bazodanowe Funkcje (procedury) zwracające zestawy rekordów 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) Modelowanie bazodanowe (W) 15 grudnia 2013 50 / 77
Przydatne funkcje bazodanowe Funkcje (procedury) zwracające zestawy rekordów 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) Modelowanie bazodanowe (W) 15 grudnia 2013 51 / 77
Przydatne funkcje bazodanowe Funkcje (procedury) zwracające zestawy rekordów 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) Modelowanie bazodanowe (W) 15 grudnia 2013 52 / 77
Przydatne funkcje bazodanowe Funkcje (procedury) zwracające zestawy rekordów Oracle Najpierw 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; G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 53 / 77
Przydatne funkcje bazodanowe Funkcje (procedury) zwracające zestawy rekordów 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) Modelowanie bazodanowe (W) 15 grudnia 2013 54 / 77
Przydatne funkcje bazodanowe 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) Modelowanie bazodanowe (W) 15 grudnia 2013 55 / 77
Przydatne funkcje bazodanowe 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) Modelowanie bazodanowe (W) 15 grudnia 2013 56 / 77
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ąż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) Modelowanie bazodanowe (W) 15 grudnia 2013 57 / 77
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 G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 58 / 77
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) G. Arkit (WMIiE) Modelowanie bazodanowe (W) 15 grudnia 2013 59 / 77
Przydatne funkcje bazodanowe Metody dostępu do bazy danych z poziomu aplikacji 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) Modelowanie bazodanowe (W) 15 grudnia 2013 60 / 77
Przydatne funkcje bazodanowe Metody dostępu do bazy danych z poziomu aplikacji 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) Modelowanie bazodanowe (W) 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) Modelowanie bazodanowe (W) 15 grudnia 2013 62 / 77
Przydatne fragmenty modeli bazodanowych System zarządzania użytkownikami 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) Modelowanie bazodanowe (W) 15 grudnia 2013 63 / 77
Przydatne fragmenty modeli bazodanowych System zarządzania użytkownikami 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) Modelowanie bazodanowe (W) 15 grudnia 2013 64 / 77
Przydatne fragmenty modeli bazodanowych System zarządzania użytkownikami 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) Modelowanie bazodanowe (W) 15 grudnia 2013 65 / 77
Przydatne fragmenty modeli bazodanowych System zarządzania użytkownikami 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) Modelowanie bazodanowe (W) 15 grudnia 2013 66 / 77
Przydatne fragmenty modeli bazodanowych System zarządzania użytkownikami 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) Modelowanie bazodanowe (W) 15 grudnia 2013 67 / 77
Przydatne fragmenty modeli bazodanowych System zarządzania użytkownikami 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) Modelowanie bazodanowe (W) 15 grudnia 2013 68 / 77
Przydatne fragmenty modeli bazodanowych System zarządzania użytkownikami 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) Modelowanie bazodanowe (W) 15 grudnia 2013 69 / 77
Przydatne fragmenty modeli bazodanowych System zarządzania użytkownikami 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) Modelowanie bazodanowe (W) 15 grudnia 2013 70 / 77