Projektowanie Baz Danych Elżbieta Mrówka - Matejewska emrowka@pjwstk.edu.pl Konsultacje wtorki godz. 15:00 - 16:00 Folder: P:\FTP(Public)\emrowka\PBD_Podyplomowe

Projektowanie Baz Danych Zaliczenie: Kolokwium – diagram związków encji w MS Visio Projekt ERD dla własnego zagadnienia

Wykład I Relacyjna baza danych i system zarządzania bazą danych Relacyjne Bazy Danych Wykład I Relacyjna baza danych i system zarządzania bazą danych opr. Lech Banachowski, Krzysztof Matejewski

Relacyjne Bazy Danych Streszczenie wykładu I W wykładzie 1 omówione zostaną podstawowe zagadnienia baz danych. Zapoznamy słuchaczy z pojęciem „baza danych”, dokonamy krótkiego przeglądu modeli baz danych, oraz szczegółowo omówimy koncepcję modelu relacyjnego, najbardziej rozpowszechnionego dziś modelu baz danych. Wykład został przygotowany w oparciu o materiały profesora Leszka Banachowskiego. Materiał w nim prezentowany znajduje się także w podręczniku „Relacyjne bazy danych. Wykłady i ćwiczenia” autorstwa Leszka Banachowskiego, Agnieszki Chądzyńskiej i Krzysztofa Matejewskiego, wydanym przez Wydawnictwo PJWSTK. Wykład jest przeznaczony dla studentów na kierunku Informatyka, w Polsko – Japońskiej Wyższej Szkole Technik Komputerowych. Krótkie opisy modeli danych powstały w oparciu o hasła Wikipedii. opr. Lech Banachowski, Krzysztof Matejewski

