Wykład 3: Projektowanie relacyjnych BD (56 slajdów)‏ Informatyczne Systemy Zarządzania Wykładowca: Prof. Anatoly Sachenko

Ogólny zarys wykładu Etapy projektowania System analizujący dziedzinę zastosowania Modelowanie BD Model związków encji Model relacyjny Wybór Systemem zarządzania bazą danych (DBMS)‏ Projektowanie logiczne (model pojęciowy)‏ Projektowanie fizyczne

Etapy projektowania - cykl życia Bazy Danych Główne etapy cyklu życia BD to: Projekt BD Projekt formularza Wdrażanie BD Opracowanie narzędzi do administrowania DB Użytkowanie BD Proces projektowania BD jest sekwencją zmian od nieformalnego, werbalnego zapisu struktury informacyjnej dziedziny danego problemu, do sformalizowanego opisu przedmiotu dziedziny zainteresowania w odniesieniu do jakiegoś modelu

Etapy projektowania – dwa spojrzenia

System analizujący dziedzinę zainteresowania - podejście funkcjonalne Podejście funkcjonalne opiera się na zasadzie przepływu “od zadania” jest to wprowadzane z czyn gdy działania jakiejś grupy użytkowników i złożone zadania są znane uprzednio BD jest projektowana dla utrzymania obu powyższych W tym przypadku możemy dokładnie wybrać niezbędny, minimalny zbiór obiektów z dziedziny wiedzy, która musi zostać opisana

System analizujący dziedzinę zainteresowania - podejście funkcjonalne Podejście funkcjonalne stosowane jest gdy potrzeby informacyjne przyszłych użytkowników BD nie są dokładnie ustalone Powyższe potrzeby mogą być wielowymiarowe oraz wysoce dynamiczne Nie możemy ustalić dokładnie minimalnego zbioru obiektów które maja być opisane w danej dziedzinie W tym przypadku opisanie dziedziny zawiera najbardziej typowe obiekty i powiązania Zaprojektowana BD nazywana jest przedmiotową BD i może być wykorzystywana do różnorodnych problemów które zostały wstępnie zdefiniowane

System analizujący dziedzinę zainteresowania (c.d.)‏ System analizujący powinien zakończyć się: Szczegółowym opisem informacji dotyczących obiektów należących do dziedziny zainteresowania Sformułowaniem charakterystycznych zadań, rozwiązaniu których służyć ma BD oraz krótkim opisem algorytmu rozwiązania tego zadania Opisem dokumentów wyjściowych, które system powinien stworzyć Opisem dokumentów wejściowych stanowiących przyszłą bazę - danych wejściowych do BD

System analizujący dziedzinę zainteresowania - przykład Wymagany jest rozwój systemu informatycznego obsługującego wypożyczanie oraz zwroty książek z biblioteki Wewnątrz biblioteki książki mogą posiadać unikalny, systemowy numer i nazwę Każda książka w bibliotece może mieć kilka kopii; ponadto cechują ją następujące parametry: Unikalny kod Nazwa Nazwisko autora Miejsce wydania Wydawnictwo Rok wydania Ilość stron Cena Ilość kopii dostępnych w bibliotece

System analizujący dziedzinę zainteresowania – przykład (c.d.)‏ System powinien udostępnić systematyczny katalog Bibliotek posiada indeks kart czytelników ; każdy czytelnik zostaje zarejestrowany na podstawie następujących informacji : Nazwisko, imię, drugie imię Adres domowy Nr telefonu Data urodzenia Użytkownicy mogący korzystać z systemu: Czytelnicy Bibliotekarze Pracownicy administracyjni biblioteki

System analizujący dziedzinę zainteresowania – przykład (c.d.)‏ Bibliotekarz powinien potrafić: Wpisywać/wypisywać czytelników, oraz wypożyczane przez nich książki Przyjmować nowe książki, rejestrować je w bibliotece, przypisywać je odpowiednim dziedzinom wiedzy to conduct books cataloguing and book removing Czytelnik może: Przeglądać katalog systemowy – listę wszystkich dostępnych w bibliotece książek, zgodnie z dziedzina wiedz Otrzymać kompletną listę książek biblioteki wewnątrz wybranej dziedziny wiedz Dla wybranych książek: Otrzymać an nr indeksów dostępnych kopii , OR Otrzymać informację o barku dostępnej książki, i Uzyskać informacje o najbliższym terminie zwrotu Pracownicy administracyjni biblioteki mogą: Wyszukiwać informacje o dłużnikach, mało popularnych książkach, itp.

