Spis treści. 1 Modelowanie logiczne. Plan wykładu. 1 Modelowanie logiczne 1

Transkrypt

1 Plan wykładu Spis treści 1 Modelowanie logiczne 1 2 Transformacja modelu pojęciowego do logicznego Transformacja własności Transformacja związków Transformacja hierarchii Dodatkowe obiekty i techniki Dostęp do danych Denormalizacja Podsumowanie 14 4 Źródła 14 1 Modelowanie logiczne Projektowanie systemu informatycznego Modelowanie logiczne Modelowanie logiczne jest realizowane przez projektantów na bazie specyfikacji wymagań i modelu pojęciowego. Powiązany ze ściśle określonym modelem bazy danych, a często z konkretną jej implementacją. Określa struktury modelu danych, nie zaś struktury fizyczne. 1

2 Efekty modelowania logicznego Efektem modelowania logicznego będzie szczegółowa dokumentacja zawierająca: tabele, ograniczenia integralności, dodatkowe obiekty (perspektywy, indeksy,sekwencje itp.), określenie użytkowników i ich uprawnień, niektóre parametry fizyczne bazy danych. Terminologia Model relacyjny Model związków Relacyjna baza encji danych relacja encja tabela krotka instancja wiersz atrybut własność kolumna dziedzina dziedzina/typ dziedzina/typ schemat relacji struktura tabeli schemat Zalecenia Efektem modelowania logicznego powinno być szczegółowe określenie struktur danych i obiektów pomocniczych. Należy zdecydować się na pełne wykorzystanie cech danego SZBD, lub tworzyć projekt łatwy do przeniesienia pomiędzy poszczególnymi SZBD. Należy stosować jednolite nazewnictwo, ułatwiajace ewentualne przenoszenie bazy: nazwy zawierają wyłącznie litery, cyfry i znaki podkreślenia, brak znaków diakrytycznych, nazwy nie mogą różnić się jedynie wielkością liter, nazwy nie powinny być zbyt długie, należy unikać skrótów, jeżeli są konieczne stosuje się jedynie te powszechnie znane, tabele nazywane są w liczbie mnogiej, kolumny w pojedynczej, stosuje się nazwy dla ograniczeń integralnościowych (np. dla kluczy głównych skrót od nazwy tabeli i angielskiego PRIMARY KEY - tab pk, dla kluczy obcych skróty nazw obu tabel i angielskiego FOREIGN KEY - tab1 tab2 fk ). 2 Transformacja modelu pojęciowego do logicznego Transformacja modelu pojęciowego do logicznego (relacyjnej bazy danych) encje tabele 2

