PODSTAWY BD

 BAZY DANYCH – MINI PRZEWODNIK

 


Bazy danych – podstawowe definicje.

Właściwości baz danych.

Bazy danych

Obecnie bazy danych, coraz częściej wykorzystywane w informatyce, stanowią niejednokrotnie podstawę funkcjonowania firm, stron internetowych, systemów zarządzania treścią, instytucji rządowych i badań naukowych. Bazy danych znajdują zastosowanie tam, gdzie zachodzi potrzeba gromadzenia dużych ilości danych, ich przechowywania, szybkiego porównywania, sortowania czy wyszukania wyników.

Baza danych jest zbiorem danych oraz narzędzi systemu DBMS (Database Management System — System Zarządzania Bazą Danych, SZBD) przeznaczonego do zarządzania bazą danych oraz gromadzenia, przekształcania i wyszukiwania danych.

Baza danych to zbiór danych, który dotyczy rzeczywistości – a konkretnie określonego jej fragmentu, który reprezentuje. Fragment ten określamy mianem obszaru analizy.

Baza danych ma takie cechy charakterystyczne, jak:

  • Trwałość danych – oznacza możliwość przechowywania danych w pamięci masowej (trwałej) komputera. Dane tymczasowe mogą być przechowywane w pamięci komputera i tracone po jego wyłączeniu.
  • Niezależność danych – pozwala osiągnąć większą elastyczność, ponieważ programy wymieniające informacje z bazą danych są niezależne od przechowywania danych na dysku i szczegółów reprezentacji danych na dysku. Niezależność dotyczy również posługiwania się danymi. Użytkownicy są zabezpieczeni przed logicznymi zmianami (program obsługujący bazę danych jest zabezpieczony przed modyfikacją struktury tabel bazy danych). DBMS – gwarantujący niezależność fizyczną – przejmuje na siebie zadanie określenia, w jakim formacie i jak dane będą przechowywane na dysku.
  • Ochrona danych – baza danych oferuje mechanizmy kontroli dostępu do danych w sposób umożliwiający użytkowanie danych wyłącznie przez uprawnionych do tego użytkowników.
  • Integralność danych – zgodność z rzeczywistością. Dane w bazie danych są odwzorowaniem rzeczywistości. Jeśli modelowany fragment rzeczywistości ulegnie zmianie, baza danych również musi się zmienić.
  • Część intensjonalna – inaczej schemat bazy danych – to zbiór definicji powstających w trakcie projektowania bazy danych określający strukturę danych. Schemat tworzy encje (klasy) oraz właściwości klas – atrybuty.
  • Część ekstensjonalna – to łączny zbiór danych w bazie danych.

   System zarządzania bazą danych SZBD (DBMS – Database Management System) obsługuje użytkowników bazy danych, umożliwiając im eksploatację oraz tworzenie baz danych. By stworzyć i zaprojektować bazę danych, należy ją zdefiniować, a do tego konieczne jest określenie (zdefiniowanie) typów przechowywanych w niej danych. Istotną rolę odgrywa również wyznaczenie użytkowników oraz ich praw dostępu.

SZBD pełni funkcje, które określane są mianem właściwości baz danych. Zaliczamy do nich:

  • tworzenie struktur baz danych,
  • wykonywanie operacji CRUD (Créate, Read, Update, Delete),
  • obsługa zapytań (selekcjonowanie danych),
  • generowanie raportów i zestawień,
  • administracja bazą danych.

Bazy danych – struktura

Tworzenie struktur baz danych

Aby utworzyć strukturę bazy danych, należy posłużyć się wcześniej sporządzonym projektem. Struktura to szkielet bazy danych, przeniesienie koncepcji tabel, powiązań na obszar systemu zarządzania bazą danych. Strukturę bazy danych możemy utworzyć po podłączeniu do serwera bazy danych. Na taką strukturę składają się: tabele, widoki, powiązania pomiędzy tabelami, domeny, funkcje. W SZBD PostgreSQL strukturę bazy danych możemy poznać, oglądając menu programu pgAdminlll.

 


Elementy struktury bazy danych widoczne na ilustracji to: tabele, funkcje, widoki, wyzwalacze, domeny, funkcje wyzwalaczy, indeksy, ograniczenia (w tym powiązania pomiędzy tabelami), czyli wszystko to, co stanowi logiczną organizację danych. 

Kolejną właściwością bazy danych jest przeprowadzanie operacji CRUD (zapisu, odczytu, aktualizacji i usuwania). Może zajść potrzeba modyfikowania tabel, widoków oraz aktualizacji danych przechowywanych w tabelach. Baza danych powinna być tak zaprojektowana, by wykonywanie aktualizacji na danych, usuwanie danych czy wprowadzanie nowych informacji do bazy danych nie spowodowało utraty spójności. Spójność bazy danych to poprawność umieszczonych w niej informacji.

Baza danych powinna mieć mechanizmy umożliwiające uzyskanie szybkiego dostępu do danych i ich selekcjonowanie. W relacyjnych bazach danych do uzyskiwania dostępu do danych służą zapytania. Zapytania to instrukcje napisane przeważnie w języku SQL.

Oprócz uzyskania dostępu do informacji i danych, ich sortowania, selekcjonowania i przeszukiwania baza danych powinna oferować mechanizmy umożliwiające drukowanie wykazów czy zapisywanie ich poza bazą danych. Funkcje takie spełniają raporty i zestawienia, które mogą być generowane z baz danych.

Baza danych powinna umożliwiać administrację swoimi zasobami. Administracja może mieć charakter nie tylko projektowania i implementowania, lecz także optymalizacji i dostosowywania do potrzeb użytkowników.

SPRAWDŹ SWOJĄ WIEDZĘ

  1. Co to jest baza danych?
  2. Wymień przykłady zastosowania baz danych.
  3. Podaj cechy bazy danych.
  4. Jaka jest różnica między częścią intensjonalną a ekstensjonalną bazy danych?

Modele danych

Modele danych

  • Definicja modelu danych
  • Modele danych: model jednorodny, hierarchiczny model danych, sieciowy model danych, model relacyjno-obiektowy, obiektowy model danych, relacyjny model baz danych
  • Rozproszona baza danych 

Model danych to zintegrowany zbiór zasad opisujących dane, relacje, powiązania (stosunki) pomiędzy danymi, dozwolone operacje i ograniczenia nakładane na dane i operacje.

Model danych jest próbą reprezentacji świata realnego i występujących w nim obiektów, zdarzeń oraz związków zachodzących między nimi. Można go opisać jako konstrukcję składającą się z trzech komponentów:

  • części strukturalnej – składającej się z reguł określających budowę bazy danych;
  • części manipulacyjnej – określającej, które operacje (transakcje) aktualizacji, pobierania i zmiany struktury można wykonywać na danych;
  • części zawierającej reguły integralności – gwarantującej stabilność działania systemu.