System analizujący dziedzinę zainteresowania – przykład (c.d.)‏ System powinien zastrzegać następujący limit informacji: Książka nie może być bez autora Czytelnik biblioteki nie może mieć mniej niż 17 lat, a książki opublikowane nie wcześniej niż w roku 1960 Każdy czytelnik może wypożyczać nie więcej niż 5 książek, i tylko po jednym egzemplarzu każdej z nich Każdy czytelnik musi w trakcie rejestracji podać nr telefonu : domowy lub służbowy Każda dziedzina zainteresowania może odnosić się jednocześnie do wielu książek każda książka z osobna może być związana z wieloma dziedzinami zainteresowań

Modelowanie – Model związków encji Model związków encji (ER model ) opisuje dane za pomocą encji, atrybutów i relacji Powstały w 1976 roku – twórca: Peter Pin Shan Chen zaproponował on metodę diagramowania nazywaną Diagramami Związków Encji (ERD), która wkrótce została przyjęta ERD wykorzystuje: prostokąty do opisu encji elipsy dla atrybutów, oraz romby reprezentujące relacje

Model związków encji – prezentacja graficzna

Model związków encji – inna prezentacja graficzna Encje Atrybuty Związki

Model związków encji – definicja encji Encja to" coś co istnieje (obiekt), co odróżnia się od innych, o czym trzeba mieć informację“ - Peter Chen Tak więc encją może być osoba, miejsce, obiekt, zdarzenie, lub pojęcie o którym chcemy przechowywać dane Każdy zbiór encji powinien mieć unikalną nazwę, która powinna przedstawiać typ lub kategorię rzeczy, a nie przykład Kilka przykładów zawierających encje: Encją dla osoby może być PRACOWNIK, WETERYNARZ lub STUDENT Encja miejsca- STAN lub PAŃSTWO Encja obiektu- BUDYNEK, SAMOCHÓD lub PRODUKT Encja pojęcia- DZIEDZINA

Model związków encji – definicja relacji Relacje – są powiązane binarnie co pokazuje jak encje są zrelacjonowane lub jak ze sobą współdziałają Relacje może istnieć pomiędzy różnymi encjami lub w jednej encji (związek rekurencyjny) Pokazuje to jak poszczególne wystąpienia encji są ze sobą zrelacjonowane Rodzaje relacji pomiędzy encjami 1:1 ("jeden do jeden") — encji odpowiada dokładnie jedna encja 1:M ("jeden do wielu") — encji odpowiada jedna lub więcej encji M:M ("wiele do wielu") — jednej lub więcej encjom odpowiada jedna lub więcej encji.

Model związków encji – relacja jeden-do-jeden Relacje nazywamy jeden-do-jeden, gdy któreś z wystąpień encji X może być kojarzony tylko z jednym wystąpieniem encji Y. Przyjmuje się, że jest tylko jedna osoba w biurze, jest to relacja jeden-do-jeden pomiędzy biurem a pracownikiem

Model związków encji – relacja jeden-do-wielu Relacje nazywamy jeden-do-wielu, gdy pojedyncze wystąpienie encji może być kojarzone z wieloma wystąpieniami kolejnych encji Zakłada się, ze jest tylko jeden budynek w którym znajduje się kilka biur, jest to relacja jeden-do- jeden pomiędzy budynkiem a biurem

Model związków encji – relacja wiele-do-wielu W rzeczywistym świecie istnieje mnóstwo przykładów relacji wiele-do-wielu Student uczestniczy w wielu kursach; w każdym kursie uczestniczy wielu studentów Klienci kupują w wielu sklepach; w każdym sklepie jest wielu klientów

Model związków encji – relacja wiele-do-wielu (c.d.)‏ Relacja wiele-do-wielu nie może być przedstawiona bezpośrednio w relacyjnej bazie danych Zamiast tego, stosuje się moduły relacji pośredniczących o relacji jeden-do-wielu z każdym z autentycznych uczestników Taka relacja pośrednicząca jest zazwyczaj nazywana tabelą krzyżową

