Jaka jest różnica między relacyjną i nierelacyjną bazą danych?

Wiem, że rozwiązania takie jak MySQL, PostgreSQL i MS SQL Server to systemy relacyjnych baz danych, a NoSQL, MongoDB itp. To nierelacyjne DBMS.

Jakie są jednak różnice między tymi dwoma typami systemów?

Preferowane są określenia laika.

Dzięki.

Relacyjne bazy danych mają podstawy matematyczne (teoria mnogości, teoria relacji), które są destylowane w SQL == Structured Query Language.

Wiele form NoSQL (np. Oparte na dokumentach, oparte na wykresach, obiektowe, magazyn wartości klucza itp.) Może, ale nie musi, opierać się na jednej podstawowej teorii matematycznej. Jak słusznie zauważył S. Lott, hierarchiczne magazyny danych rzeczywiście mają podstawę matematyczną. To samo można powiedzieć o grafowych bazach danych .

Nie znam uniwersalnego języka zapytań dla baz danych NoSQL.

Hmm, nie do końca wiem, jakie jest twoje pytanie.

W tytule pytasz o bazy danych (DB), natomiast w tekście pytasz o systemy zarządzania bazami danych (DBMS). Obie są zupełnie inne i wymagają różnych odpowiedzi.

DBMS to narzędzie, które umożliwia dostęp do bazy danych.

Oprócz samych danych baza danych to koncepcja struktury tych danych.

Tak więc, tak jak można programować za pomocą metodologii Oriented Object z kompilatorem nie opartym na OO, lub odwrotnie, tak można skonfigurować relacyjną bazę danych bez RDBMS lub użyć RDBMS do przechowywania danych nierelacyjnych.

Skoncentruję się na tym, co oznacza relacyjna baza danych (RDB) i pozostawię dyskusję o tym, co systemy robią z innymi.

Relacyjna baza danych (pojęcie) to struktura danych, która umożliwia łączenie informacji z różnych „tabel” lub różnych typów zasobników danych. Zasobnik danych musi zawierać tak zwany klucz lub indeks (który umożliwia jednoznaczną identyfikację dowolnej niepodzielnej części danych w zasobniku). Inne zasobniki danych mogą odnosić się do tego klucza, aby utworzyć połączenie między ich atomami danych a atomem wskazywanym przez klucz.

Nierelacyjna baza danych po prostu przechowuje dane bez wyraźnych i ustrukturyzowanych mechanizmów łączenia danych z różnych segmentów.

Jeśli chodzi o implementację takiego schematu, jeśli masz papierową kartotekę z indeksem, aw innym papierowym pliku odwołujesz się do indeksu, aby uzyskać odpowiednie informacje, to zaimplementowałeś relacyjną bazę danych, aczkolwiek dość prostą. Widzisz więc, że nie potrzebujesz nawet komputera (oczywiście może to szybko stać się uciążliwe bez pomocy), podobnie nie potrzebujesz RDBMS, chociaż prawdopodobnie RDBMS jest odpowiednim narzędziem do tego zadania. To powiedziawszy, istnieją różnice w możliwościach różnych narzędzi, więc wybór odpowiedniego narzędzia do pracy może nie być wcale taki prosty.

Mam nadzieję, że to wystarczające terminy dla laika i pomocne w zrozumieniu.

Większość tego, co „wiesz”, jest błędna.

Przede wszystkim, jak rutynowo (a czasem ostro) zauważa kilku guru relacyjnych, SQL nie pasuje do teorii relacji tak blisko, jak wielu ludziom się wydaje. Po drugie, większość różnic w „NoSQL” ma stosunkowo niewiele wspólnego z tym, czy jest to relacja, czy nie. Wreszcie, trudno jest powiedzieć, czym różni się „NoSQL” od SQL, ponieważ oba reprezentują dość szeroki zakres możliwości.