Model jednorodny – to model, w którym wszystkie dane są umieszczone w jednej tabeli, jednym arkuszu (pojedynczy arkusz – tabela z danymi może przechowywać duplikaty. Jeśli będzie to np. wypis sprzedanych towarów, wówczas dany towar, który został sprzedany kilkakrotnie, będzie duplikowany w kolejnych wierszach.) (kostce analitycznej). Przykładem takiego modelu jest książka telefoniczna. Cechuje go łatwość i szybkość odczytywania danych. Jego wadą jest duża liczba duplikatów, takich jak pamięć dyskowa czy operacyjna, które mogą się pojawiać i tym samym zwiększyć zużycie zasobów komputera. Dane w modelu jednorodnym nie zawsze będą łatwe do odnalezienia. Gdyby jednorodny model danych prezentować na przykładzie książki telefonicznej, to łatwe byłoby odnalezienie numeru telefonu na podstawie imienia i nazwiska, jednak wyszukanie imienia i nazwiska na podstawie numeru telefonu stwarzałoby problem. Książka telefoniczna zawiera dane ułożone alfabetycznie wg kolejności nazwisk. Dlatego nie jest zoptymalizowana pod kątem przeprowadzania wyszukiwania, w którym dysponujemy numerem, a potrzebujemy odszukać imię i nazwisko. W modelu jednorodnym dane mogą być duplikowane. Dzieje się tak właśnie ze względu na strukturę tego modelu. Na przykład, gdyby w Warszawie mieszkało 50 osób o nazwisku Nowak i każda z nich miała telefon, wówczas w jednorodnym modelu danych otrzymalibyśmy pięćdziesiąt duplikujących się nazwisk w kolejnych wierszach, różniących się adresami i numerami telefonów, przy czym nazwisko byłoby wielokrotnie powtórzone.

Hierarchiczny model danych

Początki sięgają 1960 r., gdy rozpoczęto prace nad projektami IDS (Integrated Data Store) oraz MIS (Management Information System). MIS rozwijany był przez IBM w ramach projektu kosmicznego Apollo. Hierarchiczny model bazy danych pod względem modelu przypomina strukturę odwróconego drzewa:

  • jeden korzeń (tabela nadrzędna)
  • synowie (tabele podrzędne).

Ojciec może mieć wiele dzieci, ale każde dziecko ma tylko jednego ojca.

Każdy rekord (z wyjątkiem głównego, który jest na szczycie) powiązany jest z jednym rekordem nadrzędnym. Model hierarchiczny opiera się zatem na dwóch strukturach danych – typach rekordów i związkach nadrzędny-podrzędny. Powiązanie nadrzędny-podrzędny to związek „jeden do wielu” pomiędzy dwoma typami rekordów. Model ten różni się od relacyjnego, ponieważ w modelu relacyjnym powiązania zachodzą przez klucze obce, a w hierarchicznym przez związek nadrzędny-podrzędny. W hierarchicznym modelu danych nie można wstawić rekordu podrzędnego, dopóki nie zostanie powiązany z nadrzędnym. Usunięcie rekordu nadrzędnego powoduje automatycznie usunięcie wszystkich rekordów podrzędnych.

Sieciowy model

Został ustandaryzowany w 1969 r. przez CODASYL (Conference on Data Systems Languages). Jego twórcą jest Charles Bachman i mimo że nie znalazł szerszego zastosowania, to przyczynił się do powstania relacyjnego modelu baz danych. Sieciowy model przyjmuje, podobnie jak hierarchiczny, strukturę przypominającą odwrócone drzewo z tą różnicą, że gałęzie jednego drzewa mogą być wspólne z gałęziami innych drzew.

Sieciowy model oparty jest zatem na dwóch strukturach danych:

  • typ kolekcji jest opisem związku „jeden do wielu” pomiędzy dwoma typami rekordów,
  • typ rekordów ma swój odpowiednik w modelu hierarchicznym, jednak pola są w stanie przechowywać złożone wartości, które mogą się powtarzać

 Model relacyjno-obiektowy

Model relacyjno-obiektowy

Jest mieszanym modelem bazodanowym, a jego zastosowanie jest bardziej powszechne niż w przypadku modelu obiektowego. Dzieje się tak ze względu na trudną implementację i niezadowalającą wydajność (w niektórych zastosowaniach) typowego modelu obiektowego. Model ten pozwala w relacyjnych tabelach tworzyć kolumny, w których przechowywane są dane typu obiektowego, pozwala na definiowanie zmiennych oraz metod, które będą wykonywane na danych wprowadzanych do obiektu.

Obiektowy model danych

Opiera się na koncepcji obiektów (podobnie jak w projektowaniu obiektowym – obiekt jest odwzorowaniem rzeczywistości lub abstrakcji). Odwołania do określonego obiektu w tym modelu bazy danych są wykonywane za pomocą interfejsu, dzięki któremu są zachowane integralność i bezpieczeństwo danych. Obiektowe bazy danych korzystają z obiektowego języka zapytań OQL (Object Query Language). Każdy obiekt ma zaprojektowany interfejs określający metody dostępu do niego. Obecnie coraz popularniejszy staje się standard JDO (Java Data Object) stworzony przez firmę Sun Microsystems. W ramach tego standardu rozwinął się obiektowy język zapytań JDOQL (Java Data Object Query Language). Dość powszechnym niekomercyjnym i relacyjnym systemem baz danych mającym obiektowe rozszerzenie jest PostgreSQL.

Obiektowe bazy danych do przechowywania danych używają obiektów posiadających swoją tożsamość (tożsamość obiektu – identity – która wyznacza jego identyfikator). W obiektowej bazie danych nie może być dwóch identycznych obiektów o identycznych identyfikatorach. Obiekty charakteryzujące się tymi samymi metodami i atrybutami są instancjami tej samej klasy stanowiącej dla nich model. Zwykle fragmentem definicji klasy są atrybuty, które w rozumieniu obiektowego modelu danych odpowiadają atrybutom (kolumnom) relacyjnej bazy danych. Podobnie jak w programowaniu obiektowym, klasy mają przypisane funkcje nazywane metodami, działające w obrębie obiektu. Obiektowy model danych zawiera również koncepcję hermetyzacji, hierarchii klas i dziedziczenia.

Hermetyzacja w zakresie obiektowego modelu danych wpływa na spójność i integralność odwzorowania rzeczywistości, implementując przy tym aspekty inkapsulacji znane z programowania obiektowego.

Relacyjny model danych opracował w latach osiemdziesiątych XX w. Edgar Frank Codd. Opublikował on wówczas jedną z najważniejszych swoich prac pt. Relacyjny model logiczny dla dużych wielodostępnych baz danych. Przedsięwzięcie Codda znalazło entuzjastów na Uniwersytecie Kalifornijskim w Berkeley oraz w firmie IBM. Opracowane wówczas systemy baz danych były rozwijane nie tylko w celach komercyjnych. Larry Ellison, współfundator korporacji Oracle, projekt systemu zarządzania bazami danych oparł na założeniu Codda. Nazwa Oracle jest nie tylko określeniem DBMS, lecz także nazwą kodową projektu CIA, nad którym pracowali założyciele Oracle w korporacji Ampex Corporation.