3 własności kolumny związki klucze obce lub tabele hierarchia encji jedna lub dwie lub trzy tabele 2.1 Transformacja własności Transformacja własność - kolumna Własność kolumna: typ własności typ występujący w wybranym SZBD obowiązkowość własności ograniczenie NOT NULL własność kluczowa klucz główny tabeli ograniczenia własności ograniczenia integralnościowe kolumn Transformacja własność - kolumna - zalecenia Zasady poprawnej transformacji: kolejność kolumn w tabelach oszczędzająca pamięć i ograniczająca fragmentację, np.: atrybuty obowiązkowe przed opcjonalnymi kolumny o stałej długości przed tymi o zmiennej długości dobór typów zapewniający poprawność i efektywność prezentacji, np.: typ CHAR stosowany wyłącznie dla łańcuchów o stałej długości wartości pieniężne wyrażane przez typy z możliwym określeniem skali (NUMBER, NUMERIC, DE jeżeli nie przewidziano własności kluczowej lub istniejąca nie spełnia wymagań, należy wprowadzić sztuczny klucz główny. jeżeli wiemy, że własnośc posiada niepowtarzalne wartości należy na jej bazie utworzyć klucz kandydujący - kolumnę o ograniczeniu UNIQUE 3

4 2.2 Transformacja związków Transformacja związków I związki klucze obce utworzenie kolumn nadanie ograniczeń czy wartość ma być obowiązkowa zgodne typy kluczy obcych i kluczy, na które wskazują pożądana zgodność nazw kluczy obcych i kluczy, na które wskazują związki tabele klucz główny stanowiący złożenie kluczy głównych tabeli powiązanych kolumny klucza głównego są jednocześnie dowiązaniami (kluczami obcymi) obligatoryjne uczestnictwo w związku NOT NULL dla klucza obcego Transformacja związków II Związek unarny 1:1 klucz obcy w tej samej tabeli. Związek unarny 1:M klucz obcy w tej samej tabeli. Związek unarny M:N tabela. Związek binarny 1:1 klucz obcy w jednej z tabel. Związek binarny 1:M klucz obcy w tabeli po stronie wiele. Związek binarny M:N tabela. Związek ternarny tabela. Związek unarny 1:1 Związek unarny 1:1 klucz obcy w tej samej tabeli. 4

5 Związek unarny 1:N Związek unarny 1:N klucz obcy w tej samej tabeli. Związek unarny N:M Związek unarny N:M tabela. Związek binarny 1:1 Związek binarny 1:1 klucz obcy w jednej z tabel (po stronie obligatoryjnego udziału w związku lub po stronie tabeli o mniejszym rozmiarze dla związków dwustronnie opcjonalnych). 5

6 Związek binarny 1:N Związek binarny 1:M klucz obcy w tabeli po stronie wiele, NOT NULL dla obligatoryjnego udziału. Opcjonalność lub obowiązkowość związku po stronie jeden nie jest odwzorowywana w modelu relacyjnym. Związek binarny N:M Związek binarny N:M tabela (jej nazwa jest złączeniem nazw tabel pozostających w związku, klucze obce tworzą klucz główny). 6

7 Związek ternarny Związek ternarny tabela (klucze obce tworzą klucz główny). 2.3 Transformacja hierarchii Transformacja hierarchii Trzy metody modelowania logicznego hierarchii: utworzenie jednej tabeli o dodatkowej kolumnie opisującej typ, kolumny odróżniające podtypy są opcjonalne utworzenie oddzielnych tabel dla każdego podtypu utworzenie tabeli nadtypu z kolumnami wspólnymi dla wszystkich podtypów i dowiązaniami do podtypów, oraz tabel podtypów ze specyficznymi dla nich kolumnami 7

8 Dla związków wzajemnie wykluczających się - w zależności od ww. wyboru: dla każdego podtypu odrębny klucz obcy przyjmujący opcjonalne wartości lub jeden klucz obcy i dodatkowy warunek wykluczenia (nałożony więzami CHECK) Transformacja hierarchii 1 Transformacja hierarchii 2 Transformacja hierarchii 3 8

9 Transformacja dla związków wzajemnie wykluczających się 1 Transformacja dla związków wzajemnie wykluczających się 2 9

10 2.4 Dodatkowe obiekty i techniki Indeksy Indeks bazy danych struktura (plik) kojarząca wartości klucza indeksowego (atrybutu, na który nałożono indeks) z fizycznym położeniem danych, służąca do przyśpieszania przeszukiwania bazy danych. Wady: Zastosowanie: szybkie przeszukiwanie danych, szybkie sortowanie danych, optymalizacja zapytań, efektywne wykonywanie złączeń. spowolnienie aktualizacji. Rodzaje indeksów Wyróżniamy indeksy: proste (dla jednej kolumny) i złożone (dla wielu kolumn), drzewiaste, bitmapowe, unikatowe, dopuszczające powtórzenia. 10

11 Indeksy - zalecenia Indeksy drzewiaste tworzy się dla: kluczy głównych (często domyślnie), kolumn o unikatowych lub rzadko powtarzających się wartościach, kolumn często występujących w warunkach zapytań i złączeń, kolumn rzadko aktualizowanych, kluczy obcych. Indeksy bitmapowe tworzy się dla: dużych tabel (najczęściej w systemach analitycznych), kolumn o często powtarzających się wartościach (o niskiej kardynalności). Klastry Klaster struktura umożliwiająca przechowywanie danych logicznie ze sobą powiązanych w fizycznej bliskości, nie widoczna dla użytkowników i aplikacji. Wady: Zastosowanie: przyśpiesza czas dostępu do danych, zmniejsza liczbę odczytanych bloków, ogranicza zapotrzebowanie na przestrzeń dyskową, poprawia efektywność niektórych zapytań. spowolnienie aktualizacji, spowolnienie pełnego przeglądania tabeli. Klastry - rodzaje i zalecenia Rodzaje: indeksowe, haszowe. Klastry są stosowane dla tabel: często łączonych, rzadko aktualizowanych, o stosunkowo stałych rozmiarach, rzadko przeglądanych w całości. 11

12 Partycje Partycjonowanie tabel technika dzielenia bardzo dużych tabel na mniejsze fragmenty. Typy: zakresowe, haszowe. Zastosowanie: ułatwienie zarządzania danymi, efektywniejszy dostęp. Perspektywy Perspektywa - (ang. view - widok, tabela wirtualna) jest to zapamiętane pod określoną nazwą zapytanie, którego wynik nie jest przechowywany fizycznie, używana w zapytaniach jak zwykłe tabele. Zastosowanie: ograniczenie dostępu do całości danych (dodatkowy poziom bezpieczeństwa), ułatwienie wykonywania często stosowanych lub skomplikowanych zapytań, odizolowanie aplikacji i użytkowników od definicji tabel. Perspektywy - cechy Typy: perspektywy proste i złożone. Modyfikowalność: niemodyfikowalne jeżeli brak jednoznaczności, gdzie dane mają być wstawione, niemodyfikowalne dla użytkowników o ograniczonych uprawnieniach, możliwość wymuszenia modyfikacji poprzez stosowanie odpowiednich wyzwalaczy. Perspektywy materializowane Perspektywa materializowana - (ang. materialised view) to perspektywa, której zawartość jest fizycznie składowana w bazie danych - implementowana jako: tabela + indeks. Cechy: Zastosowanie: hurtownie danych, rozproszone bazy danych, systemy mobilne. alokacja pamięci jak dla tabel, możliwość indeksowania, nakładania więzów, zazwyczaj niemodyfikowalne, odświeżane w sposób pełny lub szybki. 12

13 Sekwencje Sekwencja obiekt bazodanowy używany do generowania unikalnych wartości. Zastosowanie: generowanie sztucznych kluczy głównych. Synonimy Synonim umożliwia nadanie alternatywnych nazw dla niektórych obiektów bazy danych (tabel, sekwencji, procedur, pakietów itp.). Stosowane dla odległych lub znajdujących się w innych schematach obiektów. Korzyści: uproszczenie nazw, odizolowanie użytkowników i aplikacji od zmian zachodzących w schemacie pojęciowym, czy wewnętrznym bazy danych, uniezależnienie od rzeczywistej lokalizacji obiektów, uniezależnienie od rzeczywistej natury obiektu. Rodzaje: publiczne i prywatne. 2.5 Dostęp do danych Dostęp do danych Organizacja dostępu do danych: minimum praw dostępu, które są odpowiednio zróżnicowane, zapewnienie odporności na zmiany struktury, dane umieszczone w wydzielonym schemacie aplikacje i użytkownicy korzystają z kont nie mając bezpośredniego dostępu do schematu, a jedynie dostęp poprzez odpowiedni system uprawnień, synonimów i perspektyw. 2.6 Denormalizacja Denormalizacja Celowe wprowadzenie redundancji: dla poprawienia wydajności, dla przechowywania wyników złożonych obliczeń, dla przechowywania danych w celach kontrolnych, dla przechowywania danych w celach zapewnienia bezpieczeństwa. Czasem zastępowana przez perspektywy materializowane. 13

14 3 Podsumowanie Podsumowanie Zasady i kroki obowiązujące w trakcie modelowania logicznego: zamiana obiektów pojęciowych na logiczne - powiązane z określonym SZBD, stosowanie jednolitego i czytelnego schematu nazewnictwa dla tworzonych obiektów, ustalenie kolejności kolumn tak by zaoszczędzić pamięć, dobranie typów danych zapewniających poprawność i efektywność, każda tabela bezwzględnie musi posiadać klucz główny, na klucze alternatywne należy nałożyć ograniczenie UNIQUE, nałożenie więzów kluczy obcych na powiązane tabele, ze stosowaniem ujednoliconych nazw i typów dla odpowiadających sobie kluczy, utworzenie dodatkowych tabel dla związków wiele do wielu, realizacja podtypów i związków wzajemnie wykluczających się, utworzenie dodatkowych obiektów optymalizujących korzystanie z bazy, ustalenie pewnych cech fizycznych optymalizujących korzystanie z bazy, określenie organizacji dostępu do bazy, ewentulana denormalizacja. 4 Źródła Źródła W wykładzie wykorzystano materiały: M. Lentner, Oracle 9i Kompletny podręcznik użytkownika, PJWSTK - W-wa, 2003 Stephens, Plew: Relacyjne bazy danych - projektowanie, Robomatic 2003 Garcia-Molina, Ullman, Widom: Implementacja systemów baz danych, WNT