Projekt bazy danych - Database design

Projektowanie bazy danych to organizacja danych według modelu bazy danych . Projektant określa, jakie dane muszą być przechowywane i jak elementy danych są ze sobą powiązane. Dzięki tym informacjom mogą zacząć dopasowywać dane do modelu bazy danych. System zarządzania bazą danych odpowiednio zarządza danymi.

Projektowanie bazy danych obejmuje klasyfikację danych i identyfikację wzajemnych relacji. Ta teoretyczna reprezentacja danych nazywana jest ontologią . Ontologia jest teorią stojącą za projektem bazy danych.

Określanie danych do przechowywania

W większości przypadków osoba, która zajmuje się projektowaniem bazy danych, to osoba posiadająca wiedzę specjalistyczną w zakresie projektowania baz danych, a nie wiedzę w dziedzinie, z której pochodzą dane, które mają być przechowywane, np. informacje finansowe, informacje biologiczne itp. W związku z tym dane, które mają być przechowywane w bazie, muszą być ustalane we współpracy z osobą, która ma wiedzę w tej dziedzinie i która wie, jakie dane muszą być przechowywane w systemie.

Proces ten jest powszechnie uważany za część analizy wymagań i wymaga umiejętności ze strony projektanta bazy danych, aby uzyskać potrzebne informacje od osób posiadających wiedzę o danej dziedzinie . Dzieje się tak, ponieważ osoby posiadające niezbędną wiedzę dziedzinową często nie mogą jasno wyrazić, jakie są ich wymagania systemowe dotyczące bazy danych, ponieważ nie są przyzwyczajone do myślenia w kategoriach dyskretnych elementów danych, które muszą być przechowywane. Dane, które mają być przechowywane, można określić w specyfikacji wymagań.

Określanie relacji danych

Gdy projektant bazy danych jest świadomy danych, które mają być przechowywane w bazie danych, musi następnie określić, gdzie w danych znajduje się zależność. Czasami po zmianie danych możesz zmienić inne dane, które nie są widoczne. Na przykład na liście nazwisk i adresów, zakładając sytuację, w której wiele osób może mieć ten sam adres, ale jedna osoba nie może mieć więcej niż jednego adresu, adres jest zależny od nazwiska. Po podaniu nazwy i listy adres może być jednoznacznie określony; jednak odwrotność nie obowiązuje - po podaniu adresu i listy nie można jednoznacznie określić nazwiska, ponieważ pod jednym adresem może mieszkać wiele osób. Ponieważ adres jest określany przez nazwisko, adres jest uważany za zależny od nazwy.

(UWAGA: Powszechnym błędnym przekonaniem jest to, że model relacyjny jest tak nazywany z powodu stwierdzenia relacji między elementami danych. To nieprawda. Model relacyjny jest tak nazwany, ponieważ opiera się na strukturach matematycznych znanych jako relacje .)

Logicznie strukturyzujące dane

Główny artykuł: Schemat logiczny

Po określeniu relacji i zależności pomiędzy różnymi fragmentami informacji, możliwe jest uporządkowanie danych w strukturę logiczną, która może być następnie odwzorowana na obiekty pamięci obsługiwane przez system zarządzania bazą danych . W przypadku relacyjnych baz danych obiektami storage są tabele przechowujące dane w wierszach i kolumnach. W bazie danych Object obiekty pamięci masowej odpowiadają bezpośrednio obiektom używanym przez obiektowy język programowania używany do pisania aplikacji, które będą zarządzać danymi i uzyskiwać do nich dostęp. Relacje mogą być zdefiniowane jako atrybuty zaangażowanych klas obiektów lub jako metody operujące na klasach obiektów.

Sposób, w jaki to mapowanie jest ogólnie wykonywane, jest taki, że każdy zestaw powiązanych danych, które zależą od pojedynczego obiektu, rzeczywistego lub abstrakcyjnego, jest umieszczany w tabeli. Relacje między tymi zależnymi obiektami są następnie przechowywane jako powiązania między różnymi obiektami.

Każda tabela może reprezentować implementację obiektu logicznego lub relacji łączącej jedno lub więcej wystąpień jednego lub więcej obiektów logicznych. Relacje między tabelami mogą być następnie przechowywane jako łącza łączące tabele podrzędne z rodzicami. Ponieważ złożone relacje logiczne same w sobie są tabelami, prawdopodobnie będą miały łącza do więcej niż jednego rodzica.

Diagram ER (model relacji encji)

Przykładowy diagram relacji encja

Projekty baz danych zawierają również diagramy ER ( model relacji encji). Diagram ER to diagram, który pomaga w efektywnym projektowaniu baz danych.

Atrybuty na diagramach ER są zwykle modelowane jako owal z nazwą atrybutu, połączony z encją lub relacją zawierającą atrybut.

Modele ER są powszechnie stosowane w projektowaniu systemów informatycznych; na przykład są one używane do opisywania wymagań informacyjnych i/lub rodzajów informacji, które mają być przechowywane w bazie danych podczas fazy projektowania koncepcyjnego konstrukcji.

