Bazy danych 2. Wykład 3. Metodologia projektowania baz danych (projektowanie fizyczne)



Podobne dokumenty
Bazy danych 2. Wykład 5 Structured Query Language (SQL) c.d. DDL

Relacyjne bazy danych. Podstawy SQL

Autor: Joanna Karwowska

Projekt jest finansowany ze środków Unii Europejskiej, Europejskiego Funduszu Społecznego i budŝetu państwa. Studia Podyplomowe dla Nauczycieli

Język SQL, zajęcia nr 1

Tworzenie tabel. Bazy danych - laboratorium, Hanna Kleban 1

PRZESTRZENNE BAZY DANYCH WYKŁAD 2

Język SQL. Rozdział 9. Język definiowania danych DDL, część 2.

Podstawy języka SQL. SQL Structured Query Languagestrukturalny

Wykład 8. SQL praca z tabelami 5

Oracle11g: Wprowadzenie do SQL

77. Modelowanie bazy danych rodzaje połączeń relacyjnych, pojęcie klucza obcego.

Indeksowanie w bazach danych

Relacyjne bazy danych. Podstawy SQL

Laboratorium nr 4. Temat: SQL część II. Polecenia DML

D D L S Q L. Co to jest DDL SQL i jakie s jego ą podstawowe polecenia?

Bazy danych. Bazy danych. Zapytania SELECT. Dr inż. Paweł Kasprowski.

Systemy GIS Tworzenie zapytań w bazach danych

Przykładowa baza danych BIBLIOTEKA

3 Przygotowali: mgr inż. Barbara Łukawska, mgr inż. Maciej Lasota

Technologia informacyjna

Bazy danych 6. Klucze obce. P. F. Góra

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

Język SQL. Rozdział 10. Perspektywy Stosowanie perspektyw, tworzenie perspektyw prostych i złożonych, perspektywy modyfikowalne i niemodyfikowalne.

Bazy danych. Bazy danych. Podstawy języka SQL. Dr inż. Paweł Kasprowski.

T-SQL dla każdego / Alison Balter. Gliwice, cop Spis treści. O autorce 11. Dedykacja 12. Podziękowania 12. Wstęp 15

Bazy danych. wprowadzenie teoretyczne. Piotr Prekurat 1

Wykład 05 Bazy danych

Optymalizacja poleceń SQL Metody dostępu do danych

UPDATE Studenci SET Rok = Rok + 1 WHERE Rodzaj_studiow =' INŻ_ST'; UPDATE Studenci SET Rok = Rok 1 WHERE Nr_albumu IN ( '111345','100678');

Wykład 5. SQL praca z tabelami 2

Fizyczna struktura bazy danych w SQL Serwerze

Integralność danych Wersje języka SQL Klauzula SELECT i JOIN

Ćwiczenia laboratoryjne nr 11 Bazy danych i SQL.

SIECI KOMPUTEROWE I BAZY DANYCH

Paweł Rajba

Krzysztof Kadowski. PL-E3579, PL-EA0312,

Bazy danych Ćwiczenia projektowe

SQL - DDL. 1 Tabele systemowe. 2 Typy danych

Aspekty aktywne baz danych

Bazy danych 2. Wykład 4 Structured Query Language (SQL)

Wprowadzenie do baz danych

Bazy danych - wykład wstępny

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko

Perspektywy Stosowanie perspektyw, tworzenie perspektyw prostych i złożonych, perspektywy modyfikowalne i niemodyfikowalne, perspektywy wbudowane.

Bazy danych. Wykład IV SQL - wprowadzenie. Copyrights by Arkadiusz Rzucidło 1

Bazy Danych - Instrukcja do Ćwiczenia laboratoryjnego nr 8

SQL DDL DML TECHNOLOGIE BAZ DANYCH. Wykład 5: Język DDL i DML. Małgorzata Krętowska

< K (2) = ( Adams, John ), P (2) = adres bloku 2 > < K (1) = ( Aaron, Ed ), P (1) = adres bloku 1 >