Model związków encji – przykład “biblioteka” Pierwszym krokiem jest wybór encji Wybieramy encję «książka», każda książka posiada unikalny kod, który będzie kluczem podstawowym Każde wystąpienie encji«książka» odzwierciedla opis książki znajdujący się w katalogu systemowym, (nie określona książka)‏ Aktualnie w bibliotece może znajdować się kilka kopi książki, dlatego też tak ważne jest przypisanie warunku encji «egzemplarz» Kolejne wystąpienia encji «egzemplarz» odzwierciedla określony dla każdej książki unikalny numer inwentarza

Model związków encji – przykład “biblioteka” (c.d.)‏ Pomiędzy encjami «książka» i «egzemplarz» występuje relacja 1:M, obowiązująca dla obu stron Międzynarodowy Znormalizowany Numer Książki - ISBN jest unikalny dla jednej edycji książki , ale może istnieć więcej niż jedna kopia danej książki w bibliotece Jeżeli książka jest opisana w encji «książka», to co najmniej jedne wystąpienie tej książki przypisane jest encji «egzemplarz» W innym przypadku książka nie jest przypisana warunkowi encji «książka» Inaczej, jeżeli książka przedstawiona jest w encji «egzemplarz», powinna być opisana również w encji «książka»

Model związków encji – przykład “biblioteka” (c.d.)‏ Informacje na temat czytelników znajdują się pod warunkiem encji «czytelnik» każde wystąpienie tej encji będzie przypisane określonemu czytelnikowi Dla identyfikacji czytelników, przypisane są im unikalne numery ID Numer ID będzie kluczem podstawowym dla encji «czytelnik» Dodatkowymi atrybutami encji «czytelnik» jest np.: “imię” i “nazwisko”, “adres czytelnika”, “telefon domowy” lub “telefon do pracy” Każdy czytelni może mieć kilka książek w tym samym czasie

Model związków encji – przykład “biblioteka” (c.d.)‏ Reprezentacja sytuacji wypożyczanie/zwrot książek powinna być tworzona przez relacje pomiędzy encją <<czytelnik>> a <<egzemplarz>> typ takiej relacji to 1:M (nie wymagane dla obu stron): czytelnik w pewnym momencie może nie mieć wypożyczonych książek z drugiej strony, przykładowe książki mogą nie być wypożyczane przez czytelników

Model związków encji – przykład “biblioteka” (c.d.)‏ Katalog systemowy zawiera listę wszystkich obszarów ekspertyz problemowych dla książek w bibliotece. Będzie to zaprezentowane w encji <<katalog>> Tytuł obszary ekspertyz problemowych może być zbyt długi, więc przedstawimy dwa przypisy (opisy)‏ Kod obszarów ekspertyz problemowych oraz <<tytuł dziedziny zainteresowania>> atrybut dziedzina zainteresowania będzie kluczem podstawowym używając dodatkowego polaczenia «egzemplarz» i «książka» możemy w każdym czasie ustalić które dokładnie książki są wypożyczone przez którego czytelnika.

Model związków encji – przykład “biblioteka” (c.d.)‏ Każda książka może zawierać informacje z wielu dziedzin zainteresowania oraz są też dziedziny zainteresowania zawierające wiele książek Więc związek między encjami <<katalog>> i <<książka>> jest M:M, obowiązkowy dla obu stron.

Model związków encji – przykład “biblioteka” (c.d.)‏

Model stosunkowy - Przekształcenie Zasad modelu ER w relacyjne Każda jednostka modelu ER (relacja encji) odpowiada jednostce modelu podrzędnego. Każdy tytuł powinien być po łacinie, bez odstępów Każdy atrybut modelu ER staje się atrybutem właściwej jednostki w modelu podrzędnym. Tytuły powinny być w języku łacińskim, bez odstępów Atrybuty które należą do KLUCZA PODSTAWOWEGO przyjmują obowiązkową zasadę (NOT NULL- NIE ZERO)‏ Każda podporządkowana encja jest dodawana do głównej encji co jest podstawowym kluczem encji głównej Ten zestaw atrybutów staje się obcym kluczem dla podporządkowanych encji Dla modelowania fizycznego poziomu atrybuty – które reprezentują obcy klucz – uzyskują: NULL- własność relacji obowiązkowej NOT NULL- w relacji nieobowiązkowej

