Jedną z istotnych zalet korzystania z RDBMS jest „integralność referencyjna”. Integralność referencyjna odnosi się do dokładności i spójności danych. Ta integralność danych jest osiągana dzięki użyciu tych kluczy podstawowych i obcych.
Referencyjna integralność zachowuje integralność danych dzięki „ograniczeniom”. Ograniczenia są regułami, które wymuszają dokładność danych poprzez uniemożliwienie usunięcia powiązanego rekordu bez uprzedniego usunięcia rekordu głównego w tabeli głównej. Jeśli relacja klucz główny – klucz obcy została prawidłowo dodana, wówczas próba usunięcia rekordu głównego bez uprzedniego usunięcia powiązanych rekordów z innych tabel zablokuje transakcję do czasu usunięcia powiązanych rekordów. Zapobiega to zjawisku określanemu jako „osierocone rekordy”, które są rekordami odniesienia w tabeli, które nie mają już rekordu głównego w tabeli głównej.
Trzy zasady, które wymusza integralność referencyjna to:
1. Klucz obcy musi mieć odpowiadający mu klucz główny. (Zasada „Nie ma sierot”.)
2. Gdy rekord w tabeli głównej jest usuwany, wszystkie powiązane rekordy odwołujące się do klucza głównego muszą również zostać usunięte, co zwykle jest osiągane przez użycie kaskadowego usuwania.
3. Jeśli klucz główny dla rekordu zmienia się, wszystkie odpowiadające mu rekordy w innych tabelach używających klucza głównego jako klucza obcego muszą również zostać zmodyfikowane. Można to osiągnąć za pomocą aktualizacji kaskadowej.
Pytanie o dane w systemie zarządzania relacyjną bazą danych odbywa się za pomocą języka SQL (Structured Querying Language), który jest solidnym językiem zaprojektowanym do zarządzania danymi znajdującymi się w relacyjnej bazie danych.
SQL ma możliwości tworzenia, pobierania, aktualizowania i usuwania rekordów oraz w dużym stopniu opiera się na relacji klucz główny-klucz obcy w celu identyfikacji powiązanych danych w wielu tabelach. Możliwości SQL sprawiają, że system relacyjnej bazy danych jest pierwszym wyborem dla każdej aplikacji wymagającej silnej funkcjonalności transakcyjnej, eksploracji danych i złożonego raportowania.
Ta instrukcja SQL demonstruje pobieranie zestawu wyników, w jaki sposób zostałyby pobrane wszystkie rekordy sprzedaży dla pojedynczego pracownika, którego EmployeeId = 1.
SELECT * FROM Employees
JOIN Sales ON Employees.EmployeeId = SALES.EmployeeId
WHERE EmployeeId = 1
Następna instrukcja SQL jest przykładem zapytania implementującego złączenia na wielu tabelach. W tym przypadku zapytanie SQL pobiera wszystkie informacje o pracownikach, informacje o sprzedaży oraz informacje o klientach z tabeli Customers.
SELECT * FROM Employees
JOIN Sales ON Employees.EmployeeId = SALES.EmployeeId
JOIN Customers ON Customers.CustomerId = SALES.CustomerId
WHERE EmployeeId = 1
Relacyjne bazy danych zapewniają również funkcjonalność zwaną „indeksowaniem”. Indeks bazy danych to struktura danych, która poprawia szybkość wyszukiwania danych. Indeksy są powszechnie dodawane do pól danych, które są rutynowo używane do zapytań i łączenia tabel. W powyższych instrukcjach SQL EmployeeId i CompanyId byłyby kandydatami do tego typu optymalizacji.
Nierelacyjne bazy danych
Nierelacyjna baza danych, lub baza danych NoSQL, przechowuje dane. Jednakże, w przeciwieństwie do relacyjnej bazy danych, nie ma tabel, wierszy, kluczy głównych i obcych. Zamiast tego nierelacyjna baza danych korzysta z modelu przechowywania zoptymalizowanego pod kątem konkretnych wymagań dotyczących rodzaju przechowywanych danych.
Niektóre z bardziej popularnych baz danych NoSQL to MongoDB, Apache Cassandra, Redis, Couchbase i Apache HBase.
Istnieją cztery popularne typy nierelacyjnych baz danych: przechowywanie danych dokumentowych, baza danych zorientowana na kolumny, przechowywanie wartości kluczowych i baza danych grafowych. Często kombinacje tych typów są wykorzystywane w pojedynczej aplikacji.
Document data stores
Dokumentowy magazyn danych zarządza zbiorem nazwanych pól łańcuchowych i wartości danych obiektowych w encji określanej jako „dokument” zazwyczaj przechowywanej w postaci dokumentów JSON, które mogą być zakodowane na wiele sposobów, w tym XML, YAML, JSON, BSON lub jako zwykły tekst. Pola wewnątrz dokumentów są odsłonięte, co pozwala aplikacji na odpytywanie i filtrowanie danych przy użyciu wartości pól.
Składy dokumentów nie wymagają, aby wszystkie dokumenty utrzymywały identyczne struktury danych, co zapewnia dużą elastyczność. Łatwo więc zauważyć, jak ta elastyczność może być wykorzystywana, gdy zmieniają się wymagania organizacji.
Kolumnowe (lub zorientowane na kolumny) magazyny danych
Kolumnowy magazyn danych organizuje dane w kolumny, co jest koncepcyjnie podobne do relacyjnej bazy danych. Prawdziwą zaletą kolumnowej bazy danych jest jej zdenormalizowane podejście do strukturyzacji nielicznych danych, które wynika z jej kolumnowego podejścia do przechowywania danych.
Key-value stores
Jest to najmniej skomplikowana z baz danych NoSQL i, jak sama nazwa wskazuje, key-value store jest po prostu zbiorem par klucz-wartość zawartych w obiekcie.
Document stores
Document stores są nieco bardziej złożone niż key-value stores. Nie zakładają one konkretnej struktury dokumentu określonej schematem. Magazyn dokumentów jest przeznaczony do przechowywania codziennych dokumentów jako takich i pozwalają one na skomplikowane zapytania.
MongoDB i CouchDB są zarówno przykładami magazynów dokumentów.
Graphowe bazy danych
Ostatni jest najbardziej złożony typ nierelacyjnej bazy danych. Jest ona zaprojektowana do efektywnego przechowywania relacji między podmiotami. Gdy dane są w dużym stopniu powiązane ze sobą, np. systemy zakupów i produkcji lub katalogi referencyjne, grafowe bazy danych są dobrym rozwiązaniem.
Możliwości grafowych baz danych NoSQL są nieskończone, a ponieważ gromadzone przez nas dane stają się coraz bardziej powiązane ze sobą, grafowe bazy danych będą nadal zyskiwać na popularności, w tym wciąż dominująca relacyjna baza danych.
Zamiast języka zapytań strukturalnych (SQL) używanego przez relacyjne bazy danych, baza danych NoSQL wykorzystuje mapowanie obiektowo-relacyjne (ORM). Koncepcja ORM polega na możliwości pisania zapytań przy użyciu preferowanego języka programowania. Niektóre z bardziej popularnych ORM to Java, Javascript, .NET i PHP.
Podsumowując
Co musisz wiedzieć o relacyjnych bazach danych:
-
Pracują z ustrukturyzowanymi danymi.
-
Relacje w systemie mają ograniczenia, co sprzyja wysokiemu poziomowi integralności danych.
-
Mają nieograniczone możliwości indeksowania, co przekłada się na szybsze czasy odpowiedzi na zapytania.
-
Doskonale radzą sobie z utrzymaniem bezpieczeństwa transakcji danych.
-
Dają możliwość pisania złożonych zapytań SQL w celu analizy danych i raportowania.
-
Ich modele mogą zapewnić i egzekwować reguły biznesowe w warstwie danych, dodając poziom integralności danych niespotykany w nierelacyjnych bazach danych.
-
Są zorientowane na tabele i wiersze.
-
Używają języka SQL (structured query language) do kształtowania i manipulowania danymi, który jest bardzo potężny.
-
Przykłady baz danych MySQL: MySql, Oracle, Sqlite, Postgres i MS-SQL. Przykłady baz danych NoSQL: MongoDB, BigTable, Redis, RavenDb, Cassandra, Hbase, Neo4j i CouchDb.
-
Bazy danychSQL najlepiej nadają się do aplikacji typu transakcyjnego o dużym obciążeniu.
Nierelacyjne bazy danych/NoSQL:
-
Mają zdolność do przechowywania dużych ilości danych o niewielkiej strukturze.
-
Zapewniają skalowalność i elastyczność w celu spełnienia zmieniających się wymagań biznesowych.
-
Zapewniają opcje schema-free lub schema-on-read.
-
Mają zdolność do przechwytywania wszystkich typów danych „Big Data”, w tym danych nieustrukturyzowanych.
-
Są zorientowane na dokumenty.
-
NoSQL lub nierelacyjne bazy danych Przykłady: MongoDB, Apache Cassandra, Redis, Couchbase i Apache HBase.
-
Najlepiej nadają się do szybkiego tworzenia aplikacji. NoSQL to najlepszy wybór dla elastycznego przechowywania danych z niewielkimi lub żadnymi ograniczeniami struktury.
-
Zapewniają elastyczny model danych z możliwością łatwego przechowywania i łączenia danych o dowolnej strukturze bez konieczności modyfikacji schematu.
Więc, który z nich powinieneś wybrać dla swojego projektu? Aby uzyskać odpowiedź na to pytanie, możemy wrócić do początku tego artykułu. Te dwa bardzo różne typy baz danych są równie przydatne w ich własnym prawie, ale z różnych powodów i przypadków użycia. Jedna niekoniecznie jest lepsza od drugiej i zarówno relacyjne, jak i nierelacyjne bazy danych mają swoje miejsce.
W skrócie, nie ma jednej właściwej odpowiedzi. Najlepszym sposobem określenia, który typ bazy danych jest najlepszy dla danego projektu, jest przeanalizowanie potrzeb organizacji i funkcjonalności aplikacji, które trzeba osiągnąć.