Przestrzenne bazy danych Podstawy języka SQL

Wykład 4. SQL praca z tabelami 1

Bazy danych. Dr inż. Paweł Kasprowski

Język SQL, zajęcia nr 2

Przykłady najlepiej wykonywać od razu na bazie i eksperymentować z nimi.

Projektowanie systemów baz danych

Bazy danych - Materiały do laboratoriów VIII

Projektowanie struktury danych

1 Zaznacz poprawne stwierdzenia dotyczące grup plików (filegroup) możemy określić do której grupy plików trafi

Wprowadzenie do BD Operacje na bazie i tabelach Co poza zapytaniami? Algebra relacji. Bazy Danych i Systemy informacyjne Wykład 2.

Bazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych

Wykład 2. Relacyjny model danych

1 Wstęp do modelu relacyjnego

Ref. 7 - Język SQL - polecenia DDL i DML

2017/2018 WGGiOS AGH. LibreOffice Base

Model relacyjny. Wykład II

Cele. Definiowanie wyzwalaczy

WPROWADZENIE DO BAZ DANYCH

Relacji między tabelami klucze obce. Schemat bazy danych, wczytanej z pliku create_tables.sql. Klucz obcy jako ograniczenie dla kolumny

Instytut Mechaniki i Inżynierii Obliczeniowej fb.com/groups/bazydanychmt/

Wykład XII. optymalizacja w relacyjnych bazach danych

Bazy danych. Polecenia SQL

SQL w 24 godziny / Ryan Stephens, Arie D. Jones, Ron Plew. Warszawa, cop Spis treści

Plan wykładu. Klucz wyszukiwania. Pojęcie indeksu BAZY DANYCH. Pojęcie indeksu - rodzaje indeksów Metody implementacji indeksów.

Widok Connections po utworzeniu połączenia. Obszar roboczy

Wprowadzenie do projektowania i wykorzystania baz danych Relacje

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA Relacyjny model danych. Relacyjny model danych Struktury danych Operacje Oganiczenia integralnościowe

Blaski i cienie wyzwalaczy w relacyjnych bazach danych. Mgr inż. Andrzej Ptasznik

SIECI KOMPUTEROWE I BAZY DANYCH

I. Język manipulowania danymi - DML (Data Manipulation Language). Polecenia INSERT, UPDATE, DELETE

Modelowanie hierarchicznych struktur w relacyjnych bazach danych

Laboratorium nr 5. Temat: Funkcje agregujące, klauzule GROUP BY, HAVING

koledzy, Jan, Nowak, ul. Niecała 8/23, , Wrocław, , ,

- język zapytań służący do zapisywania wyrażeń relacji, modyfikacji relacji, tworzenia relacji

Wybór EUROPEAN będzie rozpoznawał dzień przed miesiącem, natomiast US miesiąc przed dniem.

Struktura drzewa w MySQL. Michał Tyszczenko

Bazy danych. dr inż. Arkadiusz Mirakowski

Wykład 2. SQL 1 Structured Query Lenguage

SQL w praktyce. Miłej i owocnej nauki!!!

Jarosław Kuchta Projektowanie Aplikacji Internetowych. Projektowanie warstwy danych

Ćwiczenie 14 autoryzacja

Podstawy języka SQL. standardy SQL formułowanie zapytań operacje na strukturach danych manipulowanie danymi. Bazy danych s.5-1

Cel przedmiotu. Wymagania wstępne w zakresie wiedzy, umiejętności i innych kompetencji 1 Język angielski 2 Inżynieria oprogramowania

SQL Server i T-SQL w mgnieniu oka : opanuj język zapytań w 10 minut dziennie / Ben Forta. Gliwice, Spis treści

060 SQL FIZYCZNA STRUKTURA BAZY DANYCH. Prof. dr hab. Marek Wisła

Instrukcja CREATE TABLE

Programowanie MSQL. show databases; - pokazanie jakie bazy danych są dostępne na koncie