Oprócz Oracle rozwijały się w tym czasie takie bazy danych, jak Sybase lub Informix, używające języka SQL. W 1985 r. Codd przedstawił 12 zasad opisujących model relacyjny baz danych. Zasady te rozwinął do 333 w książce wydanej w 1990 r. Podstawą relacyjnego modelu baz danych jest teoriomnogościowe pojęcie relacji. Dane przechowuje się w tabelach, nazywanych relacjami, składających się z wierszy (krotek) i kolumn (atrybutów).

Frank Codd określił 12 podstawowych zasad, które musiał spełniać system, by mógł zarządzać relacyjnym modelem danych.

Postulaty Codda

System musi być kwalifikowany jako relacyjny, jako baza danych i jako system zarządzania:

  1. Postulat informacyjny – dane są reprezentowane jedynie poprzez wartości atrybutów w wierszach tabel.
  2. Postulat dostępu – każda wartość w bazie danych jest dostępna poprzez podanie nazwy tabeli, atrybutu i wartości klucza podstawowego.
  3. Postulat dotyczący wartości NULL – dostępna jest specjalna wartość NULL dla reprezentacji zarówno wartości nieokreślonej, jak i nieadekwatnej, inna od wszystkich i podlegająca przetwarzaniu.
  4. Postulat dotyczący katalogu – wymaga się, aby system obsługiwał wbudowany katalog relacyjny z bieżącym dostępem dla uprawnionych użytkowników używających języka zapytań,
  5. Postulat języka danych – system musi dostarczać pełny język przetwarzania danych, który może być używany zarówno w trybie interaktywnym, jak i w obrębie programów aplikacyjnych, obsługuje operacje definiowania danych, operacje manipulowania danymi, ograniczenia związane z bezpieczeństwem i integralnością oraz operacje zarządzania transakcjami.
  6. Postulat modyfikowalności perspektyw – system musi umożliwiać modyfikowanie perspektyw, o ile jest ono semantycznie realizowalne.
  7. Postulat modyfikowalności danych – system musi umożliwiać operacje modyfikacji danych, musi obsługiwać operatory INSERT, UPDATE oraz DELETE.
  8. Postulat fizycznej niezależności danych – zmiany fizycznej reprezentacji danych i organizacji dostępu nie wpływają na aplikacje. Postulat logicznej niezależności danych – zmiany wartości w tabelach nie wpływają na aplikacje.
  9. Postulat logicznej niezależności danych – zmiany wartości w tabelach nie wpływają na aplikacje.
  10. Postulat niezależności więzów spójności – więzy spójności są definiowane w bazie i nie zależą od aplikacji.
  11. Postulat niezależności dystrybucyjnej – działanie aplikacji nie zależy od modyfikacji i dystrybucji bazy.
  12. Postulat bezpieczeństwa względem operacji niskiego poziomu — operacje niskiego poziomu nie mogą naruszać modelu relacyjnego i więzów spójności.

Przy użyciu zasad algebry relacyjnej opracowano również język SQL służący do komunikowania się z większością współczesnych baz danych. Obecnie spotykane bazy danych przystosowane są w większości do pracy wykorzystującej połączenia sieciowe (architektura KLIENT-SERWER). Aby sprostać rosnącemu zapotrzebowaniu na usługi oferowane przez bazy danych, wzrasta liczba zastosowań tego oprogramowania w architekturze rozproszonej (usługi chmurowe).

Rozproszona baza danych. Pracując z bazą danych typu Access lub używając narzędzi typu WAMP, LAMP lub XAMPP, mamy do czynienia z SZBD zainstalowanym na lokalnym komputerze. Zdarza się, że administrując serwerem, łączymy się zdalnie z bazą danych zainstalowaną na pojedynczym urządzeniu. Możliwość łączenia komputerów za pomocą sieci, szyfrowania i zabezpieczania połączeń sprawia, że coraz częściej baza danych rozdzielana jest na węzły sieciowe, przez co jedna baza może występować w różnych konfiguracjach sprzętowych i programistycznych. Taka baza może się znajdować na wielu komputerach położonych nie tylko w odległych od siebie geograficznie miejscach, lecz także w sieciach lokalnych.

Integralność danych

Integralność danych

ZAGADNIENIA

  • Definicje pojęć: integralność danych, integralność baz danych
  • Reguły integralności
  • Integralność encji
  • Integralność referencyjna
  • Statyczne i dynamiczne więzy integralności

Integralność danych, określana również mianem spójności danych, jest to funkcja SZBD, która gwarantuje, że dane nie zostaną usunięte lub zmienione w nieautoryzowany sposób.

Ochrona integralności danych polega również na zapewnieniu, że dane nie ulegną zniekształceniu podczas wykonywania na nich operacji. Spójność danych związana jest z ich dokładnością – dane dokładnie odzwierciedlają modelowaną rzeczywistość. Oznacza ona również ich prawdziwość oraz aktualizowanie, gdy zmienia się rzeczywistość modelowana w bazie danych. Dane muszą być poprawne i zgodne ze schematem bazy danych. W SZBD powinny istnieć mechanizmy, które pozwolą zabezpieczyć dane przed skutkami awarii zasilania, sprzętu lub oprogramowania. W bazie danych powinny działać mechanizmy, których zadaniem jest zabezpieczenie danych przed następstwami błędów logicznych. Zachowanie spójności danych powinny gwarantować systemy chroniące dane też przed błędami pojawiającymi się w chwilach współbieżnego dostępu do tej samej informacji. Istotną rolę odgrywa również system kontroli danych wejściowych. Proces utrzymania  integralności bazy danych obejmuje również kopie zapasowe danych.

Zachowanie poprawności bazy danych opiera się na utrzymaniu poprawności w obrębie semantycznym, encji i referencyjnym.

Integralność semantyczna polega na utrzymaniu ograniczeń nakładanych na dane, min.:

  • w określonej kolumnie tabeli muszą znajdować się wyłącznie dane zgodne z typem danych kolumny, np. tylko liczby całkowite;
  • w kolumnie nie mogą wystąpić braki wartości – puste miejsca NULL.

Obok integralności semantycznej wyróżniamy także integralność encji. 

Integralność encji wprowadza się w trakcie definiowania schematu danych. Zgodnie z regułami integralności encji każda tabela powinna mieć klucz główny – kolumnę, w której nie mogą wystąpić wartości NULL oraz w której dane nie mogą się powtarzać.

Integralność referencyjna polega na wprowadzeniu i utrzymaniu powiązań pomiędzy tabelami. Związki te tworzy się przez umieszczenie kolumny pełniącej rolę klucza głównego tabeli w innej tabeli, co nadaje kolumnie funkcję klucza obcego. Takie rozwiązanie nazwę związków: klucz podstawowy – klucz obcy. Reguły integralności referencyjnej determinują, czy wartości klucza obcego mają odpowiadać wartościom klucza głównego w powiązanej tabeli, czy mogą przyjmować wartości NULL.

 Podczas omawiania zagadnienia integralności bazy danych stosuje się również podział więzów integralności na statyczne i dynamiczne.

