Agnieszka Ptaszek Michał Chojecki
Krótka historia Twórcą teorii relacyjnych baz danych jest Edgar Frank Codd. Postulaty te zostały opublikowane po raz pierwszy w 1970 roku w pracy A Relational Model of Data for Large Shared Data Banks. Praca ta opisuje podstawowe zależności jakie mogą występować pomiędzy danymi trwałymi, oraz wprowadza główne założenia dotyczące modelu relacyjnego dla danych wraz z propozycją formalnych operatorów przeszukiwania danych. W 1972 roku, w pracy pt. Relational Completeness of Data Base Sublanguages Codd uszczegółowił opis modelu oraz przedstawił dwa modele formalne odpytywania (przeszukiwania) danych. Tu właśnie po raz pierwszy pojawiły się terminy algebra relacji oraz rachunek relacyjny. Codd pokazał, że oba modele są równoważne. EDGAR FRANK CODD
Krótka historia Jednym z kluczowych problemów rozwijającego się modelu relacyjnego było podejście do brakującej informacji (np. nieznany numer telefonu, brak numeru mieszkania itp.). Początkowo proponowano kilka specjalnych wartości, które użytkownik mógłby wykorzystać do zaznaczenia takich informacji. Jednak w ostateczności, w 1979 roku, Codd wprowadził do modelu pojedynczą specjalną wartość NULL. Wprowadzenie tej wartości wiązało się m.in. z rozszerzeniem logiki dwuwartościowej operatorów porównania do logiki trójwartościowej (na każde pytanie o równość można odpowiedzieć Tak, Nie, Nieznane ).
Teoria relacyjna, Model ER oraz relacyjny Projekt każdej relacyjnej bazy danych, rozpoczyna etap konceptualny (abstrakcyjny), opierając się o model E-R (Entity-Relationship Model), którego autorem jest dr. Peter Chen. Jest to opis czysto teoretyczny, wymagający przełożenia na język praktyki. Ma on na celu, opisanie fragmentu rzeczywistości za pomocą związków encji. W tym modelu używamy definicji, które mają swoje odzwierciedlenie na późniejszym etapie wdrożenia projektu w życie.
Model relacyjny Model relacyjny definiuje: sposób reprezentowania danych (strukturę), metodę ich zabezpieczania (integralność danych), operacje, które mogą być na nich wykonywane (manipulowanie danymi). Relacyjna baza danych Relacyjną bazę danych można określić jako parę złożoną z następujących składników: zbioru tabel, których wiersze opisują obiekty lub związki występujące w modelowanym świecie, zbioru zależności semantycznych, które opisują ogólne prawidłowości (zasady, reguły) występujące w modelowanym wycinku rzeczywistości.
Teoria relacyjna Model ER Relacyjne bazy Aplikacje Relacja Encja Tabela Klasa Krotka Instancja Wiersz Rekord Atrybut Atrybut Kolumna Pole Dziedzina Dziedzina/Typ Typ danych -
BAZA DANYCH Zgodnie z modelem E-R, baza danych to inaczej zbiór schematów RELACJI i ZWIĄZKÓW między nimi, czyli struktur służących do przechowywania danych w ściśle zorganizowany sposób. W praktyce będzie to zawsze zbiór tabel, w których przechowywane są dane. Ponadto tabele, posiadać będą określone powiązania (relacje) między sobą.
Relacja W modelu E-R, to po prostu TABELA czyli struktura, przechowująca informacje o obiektach określonego typu. Używając języka programistów KLASA obiektów określonego typu. KLASA ENCJI, RELACJA (Model ER) = TABELA (RDBMS) = KLASA (języki obiektowe)
Przykład relacyjnej bazy danych
Tabela (inaczej encja, klasa obiektów, relacja) to podstawowa struktura modelowania niezależnych, odrębnych obiektów, o których informacje chcemy przechowywać w bazie. Każda tabela powinna przechowywać informacje jedynie o ściśle określonych obiektach konkretnego typu. Na przykład informacje dotyczące pracowników (tabela Pracownicy), albo tylko samochodów, zamówień, produktów itp. każda typ = nowa tabela. Informacje w ramach tabeli, powinny być więc jednorodne ze względu na typ obiektu którego dotyczą.
ATRYBUT ATRYBUT w praktyce, to nic innego jak KOLUMNA. Zatem tłumacząc na model relacyjny, każda TABELA opisana jest za pomocą zbioru KOLUMN. Każda KOLUMNA jest ściśle określona TYPEM DANYCH, czyli przechowuje wartości jednorodne, z określonej DZIEDZINY (tego samego typu np. liczby, znaki, daty etc). Nazwa kolumny w ramach tabeli musi być unikalna, bo silnik musi jednoznacznie wiedzieć do którego atrybutu będziemy się odnosić.
Każda RELACJA jest opisana za pomocą zbioru ATRYBUTÓW. Każdy z ATRYBUTÓW należy do określonej DZIEDZINY, czyli może przyjmować określone wartości (np. liczbowe, tekstowe, daty etc.) oraz posiada unikalną w ramach RELACJI nazwę.
ATRYBUTY danej RELACJI, tworzą zbiór nieuporządkowany. Ich kolejność w teorii nie ma żadnego znaczenia. Sami decydujemy które z nich są w danym momencie dla nas istotne i w jakiej kolejności chcemy je zobaczyć (SELECT).
Schemat relacji Informacja o strukturze, ATRYBUTACH które opisują daną RELACJĘ. W praktyce będzie to struktura tabeli czyli informacja przez jakie kolumny, jakiego typu jest ona opisana. Mówimy więc o specjalnym typie informacji. Schematy relacji to tzw. metadane czyli informacje o strukturach w bazie danych.
KROTKA To pojedynczy egzemplarz, czyli obiekt opisany wszystkimi ATRYBUTAMI danej RELACJI. KROTKA to nic innego jak WIERSZ czy REKORD.
Każda tabela to zbiór wierszy. Zgodnie z matematyczną teorią zbiorów, każdy z definicji jest nieuporządkowany. Stąd każda tabela to zbiór elementów (wierszy) w którym zakładamy, że kolejność nie jest ustalona. W praktyce może być wymuszona np. przez klucz podstawowy czy mechanizmy składowania danych, ale w rozważaniach i działaniach musimy zawsze patrzeć przez pryzmat teorii. W celu uporządkowania wierszy, należy to określić w zapytaniu (np. sortowanie przez ORDER BY). Teoria zbiorów, mówi o jeszcze jednej bardzo ważnej zasadzie. Braku duplikatów w zbiorze.
Klucze Klucze to zbiory atrybutów mających określoną właściwość. Dzięki nim, możemy jednoznacznie identyfikować każdy pojedynczy wiersz. Znajomość pojęć kluczy podstawowych i obcych jest niezbędna do tworzenia zapytań, odwołujących się do wielu tabel.
KLUCZ PODSTAWOWY (PRIMARY KEY) To wybrany (zazwyczaj najkrótszy), jednoznacznie identyfikujący każdy, pojedynczy wiersz, zbiór atrybutów (kolumn) danej relacji (tabeli). Jest to klucz, który ma faktyczne, fizyczne odwzorowania w implementacji bazy danych. Każda tabela może mieć tylko jeden taki klucz. W praktyce, będzie to najczęściej jedna lub dwie kolumny w tabeli, jednoznacznie (UNIKALNIE) identyfikujący każdy wiersz. Nie można stworzyć klucza podstawowego, na zbiorze atrybutów nieunikalnych. Dwa wiersze nie mogą mieć takiej samej wartości klucza podstawowego.
Klucz kandydujący Polem klucza nazywamy pole lub pewną liczbę pól, które spełniają następujące własności: nie zawierają powtarzającej się wartości (unikatowość), nie zawierają wartości NULL, żaden podzbiór (właściwy) pól tworzących pole klucza nie jest kluczem (nieredukowalność). Tabela może zawierać więcej niż jeden klucz.
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.
To atrybut lub zbiór atrybutów, wskazujący na KLUCZ GŁÓWNY w innej RELACJI (tabeli). Klucz obcy to nic innego jak związek, relacja między dwoma tabelami. Cecha dobrego klucza głównego (możliwie krótki) tutaj staje się klarowna. W tabeli powiązanej kluczem obcym, trzeba powielić tą strukturę (zbiór atrybutów) aby móc jednoznacznie wiązać rekordy z dwóch tabel. Definicja klucza obcego, pilnuje aby w tabeli powiązanej, w określonych atrybutach, znaleźć się mogły tylko takie wartości które istnieją w tabeli docelowej jako klucz główny. Klucz obcy może dotyczyć również tej samej tabeli.
Powiązania pomiędzy tabelami (związki między relacjami) W praktyce spotkać możemy trzy fundamentalne związki między tabelami. Dzięki nim, możemy zapewnić integralność referencyjną danych i zamodelować odpowiednią logikę naszej struktury. Abstrahując od szczegółowej analizy wszystkich rodzajów związków jakie są możliwe w modelu E-R, skupimy się tylko na binarnych czyli dwuargumentowych. Wiedzę o ich istnieniu i sposobie modelowania wykorzystać można chociażby w pisaniu zapytań do wielu tabel.
ZWIĄZEK 1:1 (jeden do jeden) Każdy wiersz z tabeli A może mieć tylko jednego odpowiednika w tabeli B (i na odwrót). Ten rodzaj relacji może być postrzegany jako podzielenie tabeli na dwie (bo relacja jest jeden do jeden). Stosowany np. wtedy, gdy zbiór dodatkowych atrybutów jest określony tylko dla wąskiego podzbioru wierszy w tabeli podstawowej.
Innym zastosowaniem związku 1:1, jest wydzielenie pewnej grupy atrybutów które są rzadko odpytywane. Mogą być, więc umiejscowione w tabeli przechowywanej na osobnym wolniejszym, nośniku danych. Kolejny scenariusz to dodatkowa ochrona części atrybutów określonego typu (np. informacji wrażliwych takich jak wynagrodzenie, preferencje etc.). Wydzielając je do osobnej tabeli, możemy zapewnić dodatkowy poziom zabezpieczeń (dostęp, szyfrowanie), inną politykę backupową etc..
Związek jeden do wielu Jest to najczęściej spotykana relacja. Określamy w niej że każdy element ze zbioru A (wiersz tabeli A), może być powiązany z wieloma elementami zbioru B.
ZWIĄZEK N:M (wiele do wielu) Realizowana jest zawsze jako dwie relacje 1:N. Zatem jeśli chcemy między dwoma tabelami zamodelować związek N:M potrzebujemy trzecią tabelę łącznikową.
Algebra relacyjna Operatory relacyjne: selekcji - wybór krotek spełniających określone warunki - podzbiór poziomy projekcji - określenie relacji do wybranych atrybutów - podzbiór pionowy połączenia - łączenie krotek wielu relacji klasyczne operatory teorii mnogości: suma mnogościowa, iloczyn kartezjański itp.
Operacje relacyjne: Połączenie - Operacja połączenia polega na scaleniu odpowiednich krotek (rekordów) 2 różnych relacji pod warunkiem spełnienia warunku logicznego nałożonego na atrybuty połączeniowe. Warunkiem - równość atrybutów w obu relacjach suma relacji połączenie dwóch zestawów rekordów różnica relacji - dwóch zestawów rekordów to rekordy należące do jednego zestawu, ale nie do drugiego iloczyn kartezjański- umozliwia konkatenację krotek 2 relacji lub więcej, w taki sposób, że każda krotka pierwszej relacji jest łączona z każdą krotką drugiej relacji Na 3 pierwszych operacjach: selekcji, projekcji i połączeniu opiera się tzw. język manipulowania danymi, umożliwiający użytkownikom baz danych dokonywanie przekształceń relacji, wynikających z potrzeb.
KORZYŚCI Relacyjne bazy danych wprowadziły następujące ulepszenia w stosunku do hierarchicznych i sieciowych baz danych: - Prostota. Podejście bazujące na tabelach z wierszami i kolumnami jest niezwykle proste i łatwe do zrozumienia. Końcowi użytkownicy mają prosty model danych. Złożone diagramy, wykorzystywane w przypadku hierarchicznych i sieciowych baz danych, nie występują w przypadku relacyjnych baz danych.
KORZYŚCI - Niezależność danych. Niezależność danych pozwala na modyfikowanie struktury danych bez wpływu na istniejące programy. Jest to możliwe głównie dlatego, że tabele nie są ze sobą połączone na sztywno. Do tabel mogą być dodawane kolumny, tabele mogą być dołączane do bazy danych, a nowe relacje mogą być tworzone bez konieczności wprowadzania istotnych zmian do tabel. Relacyjne bazy danych dostarczają dużo wyższy poziom niezależności danych, niż hierarchiczne i sieciowe bazy danych.
KORZYŚCI - Deklaratywny język dostępu do danych. Dzięki wykorzystaniu języka SQL, użytkownik określa jedynie warunki odnośnie poszukiwanych danych, system natomiast zajmuje się pobraniem danych spełniających żądanie. Nawigacja w bazie danych jest ukryta przed użytkownikiem końcowym, w odróżnieniu od języka DML w systemie CODASYL, gdzie użytkownik musi znać wszelkie szczegóły określające ścieżkę dostępu do danych.
Wady relacyjnego modelu danych w procesie modelowania tracimy informację o tym, że w świecie rzeczywistym istnieją dwa identyczne obiekty. Jest to konsekwencją jednej z głównych zasad relacyjnego modelu baz danych, która mówi, iż w relacji nie mogą wystąpić dwie takie same krotki. A zatem przy ustalonym zestawie atrybutów nie jest możliwe wpisanie dwóch rekordów o tej samej wartości. Rozwiązaniem tego problemu jest konieczność zwiększenia liczby atrybutów. sztuczny język opisu rzeczywistości są nim dwuwymiarowe tabelki trudności w przechowywaniu informacji zmiennych w czasie, trudności w przechowywaniu informacji niepełnej, problemy z przechowywaniem dużych obiektów
Przykładowe zastosowanie SYSTEM INFORMACJI GEOGRAFICZNEJ (GIS, ang. Geographic Information System) GIS-y służą gromadzeniu, analizie i wizualizacji danych przestrzennych opisujących nasz świat i zachodzące w nim zjawiska. Zwizualizowane za pomocą wykresów, infografik i symboli dane są dużo łatwiejsze w odbiorze i stanowią nieocenioną pomoc przy podejmowaniu decyzji biznesowych lub zarządzaniu siecią rozproszonych obiektów i pracowników. Systemy GIS opierają się o złożone bazy danych, wymagają więc zaawansowanej infrastruktury IT.
DZIĘKUJEMY ZA UWAGĘ