Model stosunkowy - Przekształcenie Zasad modelu ER w relacyjne(Kontynuacja)‏ Relacja Wiele-do-Wielu jest dopuszczana przez model ER Ale nie może być to przedstawione bezpośrednio w relacyjnej bazie danych. W tym przypadku jest to sposób stworzenia specjalnego mechanizmu pozwalającego na mnożenie wielorakich łączy dla relacyjnego modelu przy pomocy dopuszczalnych kategorii Dlatego pomiędzy encjami <<KSIĄŻKA>> i <<KATALOG>> została stworzona tabela krzyżowa <<ZWIĄZEK>>, która posiada tylko dwa atrybuty: ISBN – numer książki i KW_COD – kod dziedziny zainteresowania Każdy atrybut nowej relacji jest KLUCZEM OBCYM atrybutów Obydwa atrybuty razem tworzą KLUCZ PODSTAWOWY dla tego związku

Relacyjny model "biblioteki"

Wybór DBMS - główne kryteria Są następujące kryteria dla wyboru DBMS: Modelowanie danych Używany model danych procedury urachamiające i przechowujące Wyszukiwanie narzędzi Dotarczanie typów danych Realizacja pytań językowych Cechy architektury i funkcjonalne możliwości: Zmienność Skalowalność Pozycja dystrybucji Możliwości tworzenia sieci

Wybór DBMS - główne kryteria (kontynuacja)‏ Kontrola nad układem pracy: Kontrola nad użyciem pamieci komputera Automatyczne strojenie Cechy dla rozwoju aplikacji Narzędzia projektowe Wielojęzykowe wsparcie Możliwości rozwoju podań bazujących na stronach internetowych Wspieranie oprogramowania językowego Wydajność: Klasyfikacja TPC (Transakcje procentowe) Możliwości równoległej architektury Możliwości optymalizacji wątpliwości

Wybór DBMS - główne kryteria (kontynuacja)‏ Niezawodność: odnowienie po awarii rezerwowe kopie zmienne wycofanie Wielopoziomowy system zabezpieczeń Wymagania dla środowiska pracowniczego Pomocne programy komputerowe spełnienie minimalnych wymogów dotyczących sprzętu komputerowego Maksymalny rozmiar pamięci adresowej System operacyjny, w którym DBMS jest zdolny do pracy

DBMS - powszechne relacje DBMS Systemy DBMS: Oracle MySQL Microsoft SQL Server Microsoft Access PostgreSQL CSQL FrontBase DB2 Informix InterBase Microsoft Visual FoxPro, …

Logiczny projekt danych - dokumenty końcowe Projektowanie logiczne w relacyjnych bazach prowadzi do rozwoju bazy danych jest to pakiet schematów relacyjnych, które ostatecznie modelują: abstrakcyjne obiekty dziedziny Semantyczne łącza pomiędzy tymi obiektami wspólne dokumenty jako rezultat fazy logicznego projektu: Opis pojęciowego schematu w okresie selekcji DBMS Opis zewnętrznych modeli w okresie selekcji DBMS Opis oznajmujących zasad dla zintegrowanego wspierania DB Rozwój procedur wspierających semantyczną integrację DB

Logiczny projekt danych - dwa sposoby Projektowanie logiczne może odbywać się na dwa sposoby: dekompozycja (partycjonowanie) – gdy zbiór encji źródłowych- jako część bazy danych – jest zastępowanych przez zbiór innych encji (w tym przypadku jest to wzrost liczby)‏ ostatnia jest zabezpieczeni em źródła encji synteza – droga prowadząca do zamontowania danego źródła elementarnej relacji pomiędzy obiektami schematu dziedziny bazy danych

Logiczny projekt danych - proces normalizacji Teoria normalizacji bazuje na analizie funkcjonalnych zależności pomiędzy powiązanymi atrybutami Normalizacja – jest techniką produkcyjną zestawu tabel z potrzebnymi własnościami, które wspierają wymagania użytkownika lub firmy Głównym celem relacyjnego projektu DB jest grupa kolumn w tabelach do zmniejszenia nadmiaru danych i redukcja przestrzeni magazynowej wymaganej przez bazowe tabele Główne cechy form normalnych: Każda kolejna forma jest lepsza niż poprzednia Kiedy zamienia się w kolejną normalną formę, własności poprzedniej zostają zachowane

Logiczny projekt danych - Formy Normalne Jest następujący porządek Formy Normalnej Pierwsza forma normalna (1NF )‏ Druga forma normalna (2NF)‏ Trzecia (3NF)‏ forma normalna Boyce-Codd'a (BCNF)‏ Czwarta forma normalna (4NF)‏ Piąta forma normalna (5NF lub PJNF)‏ Schemat BD nazwany jest równoważnikiem jeśli: Zawartość początkowa BD może być zrobiona z naturalnych relacji złączy, które są włączone w schemat wynikowy i Nie pojawiają się tam nowe wiersze