Jedyną główną różnicą, na którą możesz liczyć, jest to, że prawie wszystko, co obsługuje SQL, obsługuje takie rzeczy, jak wyzwalacze w samej bazie danych - tj. Możesz zaprojektować reguły we właściwej bazie danych, które mają zapewnić, że dane są zawsze wewnętrznie spójne. Na przykład, możesz ustawić rzeczy tak, aby Twoja baza danych potwierdzała, że ​​dana osoba musimieć adres. Jeśli to zrobisz, za każdym razem, gdy dodasz osobę, w zasadzie zmusi cię to do skojarzenia tej osoby z jakimś adresem. Możesz dodać nowy adres lub powiązać go z jakimś istniejącym adresem, ale w ten czy inny sposób osoba musi mieć adres. Podobnie, jeśli usuniesz adres, zmusi Cię to do usunięcia wszystkich osób znajdujących się pod tym adresem lub skojarzenia ich z innym adresem. Możesz zrobić to samo w przypadku innych relacji, na przykład powiedzieć, że każda osoba musi mieć matkę, każde biuro musi mieć numer telefonu itp.

Zwróć uwagę, że tego rodzaju rzeczy są również gwarantowane atomowo, więc jeśli ktoś inny spojrzy na bazę danych podczas dodawania osoby, albo w ogóle jej nie zobaczy, albo zobaczy osobę z adres (lub matka itp.)

Większość baz danych NoSQL nie próbuje zapewnić tego rodzaju wymuszania we właściwej bazie danych. To do Ciebie, w kodzie korzystającym z bazy danych, należy wymuszanie wszelkich relacji niezbędnych dla Twoich danych. W większości przypadków można również zobaczyć dane, które są tylko częściowo poprawne, więc nawet jeśli masz drzewo genealogiczne, w którym każda osoba ma być powiązana z rodzicami, może się zdarzyć, że jakiekolwiek ograniczenia, które nałożyłeś, tak naprawdę nie będą egzekwowane. Niektórzy pozwolą ci to robić do woli. Inni gwarantują, że dzieje się to tylko tymczasowo, chociaż można kwestionować, jak długo może / potrwa.

Relacyjna baza danych wykorzystuje formalny system predykatów do adresowania danych. Podstawowa implementacja fizyczna nie ma znaczenia i może się zmieniać w celu optymalizacji dla określonych operacji, ale zawsze musi zakładać model relacyjny . Mówiąc prostym językiem, oznacza to po prostu, że wiem dokładnie, ile wartości (atrybutów) ma każdy wiersz (krotka) w mojej tabeli (relacja), a teraz chcę odpowiednio wykorzystać ten fakt, dokładnie i do skrajności. Taka jest prawdziwa natura bestii. 

Ponieważ jesteśmy oczywiście pokoleniem, które miało relacyjne wychowanie, jeśli spojrzeć na modele baz danych NoSQL z perspektywy modelu relacyjnego, ponownie w kategoriach laika, pierwszą oczywistą różnicą jest to, że żadne założenia dotyczące liczby wartości w wierszu nie mogą zawierają jest kiedykolwiek. To naprawdę zbytnio upraszcza sprawę i nie odnosi się jasno do zawiłości fizycznych modeli każdej bazy danych NoSQL, ale jest to szczyt modelu relacyjnego i pierwsze założenie, które musimy porzucić lub, jeśli wolisz, największe skok, który musimy wykonać.

Możemy zgodzić się na dwie rzeczy, które są prawdziwe dla każdego DBMS: może przechowywać dowolne dane i ma wystarczającą ilość matematycznych podstaw, aby umożliwić zarządzanie danymi w dowolny możliwy sposób. Rzeczywistość jest taka, że ​​nigdy nie będziesz chciał popełnić błędu, poddając którykolwiek z dwóch punktów testowi, ale raczej trzymaj się tego, do czego naprawdę został stworzony system DBMS. Mówiąc prościej: szanujcie bestię w środku!

(Zwróć uwagę, że unikałem porównywania (oczywiście) dobrze ugruntowanych standardów obracających się wokół modelu relacyjnego z wieloma odmianami dostarczanymi przez bazy danych NoSQL. Jeśli chcesz, rozważ bazy danych NoSQL jako termin ogólny dla każdego DBMS, który nie jest całkowicie przyjmij model relacyjny, wykluczając wszystko inne. Różnic jest zbyt wiele, ale to jest główna różnica i myślę, że byłaby dla ciebie najbardziej przydatna do zrozumienia tych dwóch.)

