Co to jest schemat relacyjny? Jak stworzyć wydajną bazę danych?

Nie ma jednej struktury bazy danych, która byłaby zawsze bardziej wydajna niż inne. Dzieje się tak, ponieważ typ i ilość przechowywanych danych zmienia optymalną strukturę bazy danych.

Jednakże istnieje duża różnica pomiędzy budowaniem bazy danych zoptymalizowanej pod kątem wydajności a takiej, która jest zoptymalizowana pod kątem ilości danych.

Używając schematu relacyjnego w MySQL, możesz stworzyć bazę danych, która jest zoptymalizowana pod kątem ilości danych. Jest to idealne rozwiązanie w sytuacjach, gdy koszty przechowywania, przetwarzania i pamięci są zbyt wysokie.

Jakkolwiek nie jest to już przypadek standardowej elektroniki, nadal istnieje wiele sytuacji, w których programiści i deweloperzy chcieliby korzystać ze schematu relacyjnego. Chociaż pamięć masowa, moc obliczeniowa i pamięć są niedrogie dla użytkowników konwencjonalnych komputerów, te rzeczy są bardzo drogie w świecie obliczeń kwantowych.

Schemat relacyjny jest również ważny w bazach danych MySQL, które polegają na relacjach w celu wygenerowania znaczenia. Na przykład dane pracowników i studentów mogą być łatwo postrzegane jako sieci relacji, które są lepiej opisane za pomocą schematu relacyjnego niż na przykład bazy danych typu klucz-wartość lub grafy.

Schemat relacyjny jest podstawowym elementem relacyjnej bazy danych. Te bazy danych są zarządzane przy użyciu języka i struktury, które są zgodne z logiką pierwszego rzędu. Pozwala to na zarządzanie bazą danych w oparciu o relacje między podmiotami, co ułatwia ich organizację według objętości.

Schemat relacyjny odnosi się do metadanych, które opisują strukturę danych w ramach pewnej domeny. Jest to schemat bazy danych, który określa sposób, w jaki jej struktura organizuje dane w tabele.

Na przykład, jeśli twoja baza danych zawiera rekordy pracowników dla dużego przedsiębiorstwa, to możesz mieć relacje encji opisujące każdego pracownika jako silną jednostkę w ten sposób:

  • Employee Name
  • ID Number
  • Address
  • Employee Skillset
  • Hiring Date
  • Years of Service

W tym przykładzie miałbyś dwa atrybuty danych schematu relacyjnego. Po pierwsze, miałbyś atrybut Pracownik, który jest kluczem podstawowym tabeli (ponieważ wszystko jest związane z pracownikiem) i atrybut Adres, który jest atrybutem złożonym składającym się z różnych elementów.

Atrybut Adres składałby się z następujących wartości:

  • Miasto
  • Ulica
  • Numer adresu
  • Kod pocztowy

Wiedząc to, jesteś gotowy do mapowania diagramu relacji encji do schematu relacyjnego. Powinien on wyglądać następująco:

  • Pracownik (Nazwisko, Numer identyfikacyjny, Numer adresu, Ulica, Miasto, Kod pocztowy, Data zatrudnienia)
  • Zestaw umiejętności pracownika (Numer identyfikacyjny, Zestaw umiejętności)

Powinieneś zauważyć, że Lata pracy są wykluczone z tej listy. Dzieje się tak, ponieważ jest to atrybut pochodny, który może być obliczony przez odjęcie daty zatrudnienia od daty bieżącej. Powodem, dla którego Umiejętności Pracownika mają swój własny schemat jest to, że jest to atrybut wielowartościowy.

W przypadku schematów relacyjnych, każdy typ encji staje się własną tabelą, a każdy atrybut jednowartościowy jest kolumną w tej tabeli. Atrybuty pochodne mogą być bezpiecznie zignorowane, podczas gdy atrybuty wielowartościowe stają się oddzielnymi tabelami.

Metoda konwersji słabych typów encji do schematu relacyjnego jest podobna do procesu opisanego powyżej, z wyjątkiem tego, że słabe typy encji stają się własnymi tabelami, a klucz główny silnej encji działa jako klucz obcy w tabeli.

To oznacza, że dla silnej encji Pracownik, stworzyłbyś złożony klucz główny składający się z klucza obcego Zależny i klucza samej słabej encji. W ten sposób schemat wyglądałby następująco:

  • Pracownik (Nazwisko, Numer ID, Numer adresu, Ulica, Miasto, Kod pocztowy, Data zatrudnienia)
  • Zależny (Pracownik, Zależny ID, Nazwisko, Adres)

Korelacja zachodzi pomiędzy Numerem ID w tabeli Pracownik i elementem Pracownik w tabeli Zależny.

Po wykonaniu tej pracy, jesteś gotowy do rozpoczęcia konwersji relacji. Wymaga to zrozumienia kardynalności i stopnia każdej relacji.

  • Istnieją trzy możliwe kardynalności – 1:1, 1:M, 1:N
  • Istnieją trzy możliwe stopnie – jednoargumentowy, binarny i trójargumentowy.

Przechodząc dalej do powyższego przykładu, można by połączyć Employee z nową tabelą Department, aby utworzyć binarną relację 1:1. Jeśli pracownik zarządza określonym działem, wówczas można go opisać jako uczestnika częściowego, natomiast dział zostałby opisany jako uczestnik całkowity.

Schemat relacyjny wyglądałby następująco:

  • Pracownik (Nazwisko, Numer identyfikacyjny, Numer adresu, Ulica, Miasto, Kod pocztowy, Data zatrudnienia)
  • Dział (Numer identyfikacyjny kierownika, Numer identyfikacyjny działu, Nazwa, Adres)