Proces normalizacji – pełno funkcjonalna zależność funkcjonalna zależność zbioru atrybutów B dla encji R ze zbiorem atrybutów A tej samej encji jest odnotowana jako: R.A -> R.B lub A -> B oznacza to korelacje projekcji R[A] oraz R[B] gdzie żaden element projekcji R[A] nie koresponduje przez jakiś czas tylko z jednym elementem projekcji R[B] który nie jest częścią (razem z R[A]) żadnego wiersza w encji R funkcjonalna zależność R.A -> R.B jest nazywana zależnością pełną, jeżeli: zbiór atrybutów B jest funkcjonalnie zależny od A, oraz nie zależny to od żadnego podzbioru A, LUB (formalnie): żadne A1 ∈ A => R.A -/-> R.B, co należy czytać dla żadnego A1 należącego do zbioru A, R.B nie zależy funkcjonalnie od R.A w przeciwnym wypadku R.A -> R.B jest nazywane nie zero jeden

Proces normalizacji - Transitive Functional Dependency funkcjonalna zależność R.A -> R.B jest nazywana przechodnią zależnością zbiór atrybutów C istnieje, I: С nie jest podzbiorem А С nie wyklucza В funkcjonalna zależność R.A -> R.C istnieje funkcjonalna zależność R.C -> R.A nie istnieje funkcjonalna zależność R.C -> R.B istnieje

Normalization Process– Armstrong Axioms Funkcjonalne zależności BD stworzona na potrzeby uniknięcia nadmiaru reprezentacji, To zakładało liczbę zależności, które mogą być odejmowane od innych używając 3 maksym Armstronga: Zwrotność: If В is a subset of А, then А ->В Dopełnienie: If А->В , then АС->ВС Przechodność: If А->В and В->С , then А->С Zostało to aksjomatycznie udowodnione, wyczerpująco i gruntownie. Zbiór wszystkich możliwych wszystkich funkcjonalnych niezależności nazywany jest zamknięciem danego zbioru początkowego zbioru zależności funkcjonalnych

Proces normalizacji – Pierwsza normalna forma(1NF)‏ encja jest prezentowana w 1NF kiedy: podstawowe wartości atrybutów są w punktach przecinania się wszystkich kolumn i wierszy Tabela „plan zajęć” poniżej nie jest prezentowana w 1 NF

Proces normalizacji – Pierwsza normalna forma(Continued) By zredukować relację “plan” do 1 NF niezbędne jest uzupełnienie każdego rzędu w tabeli nazwiskiem wykładowcy prowadzącego Tabela “plan zajęć” poniżej jest prezentowana w 1 NF

Druga normalna forma(2NF) - Definicja Encja jest w 2 NF jeśli: Jest w 1 NF i Nie ma nieodpowiednich funkcjonalnych zależności niepodstawowym kluczem atrybutów a kluczem podstawowym Innymi słowy: Formalną definicją 2 NF jest jednostka, która jest w 1 NF i Każdy nie główny klucz jest w pełni funkcjonalnie zależny od podstawowego klucza

Druga normalna forma(2NF) – Przykład Spójrzmy na encje pokazująca proces egzaminacyjny studentów struktura tej encji mogłaby by być opisana przez zbiór następujących atrybutów: (nazwisko, numer indeksu, grupa, przedmiot, ocena)‏ kluczem podstawowym dla tej encji mógłby być (nr indeksu, przedmiot) jako unikalny dla każdego identyfikowanego wiersza encji z innej strony, atrybut nazwisko czy tez grupa, zależny jedynie od części klucza podstawowego – numer indeksu, tak wiec ta encji nie ma w pełni funkcjonalnie zależnych atrybutów Aby znormalizować ta encje do 2NF należny zaprojektować w niej dwie encje o pełnej funkcjonalne zależności od atrybutu klucza podstawowego (nr indeksu., Nazwisko, Grupa) oraz (nr indeksu, przedmiot, ocena)‏

