MODEL RELACYJNEJ BAZY DANYCH: ELEMENTY, JAK TO ZROBIĆ, PRZYKŁAD - TECHNOLOGIA - 2025

Model relacyjnej bazy danych to metoda strukturyzowania danych za pomocą relacji, przy użyciu struktur przypominających siatkę, składających się z kolumn i wierszy. Jest to koncepcyjna zasada relacyjnych baz danych. Zaproponował go Edgar F. Codd w 1969 roku.

Od tego czasu stał się dominującym modelem bazy danych dla aplikacji biznesowych w porównaniu z innymi modelami baz danych, takimi jak hierarchiczne, sieciowe i obiektowe.

Źródło: pixabay.com

Codd nie miał pojęcia, jak niezwykle ważna i wpływowa będzie jego praca jako platformy relacyjnych baz danych. Większość ludzi dobrze zna fizyczny wyraz relacji w bazie danych: tabela.

Model relacyjny jest zdefiniowany jako baza danych, która umożliwia grupowanie elementów danych w jednej lub kilku niezależnych tabelach, które mogą być ze sobą powiązane za pomocą pól wspólnych dla każdej powiązanej tabeli.

Zarządzania bazami danych

Tabela bazy danych jest podobna do arkusza kalkulacyjnego. Jednak relacje, które można utworzyć między tabelami, pozwalają relacyjnej bazie danych na wydajne przechowywanie dużej ilości danych, które można skutecznie pobrać.

Celem modelu relacyjnego jest zapewnienie deklaratywnej metody określania danych i zapytań: użytkownicy bezpośrednio deklarują, jakie informacje zawiera baza danych i jakie informacje chcą od niej.

Z drugiej strony pozostawiają to oprogramowaniu systemu zarządzania bazą danych opisanie struktur danych do przechowywania i procedury wyszukiwania w celu udzielenia odpowiedzi na zapytania.

Większość relacyjnych baz danych używa języka SQL do wykonywania zapytań i definiowania danych. Obecnie istnieje wiele systemów zarządzania relacyjnymi bazami danych lub RDBMS (Relational Data Base Management System), takich jak Oracle, IBM DB2 i Microsoft SQL Server.

Funkcje i elementy

- Wszystkie dane są koncepcyjnie reprezentowane jako uporządkowany układ danych w wierszach i kolumnach, zwany relacją lub tabelą.

- Każda tabela musi mieć nagłówek i treść. Nagłówek to po prostu lista kolumn. Treść to zestaw danych wypełniających tabelę, uporządkowany w wierszach.

- Wszystkie wartości są skalarami. Oznacza to, że w dowolnej pozycji wiersza / kolumny w tabeli jest tylko jedna wartość.

-Elementy

Poniższy rysunek przedstawia tabelę z nazwami jej podstawowych elementów, które składają się na pełną strukturę.

Tuple

Każdy wiersz danych to krotka, nazywana także rekordem. Każdy wiersz jest n-krotką, ale „n-” jest generalnie odrzucane.

Kolumna

Każda kolumna krotki jest nazywana atrybutem lub polem. Kolumna reprezentuje zestaw wartości, które może mieć określony atrybut.

Klucz

Każdy wiersz zawiera jedną lub więcej kolumn nazywanych kluczem tabeli. Ta połączona wartość jest unikatowa dla wszystkich wierszy w tabeli. Za pomocą tego klucza każda krotka zostanie jednoznacznie zidentyfikowana. Oznacza to, że klucza nie można powielić. Nazywa się to kluczem podstawowym.

Z drugiej strony klucz obcy lub pomocniczy to pole w tabeli, które odwołuje się do klucza podstawowego innej tabeli. Służy do odwoływania się do tabeli podstawowej.

-Zasady uczciwości

Projektując model relacyjny, definiujesz pewne warunki, które muszą być spełnione w bazie danych, zwane regułami integralności.

Kluczowa integralność