Część I Pojęcie bazy danych opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych informacje podstawowe Podawana przez Wikipedię definicja bazy danych brzmi następująco: Baza danych – zbiór danych zapisanych w ściśle określony sposób, w strukturach odpowiadających założonemu modelowi danych. Można tą definicję jeszcze uprościć mówiąc, że baza danych to dane wraz ze strukturą (sposobem) ich przechowywania. Należy zwrócić uwagę na fakt, że taka definicja jest uniwersalna – abstrahuje zarówno od samych danych (ich zawartości), jak też od technologii użytej do ich przechowywania. Koncepcja bazy danych, w sensie sposobu gromadzenia i przechowywania danych sięga zamierzchłej przeszłości. Ludzie od zawsze gromadzili informacje i w oparciu o ich zasoby próbowali wyciągać wnioski. Na przestrzeni lat forma przechowywania informacji ulegała daleko idącym zmianom, cel jednak pozostawał zawsze ten sam. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych dane i informacja Informacja, dane – to pewien zasób, którego celem jest opis rzeczywistości, a ściślej jej fragmentu. Dane są jednym z zasobów firmy (obok kapitału, pracowników, infrastruktury) i tak jak pozostałe zasoby wymagają zarządzania. Informacja to dane razem z ich semantyką – brak wiedzy o znaczeniu danych czyni je bezużytecznymi! Przykład – dane zaszyfrowane są czytelne tylko dla posiadaczy klucza do szyfru. Zarządzanie danymi jest realizowane poprzez system informacyjny, który zaspokaja zapotrzebowanie na informacje o pewnym fragmencie rzeczywistości (w firmie, instytucji, organizacji, państwie etc.) Baza danych stanowi na ogół fragment tego systemu Baza danych stała się standardową metodą wprowadzenia struktury do procesu zarządzania danymi. Istnieje dualizm pojęciowy: baza danych to kolekcja danych lub system zarządzania danymi (SZBD). opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych dane i informacja Od początku lat siedemdziesiątych ubiegłego (XX) wieku, coraz większy udział wśród zasobów zapisanej informacji uzyskiwał zapis cyfrowy, gromadzony na nośnikach najpierw papierowych (!), później magnetycznych, optycznych i magnetooptycznych. Wynikało to z gwałtownego rozwoju technologii informatycznej, trwającego zresztą do dnia dzisiejszego. Komputery, jakkolwiek tylko ułatwiają przetwarzanie informacji, jednak z uwagi na swoje możliwości wniosły nową jakość, poprzez udostępnienie możliwości przechowywania ogromnych zasobów danych, oraz szybkość ich obróbki (zapis, wyszukiwanie, kopiowanie, sortowanie). Można powiedzieć, że użycie komputera jako narzędzia do przechowywania i zarządzania danymi, spowodowało prawdziwą rewolucję w podejściu do zagadnienia baz danych. Z jednej strony bardzo niski koszt przechowywania danych umożliwia gromadzenie ich ogromnych zasobów, z drugiej strony te ogromne zasoby wymagają niezwykle sprawnych narzędzi zarządzających nimi, gdyż bez nich stają się bezwartościowe. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych Podstawowe wymagania stawiane bazie danych W bazach danych pokładanych jest wiele oczekiwań, które zasadniczo sprowadzają się do zagwarantowania bezpiecznego przechowywania prawdziwych danych, oraz umożliwienia dotarcia do tych danych osobom uprawnionym w możliwie najkrótszym czasie. W praktyce definiowane są następujące szczegółowe wymagania: Trwałość – dane maja być przechowywane przez pewien okres czasu, na ogół nie określony z góry, a upływ czasu nie może mieć wpływu na stan danych. Zgodność z rzeczywistością – dane mają jak najwierniej opisywać rzeczywistości, a ich struktura musi mieć możliwość dostosowywania się do zmian rzeczywistości. Kontrolowanie replikacji – system zarządzający danymi musi gwarantować kontrolę nad (ewentualną) redundancją (nadmiarową informacją), mogącą prowadzić do niejednoznaczności danych. Cały system powinien opierać się na jednym modelu danych. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych Dodatkowe wymagania stawiane bazie danych Współbieżny dostęp do danych – system powinien umożliwiać wykonywanie wielu jednoczesnych operacji na danych, przy zachowaniu gwarancji poprawności (spójności) danych. Ochrona (bezpieczeństwo) danych - zagadnienie wieloaspektowe; bezpieczeństwo danych możemy rozważać na wielu płaszczyznach i w wielu ujęciach. Niezależność danych i wykorzystujących je procesów – właściwość mająca duży wpływ na dalszy rozwój systemu informacyjnego, oraz możliwość szerokiego wykorzystania bazy danych w ramach tego systemu. Należy jednak pamiętać, że realizacja każdego z powyższych wymogów pociąga za sobą koszty, proporcjonalne do jakości rozwiązań. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych Wartość informacji Można powiedzieć, że informacja ma wartość, gdy jest: Prawdziwa – zawierająca informację o aktualnym stanie opisywanej rzeczywistości. Dokładna - ani nadmiernie szczegółowa, ani nazbyt ogólna. Dostępna – czas dotarcia do poszukiwanych informacji powinien być adekwatny do ich ważności. Zła struktura zapisu danych, oraz zły sposób ich poszukiwania, mogą uniemożliwić dotarcie do nich w czasie istotności danych. Jeśli zachodzi ten przypadek, zwiększanie mocy obliczeniowej komputera niewiele pomoże. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych DB - Istotny element współczesnej informatyki Rozważając, dlaczego bazy danych stały się tak istotnym elementem współczesnej informatyki, należy zauważyć, że sformalizowanie zagadnienia baz danych, następnie powstanie spójnego modelu, na bazie którego powstało szereg funkcjonalnych aplikacji, pozwoliło rozwiązać problemy generowane w dzisiejszym świecie przez: Wszechobecność informacji: od serwisów działających na przeglądarkach internetowych po aplikacje naukowe Zbiory danych o coraz większej różnorodności i wielkości: biblioteki elektroniczne interaktywne video multimedialne bazy danych projekty badania genomu człowieka projekt obserwacji Ziemi (NASA). opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych Obszary zagadnień Obecnie, przy konstrukcji systemów baz danych wykorzystuje się większość działów informatyki: systemy operacyjne teorię informatyki sztuczną inteligencję logikę języki programowania multimedia inżynierię oprogramowania. Obszar Systemów Baz Danych (SBD) reprezentuje obecnie jeden z największych i najbardziej aktywnych segmentów rynku oprogramowania (czyli możliwości pracy i zarobkowania!). opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych Klasyczne modele danych Kartotekowy model danych Dane przechowywane są w tablicach (jednej lub wielu) w postaci rekordów o jednakowej strukturze. Rekordy mogą być sortowane, filtrowane, Każda tablica jest samodzielnym dokumentem, bez możliwości współpracy z innymi. Przykładem może być książka telefoniczna w telefonie komórkowym, a także arkusze Excela lub tabele wykonane w MS Word. Hierarchiczny model danych Hierarchiczny model danych, to uporządkowanie danych w strukturze drzewa, na zasadzie rekordów nadrzędnych i podrzędnych. Każdy rekord (z wyjątkiem głównego – korzenia) przechowuje wskaźnik do jednego rekordu nadrzędnego. Wyszukiwanie danych w bazie hierarchicznej polega na poszukiwaniu rekordów podrzędnych względem znanego. Przykładem logicznym jest drzewo genealogiczne, a na co dzień z bazą danych zbudowaną w oparciu o ten model, mamy do czynienia w strukturze plików dyskowych, w systemach operacyjnych komputerów. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych Klasyczne modele danych Sieciowy model danych Sieciowy model danych stanowi pewną modyfikację modelu hierarchicznego, w której zamiast wskaźnika do rekordu nadrzędnego, każdy rekord posiada oznaczenie przynależności do kolekcji pewnego typu. Kolekcja to złożony typ, zawierający odniesienia do innych rekordów określonego typu. Zdefiniowanie typu kolekcji polega na podaniu typu rekordu ,,właściciela'' i typu rekordów - elementów kolekcji. Struktura logiczna danych w tym modelu może zostać zobrazowana grafem. Relacyjny model danych Model relacyjny zbudowany jest w oparciu o matematyczne pojęcie relacji, a jego struktura logiczna, to tabele o określonej strukturze i rekordy zapisane w tabelach. Dalszy ciąg tego i kilku następnych wykładów będzie poświęcony modelowi relacyjnemu. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych Współczesne modele danych Obiektowy model danych Koncepcja obiektowych baz danych, powstała jako następstwo konieczności współpracy obiektowych języków programowania, z nieobiektowymi strukturami danych. W modelu obiektowym: obiekty w bazie danych reprezentują obiekty w świecie rzeczywistym, oraz posiadają tożsamość, typ obiektowy (klasa), definiuje złożony typ danych, mogący zawierać w sobie inne typy obiektowe lub ich kolekcje, struktury danych cechuje enkapsulacja (hermetyzacja), czyli ukrycie samej struktury przed użytkownikiem, przy czym znajomość tej struktury nie jest konieczna do korzystania z niej, obiekty dziedziczą zarówno strukturę, jak też właściwości i metody swojej klasy opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych Współczesne modele danych Sieci semantyczne (Semantic Web) Projekt, w przypadku którego trudno już mówić o modelu danych. Zakłada się powstanie technologii i standardów pozwalających maszynom i programom na wyszukiwanie i przetwarzanie danych w oparciu o ich znaczenie (semantykę). Jako „bazę danych” przyjmuje się Internet i wszystkie dostępne w nim dane. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych historia rozwoju 1961 - Integrated Data Store IDS (Charles Bachman, General Electric) - pierwszy SZBD, początek sieciowego modelu danych. 1965 - 70 - Information Management System IMS (IBM) – hierarchiczny model danych 1970 - dr Edgar Codd (IBM), w artykule „A Relational Model for Large Shared Date Banks” publikuje podstawowe założenia relacyjnego modelu danych 1971 - CODASYL, standard sieciowego modelu danych. Początek lat siedemdziesiątych - w laboratorium badawczym IBM w San Jose powstał prototyp języka SQL o nazwie Sequel opracowany przez Boyce’a i Chamberlaine’a. 1973 - pierwszy system zarządzania relacyjną bazą danych (System R w firmie IBM). 1976 - Peter Chen - model związków encji (ERD, ERM); brak standardu do tej pory (!!!). opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych historia rozwoju 1979 - firma Relational Software (później Oracle) wprowadziła na rynek pierwszą komercyjną wersję systemu zarządzania relacyjną bazą danych. 1983 – pierwsza RDB dla komputerów typu mainframe – DB2 firmy IBM (do dzisiaj rozwijana, pracując a na wszystkich platformach, w tym także na działających do dzisiaj maszynach mainframe) 1986 - pierwszy standard języka SQL-86 (ANSI) Kolejne wersje standardu ANSI/ISO (za Wikipedią): SQL-89, SQL-92 (SQL2), SQL:1999 (SQL 3), SQL:2003, SQL2006, SQL:2008 Lata osiemdziesiąte – badania nad dedukcyjnymi i obiektowymi bazami danych. 1997 - Standard obiektowych baz danych ODMG 2.0. opr. Lech Banachowski, Krzysztof Matejewski