Ograniczenia integralnościowe statyczne odnoszą się do bieżącego stanu bazy danych, np. na kolumnę wiek zostało nałożone takie ograniczenie jak CHECK (wiek < 200). Nałożenie tego ograniczenia podczas tworzenia tabeli spowoduje, że w kolumnie wiek wartość nie będzie większa niż 200 w trakcie nakładania ograniczenia i w przyszłości.

Więzy integralności dynamiczne to takie, które przeciwdziałają zmianom, ponieważ związane są z przejściem bazy danych z jednego stanu w drugi. Oznacza to, że odnoszą się do bazy danych w aspekcie temporalnym. Przykładem takich więzów może być wymaganie, aby wiek pracowników nigdy nie malał. Jeśli wiek pracownika po pewnym czasie wzrośnie, to wartość kolumny wiek nie może nigdy się zmniejszyć, ponieważ nikt nie staje się młodszy. Więzy dynamiczne nazywane są również więzami przejść.

SPRAWDŹ SWOJĄ WIEDZĘ

  1. Co to jest integralność danych?
  2. Jakie wyróżniamy rodzaje integralności?
  3. Kiedy baza danych zachowuje swoją poprawność?
  4. Czym różnią się ograniczenia integralnościowe statyczne od dynamicznych?
  5. Podaj przykład integralności encji w przypadku, gdy tabelą byłby spis uczniów w dzienniku szkolnym.

Funkcje Systemu Zarządzania Bazą Danych (SZBD)

ZAGADNIENIA

  • Definicja Systemu Zarządzania Bazą Danych (SZBD)
  • Historia powstania SZBD
  • Funkcje SZBD: niezależność danych, ochrona danych, ochrona spójności bazy, szybki dostęp do bazy, tworzenie kopii zapasowych i zarządzanie nimi, przywracanie bazy danych po awarii.

 SZBD – Systemy Zarządzania Bazą Danych

System Zarządzania Bazą Danych – SZBD (DBMS – Database Management System) to oprogramowanie umożliwiające użytkownikom definiowanie, tworzenie i zarządzanie bazą danych oraz kontrolowanie dostępu do niej. Rozszerzając tę definicję, warto wspomnieć, że oprogramowanie to umożliwia dostęp do baz danych nie tylko użytkownikom, lecz także innym programom. Wszystkie powyższe czynności są możliwe dzięki zaimplementowanej obsłudze strukturalnego języka zapytań.

Funkcje SZBD

Powszechnie uważa się, że pierwszym systemem zarządzania bazą danych był system stworzony na potrzeby projektu Apollo dotyczącego lądowania człowieka na Księżycu. Ponieważ te zainicjowane przez prezydenta Kennedy’ego prace wymagały gromadzenia bardzo dużej ilości informacji, należało stworzyć system, który byłby w stanie udźwignąć mechanizm dostępu i modyfikacji informacji przy bardzo dużej ilości danych. Wykonania tego przedsięwzięcia podjęła się organizacja NAA (North American Aviatiori), która stworzyła GUAM (Generalized Update Access Method) – system modyfikacji i dostępu. W połowie lat 60. ten oparty na hierarchicznej strukturze system był rozwijany przez firmę IBM, którą przyłączono do NAA. GUAM był podstawą projektu IMS (Information Managament System). Kolejnym krokiem w rozwoju systemu zarządzania bazą danych było powstanie nowego systemu baz danych – systemu sieciowego. Zarządzany był przez produkt firmy General Electric – IDS (Integrated Data Store). Badania nad rozwojem systemów przetwarzających i gromadzących dane były przedmiotem zainteresowań nie tylko przedstawicieli rządu, lecz także finansistów i biznesmenów. Na konferencji CODASYL (Conference on Data System Lenguages) postanowili oni ukierunkować prace związane ze standardem tych systemów.

W 1965 roku powstała grupa do spraw przetwarzania danych – List Processing Task Furce. W 1967 roku zmieniła nazwę na DBTG (Data Base Task Group) i zajęła się wytyczaniem standardów dla systemów umożliwiających przetwarzanie danych i tworzenie baz danych. Propozycje standardów dla SZBD podane przez DBTG były podstawą tworzenia systemów zarządzania bazą danych, mimo iż nie zostały przyjęte przez ANSI (American Sational Standards Institute). Kolejnym krokiem były systemy tworzone po 1970 roku, kiedy to E.F. Codd opublikował swoją słynną pracę będącą do dziś podstawą założeń wszystkich relacyjnych systemów zarządzania bazą danych RDBMS.

Systemy Zarządzania Bazami Danych (Data Base Managment System – DBMS) pełnią funkcję pośrednika pomiędzy zapisanymi danymi a użytkownikiem bądź programem chcącym z tych danych skorzystać. Sprawiają, że programy (aplikacje) nie muszą mieć zaimplementowanej obsługi zapisu plików na dysku, jak również logicznej organizacji danych w tych plikach. Wszystkie te zadania SZBD biorą na siebie. Funkcja ta nazywana jest niezależnością danych. Oprócz organizacji przechowywanych danych należy zapewnić im odpowiednią ochronę, zarówno przed nieprawidłowym działaniem programów, jak i przed dostępem ze strony nieuprzywilejowanych aplikacji i użytkowników. Funkcja ta nazywana jest ochroną danych. Przechowywane w bazie danych informacje należy też zabezpieczyć, aby były logicznie spójne i odpowiadały rzeczywistości. Efekt ten osiąga się przez wprowadzanie więzów spójności, które pomagają realizować kolejną funkcję SZBD, jaką jest ochrona spójności. Funkcją, która wpływa na atrakcyjność SZBD, jest możliwość uzyskania szybkiego dostępu do danych, ich sortowania i modyfikacji. Kontrolując spójność danych, SZBD zapewnia również współbieżny dostęp do danych wielu użytkownikom i pilnuje, aby wykonywane przez nich operacje nie naruszyły spójności bazy danych. Bardzo istotną cechą jest możliwość tworzenia kopii zapasowych, zarządzania nimi oraz odtworzenia bazy danych po awarii.

Oprócz wielu możliwości, jakie dają SZBD, nie są one wolne od wad. Ponieważ oferują bardzo wiele nowoczesnych funkcji, wzrasta ich złożoność, co pociąga za sobą konieczność zapoznania się z bardzo obszerną dokumentacją. Mimo stale prowadzonych prac nad polepszeniem wydajności tych systemów, nadal wymagają zapewnienia dużych przestrzeni dyskowych i zasobów pamięci operacyjnej. W przypadku komercyjnych produktów znaczna jest też cena SZBD, która może być uzależniona od liczby procesorów wykorzystywanych w urządzeniu serwerowym. Do kosztów należy zaliczyć również opłaty za szkolenia pracowników, koszty przeniesienia systemu, koszty generowane przez audyt i bezpieczeństwo. Utrzymywanie scentralizowanego DBMS i uzależnienie od niego wielu aplikacji (np. dwieście stron internetowych korzysta z jednego serwera bazy danych) w wypadku awarii systemu uniemożliwia pracę wszystkich powiązanych z nim aplikacji.

