| Relacyjny model danych |
|---|
| Napisane przez Mon 04 Dec 2006 przez Artur (2471 cztane) |
|
Relacyjny model danych Tworząc ten model E. F. Codd, chciał położyć kres wadom w istniejących modelach, których źródło dostrzegał w niezdyscyplinowanym traktowaniu danych. Zastosowanie ścisłych metod i teorii zbiorów przyczyniło się do osiągnięcia postawionego celu . Tak jak wcześniej wspomniałem i ten model danych charakteryzowany jest przez trzy podstawowe reguły. Struktura danych Model relacyjny oferuje jedną strukturę reprezentowania danych, jest nią tabela dwuwymiarowa, nazywana relacją. Jako że, za zdyscyplinowany sposób na traktowanie danych odpowiadają matematyczne zasady, każda tabela przestrzega ściśle określone normy. Tabele oraz występujące w nich kolumny cechują się między innymi jednoznaczną nazwą. Oczywiste wydawać się powinno że same nazwy tabel jak i kolumn oddają znaczenie umieszczanych w nich danych. Poszczególne wartości kolumn charakteryzują się również tym samym typem zawartych wartości i można dodać że każdy z nich należy do tej samej dziedziny (która definiuje zbiór atomowych wartości). Sam przekaz informacji w relacji wydaje się być intuicyjny. Ewentualne sortowanie wierszy, kolumn, jest dozwolone, co wynika, podobnie jak i inne zasady z definicji zbiorów matematycznych, że uporządkowanie elementów zbioru nie jest istotne. Integralność danych Słowo integralność dotyczy tu niczego innego jak dobrego odzwierciedlenia obszaru analizy. Poprawne odzwierciedlenie danych ze świata rzeczywistego wydaje mi się tak oczywiste, że nie będę tu wyliczał błędów powstałych przez brak jego przestrzegania. Mało tego pewien nie integralny stan bazy danych może po prostu nie mieć sensu. Model relacyjny całkiem przejrzyście wyraża zasady przestrzegania integralności. Klucze główne oraz obce to najprościej nazywane pojęcia wyrażające pożądany tu rezultat. Klucz główny relacji wybieramy spośród kluczy kandydujących, które spełniają tu warunek jednoznacznego określenia wiersza w kolumnie, dodam tu również że wartość null taką nie jest . Wybrany klucz główny może przyjąć postać jednej bądź kilku kolumn za pośrednictwem czego spełnia swoje zadanie. I tak rysunek 1 zawiera kolumnę o nazwie ID która mogłaby być kluczem głównym. Klucz obcy natomiast jest rozwiązaniem na łączenie danych przechowywanych w różnych tabelach. I podobnie jak klucz główny składać się może z jednej lub grupy kolumn, które służą nam tu jako wartość odwołania do powiązanej tabeli. Operowanie danymi Naturalnie rozumując, chyba najbardziej istotnym faktem dla właściciela danego zbioru informacji jest operowanie nimi. Jak wstawiać, usuwać, edytować, wyszukiwać dane w odpowiedniej relacji ? W modelu relacyjnym istnieje szereg pojęć i przynależne im zbiory rozwiązań na odpowiedź do zadanych pytań. Pierwsze rozwiązania to algebra i rachunek relacyjny. Są one alternatywnymi teoriami a zasadniczą różnicą jest, że algebra dostarcza zbioru jawnych operacji dostarczania wyników podczas gdy rachunek daje notację do formułowania definicji dostarczania tych relacji. Twórca modelu relacyjnego zdefiniował dwie grupy operatorów, które sumarycznie w ilości ośmiu podlegają tzw. algebrze relacyjnej. Pierwsza grupa mieści tradycyjne operatory: suma (wynikiem jest suma krotek wskazanych relacji), przecięcie (wynik zawiera jedynie krotki wspólne dla podanych relacji), różnica (w wyniku krotki występujące w pierwszej ale nie w drugiej z podanych relacji) oraz iloczyn kartezjański (wynikiem jest relacja składająca się z wszystkich możliwych krotek na którą składają się dwie relacje jako argumenty). Druga gromadzi specjalne operatory: wybór (w wyniku otrzymujemy relację składającą się z kompletnych w wartości krotek spełniających określone warunki), rzut (w wyniku otrzymujemy relację z wybranymi kolumnami), złączenie (wynikowa relacja zawiera wszystkie możliwe krotki z podanych jako argumenty ale wykluczając powtarzające się kolumny) oraz iloraz (podane relacje, binarna i unarna, są tak traktowane że w wynikowej relacji znajduje się tylko kolumna zawierająca wartości wspólne dla argumentów). Rachunek relacyjny w przeciwieństwie do algebry, opisuje jaki jest problem, co w wyniku daje rozwiązanie. U podstaw rachunku leży tzw. rachunek predykatów. Innymi słowy Codd wykorzystał rachunek predykatów i dostosował go do potrzeb baz danych. Wyróżnić tu można pewne warianty rachunku relacyjnego, jeden operujący na krotkach oraz drugi operujący na dziedzinach. Owe rozróżnienie znalazło swoją implementację w dwóch językach SQL (rachunek na krotkach) oraz QBE (rachunek na dziedzinach). W tej części pracy nie będę poszerzał tych obszernych zagadnień. Cechy nieproceduralności jakie oferował rachunek relacyjny zostały niezmiernie docenione, tyle że trudność w zrozumieniu przyczyniła się do powstania SQL. Klasę programów, w której mieści się SQL nazwano językami transformacji. Jest to klasa języków nieproceduralnych, które zawierają proste w użyciu struktury pozwalające opisać oczekiwany wynik w oparciu o posiadane dane. SQL pozwala tworzyć bazę danych i struktur relacji oraz zarządzać danymi . To zwięzłe opisanie relacyjnego modelu danych, pośrednio przybliża tematykę relacyjnych systemów zarządzania bazą danych. Powyżej znajdujące się streszczenie modelu nie zastąpi ponad 30 letniego stażem, tematu - nauki i pracy. Ale nie taki jest temat tej pracy a moim zadaniem w tej części jest natomiast jak najlepiej wyszczególnić wady i zalety relacyjnego modelu danych, co w konsekwencji przyczyni się do wyboru najodpowiedniejszego modelu danych podczas projektowania bazy danych. Nieodłączną cechą w procesie tworzenia relacyjnych baz danych jest normalizacja co w konsekwencji przyczynia się rozbicia rzeczywistych obiektów pomiędzy wiele relacji. Takie rozbicie wpływa szkodliwie na odzwierciedlenie rzeczywistych obiektów w bazie danych. Semantyka encji i związków jest nie tyle że nie dopracowana ale ten problem jest po prostu nie rozwiązany. Co prawda wyróżniamy tu klucze, dziedziny oraz zależności funkcyjne, wielowartościowe i złączeniowe które zawierają informacje semantyczne. Ale mimo tego nie istnieje mechanizm pozwalający na odróżnienie encji od związków oraz występujących rodzajów związków pomiędzy encjami. Kwestia przestrzegania poprawności danych (integralność) również pozostawia tu wiele do życzenia. Więzy ogólne z którymi się często w praktyce spotykamy tu w relacyjnym modelu danych nie mają miejsca. Integralność encji oraz integralność referencyjna mimo swojego bytu w modelu, widocznie stwarza pewne trudności w systemach komercyjnych, gdyż nie w pełni są realizowane. Rzeczywiste obiekty z natury są bardziej złożone niż prosty sposób ich przedstawienia w krotkach relacji. Model relacyjny ujmuje w sposób jednorodny zawartość wierszy oraz relacji, gdzie na przecięciu wierszy i kolumn znajdują się tzw. wartości atomowe. Jednorodność zakłada, że wiersze relacji mieszczą te same atrybuty natomiast jednorodność kolumn, że wartości w każdej kolumnie muszą zawierać się w tej samej dziedzinie. Język SQL sam w sobie nie umożliwia definiowania nowych operacji co w konsekwencji sprowadza się do ograniczonego zestawu operacji. Atomowość, czyli brak możności przedstawienia atrybutów wielokrotnych, o której wspomniałem ma również swój negatywny wpływ na obliczanie wyników zapytań dotyczących związków relacji z samą sobą. Oczywiście, odpowiednia implementacja w aplikacjach, osadzenie SQL w języku programowania wysokiego poziomu zaradza niedostatkom modelu danych, co niestety przyczynia się do zwiększenia kosztów nakładu pracy. Tak jak wspomniałem wcześniej, dzisiejsza inżynieria oprogramowania ma ambicję przyjmować ciężar tworzenia zaawansowanych systemów, u których podstaw działania leży baza danych. I mam nadzieję że wyżej wymienione cechy relacyjnego modelu danych pozwolą mi dokonać później właściwego wyboru. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.