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