SPRAWDŹ SWOJĄ WIEDZĘ

  1. Wytłumacz pojęcia: dane, baza danych, system zarządzania bazą danych.
  2. Co to jest CODASYL?
  3. Omów pojęcie niezależności danych.
  4. Wymień wady SZBD.
  5. Na czym polega spójność danych?

Charakterystyka elementów bazodanowych

Zagadnienia: encja, atrybut, krotka, dziedzina, klucz (główny, kandydujący, obcy, prosty, złożony).

Znajomość budowy bazy danych wymaga zwykle fachowego określenia jej elementów. Twórca relacyjnego modelu danych – E.F. Codd – w pracy Relacyjny model danych dla dużych banków  nie używa terminów tabela, kolumna, wiersz, lecz zamiast nich stosuje pojęcia: relacja (zamiast tabela), atrybu (zamiast kolumna),  krotka (zamiast wiersz). Terminy te będą tłumaczone na przykładach w dalszej części podręcznika, ponieważ właściwe zrozumienie teorii baz danych jest kluczowe dla ich przyszłych projektantów i administratorów.

Podobnie jak w innych specjalistycznych dziedzinach wiedzy, również w przypadku informatyki posługujemy się uniwersalnym językiem do opisu elementów baz danych. W celu odniesienia się do rzeczywistości prezentowanej w bazie danych posługujemy się terminem encja.

O encji (enity) mówimy wtedy, gdy potrzebujemy określić coś, co reprezentuje obiekt lub grupę obiektów. Pojęcia encji używamy, aby określić nie tylko obiekty fizyczne materialne, lecz także niematerialne. Przykładami encji mogą być takie obiekty jak: OSOBA,  cechami mogą być wzrost, numer buta, waga. Cechy te nazywane są atrybutami encji. Istnieje pogląd wskazujący na podobieństwo pomiędzy encją a obiektem (w programowaniu obiektowym). Porównanie to wskazuje na właściwości, atrybuty encji i ich podobieństwo do klas obiektu.

Dla graficznej reprezentacji encji trybutów oraz związków używane są diagramy związków encji. Owale reprezentują atrybuty encji (autor, tytuł, ISBN), same encje zaś reprezentowane są przez prostokąty. Relacje pomiędzy encjami pokazane SA za pomocą równoległoboku.

Kolejnym często spotykanym terminem jest krotka.

 Krotka  (tuple) może być zdefiniowana następująco: jeśli tabela spełnia wymogi relacji (jest relacją), a jej kolumny są atrybutami, to krotka jest wierszem (rekordem). Krotka przechowuje stałe wartości o różnych typach danych, których to typów nie można zmodyfikować w kolejnej krotce. Dlatego typy, np. tytuł, ISBN, dla następnych krotek jednej tabeli będą stałe, a ich zawartości będą się różnić. Odczyt krotki wymaga podania jej tabeli będą stałe, a ich zawartości będą się różnić. Odczyt krotki wymaga podania jej indeksu (w naszym przykładzie niepowtarzalnego numeru ISBN).

Atrybut definiowany jest jako kolumna relacji mająca identyfikator (nazwę). W relacyjnym modelu baz danych, gdy dwuwymiarową tabelę nazwiemy relacją (gdy spełnia warunki relacji), wówczas posiadające nazwę  kolumny tej tabeli nazywamy atrybutami.

Ważną cech tabeli – relacji jest to, że kolejność atrybutów nie powinna mieć znaczenia.

Przykład

Przyjmując książkę w bibliotece jako encję,  możemy wskazać jej następujące atrybuty:

  • ISBN,
  • tytuł,
  • autor,
  • wydawnictwo,
  • liczba książek,
  • rok wydania.

Poniższy przykład pokazuje, że dla encji Książka mamy dwie krotki, mimo że teoretycznie mamy 3 książki (suma wartości w kolumnie Liczba_ksiazek).

ISBN

Tytul

Autor

Wydawnictwo

Liczba_ksiazek

Rok_wydania

234-83-2623-741-0

Janko Muzykant

Henryk Sienkiewicz

Greg

1

1999

978-83-2623-748-0

W pustyni i w puszczy

Henryk Sienkiewicz

Zielona Sowa

2

2010

Dziedzina jest zbiorem wartości, jakie może przyjąć atrybut krotki. Jeśli kolumna tabeli przechowywać będzie numery kuli używanych do losowania Lotto, dziedzina atrybutu będą numery od 1 do 49. Gdy kolumna przechowywać będzie liczbę książek, wówczas zakładamy, że będą to wartości całkowite (ponieważ w bibliotece nie występują egzemplarze ułamkowe książek, n 0,5 książki), zatem dziedzina kolumny będą wartości całkowite integer. W bazi danych typ kolumny (dziedzina) może zostać zdefiniowany jako  int(1), co oznacza, że w kolumnie książki mogą znajdować się liczby całkowite o maksymalnej długości nieprzekraczającej jedenastu znaków.

Przykład definicji typu kolumny dla bazy danych MySQL

Liczba_ksiazek 

int(11)

Klucz główny

Klucz główny

Dość często spotykanym problemem na etapie projektowania bazy danych jest określenie, która kolumna (kolumny) będzie pełnić funkcję klucza głównego. Ponieważ każdy wiersz w tabel musi my jednoznacznie zidentyfikować , zachodzi potrzeba wybrania atrybutów (kolumn), które spełniają to zadanie. Klucz główny odgrywa bardzo ważną rolę  w tabeli (relacji), dlatego jego wybór powinien zostać poprzedzony analizą typowanych przez nas kolumn pod kątem wymienionych poniżej własności:

  • trwałość – wartość kolumny powinna być stale obecna w wierszu, oznacza to , że kolumna taka (należąca do klucza głównego) nie może zawierać wartości NULL.
  • unikatowość – wartość klucza dla każdego wiersza powinna być unikatowa, ponieważ w niepowtarzalny sposób powinien on identyfikować każdą krotkę (wiersz tabeli). Może się zdarzyć, że taki niepowtarzalny identyfikator otrzymamy, umieszczając w kluczu głównym więcej niż jedną kolumnę. Kombinacja wartości, trzech kolumn, które należeć będą do klucza, będzie unikatowa i jednoznacznie zidentyfikuje każdą krotkę.
  • stabilność – wartości klucza nie powinny podlegać zmianom. Nie powinno się jako kluczy głównych używać kolumn przechowujących wartości nietrwałe, np. numer telefonu komórkowego, ponieważ mimo jego unikatowości każdy człowiek może go zmienić np. gdy przejdzie do innego operatora.

 Projektowanie relacyjnej bazy danych wymaga stosowania fachowych określeń, których używać powinno się nie tylko w odniesieniu do budowy tabel, lecz także w stosunku do relacji – związków tworzonych pomiędzy tabelami.