Trzecia normalna forma(3NF) – Definicja Encja jest w 3 NF jeśli: Jest w 1 NF i 2 NF i Nie posiada przejściowych zależności Innymi słowy: Formalną definicją 3 NF jest: encja należy do 3 NF jeśli należy do 1 NF i 2 NF i w której żaden nie-główny atrybut jest przejściowo zależny od głównej myśli Więc, to znaczy, że jednostka która jest w 1 NF i 2 NF I której wszystkie nie-główne kolumny mogą działać bez głównego atrybutu i innych atrybutów.

Trzecia normalna forma (3NF) - Przykład Spójrzmy na encję która łączy studentów w zależne grupy , zdolności i specjalności na których oni studiują (Numer książki kredytowej, Imię i nazwisko, Grupa, Wydział, Specjalność i wydział ukończenia szkoły wyższej)‏ Grupa studentów dokładnie określa fakultet gdzie student się uczy, jego specjalność i wydział ukończenia szkoły wyższej. Wydział ukończenia szkoły wyższej dokładnie określa fakultet gdzie studenci ukończyli wydział, na który uczęszczali Ale, jeśli jedna specjalność może być stworzona przez wiele wydziałów, wtedy specjalizacja nie określa wydziału ukończenia szkoły wyższej

Trzecia normalna forma(3NF) - Przykład (Kontynuacja)‏ W tym wypadku są funkcjonalne zależności: Numer książki kredytowej -> Imię i nazwisko Numer książki kredytowej -> Grupa Numer książki kredytowej -> Wydział Numer książki kredytowej -> Specjalizacja Numer książki kredytowej -> Wydział ukończenia szkoły wyższej Grupa -> Wydział Grupa -> Specjalizacja Grupa -> Wydział ukończenia szkoły wyższej Wydział ukończenia szkoły wyższej -> fakultet Te zależności tworzą grupę przechodnią. By temu zaprzeczyć proponowany jest zestaw w 3 NF (Numer książki kredytowej, Imię i nazwisko, Specjalizacja, Grupa)‏ (Grupa, Wydział ukończenia szkoły wyższej)‏ (Wydział ukończenia szkoły wyższej, Fakultet)‏

Projektowanie fizyczne – główne procedury Celem fizycznego projektu jest zmaksymalizowanie wyników bazy danych przez całe widmo zastosowań zapisanych w nim Zaczyna się gdy tabele zostały zdefiniowane i znormalizowane Skupia się na metodach magazynowania i dostępności tych tabel na dysku, umożliwiając bazie danych wysoką sprawność działania Fizyczny projekt DB zawiera zasady postępowania: wybór indeksów dzielenie gromadzenie wybór realizacji danych

Projektowanie fizyczne – powszechne definicje Logiczny zapis jest zbiorem pozycji danych albo atrybutów traktowanych jako elementy zastosowane przez program W pamięci, pewien zapis zawiera wskazówki i zapis ogólny potrzebny do identyfikacji i przetwarzania przez bazę danych zarządzania systemem. Plik jest kompletem podobnie skonstruowanych zapisów jednego typu i związanych tabel są typowo zmagazynowane jako akta Fizyczna baza danych jest zbiorem powiązanych zapisów różnego typu, możliwie wliczając w to pewien zbór powiązanych akt Pytanie i aktualizacja transakcji wobec bazy danych są wykonane skutecznie przez wprowadzone w życie pewne metody szukania jako część DBMS

Projektowanie fizyczne - Indeksy Indeks odpowiednio umieszcza zorganizowane dane by przyspieszyć ich wyszukiwanie w tabelach z danymi W DBMS , indeksy mogą być sporządzane specyficznie przez bazę danych zgłoszoną programiście przy pomocy SQL polecenia STWÓRZ … INDEKS … Typy indeksów: Unikalny indeks (zalecany)‏ Nie unikalny indeks (drugorzędny)‏ Grupowy indeks Niegrupowy indeks Indeks mieszany Blok adresowy Indeks w postaci mapy bitowej

Projektowanie fizyczne – materialny widok Kiedy jedna lub więcej tabel jest zakwestionowanych, wyniki mogą być zmagazynowane w zmaterializowanym widoku Poglądy w SQL są zmagazynowane jako definicje, lecz poglądy zmaterializowane są zmagazynowane jako tabele w DB, zupełnie jak wszystkie inne tabele Te rodzaje poglądów są bardzo pomocne (użyteczne) w poprawieniu prędkości (szybkości): Zapytania o dane, o które pytano często wcześniej, lub zapytania oparte na zbiorach danych, które mogą być budowane na zmaterializowanych poglądach, wobec odpowiedzi na pytania, zamiast przymusu cofania się za każdym razem do pierwotnych danych Potencjalnie dużo z pytań może być zrozumianych jeśli ten właściwy komplet zmaterializowanych poglądów jest zmagazynowany, co oszczędzi nam czas. Wadą jest zwykle niemożliwy do zmagazynowania zapas wszystkich możliwych poglądów z powodu limitu przestrzeni magazynowej i problemu wielorakich aktualizacji, które czynią użycie zmaterializowanych poglądów mniej wydajnym. To musi być wzięte pod uwagę w ich oznaczeniu i użyciu