Dane wejściowe. Oracle Designer Generowanie bazy danych. Wynik. Przebieg procesu

SZKOLENIE: Administrator baz danych. Cel szkolenia

SQL (ang. Structured Query Language)

Transkrypt:

Bazy danych 2 Wykład 3 Metodologia projektowania baz danych (projektowanie fizyczne)

Projektowanie fizyczne - przegląd krok po kroku 1. Wybór systemu zarządzania bazą danych (BDMS) 2. WyraŜenie logicznego modelu danych w docelowym BDMS a) Zaprojektowanie relacji w systemie b) Zaprojektowanie danych pochodnych c) Zaprojektowanie więzów ogólnych 3. Projektowanie reprezentacji fizycznej a) Analiza transakcji b) Wybór optymalnej reprezentacji plików c) Utworzenie indeksów d) Oszacowanie wymaganej pamięci dyskowej 4. Projektowanie perspektyw uŝytkowników 5. Projektowanie mechanizmów ochrony bezpieczeństwa

Wybór BDMS Projektant powinien wiedzieć: 1. Jak utworzyć relacje bazowe 2. Czy system umoŝliwia definiowanie kluczy głównych, obcych i alternatywnych 3. Czy system umoŝliwia definiowanie warunku wymagana obecność danych 4. Czy system umoŝliwia definiowanie dziedzin 5. Czy system wspiera więzy integralności referencyjnej 6. Czy system umoŝliwia definiowanie więzów ogólnych

Projektowanie relacji Do opisu relacji uŝywamy rozszerzonej wersji DBDL Domain NumerNieruchomości łańcuch o zmiennej długości, maks. dł 5 Domain Ulica łańcuch o zmiennej długości, maks. dł 25 Domain Miasto łańcuch o zmiennej długości, maks. dł 25 Domain TypNieruchomości jeden znak, wartość ze zbioru B, C, F Domain NieruchomośćPokoje liczba całkowita, z przedziału 1-15 Domain NieruchomośćCzynsz wartość walutowa, z przedziału 0,00-999,99 Domain NumerWłaściciela łańcuch o zmiennej długości, maks. dł 5 Domain NumerPracownika łańcuch o zmiennej długości, maks. dł 5 Domain NumerBiura łańcuch o stałej długości, dł 4