Aby jednoznacznie zidentyfikować wiersz tabeli, stosuje się  atrybut (kolumnę), której poszczególne wartości dla kolejnych krotek (wierszy) będą niepowtarzalne.

ISBN

Tytul

Autor

Wydawnictwo

Liczba_ksiazek

Rok_wydania

234-83-2623-741-0

Janko Muzykant

Henryk Sienkiewicz

Greg

1

1999

978-83-2623-748-0

W pustyni i w puszczy

Henryk Sienkiewicz

Zielona Sowa

Liczba_ksiazek

2010

 

W powyższym przykładzie taką kolumna jest ISBN, ponieważ dla każdej książki jest on unikatowy. Oczywiście dany ISBN będzie identyfikował grupę książek o tym samym autorze, tytule oraz roku i wersji wydania, a także zawartości. Ponieważ każda z tych książek będzie identyczna pod względem zawartości, nie ma potrzeby rozryć w tabeli kolejnych wierszy, wystarczy wpisać, że mamy dwie książki pod tytułem W pustyni i w puszczy, a każda z nich jest wierna kopią poprzedniczki.

Atrybut  będący kluczem głównym  możemy stworzyć sztucznie dla przykładu wprowadzając kolejne numerowanie wierszy 1, 2, 3, 4, 5 itd., pod warunkiem że każdy wiersz ma inny numer. Możemy również posłużyć się określoną cechą (atrybutem) opisywanej rzeczywistości (encji), np. dokonując spisu ludności, możemy posłużyć się numerem PESEL. Ponieważ każdy człowiek ma inny niepowtarzalny numer PESEL, nie zachodzi obawa, że może on się powtórzyć. Taką kolumnę (atrybut) nazywamy kluczem Głównym (primary key).

Zadanie

  1. Podaj co najmniej 5 przykładów klucza głównego.

Rodzaje kluczy

Rodzaje kluczy

Zdarza się, że baza danych nie przechowuje pojedynczej tabeli, lecz wiele tabel, pomiędzy którymi występują powiązania. Aby pomiędzy tabelami można było tworzyć związki, powinny one mieć przynajmniej jeden atrybut (kolumnę), który musi spełniać dwa podstawowe warunki. Musi być unikatowy (oznacza to, że jeo wartości nie mogą się powtarzać). Drugim warunkiem jest jego atomowość (musi być minimalny, tzn. powinien zawierać elementarne, niepodzielne wartości). Możemy rozróżnić następujące rodzaje kluczy:

  • klucz prosty – to taki, który jest jednoelementowy (składa się z jednej kolumny),
  • klucz złożony – to taki, który jest kilkuelementowy (składa się z więcej niż jednej kolumny).

Kluczem może być zatem jedna lub kilka kolumn, które wspólnie będą w stanie jednoznacznie zidentyfikować pozostałe dane w tabeli (relacji). Kolumny, które należą do kluczy (używa się ich do jednoznacznej identyfikacji wierszy w tabeli), nazywamy atrybutami podstawowymi. Kolumny nie należące do kluczy (zawierają dane, które w określonej relacji są przedmiotem opisu) nazywamy atrybutami opisowymi.

Do łączenia dwóch tabel (np. A i B) za pomocą związków używa się klucza. Klucz pochodzący z obcej tabeli B (w której jest on kluczem głównym), używany do łączenia tej tabeli z tabelą A, będzie dla tabeli A kluczem obcym.

Superklucz (superkey) –  to kolumna lub zestaw kolumn jednoznacznie identyfikujących każda krotkę tabeli. Super klucz może zawierać kolumny, które samodzielnie mogą nie identyfikować każdej z krotek. Unikatowa identyfikacja każdej z krotek może odbywać się jedynie przez zestaw np. dwóch lub trzech atrybutów. Przedmiotem zainteresowań projektantów baz danych jest taki superklucz, który zawiera minimalny zestaw atrybutów unikatowo identyfikujących krotkę.

Klucz kandydujący (nadklucz, klucz potencjalny) o super klucz zawierający minimalną liczbę kolumn unikatowo identyfikujących krotki relacji. W praktyce to kolumna lub kolumny, których użycie w charakterze klucza głównego jest rozważane przez projektanta baz danych. To właśnie twórca bazy danych decyduje, której kolumnie (kolumnom) nada funkcję klucza głównego.

Klucz główny (primary key) to klucz, który został wybrany, aby unikatowo identyfikować krotki (rekordy) tabeli. Klucz główny jest podyktowany wyborem projektanta bazy danych.

Przykład

Rozważmy przykładową sytuację, w której projektujemy relację zawierającą np., spis lokatorów nieruchomości. Poniżej przedstawiono wycinek takiej tabeli.

Id

Imię

Nazwisko

PESEL

1

Maciej

Nowak

74092932157

2

Józef

Kowalski

65112164813

Ponieważ mogą występować osoby o tym samym imieniu i nazwisku, wybór atrybutów Imię lub Nazwisko jako klucza głównego mógłby powodować błędy w wypadku wystąpienia dwóch osób o tych samych imionach i nazwiskach. Ponieważ każdy człowiek ma niepowtarzalny unikatowy numer PESEL, atrybut PESEL spełnia wymagania kolumny jednoznacznie identyfikującej każdą krotkę. Projektant baz danych jako klucza głównego wybrał atrybut Id . Przykład ten pozwala zrozumieć różnicę pomiędzy kluczem głównym a kluczem kandydującym. W tym przypadku kluczami kandydującymi mogą być Id lub PESEL. Ponieważ projektant, definiując tabelę, mianował Id kluczem głównym atrybut PESEL pozostał kluczem kandydującym.

Klucz obcy – kolumna lub zestaw kolumn w jednej tabeli, która pasuje do klucza kandydującego drugiej lub tej samej tabeli. Klucze obce wyznaczane są zwykle podczas tworzenia związków pomiędzy tabelami. Dowolne dane w kolumnie (kolumnach)  klucza głównego tabeli A muszą mieć swoje odpowiedniki w odpowiadającej kolumnie (kolumnach) tabeli B (zgodność danych kolumn w dwóch tabelach). Zjawisko posiadania odpowiedników klucza głównego w obrębie różnych tabel nazywamy  integracją referencyjną. Klucz obcy definiowany jest również jako kombinacja jednego lub kilku atrybutów (pełniących funkcję klucza głównego) wykorzystywanych do tworzenia związków pomiędzy tabelami lub w obrębie jednej tabeli.

Oprócz wymienionych powyżej definicji, istnieją również takie pojęcia jak:

  • klucz prosty – klucz zawiera tylko jeden atrybut,
  • klucz złożony – składa się z więcej niż jednego atrybutu,
  • klucz potencjalny inaczej klucz kandydujący  (candidate key).

