Projektowanie relacyjnych baz danych

Transkrypt

1 Projektowanie relacyjnych baz danych

2 Spis treści: 1 RELACYJNE BAZY DANYCH Relacyjne bazy danych - pojęcia podstawowe Informacje na temat tabeli: Informacje na temat pól: Typy danych pól (na przykładzie Ms Access) Informacje na temat kluczy: Informacje na temat relacji: Indeksowanie pól bazy danych ANALIZA POTRZEB I PROJEKTOWANIE BAZ DANYCH Proces projektowania bazy danych Formułowanie celu i założeń wstępnych systemu Analiza istniejącej bazy danych

3 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 ,73 26,98 W2A Kosz 5 9,38 14,95 KL7 Śruba nr ,12 0,67 AT8E Śruba nr ,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ą wystąpić poniższe typy (na tym etapie projektowania bazy danych będzie występował tylko pierwszy typ dane, kolejne pojawią się pózniej: Dane przechowuje dane opisujące jeden temat i jest wykorzystywana do generowania informacji Połączenie do łączenia dwóch tabel między którymi występuje relacja wiele_do_wiele Powinien w zwięzły i przejrzysty sposób określać cel stworzenia takiej tabeli i jej znaczenie dla organizacji (jeśli są trudności ze stworzeniem takiego opisu, to należy się zastanowić czy taka tabela jest potrzebna) Opis nie powinien być uzależniony 2

4 Podzbiór opisujące poddtemat tabeli-matki w bardziej szczegółowy sposób Tabela walidacji do zapewnienia integralności danych od innych opisów tabel W opisie nie powinny się pojawiać konkretne przykłady. 1.3 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 Sosnowiec ul. BBBbbb 47/21 Telefon domowy Prowadzone kursy CK, DK, WR Jest: Prowadzący Imię i nazwisko Kursy_prowadzących Imię i nazwisko Adres Sosnowiec ul. BBBbbb 47/21 Prowadzony kurs CK DK WR Telefon domowy

5 Usuwanie pól segmentowych (więcej danych różnego typu) Było: Prowadzący Imię i nazwisko Adres Sosnowiec ul. BBBbbb 47/21 Telefon domowy Jest: Prowadzący Imię Nazwisko Kod Miasto Ulica Numer_domu Telefon prowadzą prowadzą prowadzą domowy cego cego cego Sosnowiec BBBbbb 47/ Typy danych pól (na przykładzie Ms Access) Typ pola Prawidłowe zastosowanie Rozmiar na dysku Tekst Nota Liczba Data/Godzina Walutowy Autonumerowanie Tak/Nie Obiekt OLE Hiperłącze 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. Długi tekst lub ciąg numeryczny. Przykładami są notatki oraz opisy. 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. Data i godzina. Na przykład data zamówienia czy data urodzin. Dane walutowe. Przykłady: należności finansowe oraz ceny. Unikalna liczba, sekwencyjna lub losowa. Przykładami są numer faktury oraz numery umów. 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. Obiekty takie jak dokumenty programu MS Word lub MS Excel. Przykład: zapis budżetu firmy. 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. W zależności od aktualnej zawartości pola od 0 do 255 bajtów. W zależności od aktualnej zawartości pola od 0 do bajtów. 1,2,4,8,12 w zależności od wybranego rozmiaru pola (lub 16 bajtów dla Identyfikatora replikacji) 8 bajtów. 8 bajtów 4 bajty (lub 16 bajtów dla Identyfikatora replikacji) 1 bit 0 bajtów do 1 GB, w zależności od zawartości pola. 0 do 2048 bajtów dla każdej z trzech części składających się na adres (maksymalnie znaków). 4

6 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) Obce występują w przypadku tworzenia relacji jeden_do_jeden i jeden_do_wielu. 1.6 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

7 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

8 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

9 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

10 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