Relacyjne elementy modelu bazy danych, jak to zrobić, przykład

On Model relacyjny baz danych Jest to metoda struktury danych przy użyciu relacji poprzez struktury w kształcie siatki, które składają się z kolumn i wierszy. Jest to pojęciowa zasada relacyjnych baz danych. Został zaproponowany przez Edgar F. Codd w 1969 roku.

Od tego czasu stał się dominującym modelem bazy danych dla aplikacji komercyjnych, w porównaniu z innymi modelami bazy danych, takimi jak hierarchiczne, sieć i obiekt.

Źródło: Pixabay.com

CODD nie miał pojęcia o niezwykle ważnym i wpływowym, które byłyby jego pracą jako platformę dla relacyjnych baz danych. Większość ludzi jest bardzo zaznajomiona z fizyczną ekspresją związku w bazie danych: tabela.

Model relacyjny jest zdefiniowany jako baza danych, która pozwala zgrupować elementy danych w jednej lub więcej niezależnych tabelach, które można ze sobą powiązać za pomocą wspólnych pól z każdej powiązanej tabeli.

[TOC]

Zarządzania bazami danych

Baza danych jest podobna do arkusza kalkulacyjnego. Jednak relacje, które można stworzyć między tabelami, pozwalają relacyjnej bazie danych efektywne przechowywanie dużej ilości danych, które można skutecznie odzyskać.

Celem modelu relacyjnego jest dostarczenie deklaratywnej metody określenia danych i konsultacji: Użytkownicy bezpośrednio deklarują, jakie informacje zawiera baza danych i jakie informacje chcesz od niej.

Z drugiej strony pozwalają oprogramowaniu systemu zarządzania bazą danych za opisanie struktur danych do procedury przechowywania i odzyskiwania.

Większość relacyjnych baz danych używa języka SQL do konsultacji i definicji danych. Obecnie istnieje wiele relacyjnych systemów zarządzania bazami danych lub RDBM (relacyjny system zarządzania bazą danych), takich jak Oracle, IBM DB2 i Microsoft SQL Server.

Charakterystyka i elementy

- Wszystkie dane są koncepcyjnie reprezentowane jako uporządkowane rozmieszczenie danych w rzędach i kolumnach, zwane relacją lub tabelą.

- Każdy stół musi mieć nagłówek i ciało. Nagłówek to po prostu lista kolumn. Ciało to zbiór danych wypełniających tabelę, zorganizowaną w wierszach.

- Wszystkie wartości to wspinaczki. To znaczy, w dowolnej pozycji wiersza/kolumny w tabeli, istnieje tylko jedna unikalna wartość.

-Rzeczy

Poniższy rysunek pokazuje tabelę z nazwami jego podstawowych elementów, które stanowią pełną strukturę.

Tupla

Każdy wiersz danych to Tupla, znany również jako rejestracja. Każdy rząd jest n-tupla, ale „n-” jest ogólnie wykluczony.

Kolumna

Każda kolumna Tupla nazywa się atrybutem lub polem. Kolumna reprezentuje zestaw wartości, które może mieć określony atrybut.

Wskazówka

Każdy wiersz ma jedną lub więcej kolumn zwanych tabelą. Ta łączna wartość jest unikalna dla wszystkich rzędów tabeli. Za pośrednictwem tego klucza każda tupla zostanie zidentyfikowana w sposób jednoznaczny. To znaczy nie można powielić klucza. Nazywa się to kluczowym kluczem.

Z drugiej strony klucz zewnętrzny lub wtórny to pole tabeli, która odnosi się do klucza podstawowego innego tabeli. Służy do odniesienia do tabeli podstawowej.

-Zasady uczciwości

Podczas projektowania modelu relacyjnego zdefiniowane są pewne warunki, które należy spełnić w bazie danych, zwane regułami integralności.

Może ci służyć: makrokomputery: historia, cechy, zastosowania, przykłady

Kluczowa integralność

Klucz podstawowy musi być unikalny dla wszystkich krotek i nie może mieć wartości zerowej (null). W przeciwnym razie nie będziesz w stanie zidentyfikować wyłącznie wiersza.

Dla klucza złożonego z kilku kolumn żadna z tych kolumn nie może zawierać null.

Więzy integralności

Każda wartość klucza zewnętrznego musi się pokryć z wartością klucza podstawowego w tabeli odwołanej lub podstawowej.

W tabeli wtórnej tylko jeden wiersz można włożyć do klucza zewnętrznego, jeśli ta wartość istnieje w tabeli podstawowej.

Jeśli wartość klucza zmienia się w tabeli podstawowej, w celu aktualizacji lub eliminowania wiersza, wszystkie wiersze w tabelach wtórnych z tym kluczem zewnętrznym muszą być odpowiednio zaktualizowane lub wyeliminowane.

Jak zrobić model relacyjny?

-Zbieraj dane

Należy zebrać niezbędne dane do przechowywania w bazie danych. 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 punktów pływających, tekst, data itp.