Klucz podstawowy musi być unikatowy dla wszystkich krotek i nie może mieć wartości null (NULL). W przeciwnym razie nie będziesz w stanie jednoznacznie zidentyfikować wiersza.

W przypadku klucza wielokolumnowego żadna z tych kolumn nie może zawierać wartości NULL.

Więzy integralności

Każda wartość klucza obcego musi odpowiadać wartości klucza podstawowego tabeli, do której się odwołuje lub tabeli podstawowej.

Wiersz z kluczem obcym można wstawić do tabeli dodatkowej tylko wtedy, gdy ta wartość istnieje w tabeli podstawowej.

Jeśli wartość klucza zmieni się w tabeli podstawowej z powodu aktualizacji lub usunięcia wiersza, wszystkie wiersze w tabelach pomocniczych z tym kluczem obcym powinny zostać odpowiednio zaktualizowane lub usunięte.

Jak zrobić model relacyjny?

-Zbierz dane

Aby móc przechowywać je w bazie danych, należy zebrać niezbędne dane. Dane te są podzielone na różne tabele.

Dla każdej kolumny należy wybrać odpowiedni typ danych. Na przykład: liczby całkowite, liczby zmiennoprzecinkowe, tekst, data itp.

-Definiuj klucze podstawowe

Dla każdej tabeli należy wybrać kolumnę (lub kilka kolumn) jako klucz podstawowy, który będzie jednoznacznie identyfikował każdy wiersz w tabeli. Klucz podstawowy służy również do odwoływania się do innych tabel.

-Utwórz relacje między tabelami

Baza danych składająca się z niezależnych, niepowiązanych tabel ma niewielki cel.

Najważniejszym aspektem projektowania relacyjnej bazy danych jest identyfikacja relacji między tabelami. Typy relacji to:

Jeden za dużo

W bazie danych „Class Listing” nauczyciel może prowadzić zero lub więcej zajęć, podczas gdy zajęcia są prowadzone przez jednego nauczyciela. Ten typ relacji jest znany jako jeden do wielu.

Tej relacji nie można przedstawić w jednej tabeli. W bazie danych «Lista zajęć» możesz mieć tabelę Nauczyciele, która przechowuje informacje o nauczycielach.

Aby przechowywać zajęcia nauczane przez każdego nauczyciela, możesz utworzyć dodatkowe kolumny, ale napotkasz problem: ile kolumn utworzyć.

Z drugiej strony, jeśli masz tabelę o nazwie Classes, która przechowuje informacje o klasie, możesz utworzyć dodatkowe kolumny do przechowywania informacji o nauczycielu.

Ponieważ jednak nauczyciel może nauczać na wielu zajęciach, jego dane byłyby zduplikowane w wielu wierszach tabeli Zajęcia.

Zaprojektuj dwa stoły

Dlatego musisz zaprojektować dwie tabele: tabelę Classes do przechowywania informacji o zajęciach, z Class_Id jako kluczem podstawowym oraz tabelę Teachers do przechowywania informacji o nauczycielach, z kluczem podstawowym Teacher_Id.

Relację jeden do wielu można następnie utworzyć, przechowując klucz podstawowy z tabeli Master (Master_Id) w tabeli Classes, jak pokazano poniżej.

Kolumna Master_Id w tabeli Classes jest nazywana kluczem obcym lub kluczem pomocniczym.

Dla każdej wartości Master_Id w tabeli Master może znajdować się zero lub więcej wierszy w tabeli Classes. Dla każdej wartości Class_Id w tabeli Classes istnieje tylko jeden wiersz w tabeli Teachers.

Wiele do wielu

W bazie danych „Sprzedaż produktów” zamówienie klienta może zawierać wiele produktów, a produkt może występować w wielu zamówieniach. Ten typ relacji jest znany jako wielu do wielu.

Bazę danych „Sprzedaż produktów” można uruchomić z dwiema tabelami: Produkty i Zamówienia. Tabela Produkty zawiera informacje o produktach, z kluczem podstawowym productID.