Sprawdź swoją wiedzę.

  1. Co to jest encja?
  2. Wyjaśnij termin atrybuty encji.
  3. Wyjaśnij na przykładzie co to jest krotka.
  4. Jakie cechy powinien posiadać klucz główny?
  5. Jaka jest różnica między kluczem głównym a kluczem kandydującym?
  6. Co to jest klucz obcy?

Sieciowe serwery baz danych

Sieciowe serwery baz danych

ZAGADNIENIA

  • Historia powstania MySQL
  • Początki i rozwój serwera PostgreSQL
  • Komercyjne systemy bazodanowe

MySQL

Początki MySQL sięgają roku 1995, gdy Michael Widenius (znany jako Monty) rozpoczął pracę, wraz z Dawidem Axmarkiem, nad kodem bazy MySQL, który ukończyli w 1996 r. Projekt tworzony był w TCX DataKonsult AB i jako MySQL AB został sprzedany Sun Microsystems w 2008 r. Baza danych MySQL swoją nazwę prawdopodobnie odziedziczyła po córce Wideniusa – My. Monty stworzył jeszcze jeden SZBD oparty na MySQL oraz silniku Aria. Produkt znany jest jako MariaDB. 27 stycznia 2010 roku Sun Microsystems został przejęty przez Oracle za 7,4 miliardów dolarów na podstawie porozumienia podpisanego 20 kwietnia 2009 r. Od tego czasu MySQL rozwijany jest przez Oracle. Mimo że kod MySQL dostępny jest na licencji GPL, ma również wersje komercyjne, które cechuje rozszerzona funkcjonalność. SZBD MySQL wykorzystywany jest bardzo często przez firmy hostingowe, ponieważ cechuje go duża szybkość transakcji.

Nie zmniejsza to stabilności, szybkości i wysokiej funkcjonalności pozostałych systemów, takich jak PostgreSQL. Systemy bazodanowe, podobnie jak systemy operacyjne, mają swoich zwolenników i przeciwników, a spory toczone pomiędzy nimi przypominają „święte wojny” na tle religijnym. Celem tego podręcznika nie jest testowanie wydajności i funkcjonalności obu systemów, tylko przygotowanie przyszłych informatyków do stawiania pierwszych kroków w administracji i konfiguracji SZDB.

PostgreSQL jest jednym z najstarszych i najlepiej przetestowanych serwerów bazodanowych. Serwer ten ma bardzo wiele rozszerzeń w formie wtyczek (plugins), które sprawiają, że może konkurować z komercyjnymi SZBD najwyższej klasy. Historia stgreSQL sięga roku 1970, kiedy to na uniwersytecie Berkeley powstał projekt Inter aktywnej Grafiki w Systemie Wyszukiwawczym (INGRES). W1980 r. poprawioną wersję skrócono do Postgres. W 1993 r. projekt oficjalnie zakończono w Berkeley. Rozwojem Postgresa zajęła się społeczność open source pod nazwą Postgres95. Ponieważ system Sten wspierał SQL, jego nazwa została zmieniona na PostgreSQL, którą nosi do dziś. PostgreSQL wykorzystują z powodzeniem firmy i instytucje przetwarzające duże ilości danych, np. Skype, United States Federal Aviation Administration (FAA). Instalację PostgreSQL można przeprowadzać na różne sposoby w zależności od przeznaczenia systemu operacyjnego. Oprócz wymienionych wyżej systemów, które omawiane są ze wzglądu na popularne oraz na łatwy i darmowy dostęp (każdy może je za darmo pobrać i testować), istnieją również systemy komercyjne, które oprócz profesjonalnych zastosowań cechuje wysoka cena. Ze względu na to, iż w przypadku chęci użycia produktów firmy Microsoft czy Oracle należy przygotować się na wydatek kilku lub kilkudziesięciu tysięcy złotych, stosowane są one w firmach, które stać również na przeprowadzanie szkoleń z obsługi tych systemów, i Nie bez znaczenia pozostaje to, że większość narzędzi prezentowanych w obrębie tego podręcznika ma interfejsy zbliżone do ww. komercyjnych rozwiązań. Dokładne poznanie sposobu administrowania, użytkowania i projektowania przy użyciu MySOL i PostgreSQL będzie bardzo pomocne w wypadku, gdy z rozwiązań darmowych zajdzie potrzeba migracji do rozwiązań komercyjnych, np. zastąpienia MySQL lub PostgreSQL bazą danych Microsoft SQL Server lub SZBD Oracle.

SPRAWDŹ SWOJĄ WIEDZĘ

  1. Omów w kilku zdaniach historię powstania MySQL.
  2. Dlaczego serwer PostgreSQL jest obecnie tak popularny?

Tabele baz danych – iloczyn kartezjański

Relacja – tabela

Aby wyjaśnić pojęcie relacji, warto odświeżyć kilka istotnych informacji z matematyki i teorii zbiorów. Iloczyn kartezjański zawdzięcza swoją nazwę kartezjańskiemu układowi współrzędnych.

Jest to prostoliniowy układ współrzędnych o parach prostopadłych osi.

Nazwa pojęcia pochodzi od łacińskiego nazwiska francuskiego matematyka i filozofa Kartezjusza (René Descartes), który opisał tę ideę w 1637 r. w traktacie La Geometrie. Iloczynem kartezjańskim prostej A i B będzie zbiór punktów płaszczyzny zawartej między nimi (każdy punkt należący do tej płaszczyzny). Idąc tym tokiem myślenia, jeśli będziemy mieć dwa zbiory A i B, to iloczynem kartezjańskim tych zbiorów będzie taki zbiór C, w którym każdy element A będzie połączony z każdym elementem B. Prześledźmy tą sytuację na przykładzie.



Iloczynem kartezjańskim tych dwóch zbiorów będzie następujący zbiór C, w którym każdemu elementowi zbioru A, będzie odpowiadał element zbioru B:



Tabele baz danych – relacje

Teraz spróbujemy zdefiniować relację.

Relacją nazywamy podzbiory iloczynu kartezjańskiego.
Niech podzbiorem dla naszego przykładu będą (1-Jacek, 2 – Ewa). Jeśli umieścimy  te elementy w tabeli, otrzymamy:

 


 

Numery

Imiona

1

Jacek

2

Ewa

1

Ewa

3

Ewa

2

Jacek

3

Jacek

Dlatego w relacyjnych bazach danych relacją nazywać będziemy tabele bazy danych, ponieważ zawartość tabeli ulega ciągłym zmianom. Kolumny – atrybuty mogą przechowywać wartości określonych typów, jednak wartości te mogą być modyfikowane. Podobnie jest w naszym przykładzie. Relacja (tabela) przechowuje dane, które zwykle ulegają pewnym zmianom. Zawartość tabeli, jeśli nie jest modyfikowana, może być rozszerzana o kolejne wiersze (rew). Operacje, jeśli nie zachodzą w danej chwili, mogą zajść w przyszłości, dlatego zawartość relacji możemy traktować jako zmienną. Teoretyk baz danych Chris Date zaproponował określanie tabel w relacyjnych bazach danych mianem relvar. Jest to skrót od relation (relacja – tabela) oraz variable – zmienna. Ten nowy termin w ję­zyku polskim tłumaczymy jako zmienna relacyjna. Takie definiowanie tabeli w relacyjnej bazie danych ma na celu uświadomienie osobom poznającym teorie, że tabela spełnia wymogi matematyczne relacji, a jej zawartość (to co jest przechowywane wewnątrz tabe­li) może ulegać zmianom w określonym czasie.