-Zdefiniuj kluczowe klucze

Dla każdej tabeli musisz wybrać kolumnę (lub kilka kolumn) jako klucz podstawowy, który jednoznacznie zidentyfikuje każdy wiersz tabeli. Klucz podstawowy jest również używany w odniesieniu do innych tabel.

-Twórz relacje między tabelami

Baza danych składająca się z niezależnych i niepowiązanych tabel ma niewiele celów.

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

Jeden za dużo

W bazie danych „zajęć” nauczyciel może uczyć na zero lub więcej zajęciach, a klasę uczy jednego nauczyciela. Ten rodzaj relacji jest znany jako jeden dla wielu.

Ten związek nie może być reprezentowany w pojedynczej tabeli. W bazie danych „Lista klas” możesz mieć tabelę o nazwie Teachers, która przechowuje informacje o nauczycielach.

Aby przechowywać zajęcia nauczane przez każdego nauczyciela, można stworzyć dodatkowe kolumny, ale problem by się borykać: ile kolumn tworzy.

Z drugiej strony, jeśli masz tabelę o nazwie klasy, przechowuje informacje o klasie, można utworzyć dodatkowe kolumny do przechowywania informacji o nauczycielu.

Jednak jako nauczyciel może uczyć na wielu klasach, jego dane byłyby podwojone w wielu szeregach w tabeli klas.

Zaprojektuj dwa tabele

Dlatego należy zaprojektować dwa tabele: tabela klas do przechowywania informacji o zajęciach, klasa z_dem jako głównym kluczem oraz tabela główna do przechowywania informacji o nauczycielach, z głównym kluczem nauczyciela jako głównym kluczem.

Następnie możesz utworzyć związek jeden do wielu przechowywania klucza podstawowego tabeli głównej (master_id) w tabeli klas, jak pokazano poniżej.

Kolumna master_id w tabeli klas jest znana jako klucz zewnętrzny lub wtórny.

Dla każdej wartości master_id w tabeli głównej może być zero lub więcej wierszy w tabeli klas. Dla każdej wartości klasy_id w tabeli klas jest tylko jeden wiersz w tabeli głównej.

Wielu dla wielu

W bazie danych „sprzedaż produktów” zamówienie klienta może zawierać kilka produktów, a produkt może pojawić się w kilku zamówieniach. Ten rodzaj relacji jest znany dla wielu.

Może ci służyć: ICT (technologie informacyjne i komunikacyjne)

Możesz uruchomić bazę danych „Sprzedaż produktów” z dwoma tabelami: produkty i zamówienia. Tabela produktów zawiera informacje o produktach, a produkt jako klucz podstawowy.

Z drugiej strony zamówienia zawierają zamówienia klientów, z żądaniem kodu podstawowego.

Nie można przechowywać produktów żądanych w zamówionej tabeli, ponieważ nie wiadomo, ile kolumn rezerwuje produkty. Z tego samego powodu nie można przechowywać zamówień w produktach stołowych.

Aby przyznać się do wielu do wielu, konieczne jest utworzenie trzecie.

Dla tabeli żądającej klucz podstawowy składa się z dwóch kolumn: zamówienia i produktu, identyfikując każdy wiersz każdy wiersz.

Żądane i kolumny produktów na żądanie metod są używane do odwołania się do zamówień i produktów. Dlatego są to również zewnętrzne klucze do żądania żądania.

Jeden po drugim

W bazie danych „Sprzedaż produktów” produkt może mieć opcjonalne informacje, jako dodatkowy opis i jego obraz. Trzymaj go w środku produkty generowałyby wiele pustych przestrzeni.

Dlatego możesz utworzyć inną tabelę (produkt Extexts), aby przechowywać dane opcjonalne. Utworz się tylko rekord produktów z opcjonalnymi danymi.

Dwie tabele, produkty i produkt, mają relację jedną do jednego. Dla każdego wiersza w tabeli produktów jest maksymalny wiersz w tabeli produktów. Ten sam produkt powinien być używany jako główny klucz dla obu tabel.

Zalety

Niezależność strukturalna

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

Gdy możliwe jest wprowadzenie zmian w strukturze bazy danych bez wpływu na zdolność DBMS do dostępu do danych, można powiedzieć, że niezależność strukturalna została osiągnięta.

Konceptualna prostota

Model relacyjny bazy danych jest jeszcze prostszy na poziomie koncepcyjnym niż model hierarchiczny lub sieć bazy danych.

Ponieważ relacyjny model bazy danych uwalnia projektanta ze szczegóły fizycznego przechowywania danych, projektanci mogą skoncentrować się na logicznym widoku bazy danych.

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

Model relacyjnej bazy danych osiąga zarówno niezależność danych, jak i niezależność struktury, co sprawia, że ​​projekt, konserwacja, administracja i korzystanie z bazy danych jest znacznie łatwiejsze niż inne modele.

Zdolność konsultacyjna ad hoc