Bazy Danych historia rozwoju Lata dziewięćdziesiąte i późniejsze – rozszerzenie baz danych o nowe aspekty: Architektury wielowarstwowe Rozproszenie Równoległość Internet Hurtownie danych OLAP (On Line Analysis Processes) Multimedia Bazy dokumentów (w tym XML) GIS (Geographical Information Systems) ERP (Enterprise Resource Planning) oraz MRP (Management Resource Planning) - pakiety takie jak SAP, Baan, Oracle, PeopleSoft, Siebel, CRM (Client Relationship Management). opr. Lech Banachowski, Krzysztof Matejewski

Relacyjne Bazy Danych Geneza Twórcą relacyjnych baz danych jest Edgar Codd. Poniżej krótka notka biograficzna zaczerpnięta z Wikipedii: Edgar Frank "Ted" Codd (ur. 23 sierpnia 1923 w Portland, Dorset, zm. 18 kwietnia 2003 w Williams Island, Floryda) - brytyjski informatyk, znany przede wszystkim ze swojego wkładu do rozwoju teorii relacyjnych baz danych. Studiował matematykę i chemię na uniwersytecie w Oksfordzie. W czasie II wojny światowej służył jako pilot w siłach powietrznych Wielkiej Brytanii (RAF). W 1948 przeniósł się do Nowego Jorku, gdzie podjął pracę dla IBM, jako programista. W 1953 r., w okresie działania komisji senatora Josepha McCarthy'ego, przeniósł się do kanadyjskiej Ottawy, skąd powrócił 10 lat później. Na uniwersytecie stanu Michigan w Ann Arbor zdobył stopień naukowy doktora z dziedziny nauk komputerowych, a następnie zamieszkał w San Jose, w Kalifornii, gdzie podjął pracę dla IBM. W latach 60. i 70. pracował nad zagadnieniami porządkowania danych - w 1970 wydał fundamentalną pracę "A Relational Model of Data for Large Shared Data Banks", w której przedstawił relacyjny model zarządzania bazami danych. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjne Bazy Danych Geneza Ku jego rozczarowaniu IBM zwlekał z praktycznym zastosowaniem zaprezentowanych rozwiązań aż do chwili, gdy konkurencyjne firmy zaczęły implementować ten model - przykładem była baza danych Oracle, opracowana przez Larry’ego Ellisona na bazie idei Codda. Codd ukuł także termin OLAP i sformułował dwanaście praw techniki online analytical processing. Wniósł również wkład w dziedzinie automatów komórkowych. W roku 1981 Codd został uhonoro- wany Nagrodą Turinga. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjne Bazy Danych Geneza Początkowo model relacyjny przyjęty został dość sceptycznie . Istniał już Integrated Data Store IDS Charlesa Bachmana powstały w oparciu o sieciowy model danych (General Electric), a także stworzony w samym IBM Information Management System, zbudowany według hierarchicznego modelu danych. Wkrótce jednak model relacyjny zrobił oszałamiającą karierę, wypierając niemal całkowicie systemy zbudowane według innych modeli danych. Dziś, pomimo istnienia modeli nowszej generacji – obiektowego i semantycznego – nadal na rynku najsilniejszą pozycję zajmują aplikacje zbudowane w oparciu o model relacyjny. Wynika to z prostoty i funkcjonalności tego modelu, oraz bardzo wysokiej jakości aplikacji wykorzystujących ten model. Obserwuje się natomiast tendencje do ewoluowania modelu relacyjnego w kierunku przejmowania pewnych cech modeli obiektowych. Mówi się tu o modelu obiektowo – relacyjnym. Zainteresowanych tym tematem odsyłam do pracy Leszka Banachowskiego i Krzysztofa Stencla „Systemy Zarządzania Bazami Danych”, wydanej przez Wydawnictwo PJWSTK. opr. Lech Banachowski, Krzysztof Matejewski

