Projektowanie relacyjnych baz danych

Transkrypt

Projektowanie relacyjnych baz danych
Projektowanie relacyjnych
baz danych
Spis treści:
1
2
RELACYJNE BAZY DANYCH ...............................................................................................................................2
1.1
Relacyjne bazy danych - pojęcia podstawowe ............................................................................................2
1.2
Informacje na temat tabeli: ...........................................................................................................................2
1.3
Informacje na temat pól: ...............................................................................................................................3
1.4
Typy danych pól (na przykładzie Ms Access) ...............................................................................................4
1.5
Informacje na temat kluczy: ..........................................................................................................................5
1.6
Informacje na temat relacji: ...........................................................................................................................5
1.7
Indeksowanie pól bazy danych .....................................................................................................................6
ANALIZA POTRZEB I PROJEKTOWANIE BAZ DANYCH ...................................................................................8
2.1
Proces projektowania bazy danych ..............................................................................................................8
2.2
Formułowanie celu i założeń wstępnych systemu ........................................................................................8
2.3
Analiza istniejącej bazy danych ....................................................................................................................8
1
1
RELACYJNE BAZY DANYCH
1.1
Relacyjne bazy danych - pojęcia podstawowe
Tabela INWENTARZ
Kod części Opis
Ilość
Cena hurtowa Cena detaliczna
XG 12
Gwóźdź
47
0,52
1,35
C1 – 98
Gniazdo nr 4
3
16,73
26,98
W2A
Kosz
5
9,38
14,95
KL7
Śruba nr 4
62
0,12
0,67
AT8E
Śruba nr 5
38
0,08
0,21
MVP8
Wkręt okrągły 4
7,88
15,00
Pola
Rekordy
Pole – (atrybut, kolumna) – najmniejsza wyróżniona struktura w logicznej bazie danych. (Nazwy pól nigdy nie są
częścią danych, służą jedynie jako etykiety pól.)
Rekord – (krotka, wiersz) – reprezentuje pojedynczą instancję. Rekord zawiera pełny opis wszystkich pól.
Tabela – składa się z logicznej kombinacji pól i rekordów, których kolejność jest obojętna. Tabela może dotyczyć:
Obiektu – reprezentuje wówczas cechy osoby, miejsca, itp.
Zdarzenia – cechy spotkania, wizyt, transakcji, ...
Relacja – logiczne powiązanie między tabelami, realizowane poprzez klucze lub tabele łączące.
Klucz – pole zawierające dla każdego rekordu unikatową wartość (np. Kod części)
1.2
Informacje na temat tabeli:
Nazwy przypisywane tabelom powinny spełniać pewne kryteria:
•
Unikatowe i zrozumiałe
•
Czytelnie opisujące temat (części_silnika a nie tylko części)
•
Nie używać skrótów i zlepków liter
•
Nie wykorzystywać nazw własnych
•
Używać liczby mnogiej
Każda tabela powinna być określona przez trzy parametry:
Nazwa tabeli
Typ tabeli
Opis tabeli
W zależności od pełnionej przez tabele funkcji mogą
Powinien w zwięzły i przejrzysty
wystąpić poniższe typy (na tym etapie projektowania
sposób określać cel stworzenia
bazy danych będzie występował tylko pierwszy typ
takiej tabeli i jej znaczenie dla
„dane”, kolejne pojawią się pózniej:
organizacji (jeśli są trudności ze
Dane – przechowuje dane opisujące jeden temat i jest
stworzeniem takiego opisu, to
wykorzystywana do generowania informacji
należy się zastanowić czy taka
Połączenie – do łączenia dwóch tabel między którymi
tabela jest potrzebna)
występuje relacja wiele_do_wiele
Opis nie powinien być uzależniony
2
1.3
Podzbiór – opisujące poddtemat „tabeli-matki” w
od innych opisów tabel
bardziej szczegółowy sposób
W opisie nie powinny się pojawiać
Tabela walidacji – do zapewnienia integralności danych
konkretne przykłady.
Informacje na temat pól:
Każde pole należy poddać analizie, czy spełnia kryteria stawiane „polu doskonałemu”
•
Reprezentuje cechę tematu tabeli
•
Nie zawiera wartości będącej wynikiem połączenia albo operacji matematycznej na wartościach innych pół
(stwarzałoby to problemy w przypadku aktualizacji)
•
Jest unikatowe w zakresie całej struktury bazy danych (powtarzają się tylko te pola, które są niezbędna do
stworzenia relacji między tabelami)
•
Zachowuje identyczne atrybuty we wszystkich tabelach, w których występuje.
•
Zawiera pojedynczą wartość
Jeżeli tak nie jest, należy wykonać poniższe czynności:
Usuwanie pól wielowartościowych- (kilka wystąpień tego samego rodzaju danych)
Należy stworzyć z tego pola odrębną tabelę i poprzez wybrane pole powiązać ją z tabelą macierzystą
Było:
Prowadzący
Imię i nazwisko
Adres prowadzącego
prowadzącego
Jan Kowalski
Telefon domowy
Prowadzone kursy
prowadzącego
42-512 Sosnowiec ul.
266-55-55
CK, DK, WR
BBBbbb 47/21
Jest:
Prowadzący
Imię i nazwisko
Adres prowadzącego
prowadzącego
Jan Kowalski
Telefon domowy
prowadzącego
42-512 Sosnowiec ul.
266-55-55
BBBbbb 47/21
Kursy_prowadzących
Imię i nazwisko
Prowadzony kurs
prowadzącego
Jan Kowalski
CK
Jan Kowalski
DK
Jan Kowalski
WR
3
Usuwanie pól segmentowych – (więcej danych różnego typu)
Było:
Prowadzący
Imię i nazwisko
Adres prowadzącego
prowadzącego
Telefon domowy
prowadzącego
Jan Kowalski
42-512 Sosnowiec ul.
266-55-55
BBBbbb 47/21
Jest:
Prowadzący
Nazwisko
Imię
prowadzącego prowadzącego
Jan
1.4
Kowalski
Kod
Miasto
Ulica
Numer_domu
Telefon
prowadzą
prowadzą
prowadzą
prowadzącego
domowy
cego
cego
cego
42-512
Sosnowiec
BBBbbb
prowadzącego
47/21
266-55-55
Typy danych pól (na przykładzie Ms Access)
Typ pola
Prawidłowe zastosowanie
Rozmiar na dysku
Tekst
Dane zawierające tekst, połączenie tekstu i
liczb, liczby, na których nie będą dokonywane
obliczenia. Przykłady: nazwy, adresy, kody
pocztowe, numery telefonów.
W zależności od aktualnej
zawartości pola od 0 do 255
bajtów.
Nota
Długi tekst lub ciąg numeryczny. Przykładami
są notatki oraz opisy.
W zależności od aktualnej
zawartości pola od 0 do 65536
bajtów.
Liczba
Dane wykorzystywane w obliczeniach
(wyłączając obliczenia na wartościach
pieniężnych). Przykładami są: wiek, kody (np.
ID pracowników), terminy płatności.
1,2,4,8,12 w zależności od
wybranego rozmiaru pola (lub 16
bajtów dla Identyfikatora replikacji)
Data/Godzina
Data i godzina. Na przykład data zamówienia
czy data urodzin.
8 bajtów.
Walutowy
Dane walutowe. Przykłady: należności
finansowe oraz ceny.
8 bajtów
Autonumerowanie
Unikalna liczba, sekwencyjna lub losowa.
Przykładami są numer faktury oraz numery
umów.
4 bajty (lub 16 bajtów dla
Identyfikatora replikacji)
Tak/Nie
Pola, które zawierają jedną z dwóch wartości
(np. tak/nie, prawda/fałsz). Przykładowe
zastosowanie to status opłacenia rachunków
lub czy z pracownikiem zawarto umowę na czas
określony.
1 bit
Obiekt OLE
Obiekty takie jak dokumenty programu MS
Word lub MS Excel. Przykład: zapis budżetu
firmy.
0 bajtów do 1 GB, w zależności od
zawartości pola.
Hiperłącze
Tekst lub tekstu i liczb, przechowywane jako
tekst i wykorzystywane jako hiperłącze adresu
URL ( Uniform Resource Locator – uniwersalny
lokalizator zasobów) lub ścieżka UNC
(Universal Naming Convention – jednolita
konwencja nazewnictwa). Przykładami są
strony WWW oraz pliki sieciowe.
0 do 2048 bajtów dla każdej z
trzech części składających się na
adres (maksymalnie 64000
znaków).
4
1.5
Informacje na temat kluczy:
Klucze:
•
Umożliwiają identyfikację każdego rekordu
•
Umożliwiają definiowanie relacji
•
Umożliwiają wprowadzenie i egzekwowanie różnych rodzajów integralności tabel
Rodzaje kluczy:
•
Kandydujące – tworzy się zbiór kluczy kandydujących (KK), z których potem wybrany zostanie jeden
podstawowy (KP).
Klucz kandydujący powinien spełniać pewne warunki:
•
Musi jednoznacznie identyfikować każdy rekord w tabeli, do której należy (może to być jedno pole lub
zespół pól)
•
Musi zawierać unikatowe wartości
•
Nie może zawierać wartości zerowych
•
Składa się z minimalnej liczby pól niezbędnej do uzyskania niepowtarzalności
•
Jego wartość nie może być opcjonalna
•
Każde pole w tabeli musi być funkcyjnie zależne od wartości klucza kandydującego
•
Jego wartości powinno modyfikować się jedynie w wyjątkowych przypadkach
Czasem tworzy się sztuczne klucze kandydujące (dołącza się pole do tabeli np.: ID_procownika)
•
Podstawowe – dla każdej tabeli ze zbioru kluczy kandydujących wybiera się jeden klucz podstawowy
(najlepszy – możliwie prosty)
Wszystkie klucze podstawowe w bazie muszą się różnić (wyjątek - podzbiory)
•
1.6
Obce – występują w przypadku tworzenia relacji jeden_do_jeden i jeden_do_wielu.
Informacje na temat relacji:
Rodzaje relacji
Jeden – do jeden – pojedynczemu rekordowi z tabeli A odpowiada dokładnie jeden rekord z tabeli B, a
pojedynczemu rekordowi z tabeli B dokładnie jeden rekord z tabeli A.
Jeden – do wielu - pojedynczemu rekordowi z tabeli A odpowiada jeden lub więcej rekordów z tabeli B, a
pojedynczemu rekordowi z tabeli B odpowiada dokładnie jeden rekord z tabeli A.
Wiele – do – wiele - pojedynczemu rekordowi z tabeli A odpowiada jeden lub więcej rekordów z tabeli B, a
pojedynczemu rekordowi z tabeli B odpowiada jeden lub więcej rekordów z tabeli A.
Definiowanie relacji - Tworzenie połączeń między dwiema tabelami, pomiędzy którymi istnieje relacja
•
Jeden-do jeden – poprzez klucz obcy. Do tabeli podporządkowanej dołącza się kopię klucza
podstawowego z tabeli głównej.
Przykładem takiej relacji jest powiązanie:
DZIAŁY KIEROWNICY
•
Jeden- do – wielu - poprzez klucz obcy. Do tabeli leżącej po stronie „wiele” dołącza się kopię
klucza podstawowego z tabeli „jeden”.
Jest to najczęściej występująca relacja
5
Przykładem takiej relacji może być:
MATKI DZIECI
BUDYNKI POMIESZCZENIA
•
Wiele – do – wielu – poprzez tabelę łączącą, która rozbija relację „wiele_do_wiele” na dwie relacje
„jeden_do_wiele”. Tabela łącząca posiada „złożony klucz podstawowy”, który zawiera w sobie
klucze podstawowe z tabel głównych.
Przykładem takiej relacji jest:
STUDENCI WYKŁADY
ZAMÓWIENIA PRODUKTY
Istnieje możliwość dołączania do tabeli łączącej jeszcze innych pól, co zmniejsza powtórzenia w
tabelach.
Definiowanie cech relacji:
•
Reguły usuwania – dotyczą rekordów w tabeli głównej z relacji „jeden_do_jeden” oraz w tabeli leżącej po
stronie „jeden” w relacji „jeden_do_wielu”.
Reguła restrykcyjna (R) – rekord nie może zostać skasowany, jeśli istnieją powiązane z nim rekordy
podporządkowane. Muszą one być skasowane wcześniej.
Reguła kaskadowa (C) - żądany rekord zostanie skasowany razem z powiązanymi z nim rekordami.
•
Typy uczestnictwa – określają, czy do wprowadzenia rekordu do tabeli leżącej po drugiej stronie relacji
wymagane jest istnienie jakiegoś rekordu w tabeli analizowanej.
Uczestnictwo obowiązkowe – w rozpatrywanej tabeli musi istnieć przynajmniej jeden rekord zanim
zaczniemy wprowadzać rekordy do drugiej z nich.
Uczestnictwo opcjonalne – dana tabela może być pusta przy przystępowaniu do umieszczania
rekordów w drugiej tabeli.
•
Stopień uczestnictwa – określa ile rekordów w jednej z tabel może być powiązanych z pojedynczym
rekordem w drugiej tabeli.
1.7
Indeksowanie pól bazy danych
W systemie zarządzania relacyjną bazą danych indeks jest mechanizmem zwiększającym wydajność pracy
z bazą danych. Tak jak indeks w książce umożliwia szybkie odnalezienie stron, które chce się przeczytać, tak
indeks kolumny przyspiesza wyszukiwanie danych.
Istnieje kilka istotnych różnic pomiędzy indeksem w książce a indeksem w systemie zarządzania relacyjną
bazą danych. Przy czytaniu książki czytelnik sam decyduje czy zajrzeć do indeksu, czy nie. Natomiast w przypadku
baz danych decydujemy tylko czy utworzyć indeks, czy nie, a system sam określa, czy i jak indeks ma być użyty
przy każdym zapytaniu. Każde wydanie książki i jej indeksy są drukowane raz, natomiast dane w systemie
relacyjnym i jego indeksy mogą zmieniać się często. Za każdym razem, gdy dane w tabeli są modyfikowane, w
jednym lub większej liczbie indeksów tabeli następuje automatyczna aktualizacja.
Jak, co i kiedy indeksować?
Indeksy przyspieszają wyszukiwanie danych. Indeks utworzony dla kolumny często decyduje o tym jak
długo będziemy czekali na reakcje systemu na zadane pytanie.
6
Czemu więc nie tworzyć indeksu dla każdej kolumny? Najważniejszy powód jest taki, że budowanie i
utrzymywanie indeksów pochłania czas i pamięć urządzeń bazodanowych.
Drugim powodem jest to, że wstawianie, usuwanie, modyfikowanie danych w kolumnach indeksowanych
trwa nieco dłużej niż w przypadku kolumn nieindeksowanych, ze względu na czas, jaki potrzebuje system na
utrzymanie indeksu po zmianie wartości.
Na ogół korzystne jest tworzenie indeksów dla kolumn, w których często wykonuje się wyszukiwanie –
szczególnie dla kolumn klucza głównego i kolumn używanych w złączeniach (relacjach) i sortowaniu. Poniżej
podajemy kilka bardziej precyzyjnych wskazówek:
•
Kolumna lub kolumny zawierające klucz główny tabeli powinny być prawie zawsze indeksowane.
•
Kolumna, do której często się sięga zgodnie z porządkiem sortowania, powinna być indeksowana.
•
Kolumny regularnie wykorzystywane w złączeniach powinny być indeksowane, gdyż wtedy system szybciej
może dokonać złączenia.
Jest kilka przypadków, kiedy indeksowanie nie jest użyteczne:
•
Kolumny, do których zapytania odwołują się rzadko, nie dają korzyści z indeksowania, jeżeli chodzi o
wydajność.
•
Kolumny, które mają tylko dwie lub trzy wartości (np. męski, żeński, nieznany) nie dają korzyści z
indeksowania.
•
Małe tabele z kilkoma wierszami nie powodują wzrostu wydajności z powodu indeksowania kolumn.
7
2
ANALIZA POTRZEB I PROJEKTOWANIE BAZ DANYCH
2.1
Proces projektowania bazy danych
Analiza wymagań
•
Ocena funkcjonowania organizacji
•
Ocena wymagań informacyjnych
•
Ocena przepływu informacji
Modelowanie danych
•
Tworzenie struktury nowej bazy danych
•
Tworzenie diagramów związków
•
Analiza zależności
Normalizacja
•
Rozkład dużych tabel na mniejsze w celu uniknięcia redundancji, oraz problemów z modyfikowaniem i
usuwaniem rekordów.
•
Sprawdzenie struktur baz danych z "postaciami normalnymi" (zestaw kryteriów, które musi spełniać dana
tabela, aby mogła być uznana za poprawną i nie przyczyniała się do powstawania błędów).
2.2
Formułowanie celu i założeń wstępnych systemu
Definicja celu powinna być krótka i zwięzła, nie powinna opisywać konkretnych zadań. Powinna opisywać
ogólny cel bazy danych w sposób zrozumiały dla twórców bazy i jej przyszłych użytkowników.
np.: „celem bazy danych jest przechowywanie danych wykorzystywanych w obsłudze sprzedaży detalicznej
oraz usług serwisowych świadczonych klientom”
Założenia wstępne to ogólne zadania, jakie mają spełniać dane przechowywane w projektowanej bazie
(każde założenie powinno być reprezentowane przez pojedyncze zdanie).
Poprawnie sformułowane założenia wstępne ułatwią definiowanie pól, tabel, relacji,...
np.:„Chcemy przechowywać informacje o zawieranych przez nas umowach.
Chcemy przechowywać informacje o klientach.”
2.3
Analiza istniejącej bazy danych
Etapy analizy istniejącej bazy danych
Analiza sposobu gromadzenia danych
Zebrać przykładowe egzemplarze formularzy
Wydrukować ekrany z programów obsługi danych
Analiza sposobu prezentowania informacji
Zebrać wszystkie przykładowe raporty (np.: stan magazynu)
Przeprowadzenie wywiadów z pracownikami i kierownictwem
8
Jak organizacja wykorzystuje swoje dane (wyodrębnić obiekty, zdarzenia, cechy, później będzie to
wykorzystane przy definiowaniu tabel i pól)
Skąd pochodzą dane do raportów (później ma to znaczenie przy definiowaniu relacji)
Informacje, których brakuje w raportach (a pracownicy odczuwają potrzebę ich posiadania)
Przewidzieć możliwy, najbliższy rozwój organizacji
9