Propozycja procesu projektowania dla Microsoft Access

  1. Określ przeznaczenie bazy danych — pomaga to przygotować się do pozostałych kroków.
  2. Znajdź i uporządkuj wymagane informacje — Zbierz wszystkie rodzaje informacji do zapisania w bazie danych, takie jak nazwa produktu i numer zamówienia.
  3. Podziel informacje na tabele — podziel informacje na główne jednostki lub tematy, takie jak Produkty lub Zamówienia. Każdy przedmiot staje się wtedy tabelą.
  4. Przekształć elementy informacyjne w kolumny — zdecyduj, jakie informacje mają być przechowywane w każdej tabeli. Każdy element staje się polem i jest wyświetlany jako kolumna w tabeli. Na przykład tabela Pracownicy może zawierać pola takie jak Nazwisko i Data zatrudnienia.
  5. Określ klucze podstawowe — wybierz klucz podstawowy każdej tabeli. Klucz podstawowy to kolumna lub zestaw kolumn, który służy do jednoznacznego identyfikowania każdego wiersza. Przykładem może być ID produktu lub ID zamówienia.
  6. Skonfiguruj relacje między tabelami — spójrz na każdą tabelę i zdecyduj, w jaki sposób dane w jednej tabeli są powiązane z danymi w innych tabelach. W razie potrzeby dodaj pola do tabel lub utwórz nowe tabele, aby wyjaśnić relacje.
  7. Udoskonal projekt — Przeanalizuj projekt pod kątem błędów. Utwórz tabele i dodaj kilka rekordów przykładowych danych. Sprawdź, czy wyniki pochodzą z tabel zgodnie z oczekiwaniami. W razie potrzeby wprowadź poprawki w projekcie.
  8. Zastosuj reguły normalizacji — zastosuj reguły normalizacji danych, aby sprawdzić, czy tabele mają prawidłową strukturę. W razie potrzeby dostosuj tabele.

Normalizacja

Główny artykuł: Normalizacja bazy danych

W dziedzinie projektowania relacyjnych baz danych normalizacja jest systematycznym sposobem zapewnienia, że ​​struktura bazy danych jest odpowiednia do wykonywania zapytań ogólnego przeznaczenia i jest wolna od pewnych niepożądanych cech — anomalii wstawiania, aktualizacji i usuwania, które mogą prowadzić do utraty integralności danych .

Standardową częścią wskazówek dotyczących projektowania bazy danych jest to, że projektant powinien utworzyć w pełni znormalizowany projekt; selektywną denormalizację można następnie przeprowadzić, ale tylko ze względu na wydajność . Kompromisem jest miejsce na dane w porównaniu z wydajnością. Im bardziej znormalizowany jest projekt, tym mniej jest nadmiarowości danych (a tym samym zajmuje mniej miejsca do przechowywania), jednak wspólne wzorce pobierania danych mogą teraz wymagać złożonych łączeń, scalania i sortowania - co zajmuje więcej danych czytać i obliczać cykle. Niektóre dyscypliny modelowania, takie jak podejście modelowania wymiarowego do projektowania hurtowni danych , wyraźnie zalecają projekty nieznormalizowane, tj. projekty, które w dużej mierze nie są zgodne z 3NF. Normalizacja składa się z normalnych form, które są 1NF,2NF,3NF,BOYCE-CODD NF (3.5NF),4NF i 5NF

Bazy danych dokumentów przyjmują inne podejście. Dokument przechowywany w takiej bazie danych zazwyczaj zawiera więcej niż jedną znormalizowaną jednostkę danych, a często także relacje między jednostkami. Jeśli wszystkie jednostki danych i relacje, o których mowa, są często pobierane razem, to podejście to optymalizuje liczbę pobierań. Upraszcza również sposób replikacji danych, ponieważ teraz istnieje wyraźnie identyfikowalna jednostka danych, której spójność jest niezależna. Inną kwestią jest to, że odczytanie i zapisanie pojedynczego dokumentu w takich bazach danych będzie wymagało pojedynczej transakcji - co może być ważnym czynnikiem w architekturze mikrousług . W takich sytuacjach często fragmenty dokumentu są pobierane z innych usług za pośrednictwem interfejsu API i przechowywane lokalnie ze względu na wydajność. Jeśli jednostki danych miałyby zostać podzielone na usługi, wówczas odczyt (lub zapis) w celu obsługi konsumenta usługi może wymagać więcej niż jednego wywołania usługi, co może skutkować zarządzaniem wieloma transakcjami, co może nie być preferowane.

Schemat koncepcyjny

Główny artykuł: Schemat koncepcyjny

Projekt fizyczny

Główny artykuł: Schemat fizyczny

Fizyczny projekt bazy danych określa fizyczną konfigurację bazy danych na nośniku pamięci. Obejmuje to szczegółową specyfikację elementów danych , typy danych , indeksowane opcji i innych parametrów przebywających w DBMS słowniku danych . Jest to szczegółowy projekt systemu, który zawiera moduły oraz specyfikacje sprzętowe i programowe bazy danych systemu. Niektóre aspekty, które są adresowane w warstwie fizycznej:

  • Bezpieczeństwo - użytkownika końcowego, a także bezpieczeństwo administracyjne.
  • Replikacja — jakie fragmenty danych są kopiowane do innej bazy danych i jak często. Czy istnieje wiele mistrzów, czy jeden?
  • Wysoka dostępność — niezależnie od tego, czy konfiguracja jest aktywna-pasywna, czy aktywna-aktywna, należy zdefiniować topologię, schemat koordynacji, cele niezawodności itp.
  • Partycjonowanie - jeśli baza danych jest rozproszona, to dla pojedynczego podmiotu, w jaki sposób dane są dystrybuowane na wszystkie partycje bazy danych i jak uwzględniana jest awaria partycji.
  • Schematy tworzenia kopii zapasowych i przywracania.

Na poziomie aplikacji inne aspekty projektowania fizycznego mogą obejmować konieczność zdefiniowania procedur składowanych lub widoków zmaterializowanych zapytań, kostek OLAP itp.

Zobacz też

Bibliografia

Dalsza lektura

Linki zewnętrzne