Spróbuj wyjaśnić to pytanie na poziomie odnoszącym się do trochę technologii

Weźmy MongoDB i tradycyjny SQL dla porównania, wyobraź sobie scenariusz publikowania tweeta na Twitterze. Ten tweet zawiera 9 zdjęć. Jak przechowujesz ten tweet i odpowiadające mu zdjęcia?

Jeśli chodzi o tradycyjny SQL relacji, możesz przechowywać tweety i obrazy w oddzielnych tabelach i reprezentować połączenie poprzez utworzenie nowej tabeli.

Co więcej, możesz ustawić pole, które jest typem obrazu, spakować 9 zdjęć do dokumentu binarnego i zapisać go w tym polu.

Korzystając z MongoDB, możesz zbudować taki dokument (podobny do koncepcji tabeli w relacyjnym SQL):

{

"id":"XXX",

"user":"XXX",

"date":"xxxx-xx-xx",

"content":{

"text":"XXXX",

"picture":["p1.png","p2.png","p3.png"]

}

Dlatego moim zdaniem główna różnica polega na tym, w jaki sposób przechowujesz dane i jak zapamiętujesz relacje między nimi.

W tym przykładzie dane to tweet i zdjęcia. Różne mechanizmy dotyczące poziomu przechowywania relacji między nimi również odgrywają ważną rolę w różnicy między nimi.

Mam nadzieję, że ten mały przykład pomoże pokazać różnicę między SQL i NoSQL (ACID i BASE).

Oto link do obrazu o celach NoSQL z Internetu:

http://icamchuwordpress-wordpress.stor.sinaapp.com/uploads/2015/01/dbc795f6f262e9d01fa0ab9b323b2dd1_b.png

Różnica między relacją a nierelacją jest właśnie taka. Architektura relacyjnej bazy danych zapewnia obiekty ograniczeń, takie jak klucze podstawowe, klucze obce itp., Które umożliwiają powiązanie dwóch lub więcej tabel w relacji. Jest to dobre, abyśmy znormalizowali nasze tabele, co oznacza podzielenie informacji o tym, co reprezentuje baza danych, na wiele różnych tabel, raz może zachować integralność danych.

Załóżmy na przykład, że masz szereg tabel, w których znajdują się informacje o pracowniku. Nie można było usunąć rekordu z tabeli bez usunięcia wszystkich rekordów, które dotyczą takiego rekordu z innych tabel. W ten sposób wdrażasz integralność danych. Nierelacyjna baza danych nie zapewnia tych konstrukcji ograniczeń, które pozwolą na zaimplementowanie integralności danych.

Jeśli nie zaimplementujesz tego ograniczenia w aplikacji front-end, która jest używana do zapełniania tabel baz danych, wprowadzasz bałagan, który można porównać z dzikim zachodem.

Najpierw pozwól mi zacząć od wyjaśnienia, dlaczego potrzebujemy bazy danych.

Potrzebujemy bazy danych, która pomoże nam uporządkować informacje w taki sposób, abyśmy mogli odzyskać te przechowywane dane w efektywny sposób.

Przykłady systemów zarządzania relacyjnymi bazami danych (SQL):

1) Baza danych Oracle

2) SQLite

3) PostgreSQL

4) MySQL

5) Microsoft SQL Server

6) IBM DB2

Przykłady nierelacyjnych systemów zarządzania bazami danych (NoSQL)

1) MongoDB

2) Cassandra

3) Redis

4) Couchbase

5) HBase

6) DocumentDB

7) Neo4j

Relacyjne bazy danych mają znormalizowane dane, ponieważ informacje są przechowywane w tabelach w postaci wierszy i kolumn, a normalnie, gdy dane są w znormalizowanej formie, pomaga to zmniejszyć nadmiarowość danych, a dane w tabelach są zwykle ze sobą powiązane, więc kiedy Chcemy odzyskać dane, możemy zapytać o dane za pomocą instrukcji złączenia i pobierać dane zgodnie z naszymi potrzebami. jest to przydatne, gdy chcemy mieć więcej zapisów, mniej odczytów i nie wymaga dużo danych, a także jest to naprawdę łatwe względnie aktualizuj dane w tabelach niż w nierelacyjnych bazach danych. Skalowanie poziome niemożliwe, skalowanie pionowe możliwe do pewnego stopnia Zgodność z CAP (Consistency, Availability, Partition Tolerant) i ACID (Atomicity, Consistency, Isolation, Duration).