Z drugiej strony tabela Zamówienia zawiera zamówienia klienta, z kluczem podstawowym orderID.

Nie możesz przechowywać zamówionych produktów w tabeli Zamówienia, ponieważ nie wiesz, ile kolumn zarezerwować dla produktów. Z tego samego powodu nie można również przechowywać zamówień w tabeli Produkty.

Aby obsługiwać relację wiele do wielu, musisz utworzyć trzecią tabelę, zwaną tabelą łączenia (OrderDetails), w której każdy wiersz reprezentuje element w określonej kolejności.

W tabeli OrderDetails klucz podstawowy składa się z dwóch kolumn: orderID i productID, które jednoznacznie identyfikują każdy wiersz.

Kolumny orderID i productID w tabeli OrderDetails służą do odwoływania się do tabel Zamówienia i Produkty. Dlatego są również kluczami obcymi w tabeli OrderDetails.

Jeden po drugim

W bazie danych „Sprzedaż produktów” produkt może mieć opcjonalne informacje, takie jak dodatkowy opis i jego zdjęcie. Pozostawienie go w tabeli Produkty wygenerowałoby wiele pustych miejsc.

W związku z tym można utworzyć inną tabelę (ProductExtras) do przechowywania opcjonalnych danych. Dla produktów z danymi opcjonalnymi zostanie utworzony tylko jeden rekord.

Dwie tabele, Products i ProductExtras, mają relację jeden do jednego. Dla każdego wiersza w tabeli Products istnieje maksymalnie jeden wiersz w tabeli ProductExtras. Ten sam identyfikator produktu musi być używany jako klucz podstawowy dla obu tabel.

Korzyść

Strukturalna niezależność

W modelu relacyjnej bazy danych zmiany w strukturze bazy danych nie wpływają na dostęp do danych.

Gdy możliwe jest dokonanie zmian w strukturze bazy danych bez wpływu na zdolność DBMS do dostępu do danych, można powiedzieć, że uzyskano niezależność strukturalną.

Koncepcyjna prostota

Model relacyjnej bazy danych jest koncepcyjnie jeszcze prostszy niż model hierarchicznej lub sieciowej bazy danych.

Ponieważ model relacyjnej bazy danych uwalnia projektanta od szczegółów dotyczących fizycznego przechowywania danych, projektanci mogą skupić się na logicznym widoku bazy danych.

Łatwość projektowania, wdrażania, konserwacji i użytkowania

Model relacyjnej bazy danych zapewnia zarówno niezależność danych, jak i niezależność od struktury, co sprawia, że ​​projektowanie, konserwacja, zarządzanie i używanie bazy danych jest znacznie łatwiejsze niż w przypadku innych modeli.

Pojemność zapytań ad hoc

Obecność bardzo potężnych, elastycznych i łatwych w użyciu funkcji zapytań jest jednym z głównych powodów ogromnej popularności modelu relacyjnej bazy danych.

Język zapytań modelu relacyjnej bazy danych, nazywany strukturalnym językiem zapytań lub SQL, sprawia, że ​​zapytania ad hoc stają się rzeczywistością. SQL to język czwartej generacji (4GL).

4GL pozwala użytkownikowi określić, co należy zrobić, bez określania, jak należy to zrobić. W ten sposób, korzystając z SQL, użytkownicy mogą określić, jakie informacje chcą i pozostawić szczegóły dotyczące sposobu pobierania informacji do bazy danych.

Niedogodności

Wydatki na sprzęt

Model relacyjnej bazy danych ukrywa złożoność jego implementacji oraz szczegóły fizycznego przechowywania danych użytkownika.

Aby to zrobić, systemy relacyjnych baz danych potrzebują komputerów z wydajniejszym sprzętem i urządzeniami do przechowywania danych.

