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 uzywać 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

  Czytaj dalej

Charakterystyka elementów bazodanowych

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, 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.

Czytaj dalej

Postulaty Codda

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 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.