Czym jest Relational Database? Zalety i wady baz danych relacyjnych.
Każdy program ma bazę danych. To w niej przechowujesz wszystkie informacje niezbędne do działania Twojego oprogramowania. W tym artykule przyjrzymy się jednemu z najpopularniejszych typów baz danych – Relational Database.
Zanim wyjaśnimy, co oznacza "relacyjny", odświeżmy podstawy: czym jest baza danych? To proste. Baza danych to zbiór danych zapisanych w odpowiednim formacie. Format, w którym zapisywane są dane, determinuje sposób dostępu do nich.
W zależności od aplikacji, dane są zapisywane inaczej, a sposób zapisu wpływa na wydajność poszczególnych operacji (zapisywanie, odczytywanie, usuwanie i modyfikowanie danych). Jeśli chcesz dowiedzieć się więcej o inżynierii danych, odwiedź naszą stronę data engineering consultancy.
Istnieje wiele typów baz danych, a Relational Database jest bardzo popularna.
Czym jest Relational Database?
Termin "baza danych relacyjnych" został po raz pierwszy wprowadzony w 1970 roku przez Dr. Edgara Teda Codda z IBM.
W Relational Database użytkownik konfiguruje relacje, a informacje są przechowywane i pobierane zgodnie z tą konfiguracją. W tym modelu dane są przechowywane w prostych, liniowych plikach, zwanych "relacjami" lub "tabelami".
Operacje w bazach danych relacyjnych oparte są na algebrze relacji. Algebra relacji to zbiór operatorów, które manipulują relacjami; w ten sposób wynik i argumenty tych operatorów są relacjami. Operatory te można podzielić na dwie grupy:
- Operacje na zbiorach
- Operatory zaprojektowane dla modelu relacyjnego
Model relacyjny wprowadził SQL (Structured Query Language), który jest głównym językiem używanym do uzyskiwania dostępu i modyfikowania danych w bazach danych.
Podstawy implementacji Relational Database
Bazy danych mają różne implementacje. Różnią się również w wersji SQL, którą obsługują. Chociaż istnieje standard opisujący język SQL, istnieją pewne niewielkie różnice między SQL obsługiwanym przez poszczególne bazy danych. Różne wersje SQL nazywane są dialektami.
Można spotkać wiele implementacji Relational Database. Kilka z najczęściej używanych implementacji wymieniono poniżej:
- PostgreSQL
- MySQL
- SQLite
- Oracle
- SQL Server
- HyperSQL
Podstawową jednostką operacyjną języka SQL jest zapytanie. Istnieją trzy podstawowe typy zapytań wyszukiwania danych (tzw. zapytania select):
- Projekcja (wybór tylko niektórych pól/atrybutów, cech, kolumn)
- Selekcja (wybór rekordów/wierszy spełniających jeden określony warunek)
- Łączenie (scalanie danych z różnych tabel)
Zalety Relational Databases
Istnieją trzy kluczowe rzeczy, które sprawiają, że Relational Databases są bardzo przydatne:
- Prosty, ale potężny model relacyjny może być używany przez przedsiębiorstwa wszystkich typów i rozmiarów do zaspokojenia szerokiego zakresu potrzeb informacyjnych.
- Relational Databases mogą być używane do śledzenia zapasów, przetwarzania transakcji e-commerce, zarządzania dużymi ilościami kluczowych informacji o klientach i nie tylko.
- Relational Database może być używana do zaspokojenia wszelkich potrzeb informacyjnych w sytuacjach, w których elementy danych są powiązane i muszą być zarządzane w bezpieczny, oparty na regułach i spójny sposób.
Mimo że Relational Databases istnieją od lat 70., zalety modelu relacyjnego sprawiły, że jest to najszerzej akceptowany model bazy danych do dziś i prawdopodobnie tak pozostanie w dającej się przewidzieć przyszłości.
Co należy wziąć pod uwagę przy wyborze Relational Database?
Oprogramowanie używane do przechowywania, pobierania, zarządzania i modyfikowania danych przechowywanych w Relational Database nazywa się relational database management system (RDBMS).
RDBMS zapewnia interfejs między użytkownikami, aplikacjami i bazą danych. System zarządzania bazą danych zapewnia również dostęp do funkcji administracyjnych ułatwiających zarządzanie przechowywaniem danych, dostępem i wydajnością.
Istnieje kilka czynników, które wpływają na wybór konkretnego typu bazy danych i produktów Relational Database. Wybór RDBMS zależy od potrzeb biznesowych firmy. Dokonując tego wyboru, należy zadać sobie następujące pytania:
- Jakie są nasze wymagania dotyczące dokładności danych?
- Czy retencja i dokładność danych zależą od logiki biznesowej?
- Czy nasze dane podlegają ścisłym wymaganiom dotyczącym dokładności (na przykład dane finansowe i raporty dla organów publicznych)?
- Czy potrzebujemy skalowalności?
- Jaka jest skala zarządzanych danych i jaki jest oczekiwany wzrost ich ilości? Czy model bazy danych będzie musiał obsługiwać mirroring bazy danych (jako oddzielne instancje) w celu skalowania? Jeśli tak, czy może utrzymać spójność danych między tymi instancjami?
- Jak ważna jest współbieżność?
- Czy wielu użytkowników i wiele aplikacji będzie potrzebowało jednoczesnego dostępu do danych? Czy oprogramowanie bazy danych obsługuje współbieżność, chroniąc jednocześnie dane?
- Jakie są nasze potrzeby w zakresie wydajności i niezawodności? Czy potrzebujemy produktu o wysokiej wydajności i niezawodności?
- Jakie są wymagania dotyczące wydajności odpowiedzi na zapytania? Jakie są zobowiązania dostawcy dotyczące umów o poziomie usług (SLA) lub nieplanowanych przestojów?
Główne zasady Relational Databases (i SQL)
Relational Databases (jak również ich standard, SQL) oparte są na czterech prostych zasadach:
- Wszystkie wartości danych oparte są na prostych typach danych.
- Wszystkie dane w Relational Database prezentowane są w formie dwuwymiarowych tabel (zwanych "relacjami").
Każda tabela zawiera zero lub więcej wierszy (w tym "krotki") i jedną lub więcej kolumn ("atrybuty"). Każdy wiersz składa się z równomiernie ułożonych kolumn wypełnionych wartościami, które z kolei mogą być różne w każdym wierszu. - Po wprowadzeniu danych do bazy danych możliwe jest porównywanie wartości z różnych kolumn, zwykle również z różnych tabel, i scalanie wierszy, gdy ich wartości pasują.
Umożliwia to wiązanie danych i wykonywanie stosunkowo złożonych operacji w całej bazie danych. Wszystkie operacje są logiczne, niezależnie od pozycji wiersza tabeli. Wiersze w Relational Database są przechowywane w całkowicie dowolnej kolejności – nie musi ona odzwierciedlać kolejności, w jakiej są wprowadzane lub przechowywane.
Rodzaje relacji:
- jeden-do-jednego (jeśli pojedynczy rekord z pierwszej tabeli ma co najwyżej jeden rekord z drugiej tabeli i odwrotnie)
- jeden-do-wielu (jeśli pojedynczy rekord z pierwszej tabeli może mieć jeden lub więcej rekordów z drugiej tabeli, ale pojedynczy rekord z drugiej tabeli ma co najwyżej jeden rekord z pierwszej tabeli).
- wiele-do-wielu (występuje, gdy jeden rekord z pierwszej tabeli ma wiele rekordów z drugiej tabeli, a jeden rekord z drugiej tabeli ma wiele rekordów z pierwszej tabeli).
- Ponieważ wiersza nie można zidentyfikować po jego pozycji, w całej tabeli musi istnieć jedna lub więcej unikalnych kolumn, umożliwiających znalezienie konkretnego wiersza.
Kolumny te są znane jako "klucz podstawowy" tabeli.
Należy pamiętać, że klucz podstawowy nie zawsze występuje we wszystkich tabelach. Ponadto można również mieć klucze obce — trochę jak hiperłącze, klucz obcy odnosi się do klucza podstawowego z innej tabeli, łącząc ze sobą dwie tabele.
Aby przygotować bazę danych, wykonaj następujące kroki:
- Definicja wymagań
- Wstępne projektowanie formularzy i raportów
- Przygotowanie tabel
- Definiowanie relacji
- Tworzenie formularzy
- Tworzenie instrukcji – zapytań i raportów
Aby przygotować tabele, postępuj zgodnie z tymi pięcioma zasadami:
- Przypisz jedną kategorię informacji do jednej tabeli.
- W każdej kolumnie tabeli powinna znajdować się pojedyncza informacja.
- Używaj nazw, które pozwolą uniknąć zamieszania lub niejasności.
- Unikaj powtarzania tych samych informacji w kilku tabelach.
- Lista danych nie powinna być przechowywana w jednym polu.
W Relational Databases istnieją różne nieodłączne ograniczenia, takie jak ograniczenie integralności referencyjnej. Na przykład, jeśli masz dwie tabele z wierszem Customer ID, ID #1 musi istnieć i być taki sam w obu tabelach.
- Dane powinny być znormalizowane
Normalizacja polega na organizowaniu danych w taki sposób, aby płynnie przepływały do, z i wokół bazy danych.
To trochę jak organizowanie walizki na długie wakacje. Jeśli po prostu wrzucisz wszystko losowo, będziesz mieć ograniczoną przestrzeń i stracisz czas na przekopywanie się przez wszystkie swoje rzeczy, aby znaleźć to, czego potrzebujesz.
Ale jeśli zorganizujesz swoją walizkę za pomocą kilku prostych zasad (na przykład ciasno wszystko złożyć, oddzielić różne grupy ubrań itp.), nagle masz więcej miejsca i wszystko jest natychmiast dostępne.
W Relational Databases zasady te nazywane są "postaciami normalnymi" (normal forms). Nie pasują one do wszystkich scenariuszy z życia wziętych, ale są dobrym punktem odniesienia, aby upewnić się, że Twoja baza danych jest spójna.
Wady Relational Databases
Nie wszyscy są fanami Relational Databases. Programiści mogą nie lubić tego typu baz danych, ponieważ:
- To stara technologia
- Model relacyjny został wynaleziony rok po lądowaniu na Księżycu. Niektórzy programiści uważają, że jest przestarzały i wolą używać nowoczesnych alternatyw.
- Model relacyjny i język SQL mogą być trudne
- Programista może nie lubić modelu relacyjnego lub języka SQL. To kwestia preferencji i wymagań projektu, podobnie jak wybór między programowaniem obiektowym a programowaniem funkcyjnym lub między Pythonem a Ruby. Popularnym zarzutem wobec SQL i Relational Databases jest to, że trudno jest sprawić, by robiły dokładnie to, czego chcesz.
- Relational Databases nie skalują się dobrze
- Utrzymanie Relational Database w ogromnym projekcie (czyli coś w rodzaju Facebooka lub korporacyjnej aplikacji big data) może być bardzo kosztowne i trudne. Niektóre nowoczesne typy oprogramowania po prostu nie działałyby dobrze z Relational Database, dlatego stworzono wiele alternatyw jako zamienniki.
- Jest dużo narzutu
- Model relacyjny jest zbudowany wokół określonej struktury. Zapewnia integralność danych, ale aby to zrobić, zmusza Cię do przeskakiwania przez pewne przeszkody dla prostych operacji, takich jak odczytywanie danych. Jeśli potrzebujesz dużej elastyczności, jeśli chodzi o Twoje dane (zwłaszcza jeśli masz niespójnie ustrukturyzowane dane), możesz potrzebować poszukać alternatywy.
Kiedy używać Relational Databases
Oto kilka podstawowych wskazówek, kiedy używać Relational Databases:
- Gdy masz średnie obciążenia, takie jak tysiące operacji na sekundę (jeśli wykonujesz miliony transakcji na sekundę, SQL Cię spowolni).
- Twoje dane są ustrukturyzowane i nie zmieniają się cały czas.
- Relacje danych oparte są na znormalizowanych modelach danych (jeśli potrzebujesz zdenormalizowanych modeli danych, SQL nie będzie pasował).
- Musisz wykonywać złożone zapytania w swojej bazie danych (jeśli potrzebujesz tylko prostych zapytań, SQL będzie zbyt duży).
- Używasz zastrzeżonego sprzętu do wdrożenia bazy danych (jeśli używasz hostingu w chmurze, SQL może nie być najlepszym wyborem ze względu na koszty).
Alternatywy dla Relational Databases – nowoczesne modele baz danych
Ponieważ Relational Databases oparte są na SQL, alternatywy nazywane są ogólnie NoSQL. Istnieją różne podejścia do NoSQL, niektóre z tych baz danych obsługują nawet języki zapytań podobne do SQL. Głównym wyróżnikiem NoSQL jest to, że te bazy danych są nierelacyjne.
Istnieją cztery typy baz danych NoSQL:
- Key-value stores
- Ten typ bazy danych jest bardzo podobny do słownika (ludzie faktycznie nazywają je słownikami, a także "tablicami mieszającymi"). Klucz jest przypisany do jednej i tylko jednej wartości w bazie danych i to jest podstawa, na której budowane są wszystkie relacje. Jest to prosty typ bazy danych, który bardzo dobrze się skaluje, ale ma ograniczoną funkcjonalność.
- Graph stores
- Tutaj nie masz tabel. Masz węzły i połączenia między nimi, gdzie zarówno węzły, jak i połączenia mogą również mieć właściwości w formie par klucz-wartość. Relational Database jest świetna, jeśli musisz zdefiniować jedną relację. Gdy masz wiele węzłów, które są połączone w złożony sposób, Relational Database nie poradzi sobie z tym, a graph store jest znacznie lepszy.
- Column stores
- To jest jak Relational Database, tylko przechowuje tabele danych według kolumn, a nie według wierszy. Z tego powodu column store jest świetny dla aplikacji do analizy. Są dobre do obliczania statystyk na dużej części poszczególnych tabel.
- Document stores
- To w zasadzie to, co mówi nazwa – baza danych, która przechowuje dane w formie dokumentów (w formacie XML, JSON, a nawet PDF). Jeśli Twoja aplikacja nie potrzebuje danych tabelarycznych lub potrzebujesz szybkiego dostępu w pamięci, document store może być dla Ciebie. Każdy dokument ma swój własny schemat (w przeciwieństwie do Relational Database, gdzie każdy wiersz w tabeli musi mieć te same kolumny).
Podsumowanie
Chociaż model relacyjny jest już dojrzałą, 50-letnią technologią, w najbliższej przyszłości nie ma alternatywy, która by go zastąpiła. Rynek baz danych rozwija się cały czas, a co za tym idzie, rośnie zapotrzebowanie na specjalistów od baz danych.
Nowoczesne organizacje wykorzystują bazy danych nie tylko do przechowywania danych i wykonywania transakcji, ale także do analizowania danych. Dzięki bazom danych i innym narzędziom do przetwarzania i analizy biznesowej organizacje mogą wykorzystywać zebrane dane do wydajniejszego działania, podejmowania lepszych decyzji oraz poprawy elastyczności i skalowalności.
Tworząc bazę danych dla swojego projektu, wybór odpowiedniego modelu danych jest krytyczną decyzją długoterminową. Jeśli szukasz wsparcia, możemy pomóc Ci dokonać właściwego wyboru, aby zapewnić odpowiednią wydajność Twojej aplikacji przy rozsądnych kosztach.
Databricks polaczenie z klastrem z lokalnego ide
Systemy rozproszone i twierdzenie cap