Pozwólcie, że pokażę wprowadzanie danych do relacyjnej bazy danych na przykładzie PostgreSQL.

Najpierw utwórz tabelę produktów w następujący sposób:

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric
);

następnie wstaw dane

INSERT INTO products (product_no, name, price) VALUES (1, 'Cheese', 9.99);

Spójrzmy na inny inny przykład:

Tutaj w relacyjnej bazie danych możemy połączyć tabelę uczniów i tabelę przedmiotów za pomocą relacji, za pomocą klucza obcego, identyfikatora podmiotu, ale w nierelacyjnej bazie danych nie ma potrzeby posiadania dwóch dokumentów, ponieważ nie ma relacji, więc przechowujemy wszystkie szczegóły przedmiotu i dane ucznia w jednym dokumencie mówią o dokumencie ucznia, a następnie dane są duplikowane, co sprawia, że ​​aktualizacja rekordów jest kłopotliwa.

W nierelacyjnych bazach danych nie ma ustalonego schematu, dane nie są znormalizowane. nie są tworzone żadne relacje między danymi, wszystkie dane są przeważnie umieszczane w jednym dokumencie. Dobrze nadaje się do obsługi dużej ilości danych i może przesyłać wiele danych naraz, najlepiej tam, gdzie duże ilości odczytów i mniej zapisów oraz mniej aktualizacji, co jest trudne do przeszukania danych, ponieważ nie ma ustalonego schematu. Możliwe jest skalowanie poziome i pionowe Zgodność z CAP (spójność, dostępność, tolerancja partycji) i BASE (zasadniczo dostępna, stan miękki, ostatecznie spójna).

Pokażę przykład wprowadzania danych do nierelacyjnej bazy danych za pomocą Mongodb

db.users.insertOne({name: ‘Mary’, age: 28 , occupation: ‘writer’ })
db.users.insertOne({name: ‘Ben’ , age: 21})

Stąd można zrozumieć, że do bazy danych o nazwie db, jest zbiór nazw użytkowników i dokument o nazwie insertOne, do którego dodajemy dane, i nie ma ustalonego schematu, ponieważ nasz pierwszy rekord ma 3 atrybuty, a drugi atrybut ma tylko 2 atrybuty , nie stanowi to problemu w nierelacyjnych bazach danych, ale nie można tego zrobić w relacyjnych bazach danych, ponieważ relacyjne bazy danych mają ustalony schemat.

Spójrzmy na inny inny przykład

({Studname: ‘Ash’, Subname: ‘Mathematics’, LecturerName: ‘Mr. Oak’})

Stąd widzimy, że w nierelacyjnych bazach danych możemy wprowadzić zarówno dane studenta, jak i szczegóły przedmiotu do jednego dokumentu, ponieważ żadne relacje nie są zdefiniowane w nierelacyjnych bazach danych, ale tutaj w ten sposób może prowadzić do duplikacji danych, a zatem mogą wystąpić błędy w aktualizacji.

Mam nadzieję, że to wszystko wyjaśnia

Mówiąc prostym językiem, jest to silnie ustrukturyzowane vs nieustrukturyzowane, co oznacza, że ​​masz różne stopnie adaptacji dla swojej bazy danych. Różnice pojawiają się w indeksacji, zwłaszcza gdy trzeba się upewnić, że dany indeks referencyjny może łączyć się z inną pozycją -> to jest relacja. Bardziej rygorystyczna struktura relacyjnej bazy danych wynika z tego wymagania.

Należy zauważyć, że NosDB obecnie zapewnia zarówno relacyjne, jak i nierelacyjne bazy danych, a także sposób na zapytanie http://www.alachisoft.com/nosdb/sql-cheat-sheet.html