Obecność bardzo potężnej, elastycznej i łatwej zdolności konsultacyjnej do użycia jest jednym z głównych powodów ogromnej popularności modelu relacyjnego bazy danych.

Język konsultacyjny relacyjnego modelu bazy danych, zwany językiem konsultacji ustrukturyzowanej lub SQL, czyni zapytania ad-hoc. SQL to język czwartej generacji (4GL).

4GL pozwala użytkownikowi określić, co należy zrobić, bez określenia, w jaki sposób należy to zrobić. Zatem wraz z użytkownikami SQL mogą określić, jakie informacje chcą i zostawić szczegóły dotyczące uzyskania informacji do bazy danych.

Niedogodności

Wydatki sprzętowe

Model relacyjny bazy danych ukrywa złożoność jej implementacji i szczegóły fizycznego przechowywania danych użytkownika.

Może ci służyć: jakie są kody G? (Z przykładem)

Aby to zrobić, relacyjne systemy baz danych wymagają komputerów z mocniejszym sprzętem i pamięcią.

Dlatego RDBMS potrzebuje potężnych maszyn do pracy bez problemów. Ponieważ jednak moc przetwarzania współczesnych komputerów rośnie w tempie wykładniczym, potrzeba większej mocy obliczeniowej w obecnym scenariuszu nie jest już bardzo dużym problemem.

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

Relacyjna baza danych jest łatwa do zaprojektowania i użycia. Użytkownicy nie muszą znać złożonych szczegółów fizycznego przechowywania danych. Nie muszą wiedzieć, w jaki sposób dane są naprawdę przechowywane, aby uzyskać do nich dostęp.

Ta konstrukcja i łatwość użycia mogą prowadzić do opracowania i wdrażania bardzo słabo zaprojektowanych systemów zarządzania bazami danych. Ponieważ baza danych jest wydajna, te nieefektywności projektowe nie wyjdą na jaw, gdy baza danych jest zaprojektowana i gdy jest tylko niewielka ilość danych.

W miarę wzrostu bazy danych słabo zaprojektowane bazy danych spowolnią system i spowodują degradację wydajności danych i uszkodzenia.

Zjawisko „wysp informacyjnych”

Jak powiedziano wcześniej, relacyjne systemy baz danych są łatwe do wdrożenia i użycia. Stworzy to sytuację, w której zbyt wiele osób lub działów stworzy własne bazy danych i aplikacji.

Te wyspy informacyjne unikną integracji informacji, która jest niezbędna do płynu i wydajnego funkcjonowania organizacji.

Te poszczególne bazy danych stworzą również problemy, takie jak niespójność danych, powielanie danych, nadmiarowość danych itp.

Przykład

Załóżmy, że baza danych składająca się z przypuszczalnych tabel, kawałków i przesyłek. Struktura tabel i niektóre przykładowe rekordy przedstawiono poniżej:

Każdy rząd w tabeli zasilaczy jest identyfikowany przez unikalny numer dostawcy (SNO), wyjątkowo identyfikując każdy wiersz tabeli. Podobnie, każdy element ma unikalny numer części (PNO).

Ponadto w kombinacji dostawcy / sztuk może być nie więcej niż jedna przesyłka dla danego dostawcy / sztuk, ponieważ ta kombinacja jest głównym kluczem wysyłkowym, który służy jako stół ujednolicony, ponieważ wiele jest relacji z wieloma z wieloma.

Związek tabel i przesyłek podaje się poprzez posiadanie wspólnego pola PNO (numer elementu), a związek między dostawcami a przesyłkami wynika z posiadania wspólnego pola SNO (numer dostawcy).

Analiza tabeli przesyłek można uzyskać jako informacje, które są wysyłane łącznie 500 orzechów z dostawców SUNEET i ANKIT, 250 każdy.

Podobnie, wysłano 1.W sumie 100 śrub od trzech różnych dostawców. 500 niebieskich śrub wysłano od dostawcy SUNEEet. Nie ma przesyłek czerwonych śrub.

Bibliografia

1. Wikipedia, The Free Encyclopedia (2019). Model relacyjny. Zaczerpnięte z: w.Wikipedia.org.
2. Ravepedia (2019). Model relacyjny. Zaczerpnięte z: Ravepedia.com.
3. Diesh Thakur (2019). Model relacyjny. Notatki ecomputer. Zaczerpnięte z: ecomputternotes.com.
4. Geeks dla Geeks (2019). Model relacyjny. Zaczerpnięte z: Geeksforgeeks.org.
5. Nanyang Technological University (2019). Szybki samouczek dotyczący projektowania relacyjnej bazy danych. Zaczerpnięte z: NTU.Edu.Sg.
6. Adrienne Watt (2019). Rozdział 7 Model danych relacji. BC Otwórz podręczniki. Zaczerpnięte z: openTextBC.AC.
7. Toppr (2019). Relacyjne bazy danych i schematy. Zaczerpnięte z: toppr.com.