Koniec części 1 wykładu I W pierwszej części wykładu, poświęconego relacyjnym bazom danych, omówiliśmy pojęcie bazy danych , dokonaliśmy przeglądu modeli danych wykorzystywanych do budowy baz, oraz zapoznaliśmy się z historią prac nad rozwojem tej dziedziny informatyki, ze szczególnym uwzględnieniem baz relacyjnych. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjny model danych Część II Relacyjny model danych opr. Lech Banachowski, Krzysztof Matejewski

Część 2 wykładu I W drugiej części wykładu zostanie przedstawiona koncepcja relacyjnego modelu danych i podstawowe założenia dla baz danych tworzonych według tego modelu. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjny model danych Podstawowe założenia W pojęciu matematycznym relacyjna baza danych jest zbiorem relacji. Stąd historycznie pochodzi nazwa relacyjny model danych i relacyjna baza danych. W matematyce definiuje się relację jako podzbiór iloczynu kartezjańskiego zbiorów wartości. Reprezentacją relacji jest dwuwymiarowa tabela, złożona z kolumn (pól) i wierszy (rekordów). Rozszerzenie tego tematu, wraz z zarysem matematycznych podstaw modelu relacyjnego, nastąpi w kolejnych wykładach z tego przedmiotu. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjny model danych Podstawowe założenia Zgodnie z postulatami Codd’a, baza danych zbudowana według modelu relacyjnego musi spełniać poniższe warunki: Wszystkie dane (również cała struktura bazy danych) zapisane są w postaci tabel. Liczba tabel w bazie jest nieograniczona, a każda tabela ma nazwę unikalną w obszarze bazy. Liczba kolumn jest z góry ustalona (ale nie ograniczona), a nazwa każdej kolumny jest unikalna w obszarze tabeli. Z każdą kolumną jest związana jej dziedzina, określająca zbiór wartości, jakie mogą pojawić się w kolumnie. Na przecięciu wiersza i kolumny znajduje się pojedyncza (atomowa) wartość należąca do dziedziny kolumny, nie będąca ciągiem ani zbiorem. Wiersz reprezentuje jeden rekord informacji np. Osobę i nie dopuszcza się powtarzania wierszy. Abstrahujemy od kolejności wierszy (rekordów) i kolumn (pól), to znaczy, że ich dowolne zmiany nie mogą wpływać na zawartość informacji w tabeli. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Elementarny przykład Jako najprostszy przykład bazy danych, wyjaśniający istotę modelu relacyjnego, rozpatrzymy zagadnienie danych opisujących wykładowców, oraz wykładanych przez nich przedmiotów. Dane zostaną umieszczone w dwóch tabelach: tabeli przedmiotów i tabeli wykładowców. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Elementarny przykład Tabela wykładowców zawiera dane pracowników uczelni – imię, nazwisko, stopień naukowy. Każdy rekord w tabeli (a zatem i sam dydaktyk, opisywany przez ten rekord) identyfikowany jest przez dodatkowe pole Id_wykladowcy. Istotne jest więc, aby identyfikator ten jednoznacznie określał danego wykładowcę. W modelu relacyjnym nie ma bowiem innej możliwości identyfikacji wiersza, jak tylko poprzez wartości kolumn, które jednoznacznie wiersz identyfikują. Id_wykładowcy Imię Nazwisko Tytuł 237 Jan Kowalski Doktor 3245 Maciej Jankowski Docent 8976 Artur Malinowski Profesor opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Elementarny przykład Tabela przedmiotów zawiera dane przedmiotów wykładanych na uczelni – nazwę przedmiotu, jego kod oraz identyfikator wykładowcy. Wartość tego identyfikatora nie opisuje żadnej cechy przedmiotu. Reprezentuje on związek danego przedmiotu z wykładowcą, o którym informacja znajduje się w innej tabeli. Jak widać, tylko korzystając z identyfikatora, możemy rozpoznać w innej tabeli wiersz właściwego wykładowcy i odczytać o nim informacje. Istotne jest więc, aby identyfikator ten jednoznacznie określał danego wykładowcę. Nazwa_Przedmiotu Kod Id_wykładowcy Bazy danych BDA 237 Projektowanie systemów informacyjnych  PSI 3245 Technologie internetowe TIN Programowanie obiektowe POB 8976 Systemy decyzyjne SDE Automaty i gramatyki AUG opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Klucz główny i jednoznaczny Dla każdej tabeli musi być określony jednoznaczny identyfikator, nazywany kluczem głównym - jedna lub więcej kolumn, w których wartości jednoznacznie identyfikują cały wiersz. Klucz jednoznaczny (nazywany też kluczem alternatywnym, lub w skrócie kluczem) ma tę samą właściwość, co klucz główny, przy czym klucz główny jest tylko jeden, a kluczy jednoznacznych w tabeli może być wiele. W tabeli Przedmioty kluczem głównym jest Kod_Przedmiotu, kluczem alternatywnym jest NazwaPrzedmiotu. W tabeli Wykładowcy kluczem głównym jest Id_Wykładowcy. Nazwisko nie musi, a nawet nie może być kluczem! Pytania: Ile kluczy głównych może mieć tabela? Z ilu pól maksymalnie może składać się klucz główny? opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Klucz obcy Klucz obcy jest to jedna lub więcej kolumn, których wartości występują jako wartości ustalonego klucza głównego lub jednoznacznego w tej lub innej tabeli i są interpretowane jako wskaźniki do wierszy w tej drugiej tabeli. W tabeli Przedmioty kluczem obcym jest Id_Wykładowcy, którego wartości pochodzą z kolumny Id_Wykładowcy w tabeli Wykładowcy. Na przykład, wartość 237 występująca w wierszu przedmiotu "Bazy danych" tabeli Przedmioty stanowi odwołanie do wiersza w tabeli Wykładowcy, w którym są zapisane informacje dotyczące wykładowcy o nazwisku "Kowalski”. Całość informacji interpretujemy: "Przedmiot Bazy danych jest wykładany przez doktora Jana Kowalskiego” Pytanie: Ile kluczy obcych może mieć tabela? opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Pseudowartość NULL Dziedziny kolumn są rozszerzane o specjalny obiekt (pseudowartość) Null - oznaczający brak wartości – chwilowy, bądź wynikający z istoty rzeczy. Null to coś innego niż zero, czy napis o zerowej liczbie znaków. Wszystkie porównania i operacje na danych, w których argumentem jest Null dają w wyniku Null (również Null = Null). Jest to więc w efekcie trzecia wartość logiczna obok True i False. Można powiedzieć , że Null to albo True, albo False, ale co – nie wiemy. Na kolejnym slajdzie przedstawione są matryce logiczne dla funktorów NOT, AND, OR z uwzględnieniem pseudowartości logicznej Null. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Pseudowartość NULL Operator alternatywy OR Operator koniunkcji AND OR True False Null  Null AND   True False Null Operator negacji NOT NOT True False Null opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Predykaty Is Null oraz Is Not Null Ponieważ niemożności porównywania wartości ,z których jedna może być NULL (każda operacja i porównanie, w której jednym z operandów jest NULL daje w wyniku NULL), należało wprowadzić mechanizm testowania wartości NULL. Służą do tego predykaty IS NULL i IS NOT NULL. Predykaty te pozwalają stwierdzić, czy dana wartość jest Null czy nie: "X Is Null” -> True, gdy X jest Null "X Is Null” -> False, gdy X nie jest Null Ale "X = Null” -> Null dla wszystkich X !!! opr. Lech Banachowski, Krzysztof Matejewski

