Łódź 2008

Banki danychWYKŁAD 1

dr Łukasz Murowanieckilukaszm@uni.lodz.pl

T-109

Łódź 2008

Plan wykładu

Pojęcia podstawowe System zarządzania bazą danych (DBMS) Relacyjny model danych Inne modele baz danych Projektowanie baz danych Język SQL Zastosowania i technologie powiązane (hurtownia danych,

eksploracja danych)

Łódź 2008

Literatura

Podstawowa: C. J. Date – Wprowadzenie do systemów baz danych -

Wydawnictwa Naukowo-Techniczne J. Ullman, J. Widom – Podstawowy wykład z systemów baz

danych - Wydawnictwa Naukowo-Techniczne

Uzupełniająca: Lech Bałachowski, Krzysztof Stencel - Systemy

zarządzania bazami danych - Wydawnictwo PJWSTK (Polsko-Japońska Wyższa Szkoła Technik Komputerowych)

M. Szeliga – Transact-SQL Czarna księga R. Barker – CASE Method – Modelowanie związków encji D. Tsichritzis, F. Lochovsky – Modele danych

Łódź 2008

Pojęcia podstawowe

Baza danych - zbiór danych uporządkowany dane trwałe istniejących przez długi czas, często przez wiele lat przechowywanych w specjalnie wyznaczonym miejscu

(systemie informatycznym) Dane – wartości faktycznie przechowywane w bazie

danych Informacje – znaczenie tych wartości dla użytkowników

Łódź 2008

Pojęcia podstawowe

System zarządzania bazą danych - SZBD (ang. Database Management System - DBMS) Program (zbiór programów), działający na serwerze bazy

danych Odpowiada za organizację danych wewnątrz bazy danych Pośredniczy w uzyskaniu dostępu do danych w bazie

Łódź 2008

Pojęcia podstawowe

Rola DBMS Izolowanie programów korzystających z danych od

reprezentacji fizycznej danych Zapewnienie mechanizmów dostępu do danych (języki

zapytań i manipulacji danymi) Ochrona danych (autoryzacja dostępu, ochrona spójności,

mechanizmy odtwarzania po awarii) Zapewnienie wielodostępu Dostępność przez sieć

Łódź 2008

Pojęcia podstawowe

Baza danych opisuje w sposób uproszczony pewien fragment rzeczywistości. Opisuje go przy pomocy modelu danych.

Model danych - zbiór ogólnych zasad posługiwania się danymi. Zbiór ten obejmuje trzy główne części: Definicja danych: zbiór reguł określających strukturę danych; Operowanie danymi: zbiór reguł dotyczących procesu

dostępu do danych i ich modyfikacji; Integralność danych: zbiór reguł określających, które stany

bazy danych są poprawne (a więc zarazem jakie operacje prowadzące do modyfikacji danych są dozwolone)

Łódź 2008

Pojęcia podstawowe

System zarządzania bazą danych

Baza danych

Computer

Computer

Computer

Aplikacje Użytkownicy

Model danych

Łódź 2008

System zarządzania bazą danych

Oczekiwania stawiane DBMS Tworzenie bazy danych - język definiowania danych DDL Wyszukiwanie danych – język zapytań DQL, kwerendy Aktualizacja danych – język manipulacji danymi DML Przechowywanie danych Sterowanie dostępem do danych

Łódź 2008

System zarządzania bazą danychSkładowe DBMS

DaneMetadane

Moduł zarządania pamięcią

Procesor zapytań

Moduł zarządzania transakcjami

Modyfikacje schematu

Zapytania Aktualizacje

Użytkownicy

Moduł zarządzania plikami

Moduł zarządzania buforami

Łódź 2008

System zarządzania bazą danychWłasności transakcji

Zespół własności DBMS, za który odpowiedzialny jest moduł zarządzania transakcjami nazywany jest słowem

ACID: Niepodzielność (Atomicity) Spójność (Consistency) Izolację (Isolaction) Trwałość (Durability)

Łódź 2008

System zarządzania bazą danychWspółbieżność

DBMS musi sprawować kontrolę nad przebiegiem transakcji, nie dopuszczając do wzajemnej blokady poszczególnych transakcji lub stanu niezgodnego bazy danych

Sytuacja konfliktowa pojawia się wówczas, gdy dwie transakcje próbują dokonać zapisu na tym samym obiekcie w jednej chwili

Problem utraconej modyfikacji (zapis-zapis) Problem zależności od niezatwierdzonej wartości (zapis-

odczyt) Problem niespójnej analizy (zapis-odczyt)

Łódź 2008

System zarządzania bazą danychWspółbieżność

Typowa transakcja Czas

t2

t3

t1

Transakcja A

Zapis zmiany

Odczyt wartości

Zatwierdzenie zmianylub

cofnięcie zmiany

Łódź 2008

System zarządzania bazą danychWspółbieżność

Problem utraconej modyfikacji (zapis-zapis)

Transakcja A Czas Transakcja B

Odczyt wartości

Odczyt wartości

Zapis zmiany

Zapis zmiany

t2

t3

t4

t1

Łódź 2008

System zarządzania bazą danychWspółbieżność

Problem utraconej modyfikacji – nie wystąpi, gdy przestrzega się następującej reguły:

transakcja T1 nie powinna dokonywać zapisu wartości obiektu modyfikowanej przez inną transakcję T2, która nie osiągnęła jeszcze punktu potwierdzenia

Łódź 2008

