Transformacja modelu pojęciowego. do logicznego

Transkrypt

1 Transformacja modelu pojęciowego do logicznego

2 Plan wykładu 1. Modelowanie logiczne 2. Transformacja modelu pojęciowego do logicznego Transformacja własności Transformacja związków Transformacja hierarchii Dodatkowe obiekty i techniki 3. Podsumowanie 4. Źródła

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

4 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

5 Terminologia Model relacyjny Model związków encji Relacyjna baza danych relacja encja tabela krotka instancja wiersz atrybut własność kolumna dziedzina dziedzina/typ dziedzina/typ schemat relacji - struktura tabeli - - schemat

6 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, lubtworzyć projekt łatwy do przeniesienia pomiędzy poszczególnymi SZBD. Należy stosować jednolite nazewnictwo,ułatwiające ewentualne przenoszenie bazy: nazwy zawierają wyłącznie litery, cyfry i znaki podkreślenia brak znaków diakrytycznych nazwy nie mogą różnic 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

7 Zalecenia c.d. 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 PRIMARYKEY -tabpk, dla kluczy obcych skróty nazw obu tabel i angielskiego FOREIGN KEY - tab1 tab2fk)

8 Transformacja modelu pojęciowego do logicznego encje tabele własności kolumny związki klucze obce lub tabele hierarchia encji jedna lub dwie lub trzy tabele

9 Transformacja własność- kolumna Własność kolumna typ własności typ występujący w wybranym SZBD obowiązkowość własności ograniczenie NOTNULL własność kluczowa klucz główny tabeli ograniczenia własności ograniczenia integralnościowe kolumn

10 Transformacja własność- kolumna - zalecenia Zasady poprawnej transformacji: kolejność kolumn w tabelach oszczędzająca pamięć i ograniczająca fragmentacje, 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, DECIMAL)

11 Transformacja własność- kolumna - zalecenia 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, ze własność posiada niepowtarzalne wartości należy na jej bazie utworzyć klucz kandydujący kolumnę oograniczeniu UNIQUE

12 Transformacja związków związki klucze 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

13 Transformacja zwiazków Związekunarny1: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.

14 Związek unarny 1:1 klucz obcy w tej samej tabeli Związek unarny 1:1

15 Związek unarny 1:N klucz obcy w tej samej tabeli Związek unarny 1:N

16 Związek unarny N:M tabela Związek unarny N:M

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

18 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

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

20 Związek ternarny Związek ternarny tabela (klucze obce tworzą klucz główny)

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

22 Transformacja hierarchii 1

23 Transformacja hierarchii 2

24 Transformacja hierarchii 3

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

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

27 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 przyspieszania przeszukiwania bazy danych. Zastosowanie: szybkie przeszukiwanie danych szybkie sortowanie danych optymalizacja zapytań efektywne wykonywanie złączeń Wady: spowolnienie aktualizacji

28 Rodzaje indeksów Wyróżniamy indeksy: proste (dla jednej kolumny) i złożone (dla wielu kolumn) drzewiaste,bitmapowe unikatowe,dopuszczające powtórzenia

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

30 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. Zastosowanie: Wady: przyspiesza czas dostępu do danych zmniejsza liczbę odczytanych bloków ogranicza zapotrzebowanie na przestrzeń dyskowa poprawia efektywność niektórych zapytań spowolnienie aktualizacji spowolnienie pełnego przeglądania tabeli

31 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

32 Partycje Partycjonowanie tabel technika dzielenia bardzo dużych tabel na mniejsze fragmenty. Typy: zakresowe haszowe Zastosowanie: ułatwienie zarzadzania danymi efektywniejszy dostęp

33 Podsumowanie I 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 nap owiązane tabele,ze stosowaniem ujednoliconych nazw i typów dla odpowiadających sobie kluczy

34 Podsumowanie II utworzenie dodatkowych tabel dla związków wiele do wielu realizacja podtypów i związków wzajemnie wykluczających się

35 Źródła W wykładzie wykorzystano materiały: Wykład dr inż. O.Siedlecka-Lamch M. Lentner,Oracle9i Kompletnypodręcznik użytkownika, PJWSTK- W-wa, 2003 Stephens, Plew: Relacyjne bazy danych -projektowanie,robomatic2003 Garcia-Molina, Ullman, Widom: Implementacjasystemów bazdanych, WNT 2003