Koniec części 2 wykładu I W drugiej części wykładu zostały przedstawione podstawowe założenia relacyjnej bazy danych. Na elementarnym przykładzie dwóch tabel pokazany został sposób zapisu danych, wprowadzone zostały pojęcia klucza głównego i klucza obcego. Wprowadzono także pojęcie pseudowartości null. opr. Lech Banachowski, Krzysztof Matejewski

Obiekty relacyjnej bazy danych Część III Obiekty relacyjnej bazy danych opr. Lech Banachowski, Krzysztof Matejewski

Część 3 wykładu I W trzeciej części wykładu zapoznacie się Państwo z obiektami, z których zbudowana jest relacyjna baza danych, oraz z rolą, jaką pełni baza danych w systemie informacyjnym. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Więzy integralności (spójności) danych Więzy integralności (spójności ) danych, są to warunki poprawności danych w bazie. Więzy są definiowane na etapie projektowania bazy danych, a za ich przestrzeganie odpowiada system bazy danych. Więzy mogą być definiowane: Na poziomie kolumny – dla pojedynczych wartości w wierszu, np.: 0 < Wiek < 140 Na poziomie tabeli - dla kilku wartości w wierszu np.: Data_urodzenia < Data_zatrudnienia Jako więzy klucza głównego i więzy klucza jednoznacznego. Jako więzy NOT NULL. Jako reguły bardziej skomplikowane, wymagające zastosowania języka o wyższym poziomie komplikacji, np.: Suma wszystkich zarobków pracowników działu X = Fundusz płac działu X opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Referencyjne więzy integralności Szczególnym przypadkiem więzów spójności są więzy referencyjne. Ich rolą jest zachowanie zgodności pomiędzy wartościami klucza głównego tabeli, a wartościami odpowiadających mu kluczy obcych tabel powiązanych. Zagadnienie sprowadza się do stwierdzenia, że wartość klucza obcego może być albo Null (jeżeli definicja kolumny klucza obcego to dopuszcza), albo musi występować jako wcześniej wygenerowana wartość powiązanego z nim klucza głównego (lub jednoznacznego). Tak jak w przypadku pozostałych więzów integralności, za przestrzeganie opisanych nimi reguł odpowiada system bazy danych, przy czym należy zwrócić uwagę na fakt, że zgodność musi zostać zachowana w przypadku usuwania i modyfikacji powiązanych rekordów. To zagadnienie zostanie omówione w dalszej części wykładów. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Perspektywa (widok, view) Perspektywa, (widok - view) to obiekt bazy danych, nie będący tabelą, nie przechowujący danych, lecz przeznaczony do prezentacji danych w postaci tabeli. Można ją nazwać wirtualną tabelą. Perspektywa ma stanowić takie „spojrzenie na dane” , jakie w danym przypadku jest najdogodniejsze dla użytkownika, np. Przedmioty - Wykładowcy Nazwa_Przedmiotu  Wykładowca Bazy danych Kowalski Projektowanie systemów informacyjnych Jankowski Technologie internetowe Programowanie obiektowe Malinowski Systemy decyzyjne opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Perspektywa (widok, view) Zawartość zwykłej perspektywy jest na życzenie wyliczana przez system ze źródłowych tabel. Wynik działania perspektywy nie jest na stałe zapisywany w bazie danych, zapisana natomiast może zostać definicja perspektywy („przepis” na jej wykonanie). W pewnych sytuacjach wygodniej jednak jest zapisać zawartość perspektywy w bazie danych, a następnie korzystać z jej „materializacji”. Taki specjalny rodzaj perspektywy nosi nazwę perspektywy zmaterializowanej. Należy jednak pamiętać, że dane przechowywane w perspektywie zmaterializowanej zawsze są wtórne, wobec danych przechowywanych w tabelach. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Indeks Należy zdać sobie sprawę z faktu, iż relacyjny model danych jest modelem logicznym. Fizyczna struktura danych zapisanych na dysku komputera, zależna od systemu operacyjnego zawsze sprowadza się do struktury plików i katalogów (folderów). Konieczne powiązanie tych struktur rozwiązywane jest przez obiekty bazy danych nazywane indeksami. Indeks jest to dodatkowa struktura danych, umożliwiająca szybki dostęp do wierszy tabeli na podstawie wartości w określonej kolumnie lub kolumnach. Inaczej – jest to mechanizm wiążący wartości logiczne z ich adresami fizycznymi (miejscem zapisu na dysku). Np. indeks zbudowany na kolumnie Nazwisko umożliwia szybkie wyszukiwanie danych wykładowcy w oparciu o jego nazwisko. Funkcja indeksu przypomina funkcję indeksu (skorowidza) w książce. Więcej informacji na temat funkcji i budowy indeksów w Relacyjnych Bazach Danych zostanie przedstawione w przedmiotach SBD i SZBD. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Poziomy abstrakcji relacyjnej bazy danych Baza danych rozpatrywana jest na kilku poziomach abstrakcji. Poziom użytkowy – widoki na dane i programy, którymi posługuje się użytkownik. Poziom logiczny (koncepcyjny) – zbiór tabel, perspektyw i indeksów. Poziom fizyczny – zbiór plików z danymi i z indeksami. Perspektywy definiuje się na poziomie logicznym, a używa się na poziomie użytkowym; Indeksy definiuje się na poziomie logicznym, a używa się na poziomie fizycznym; Tabele definiuje się na poziomie logicznym, a używa się zarówno na poziomie użytkowym jak i fizycznym. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Poziomy abstrakcji relacyjnej bazy danych Użytkownikami poszczególnych poziomów są różne grupy użytkowników bazy danych. I tak: Poziom użytkowy wykorzystują głównie końcowi użytkownicy systemu. Poziom logiczny wykorzystuje głównie administrator danych systemu. Poziom fizyczny wykorzystuje głównie administrator bazy danych (dba). Oczywiście, projektant bazy danych definiuje i zajmuje się wszystkimi trzema poziomami. Korzystanie z poszczególnych poziomów odbywa się do pewnego stopnia w sposób niezależny. Można zmieniać położenie danych na dysku i ich zapis, bez potrzeby zmiany struktury logicznej tabel. Można zmieniać tabele, bez konieczności zmiany programów aplikacyjnych - o ile programy aplikacyjne są oparte na perspektywach a nie tabelach(!). W pierwszym przypadku mamy do czynienia z tak zwaną niezależnością fizyczną danych, w drugim z niezależnością logiczną danych. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Katalog (słownik) danych, metadane Schemat bazy danych, czyli definicje wszystkich jej obiektów (na każdym z trzech poziomów bazy danych), noszące nazwę metadane, zapisywane są w katalogu (słowniku danych). Jest to zbiór tabel i perspektyw, zawierający komplet informacji o budowie i strukturze bazy danych. Istotne jest użycie relacyjnego modelu danych w tym celu. Zatem metadane są zapisywane i przetwarzane w taki sam sposób jak zwykłe dane, a do ich eksploatacji służą te same narzędzia którymi posługujemy się przy zarządzaniu i edycji zwykłych danych. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Architektura klient - serwer Aplikacje bazodanowe składają się zwykle z co najmniej dwóch części: strony klienta - na stacji roboczej użytkownika, strony serwera – na komputerze zawierającym serwer bazy danych, czyli bazę danych wraz z jej systemem zarządzania (SZBD). Powyższe rozwiązanie (tzw. model „klient – serwer”), stosowane jest w celu fizycznego rozdzielenia aplikacji realizujących różne funkcje, charakterystyczne dla każdej ze stron, a także w celu umożliwienia równoległego dostępu do danych dla wielu użytkowników, zróżnicowanych w swoim zapotrzebowaniu na dane a także w prawach dostępu. opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Architektura klient - serwer Fizyczne maszyny (komputery) na których realizowane są poszczególne „strony” (a w zasadzie pracują aplikacje realizujące odpowiednie funkcje), mogą być dwiema sąsiednimi maszynami w układzie peer – to – peer, mogą być maszynami we wspólnej domenie, mogą być odległymi maszynami połączonymi siecią internet, w skrajnym przypadku może być to jedna maszyna, na której uruchomiono obie aplikacje. Ważny jest model działania: aplikacja klient zgłasza zamiar wykonania pewnej operacji na danych (pobrania, edycji etc.), aplikacja serwer sprawdza możliwość realizacji tej operacji (uprawnienia klienta, poprawność operacji), po czym ją wykonuje (lub nie!), a o wyniku informuje klienta. W szerszym znaczeniu to pojęcie można odnieść do każdych dwóch aplikacji, z których jedna zgłasza zapotrzebowanie na wykonanie pewnej operacji, a druga tą operację wykonuję, po czym role mogą się odwrócić! opr. Lech Banachowski, Krzysztof Matejewski