Projektowanie fizyczne - partycjonowanie i dzielenie wielowymiarowe Partycjowanie w fizycznym projekcie BD jest pewną metodą redukcji obciążenia pracy wszelkich sprzętów wchodzących w skład komputera, jak np. indywidualny dysk , poprzez dzielenie (podzielenie się) danych na kilka dysków. W partycjowanie rzędów , dane przypisane wartości są sortowane, a dziedziny wartości są wybierane, więc każdy rząd ma obowiązkowo tą samą liczbę zapisów. dokumentacja w pewnym ustalonym rzędzie jest alokowana na specyficznym dysku dokumentacja ta może być rozpatrywana niezależnie od innych dziedzin To jest technika (metoda działania) według której dane mogą być skupione przez: Wielkości (rozmiary), tak jak lokalizacja ramę czasową typ produktu

Projektowanie fizyczne – pozostałe metody Inne sposoby poprawy dostepnosci do danych BD Kompresja danych pozawla to na umieszczenie większej ilości danych w przestrzeni dyskowej i przyspiesza dostęp do danych oraz ich skanowanie Segmentacja danych jest to sposób szczegółowego dopasowania do architektury przestrzeni dyskowej - jak RAID (Redundant Arrays of Independent Disks – zbyteczne przestrzenie niezależnego dysku), gdy dane mogą być udostępniane równolegle, w zorganizowany sposób na dyskach wymiennych. Redundacja danych (jak odbicie lustrzane)‏ dane są kopiowane (tworzone duplikaty) na inne dyski

Bibliografia Lecture Notes. Database (e-version). Based on a book by T.S. Karpova. Database: Models, Development, Implementation. (in Russian). S.Pitersburg. Piter. 2002, 304p., (translated and edited by Anatoly Sachenko)‏ C.J. Date. An Introduction to Database Systems. Addison- Wesley, Copyright , 1024 p., 2003 Rebecca M. Riordan. Designing Effective Database Systems . Addison Wesley Professional. 384 p., 2005 By Michael J. Hernandez. Database Design for Mere Mortals™: A Hands-On Guide to Relational Database Design, Second Edition. Addison Wesley. 672 p., 2003

Bibliografia (kontynuacja)‏ Thomas Connolly, Carolyn Begg. Database Systems: A Practical Approach to Design, Implementation, and Management. 3rd Edition. Addison Wesley. 1236 p., 2001 Sikha Bagui and Richard Earp. Database Design Using Entity- Relationship Diagrams. Auerbach Publications, 242 p., 2003 Sam Lightstone, Toby Teorey, and Tom Nadeau. Physical database design : the database professional’s guide to exploiting indexes, views, storage, and more Kisielnicki J., Sroka H.: Systemy informacyjne biznesu. Informatyka dla zarządzania. Metody projektowania i wdrażania systemów. A.W. „Placet”, Wwarszawa 1999 r. Dobson R.: Programowanie Microsoft Access 2000. Wydawnictwo RM, Warszawa 2000. Beynon-Davies P.: Systemy baz danych. WNT, Warszawa 2000.

Bibliografia (kontynuacja)‏ Andrzejewski M., Chudzicki M., Nowosielska G.: Materiały pomocnicze do projektowania aplikacji bazodanowych. Wydawnictwo Politechniki Śląskiej, Gliwice 2003. Microsoft Official Curriculum: MS #2072: Administering a Microsoft SQL Server 2000 Database. Date C.J.: Wprowadzenie do systemów baz danych. WNT, Warszawa 2000. Internet: Strona domowa przedmiotu: http://www.roz6.polsl.pl/bazydanych. Internet: Portal wiedzy Katedry Informatyki i Ekonometrii http://www.roz6.polsl.pl/portalwiedzy. http://www.roz6.polsl.pl/asachenko/sutaa.html