System zarządzania bazą danychWspółbieżność

Problem zależności od niezatwierdzonej wartości (zapis-odczyt)Transakcja A Czas Transakcja B

Odczyt wartości

Cofnięcie zmiany

Zapis zmiany

t2

t3

t1

Łódź 2008

System zarządzania bazą danychWspółbieżność

Problem zależności od niezatwierdzonej wartości (zapis-odczyt)Transakcja A Czas Transakcja B

Zapis zmiany

Cofnięcie zmiany

Zapis zmiany

t2

t3

t1

Łódź 2008

System zarządzania bazą danychWspółbieżność

Problem zależności od niezatwierdzonej wartości– nie wystąpi, gdy przestrzega się następującej reguły:

Transakcja A nie powinna dokonywać dokonywać odczytu wartości niepotwierdzonych, którymi w tym czasie manipulują inne transakcje

Łódź 2008

System zarządzania bazą danychWspółbieżność

Problem niespójnej analizy (zapis-odczyt)Czas

t2

t3

t1

Transakcja A

Odczyt wartości B (A+B)

Odczyt wartości A

Odczyt wartości A

Zapis wartości A -> A1

Zatwierdzenie wartości A1

Odczyt wartości C (A+B+C)

t4

t5

t6

Transakcja B

Łódź 2008

System zarządzania bazą danychWspółbieżność

Problem niespójnej analizy – nie wystąpi, gdy przestrzega się następującej reguły:

Żadna transakcja nie powinna modyfikować wartości odczytywanej przez inną transakcję, zanim ta ostatnia nie osiągnie punktu potwierdzenia

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura dwuwarstwowa (client-server) Architektura dwu i pół warstwowa Architektura trójwarstwowa

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura client-server Serwer sam stanowi DBMS.

Może realizować wszystkie podstawowe funkcje: definiowanie danych, obróbkę danych, zapewnienie bezpieczeństwa i integralności danych

Klienci są to rozmaite aplikacje korzystające z DBMS – zarówno napisane przez użytkowników jak i aplikacje wbudowane, czyli dostarczone wraz z DBMS

DBMS

Baza danych

Serwer

Klienci

Użytkownicyaplikacji

Aplikacje

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura client-server - zalety Elastyczność systemu – można pracować z różnymi

środowiskami graficznymi równocześnie. Można operować danymi w sposób spójny a jednocześnie niezależny od bieżącej struktury

Zarządzanie samym serwerem powoduje uniezależnienie od konkretnych użytkowników i problemów związanych z wielodostępem

Zmiana jednostki serwera lub oprogramowania serwera nie wymaga zmiany aplikacji po stronie klienta

Istnieje możliwość wyboru dostępu do danych w zależności od kategorii użytkowników

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura client-server - wady Duży stopień komplikacji systemu – istnieje konieczność

zapewnienia mechanizmów spójności i wielodostępu

Konieczność zapewnienia właściwej komunikacji aplikacji klienckiej z serwerem bazy danych

Zapewnienie odpowiednich połączeń sieciowych (standardy)

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura client-server - rozwarstwienie

Warstwa bazy danych

Warstwa aplikacjii

prezentacji

Serwer

Klient

Struktura bazydanych

Regułybiznesowe

Interfaceużytkownika

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura dwu i pół warstwowa

Warstwa bazy danych

Warstwa aplikacjii

prezentacji

Serwer

Klient

Klient

Reguły biznesowe

Struktura bazydanych

Interfaceużytkownika

SerwerProcedury

wbudowane,trigery

Podwarstwa procedurwbudowanych i trigerów

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura dwu i pół warstwowa - cechy aplikacja kliencka nie odwołuje się bezpośrednio do bazy

danych, ale jedynie wywołuje pewne operacje w serwerze danych, który bądź udostępnia pewne dane bądź realizuje wywołane procedury bazodanowe

w bazie danych zaimplementowane są reguły biznesowe, wspólne dla wszystkich aplikacji klienckich. Wymiana takiej reguły powoduje, że sposób funkcjonowania aplikacji klienta zmieni się dla każdego klienta jednocześnie

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura trójwarstwowa

DBMS

Baza danych

Serwer bazydanych

Klienci

Użytkownicyaplikacji

Aplikacje - procedurybiznesowe

Aplikacje - interface

Serwer aplikacji

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura trójwarstwowa

Warstwa bazy danych

Warstwa aplikacji

Serwer bazy danych

Klient

Struktura bazydanych

Regułybiznesowe

Interfaceużytkownika

Warstwa prezentacji

Serwer aplikacji

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura trójwarstwowa – cechy Istnieje potrzeba wyprowadzenia kodu poza strukturę

serwera bazy danych Aplikacja kliencka komunikuje się jedynie z serwerem

aplikacji Serwer aplikacji wykonuje procedury na żądanie aplikacji

klienckiej a one odwołują się do bazy danych Serwer aplikacji może inicjować realizowanie operacji

bazodanowych na kilku serwerach aplikacji jednocześnie Warstwa aplikacji jest odpowiedzialna za spójność danych

posadowionych na kilku serwerach oraz za odseparowanie aplikacji klienckiej od struktur baz danych

Architektura trójwarstwowa stosowana jest m.in.. W systemach, w których komunikacja oparta jest o internet, np.. ORACLE 9i (IAS)

Łódź 2008

System zarządzania bazą danychArchitektura

Architektura trójwarstwowa