Relacyjna Baza Danych Architektura klient - serwer Funkcje aplikacji po stronie serwera bazy danych Przechowywanie i organizacja dostępu do danych. Wykonywanie instrukcji języka baz danych (język SQL). Sprawowanie kontroli nad spójnością danych. Zarządzanie zasobami bazy danych, w tym kontami użytkowników. Funkcje aplikacji po stronie klienta Kontakt z użytkownikiem (przyjazny interfejs użytkownika). Wyjaśnianie użytkownikowi stanu obliczeń, w tym błędów i sytuacji wyjątkowych. Przyjmowanie od niego zleceń na operacje, wykonywanie tych zleceń lub przesyłanie ich w postaci instrukcji języka SQL do serwera bazy danych. opr. Lech Banachowski, Krzysztof Matejewski

Postulaty Codd’a dla modelu relacyjnego baz danych Zbiór zasad, które powinny zostać spełnione przy projektowaniu zarówno Systemu Zarządzania Bazą Danych (SZBD), jak też modelu bazy danych został opublikowany przez Edgara Codde’a w artykule A Relational Model of Data for Large Shared Data Banks opublikowanym w 1970 r. Znany jest pod nazwą Postulatów Codd’a. Postulat informacyjny. Na poziomie logicznym dane reprezentowane są wyłącznie za pomocą tabel wartości. Postulat dostępu. Do każdej pojedynczej danej dostęp możliwy jest poprzez nazwę tabeli, nazwę kolumny oraz wartość (wartości) klucza głównego. Postulat obiektu null. W systemie zarządzania bazą danych (SZBD) dostępny jest specjalny obiekt null reprezentujący stan braku wartości (tj. reprezentujący wartość brakującą, nieokreśloną lub nieznaną) – różny od każdej konkretnej wartości jak 0 lub pusty napis. opr. Lech Banachowski, Krzysztof Matejewski