Nieruchomość( nieruchomośćnr NumerNieruchomości NOT NULL ulica Ulica NOT NULL miasto Miasto NOT NULL typ TypNieruchomości NOT NULL DEFAULT F pokoje NieruchomośćPokoje NOT NULL DEFAULT 4 czynsz NieruchomośćCzynsz NOT NULL DEFAULT 600 właścicielnr NumerWłaściciela NOT NULL pracowniknr NumerPracownika NOT NULL biuronr NumerBiura NOT NULL kaucja NieruchomośćCzynsz NOT NULL PRIMARY KEY (nieruchomośćnr) ALTERNATE KEY (ulica, miasto) FOREIGN KEY (pracowniknr) REFERENCES Personel(pracownikNr) ON UPDATE CASCADE ON DELETE SET NULL FOREIGN KEY (właścicielnr) REFERENCES WłaścicielPrywatny(właścicielNr) and WłaścicielInstytucjonalny(właścicielNr) ON UPDATE CASCADE ON DELETE NO ACTION DERIVED kaucja (czynsz*0,1)

Projektowanie relacji Sposób implementacji relacji bazowych jest uzaleŝniony od moŝliwości oferowanych przez docelowy DBMS Projekt relacji powinien być w pełni udokumentowany wraz z informacjami o przyczynach wyboru konkretnych rozwiązań

Projektowanie danych pochodnych Z punktu widzenia fizycznego projektu bazy danych wybór między reprezentacją atrybutu pochodnego w bazie danych a jego wyliczaniem przy kaŝdym odwołaniu do niego jest zawsze kompromisem pomiędzy róŝnymi celami. NaleŜy oszacować: Koszt związany z przechowywaniem danych pochodnych w bazie i zapewnieniem ich zgodności z danymi, na podstawie których są wyznaczane; Koszt wyliczenia wartości atrybutów pochodnych przy kaŝdym odwołanie do nich Ostateczny wybór powinien słuŝyć zapewnieniu maksymalnej wydajności systemu.

Projektowanie danych pochodnych (przykład)

Projektowanie więzów ogólnych Sposób zaprojektowania więzów ogólnych jest zaleŝny od DBMS. Zakres wbudowanych w DBMS funkcji, które umoŝliwiają definiowanie więzów ogólnych, jest bardzo zróŝnicowany. Niektóre systemy umoŝliwiają zapewnienie więzów za pomocą standardowych poleceń SQL, w innych konieczne jest zastosowanie wyzwalaczy wymuszających spełnienie określonych więzów. W standardzie SQL moŝemy realizować więzy ogólne za pomocą klauzuli CHECK WyróŜnia się dwa sposoby stosowania ograniczenia CHECK Ograniczenie na poziomie kolumny ograniczenie to dotyczy tylko i wyłącznie danej kolumny Ograniczenie na poziomie tabeli ograniczenie dotyczące kilku kolumn tabeli

Projektowanie więzów ogólnych Przykłady ograniczenie na poziomie kolumny CREATE TABLE products ( product_no integer, name text, price numeric CHECK (price > 0) ); Ograniczeniom moŝna nadawać nazwy, ułatwia to odwoływanie do nich CREATE TABLE products ( product_no integer, name text, price numeric CONSTRAINT positive_price CHECK (price > 0) );

Projektowanie więzów ogólnych Przykłady ograniczenie na poziomie tabel CREATE TABLE products ( product_no integer, name text, price numeric CHECK (price > 0), discounted_price numeric, CHECK (discounted_price > 0), CONSTRAINT valid_discount CHECK (price > discounted_price) ); Standard SQL dopuszcza tworzenie podzapytań w klauzuli CHECK CHECK (NOT EXISTS (SELECT pracowniknr FROM Nieruchomość GROUP BY pracowniknr HAVING COUNT(*)>100))

Projektowanie reprezentacji fizycznej CEL: wybór sposobu reprezentacji relacji i krotek w pamięci zewnętrznej Na ocenę wydajności systemu wpływa szereg czynników: Przepustowość transakcyjna określa liczbę transakcji, które mogą zostać przetworzone w ustalonej jednostce czasu Czas reakcji jest to czas potrzebny na realizację jednej transakcji Zapotrzebowanie na pamięć zewnętrzna parametr ten określa rozmiar pamięci zewnętrznej zajmowanej przez pliki bazy danych

Analiza transakcji CEL: Zrozumienie sposobu działania transakcji występujących w projekcie oraz analiza najwaŝniejszych z nich Pytania: Które transakcje są często wykonywane i mają istotny wpływ na wydajność systemu Które transakcje są kluczowe dla działania instytucji W jakich godzinach/dniach tygodnia występuje szczyt odwołań do bazy danych Informacje te wykorzystujemy do ustalenia, w których komponentach bazy danych mogą występować problemy obniŝające wydajność systemu Na podstawie tych danych wybierzemy organizację plików i indeksów

Analiza transakcji (przykład)

Analiza transakcji (przykład)

Analiza transakcji (przykład)

Analiza transakcji Po przeanalizowaniu istotnych transakcji, analizujemy dokładniej kaŝdą z nich musimy ustalić Relacje i atrybuty do których odwołuje się transakcja oraz typ odwołania Dla transakcji modyfikującej naleŝy ustalić modyfikowane atrybuty te atrybuty nie powinny występować w strukturach dostępu do danych (indeksach) Wszystkie atrybuty wykorzystywane w predykatach (w SQL warunki umieszczone w klauzuli WHERE) Atrybuty te naleŝy traktować jako kandydatów do umieszczenia w strukturach ułatwiających dostęp do danych

Analiza transakcji Dla zapytań, atrybuty występujące w złączeniu dwóch lub większej liczby relacji Te atrybuty równieŝ mogą być kandydatami do umieszczenia w strukturach ułatwiających dostęp do danych Przewidywana częstotliwość wykonywania transakcji Wymagania dotyczące sposobu wykonania transakcji Atrybuty wykorzystywane w jakichkolwiek predykatach krytycznych lub w predykatach bardzo często wykonywanych transakcji powinny mieć większy priorytet przy wyborze elementów struktur ułatwiających dostęp do danych

Wybór reprezentacji plików Celem tego kroku jest wybór optymalnej organizacji plików dla kaŝdej relacji, o ile umoŝliwia to docelowy DBMS. WyróŜnia się kilka róŝnych metod organizacji plików: Sterty Pliki haszowane B+ - drzewa klastry JeŜeli system nie umoŝliwia wyboru organizacji plików, to krok ten moŝna pominąć.

Wybór indeksów Definicja: Indeks jest to struktura danych umoŝliwiająca szybszy dostęp do konkretnych rekordów w pliku, a tym samym przyspieszenie realizacji zapytań. Indeks w bazie pełni podobną rolę jak skorowidz (indeks) w ksiąŝce. Jest on strukturą pomocniczą, stowarzyszoną z sekwencyjnym plikiem danych, w którym poszukiwanymi elementami są rekordy lub grupy rekordów. Indeks jest złoŝony z rekordów - kaŝda jego pozycja zawiera jedną z wartości klucza wyszukiwania oraz jeden lub więcej adresów (numerów rekordów) pod którymi moŝna znaleźć poszukiwaną wartość. Indeks jest posortowany według pola indeksującego, odpowiadającego kluczowi wyszukiwania (jeden lub więcej atrybutów)

Wybór indeksów Do głównych typów indeksów nalezą: Indeks główny plik danych jest uporządkowany według pola porządkującego, które jest kluczem relacji; pole indeksujące jest równe polu porządkującemu relacji, jego wartości w poszczególnych rekordach są unikalne Indeks grupujący plik danych jest uporządkowany według pola nie będącego kluczem relacji, które jest teŝ polem indeksującym; jednej wartości pola indeksującego moŝe odpowiadać więcej niŝ jeden rekord; wykorzystane w tym indeksie pole nazywa się atrybutem grupującym Indeks pomocniczy indeks zdefiniowany na podstawie pola, które nie jest uŝywane przy wyznaczaniu porządku rekordów w bazie

Wybór indeksów Wskazówki dotyczące tworzenia listy poŝądanych indeksów NaleŜy utworzyć indeks dla klucza głównego (jeśli nie robi tego DBMS) Jeśli często występują odwołania do klucza obcego, warto utworzyć dla niego indeks (jeśli nie robi tego DBMS). NaleŜy utworzyć indeks pomocniczy dla kolumn, które nie są kluczami głównymi ani kluczami obcymi, ale mogą być uŝywane w złoŝonych powiązaniach NaleŜy utworzyć indeksy pomocnicze dla atrybutów intensywnie wykorzystywanych w: Kryteriach selekcji ORDER BY GROUP BY Innych operacjach wymagających sortowania

Wybór indeksów Wskazówki dotyczące tworzenia listy poŝądanych indeksów Nie naleŝy indeksować małych relacji NaleŜy unikać indeksowania często modyfikowanego atrybutu bądź relacji Nie jest wskazane indeksowanie atrybutu słuŝącego realizacji zapytań, których wynikiem jest istotna frakcja krotek w relacji (>25%) NaleŜy unikać indeksowania atrybutów składających się z długich łańcuchów

Wybór indeksów Z utrzymywaniem i uŝywaniem indeksów wiąŝe się dodatkowy koszt, na który składa się m.in.: Koszt dodania nowego rekordu indeksowego do kaŝdego indeksu pomocniczego przy kaŝdym dodaniu krotki do relacji; Koszt modyfikacji indeksów pomocniczych wynikający z odpowiednich modyfikacji krotek w relacji; Wzrost rozmiaru pamięci dyskowej; MoŜliwość obniŝenia wydajności na etapie optymalizacji zapytań, będąca wynikiem rozwaŝania przez optymalizator uŝycia kaŝdego z indeksów Przy dodawaniu indeksów pomocniczych naleŝy rozwaŝyć, czy ten dodatkowy koszt zostanie zrekompensowany poprzez uzyskaną dzięki indeksowi poprawę wydajności.

Wybór indeksów Indeksy tworzymy w SQL za pomocą polecenia CREATE [ UNIQUE ] INDEX name ON table [ USING method ] (column1 [ASC DESC], column2 [ASC DESC,..) gdzie name nazwa indeksu table nazwa tabeli method nazwa metody organizacji pliku indeksu, Column1, column2,.. nazwy kolumn tabeli, tworzą klucz indeksu; powinny być wymienione w kolejności od najbardziej do najmniej znaczących ASC DESC porządek kolumny rosnący malejący

Wybór indeksów Przykład CREATE TABLE test2 ( major int, minor int, name varchar ); Utworzymy indeks dla kolumn major i minor CREATE INDEX test2_mm_idx ON test2 (major, minor);

Oszacowanie rozmiaru pamięci dyskowej Podstawą szacowania są informacje: o rozmiarze krotki liczbie krotek w relacji NaleŜy oszacować maksymalny rozmiar danych w bieŝących warunkach NaleŜy uwzględnić moŝliwość rozrostu bazy danych

Projektowanie perspektyw uŝytkowników Perspektywa jest relacja wirtualną, która nie musi istnieć fizycznie w bazie danych, ale moŝe być wyliczona w kaŝdej chwili na Ŝądanie uŝytkownika. Czasami perspektywy mogą być przechowywane w bazie danych w postaci tabeli tymczasowej tworzonej w momencie pierwszego odwołania do perspektywy RozróŜniamy róŝne typy perspektyw Perspektywa pozioma ogranicza dostęp do wybranych wierszy jednej lub wielu tabel Perspektywa pionowa ogranicza dostęp do wybranych kolumn jednej lub wielu tabel Perspektywy oparte na grupowaniu

Projektowanie perspektyw uŝytkowników Zalety perspektyw NiezaleŜność danych perspektywa moŝe reprezentować spójny i niezmienny obraz struktury bazy danych pomimo zmian dokonywanych w tabelach bazowych (pomimo dodawania i usuwania kolumn, zmiany związków, dzielenia tablic, zmiany ich struktury i nazwy) Poprawa bezpieczeństwa kaŝdy uŝytkownik moŝe otrzymać uprawnienia do bazy danych poprzez niewielki zbiór perspektyw, które zawierają potrzebne mu dane Uproszczenie zapytań Wygoda uŝytkownik widzi tylko tyle ile potrzebuje Dostosowanie do uŝytkownika

Projektowanie perspektyw uŝytkowników Wady perspektyw Ograniczona moŝliwość modyfikacji pewnych danych nie moŝna modyfikować poprzez perspektywy Ograniczenia struktury jeśli tworzona była perspektywa ze wszystkich kolumn tabeli i dodaliśmy nowe kolumny, to nie będą one występowały w perspektywie Wydajność korzystanie z perspektyw moŝe spowodowac spadek wydajności

Projektowanie mechanizmów ochrony bezpieczeństwa Zakres mechanizmów ochrony bezpieczeństwa oferowanych przez systemy zarządzania bazą danych jest zróŝnicowany Relacyjne DBMS zasadniczo dostarczają dwa poziomy ochrony bezpieczeństwa ochronę systemu stanowią mechanizmy kontroli dostępu i uŝytkowania bazy danych na poziomie systemu, takie jak nazwy uŝytkowników i hasła ochronę danych stanowią mechanizmy dostępu i uŝytkowania obiektów bazy danych (relacji i perspektyw) do których uŝytkownicy są uprawnieni