W tym przypadku klucz główny uczestnika częściowego staje się kluczem obcym uczestnika całkowitego. Numer identyfikacyjny menedżera koreluje z odpowiednim numerem identyfikacyjnym pracownika.

To pokazuje ważną część tworzenia schematu relacyjnego. Klucz główny jednego z uczestników relacji binarnej 1:1 może stać się kluczem obcym w drugiej relacji. Innym sposobem opisania powyższej relacji byłoby użycie Manages jako klucza obcego w pozycji Employee, korelującego z kluczem podstawowym Department ID w pozycji Department.

Przykładem relacji binarnej 1:N byłaby relacja między nauczycielem uczącym przedmiotu. W danej klasie nauczyciele mogą uczyć więcej niż jednego przedmiotu różnych uczniów, ale wszystkie przedmioty mają tę samą relację z nauczycielem.

W powyższej relacji binarnej 1:1 każdy dział miał unikalnego menedżera. W tej binarnej relacji 1:N, zmienna liczba studentów może dzielić tego samego nauczyciela. Kluczem podstawowym Nauczyciela byłby identyfikator Nauczyciela, który byłby skorelowany z kluczem obcym Przedmiotu, pod Nauczycielem.

Aby opisać binarną relację M:N, wyobraź sobie studenta zapisującego się na kurs. Utwórz nową tabelę opisującą Studenta i inną opisującą Kurs. Obie te tabele są powiązane poprzez akt zapisania się na kurs i obie posiadają klucze obce.

  • Kluczem obcym dla Studenta jest identyfikator Studenta.
  • Kluczem obcym dla Kursu jest identyfikator Kursu.

Kluczem głównym nowej tabeli jest kombinacja kluczy obcych każdej encji. Można go opisać jako (ID studenta, ID kursu). Jest to unikalny binarny schemat relacyjny M:N, który łączy poszczególnych studentów z kursami.

To działa, ponieważ identyfikatory są z natury tworzone w celu bycia kluczami obcymi w relacyjnych bazach danych.

Możesz użyć schematu relacyjnego do opisania relacji samoodnoszących się do siebie. Na przykład dwóch pracowników, którzy są ze sobą w związku małżeńskim, może posiadać klucz obcy Spouse. Dla obu tych kluczy obcych pracownika, odniesienie będzie do ID pracownika, który jest kluczem podstawowym każdej tabeli pracownika.

To działa również w schemacie relacji z kardynalnością 1:N. Samo pole klucza podstawowego stałoby się kluczem obcym tej samej tabeli w tym przypadku. To jest to samo, co schemat unarny 1:1.

Na przykład Pracownik, który jest kierownikiem podwładnego może mieć kierownika jako swój klucz obcy. W tym przypadku identyfikator pracownika byłby kluczem głównym w tej samej tabeli.

Samodzielne odniesienie do relacji M:N wymaga dwóch tabel. Jedna musi reprezentować podmiot, o którym mowa, a druga musi reprezentować relację M:N.

Wyobraź sobie pracownika, który jest odpowiedzialny za zagwarantowanie jakości pewnego produktu lub usługi. Ta relacja musiałaby zawierać zarówno Gwaranta, jak i Beneficjenta jako klucze obce, które łączą się w celu skorelowania z identyfikatorem pracownika w tabeli Employee. Zarówno Gwarant i Beneficjent będą działać jako klucze podstawowe i obce w nowo utworzonej tabeli schematu relacyjnego.

Podczas gdy relacje binarne i unarne są proste do opisania przy użyciu schematu relacyjnego z jedną lub dwiema tabelami. Tabele trójstronne wymagają trzeciej, nowej tabeli.

Klucz główny tej nowej tabeli składa się z klucza obcego każdej uczestniczącej encji, dodanego razem. Oznacza to, że nowa tabela musi zawierać trzy klucze obce do korelacji.

Na przykład, relacja między lekarzem a jej pacjentem składa się w rzeczywistości z trzech podmiotów: Lekarz, Pacjent i Lekarstwo. Aby poprawnie opisać tę relację jako schemat relacyjny, musisz przypisać klucze obce do każdej z tych encji i skorelować je z nową tabelą o nazwie Recepta.

Jest to prosty sposób wizualizacji sposobu działania tabeli trójdzielnej. Kluczem głównym nowo utworzonej tabeli Prescription jest (ID lekarza, ID pacjenta, ID leku). Każdy schemat, który nie zawiera tych trzech ważnych elementów danych, jest pozbawiony ważnej części układanki.

Takie podejście pozwoliłoby administratorowi bazy danych na stworzenie zorganizowanego archiwum recept, które uwzględnia konkretne typy leków, natychmiast skorelowane z nazwiskami pacjentów, którzy ich używają, i oferuje nazwiska lekarzy, którzy je przepisali.

Dla kompletności możesz dodać datę ważności do tabeli Leki, aby te dane były dostępne w głównej macierzy. Możesz dodać Next Appointment lub Refill Date do tabeli Prescription. Logicznie chciałbyś dodać datę urodzenia, adres i inne ważne dane relacyjne do tabeli Pacjent.

Wszystkie te narzędzia łączą się, aby umożliwić tworzenie baz danych zorientowanych na relacje w MySQL. Możesz ćwiczyć tworzenie własnych baz danych MySQL online za pomocą dowolnej przeglądarki przy użyciu SQLDBM.

.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.