W większości opracowań dotyczących baz danych pojęcie relacja odnosi się do tabeli w relacyjnej bazie danych. Problemem teorii baz danych jest stosowanie terminu relacja również do związków, które występują pomiędzy tabelami (np. relacja jeden do wielu). W efekcie przyjęcia takiej nomenklatury, gdy chcemy powiedzieć, że pomiędzy tabelą A i tabelą B występuje związek „jeden do wielu”, mówimy, że pomiędzy relacją A a relacją B występuje relacja „jeden do wielu” (zupełnie tak, jakby oznaczało to istnienie trzeciej tabeli o nazwie „jeden do wielu”). Jak łatwo zauważyć, postępowanie takie doprowadza do zatarcia sensu wypowiedzi. W tym podręczniku konsekwentnie używane będą jako syno­nimy pojęcia relacja i tabela, a stosunki pomiędzy tabelami nazywane będą związkami, np. związkiem jeden do wielu, związkiem jeden do jednego.

PRZYKŁAD

Nr

Imię i nazwisko

Data urodzenia / Wiek

Występy

Gole

Klub

12

Grzegorz Sandomierski

5 września 1989 / 22 lata

3

0

Jagiellonia Białystok

1

Wojciech Szczęsny

18 kwietnia 1990 / 22 lata

11

0

Arsenał F.C.

22

Przemysław Tytoń

4 stycznia 1987 / 25 lat

8

0

PSY Eindhoven

 

Tabela 7.1. Lista reprezentantów Polski w piłce nożnej

Tabela przedstawia fragment składu reprezentacji Polski w piłce nożnej. W dniu 16.07.2012 r. odpowiadała rzeczywistości, jednak po pewnym czasie jej zawartość może ulec zmianie. Wystarczy, że któryś z zawodników strzeli gola, wtedy zawar­tość relacji ulegnie zmianie. Podobnie dane ulegną modyfikacji po podjęciu decyzji personalnej przez selekcjonera mającego wpływ na ostateczny skład reprezentacji Polski. W 2013 roku zmieni się również zawartość kolumny Wiek (każdy z piłkarzy będzie o rok starszy).

Ponieważ zachowanie zawartości relacji przypomina zawartość zmiennej znanej z języków programowania (pole przechowuje pewną wartość określonego typu i może ulec zmianie), stąd pisząc o tabeli, której zawartość ulega zmianom, użyjemy pojęcia zmienna relacyjna, natomiast gdy mamy na myśli tabelę, której zawartość jest rozpatrywani w danej określonej chwili i nie ulega zmianie, będziemy mówić o wartości relacyjnej lub w skrócie, relacji.

SPRAWDŹ SWOJĄ WIEDZĘ

  1. Co to jest iloczyn kartezjański i kto jest jego twórcą?
  2. Dlaczego tabela w relacyjnych bazach danych określana jest terminem relacja?

Projektowanie konceptualne,

Projektowanie konceptualne

ZAGADNIENIA

  •  Pojęcie projektowania konceptualnego
  • Różnica pomiędzy modelami (konceptualnym, logicznym, fizycznym)
  • Pojęcie anomalii występujących w bazach danych

Projektowanie konceptualne to proces konstrukcji modelu danych używany niezależnie od fizycznych rozważań (decydowania o zawartości tabel, typach danych w tabelach i rodza­jach powiązań).

Projektowanie konceptualne prowadzone dla przedsiębiorstwa rozpoczyna się od stwo­rzenia modelu projektu – zamierzenia. Rzeczywistość oddawana przez model konceptu­alny nie jest ograniczana do reguł implementacji, rodzaju DBMS, aplikacji i programów.

Projektowanie relacyjnej bazy danych przebiega od modelu konceptualnego do fizycznego.

Model

Konceptualny

Logiczny

Fizyczny

Nazwa encji

Tak

Tak

Związek encji

Tak

Tak

Atrybuty

Tak

Klucze główne

Tak

Tak

Klucze obce

Tak

Tak

Nazwy tabel

Tak

Nazwy kolumn

Tak

Typy danych

Tak

Projektowanie logiczne to proces konstrukcji modelu danych oparty na specyficznym modelu, ale niezależnym od DBMS.

Model fizyczny to proces produkcji i opisu implementacji bazy danych opisujący relacje bazy danych, organizację plików, indeksy, dostęp do danych, ograniczenia, wyznaczenie reguł integralności i stosowanie środków bezpieczeństwa.

Proces projektowania relacyjnej bazy danych można podzielić na trzy etapy:

  1. Przygotowanie diagramów związków encji.
  2. Normalizacja.
  3. Wprowadzenie zasad wymuszających integralność danych.

Normalizacją zajmiemy się w późniejszym czasie

Przygotowanie diagramów związków encji wiąże się z budową schematu – struktury, w jakiej będą przechowywane dane. Należy przyjąć, że w bazie danych przechowywane są obiekty lub wartości, które są odwzorowaniem realnych lub abstrakcyjnych bytów. Obiekty te są opisywane za pomocą właściwych dla nich cech, atrybutów, zdarzeń i metod. Właściwa organizacja tych obiektów oraz wybór odpowiadających im cech jest podstawą budowy diagramu związków encji.

Przykładem budowy takiego diagramu może być próba zaprojektowania bazy danych na potrzeby organizacji służby zdrowia. Encją (realnym lub abstrakcyjnym bytem), któ­ra będzie przedmiotem opisu w naszej bazie danych, będą lekarze. Atrybutami tej encji mogą być:

  • imię,
  • nazwisko lekarza,
  • wiek,
  • płeć,
  • specjalizacja.

Dobór atrybutów podykto­wany jest oczekiwaniami klientów w stosunku do bazy danych, jeśli baza danych miałaby rozliczać liczbę przepracowanych przez lekarza godzin, należałoby umieścić dodatkowo takie atrybuty, jak:

  • godzina przyjścia do pracy,
  • godzina wyjścia z pracy.

Każdy kolejny lekarz opisywany przez atrybuty będzie instancją encji „lekarze”. Podobnie jak podczas programowania, definiujemy zmienną lub obiekt, gdy podstawimy wartość do zmiennej lub powołamy do życia obiekt, otrzymujemy instancję zmiennej lub instancję obiektu. Tłumacząc wprost, instancją jest powołany do życia obiekt, a w przypadku bazy danych instancją encji „lekarze” będzie np. „Jan Nowak”, „internista”, „lat 43”, „mężczyzna”. Zazwyczaj opisywane przez bazy danych encje mają formę tabel, np. tabela „lekarze”.

____________________________________________________________________________

 

 

Komentarze

Prześlij komentarz