Postulaty Codd’a dla modelu relacyjnego baz danych Postulat struktury metadanych Informacje o obiektach bazy danych tworzących schemat bazy danych są na poziomie logicznym reprezentowane za pomocą tabel i dostępne tak jak każde inne dane. Postulat pełnego języka danych W SZBD zaimplementowany jest pełny język, obejmujący definiowanie tabel, perspektyw, więzów spójności, operowanie danymi (zarówno na poziomie interaktywnym jak też przez interfejs programistyczny), nadawanie uprawnień użytkownikom, przeprowadzanie na bazie danych operacji pogrupowanych w transakcje. Postulat modyfikowania danych poprzez perspektywy. SZBD umożliwia modyfikowanie danych przy użyciu perspektyw w sytuacji, gdy taka modyfikacja jest semantycznie sensowna. opr. Lech Banachowski, Krzysztof Matejewski

Postulaty Codd’a dla modelu relacyjnego baz danych Postulat modyfikowania danych na wysokim poziomie abstrakcji. SZBD umożliwia modyfikowanie danych za pomocą operacji, których argumentami są tabele (perspektywy) – a więc nie tylko w sposób nawigacyjny, polegający na przejściu wszystkich wierszy (rekordów) w tabeli (perspektywie). Postulat fizycznej niezależność danych. Zmiany w metodach zapisu danych i dostępu do nich nie mają wpływu na aplikację. Postulat logicznej niezależność danych. Zmiany w tabelach zachowujące informacje i poprawne semantycznie nie mają wpływu na aplikację. Postulat niezależności więzów spójności. Więzy spójności są definiowane w języku bazy danych (nie muszą być wyrażane w aplikacji). opr. Lech Banachowski, Krzysztof Matejewski