Dlatego RDBMS potrzebuje wydajnych maszyn do płynnego działania. Ponieważ jednak moc obliczeniowa nowoczesnych komputerów rośnie wykładniczo, zapotrzebowanie na większą moc obliczeniową w dzisiejszym scenariuszu nie jest już bardzo dużym problemem.

Łatwość projektowania może prowadzić do złego projektu

Relacyjna baza danych jest łatwa w projektowaniu i obsłudze. Użytkownicy nie muszą znać skomplikowanych szczegółów dotyczących fizycznego przechowywania danych. Nie muszą wiedzieć, w jaki sposób dane są faktycznie przechowywane, aby uzyskać do nich dostęp.

Ta łatwość projektowania i użytkowania może prowadzić do rozwoju i wdrażania źle zaprojektowanych systemów zarządzania bazami danych. Ponieważ baza danych jest wydajna, te nieefektywności projektowe nie wyjdą na jaw podczas projektowania bazy danych i gdy jest tylko niewielka ilość danych.

W miarę rozwoju bazy danych źle zaprojektowane bazy danych spowalniają system i prowadzą do obniżenia wydajności i uszkodzenia danych.

Fenomen „wysp informacyjnych”

Jak wspomniano wcześniej, systemy relacyjnych baz danych są łatwe do wdrożenia i użytkowania. Stworzy to sytuację, w której zbyt wiele osób lub działów utworzy własne bazy danych i aplikacje.

Te wyspy informacji uniemożliwiają integrację informacji, która jest niezbędna dla sprawnego i wydajnego funkcjonowania organizacji.

Te indywidualne bazy danych będą również powodować problemy, takie jak niespójność danych, powielanie danych, nadmiarowość danych itp.

Przykład

Załóżmy, że baza danych zawiera tabele dostawców, części i przesyłek. Struktura tabel i niektórych przykładowych rekordów jest następująca:

Każdy wiersz w tabeli Dostawcy jest identyfikowany za pomocą unikalnego numeru dostawcy (SNo), który jednoznacznie identyfikuje każdy wiersz w tabeli. Podobnie każda część ma unikalny numer części (PNo).

Ponadto w tabeli Przesyłki nie może istnieć więcej niż jedna przesyłka dla danej kombinacji Dostawca / Część, ponieważ ta kombinacja jest kluczem podstawowym przesyłek, który służy jako tabela sumująca, ponieważ jest to relacja wiele do wielu.

Zależność między tabelami Części i Przesyłki jest podawana poprzez wspólne posiadanie pola PNo (numer części), a związek między dostawcami a wysyłkami wynika z posiadania wspólnego pola SNo (numer dostawcy).

Analizując tabelę wysyłek, można uzyskać informację, że od dostawców Suneet i Ankit wysyłanych jest łącznie 500 orzechów, po 250 każdy.

Podobnie wysłano łącznie 1100 śrub od trzech różnych dostawców. 500 niebieskich śrub zostało wysłanych od dostawcy Suneet. Brak przesyłek czerwonych śrub.

Bibliografia

1. Wikipedia, wolna encyklopedia (2019). Model relacyjny. Zaczerpnięte z: en.wikipedia.org.
2. Techopedia (2019). Model relacyjny. Zaczerpnięte z: sufitpedia.com.
3. Dinesh Thakur (2019). Model relacyjny. Uwagi do komputera. Zaczerpnięte z: ecomputernotes.com.
4. Geeks for Geeks (2019). Model relacyjny. Zaczerpnięte z: geeksforgeeks.org.
5. Uniwersytet Technologiczny Nanyang (2019). Samouczek Szybki start dotyczący projektowania relacyjnych baz danych. Zaczerpnięte z: ntu.edu.sg.
6. Adrienne Watt (2019). Rozdział 7 Relacyjny model danych. BC Open Textbooks. Zaczerpnięte z: opentextbc.ca.
7. Toppr (2019). Relacyjne bazy danych i schematy. Zaczerpnięte z: toppr.com.