Postulaty Codd’a dla modelu relacyjnego baz danych Postulat niezależności dystrybucyjnej. SZBD (i jego język) umożliwiają używanie danych zapisanych w różnych fizycznie miejscach (w różnych węzłach sieci). Postulat zabezpieczenia przed operacjami na niższych poziomach abstrakcji. Jeżeli system umożliwia operacje na niższych poziomach abstrakcji, nie mogą one naruszać relacyjnego modelu danych (w tym nie mogą omijać ograniczeń określonych przez więzy spójności). opr. Lech Banachowski, Krzysztof Matejewski

Podsumowanie Wykładu I W tym wykładzie zapoznali się Państwo z pojęciem bazy danych, z kilkoma modelami danych, zarówno historycznymi z dzisiejszej perspektywy rozwoju technologii, jak też modelami współcześnie używanymi i rozwijanymi. Szczególną uwagę poświęciliśmy modelowi relacyjnemu, omówieniu jego podstawowych cech i struktur. W kolejnych wykładach zagadnienia dotyczące tego modelu będą rozwijane i uszczegółowiane. opr. Lech Banachowski, Krzysztof Matejewski

Do zobaczenia na wykładzie II Koniec wykładu I Do zobaczenia na wykładzie II opr. Lech Banachowski, Krzysztof Matejewski

Do zobaczenia na wykładzie II Koniec wykładu II Do zobaczenia na wykładzie II opr. Lech Banachowski, Krzysztof Matejewski