Koncepcje projektowania bazy danych za pomocą programu SQL Server Management Studio (SSMS) część 1

Ten artykuł jest przeznaczony głównie dla początkujących. Mimo to obejmuje kilka interesujących i często zapomnianych koncepcji projektowania baz danych, które są równie atrakcyjne dla profesjonalistów baz danych SQL.

Bieżąca część koncentruje się na koncepcjach projektowania baz danych i ich mapowaniu na tabele, kolumny i relacje SQL Database. Jeśli rozumiesz podstawy baz danych i narzędzi, których będziemy używać, z pewnością zaprojektujesz swoją pierwszą bazę danych SQL.

Warunki wstępne

Zanim przejdziemy dalej, upewnij się, że masz następujące rzeczy:

1. SQL Server 2016/2017/2019 wersja Express/Developer jest zainstalowana na Twoim komputerze
2. Zainstalowano SSMS (SQL Server Management Studio)

Ponadto musisz mieć podstawową wiedzę na temat baz danych i powyższych narzędzi.

Nie stanowi to problemu, jeśli nie masz najnowszych wersji SQL Server i SSMS. Jednak zdecydowanie zaleca się posiadanie nowszych wersji, jeśli nie najnowszych dostępnych. Niezbędne wersje można pobrać z poniższych zasobów:

• Pobierz wersję SQL Server 2017 Developer.
• Pobierz SQL Server 2019 (alternatywnie, aby uzyskać najnowszą wersję SQL Server Express/Developer).
• Lub Pobierz bezpłatną specjalistyczną edycję Developer lub Express SQL Server.
• Pobierz SSMS (SQL Server Management Studio)

Pamiętaj, że wszystkie te linki działają dobrze w momencie pisania tego artykułu. Jeśli Microsoft zdecyduje się je zastąpić, pobierz nowszą dostępną wersję.

Informacje o projektowaniu baz danych SQL

Aby rozpocząć projektowanie bazy danych SQL za pomocą SQL Server Management Studio (SSMS), musisz mieć w głowie jakiś plan projektowania.

Nie jest to łatwe bez znajomości podstawowych koncepcji projektowania baz danych. Jednak kiedy już zdobędziesz te koncepcje i ich wdrożenie, w naturalny sposób zaczniesz przestrzegać zasad projektowania. Jest to powszechne u prawie wszystkich programistów baz danych.

Przejdźmy najpierw przez kilka podstawowych koncepcji projektowania baz danych. Nie jest łatwo omówić je wszystkie w jednym artykule, ale potrzebujemy czegoś na początek.

Typową bazę danych rozumiemy pod następującymi warunkami:

1. Podmioty
2. Atrybuty
3. Związki

Co to jest podmiot?

Jednostka to wszystko, co firma lub osoba fizyczna chciałaby przechowywać w bazie danych. Na przykład:

1. Klient.
2. Zamów.
3. Produkt.

Można powiedzieć, że Klient jest podmiotem, jeśli firma chce przechowywać go w strukturze bazy danych do celów transakcyjnych, analitycznych i raportowych. Podobnie Zamówienie umieszczone przez Klienta jest również podmiotem, jeśli firma chce zobaczyć te informacje. Dlatego te informacje muszą być częścią bazy danych.

Jednak Zamówienie nie ma większego sensu bez produktu . Oferowany Klientowi Produkt jest jednocześnie podmiotem.

W jaki sposób jednostka jest mapowana do bazy danych?

Z perspektywy bazy danych encja może być zmapowana do tabeli. Tak więc, jeśli firma potrzebuje jednostek Klienta, Zamówienia i Produktu, programista bazy danych może zmapować je jako trzy tabele.

Co to jest atrybut?

Atrybut to opis jednostki. Na przykład:

1. Nazwa klienta
2. Typ zamówienia
3. Nazwa produktu

Jeśli Klient jest podmiotem, nazwa klienta (CustomerName ) jest atrybutem. Ten atrybut opisuje naszą jednostkę (Klient ). Podobnie Typ zamówienia jest atrybutem Zamówienia podmiot i ProductName jest atrybutem Produktu podmiot.

W jaki sposób atrybut jest mapowany do bazy danych?

Atrybut, taki jak Nazwa klienta, opisuje Klienta tabeli i mogą być mapowane do kolumny w tej tabeli.

Jednostka z wieloma atrybutami

Jednostka może mieć wiele atrybutów. Dlatego możemy mieć wiele kolumn (atrybutów) w tabeli (encji).

Relacje z podmiotami

Jednostka może być powiązana z inną jednostką poprzez relacje. Tabela może być powiązana z inną tabelą. Istnieje wiele rodzajów encji lub relacji tabelarycznych:

Relacja klient-zamówienie (jeden do wielu)

Klient (podmiot/tabela) może być powiązany z Zamówieniem (podmiot/tabela) z następujących powodów:

1. Klient może złożyć jedno zamówienie.
2. Klient może złożyć wiele zamówień.

Prawdą jest również coś przeciwnego:

1. Jeden klient może złożyć wiele zamówień.
2. Jedno zamówienie może złożyć jeden klient.

To jest przykład relacji jeden-do-wielu :jeden klient może złożyć wiele zamówień, a jeden klient może złożyć wiele zamówień.

Relacja produkt-zamówienie (jeden do wielu)

Produkt (podmiot/tabela) może być powiązany z Zamówieniem (podmiot/tabela) w następujący sposób:

1. Produkt można przypisać do jednego zamówienia.
2. Produkt można przypisać do wielu zamówień.

Podobnie:

1. Do produktu można przypisać wiele zamówień.
2. Jedno zamówienie może mieć jeden produkt.

Pomiędzy Produktem istnieje relacja jeden-do-wielu i Zamów .

Relacja klient-produkt (wiele do wielu)

Teraz relacja między klientem a produktem jest wyjaśniona w następujący sposób:

1. Klient może kupić jeden produkt.
2. Klient może kupić więcej niż jeden produkt.
3. Produkt może kupić klient.
4. Produkt może kupić więcej niż jeden klient.

Wiele produktów może kupić wielu klientów, co oznacza, że ​​Klient i Produkt związek to wiele do wielu .

Spójrz na poniższą ilustrację:

Scenariusz projektowania ucznia-instruktora

Rozważmy inny scenariusz projektowania bazy danych. Zaimplementujesz go za pomocą SSMS (SQL Server Management Studio) w drugiej części tego artykułu.

Wymagania biznesowe

Załóżmy, że musisz zaprojektować bazę danych, która przechowuje następujące informacje:

1. Student(cy).
2. Instruktorzy.
3. Uczniowie, którym przydzielono instruktora.
4. Instruktorzy przypisani do uczniów.

Analiza wstępna

Po uważnej obserwacji odkryjesz coś całkiem interesującego na temat powyższych wymagań. „Uczniowie, którzy przydzielili instruktora” i „Instruktorzy, którzy zostali przypisani do uczniów” są tym samym wymaganiem.

Często zdarza się, że dwa różnie wyglądające wymagania okazują się takie same w kontekście projektowania bazy danych.

Zidentyfikuj jednostki

Następujące jednostki można od razu wyodrębnić z wymagań:

1. Student
2. Instruktor

Jednak jeszcze jeden podmiot służy do dostarczania nam informacji o instruktorach przydzielonych uczniom.

Przypomnijmy pierwszy przykład, w którym użyliśmy tabeli Order – wielu klientów może kupić wiele zamówień w relacji Klient-Zamówienie. Jest podobny do naszego studenta-instruktora relacja tabelaryczna – wielu instruktorów może być przydzielonych do wielu uczniów.

Zidentyfikuj atrybuty

Możemy wybrać przydatne atrybuty dla zidentyfikowanych podmiotów, zgodnie ze scenariuszem zamówienia klienta:

1. Student:legitymacja studencka, imię i nazwisko.
2. Instruktor:identyfikator instruktora, imię i nazwisko.
3. Student-instruktor:legitymacja ucznia-instruktora, legitymacja ucznia, legitymacja instruktora.

Relacje tożsamościowe:

Zidentyfikuj relacje podmiotów:

1. Student -> Uczeń-Instruktor (jeden do wielu).
2. Instruktor->Uczeń-Instruktor (jeden do wielu).
3. Student -> Instruktor (wielu do wielu).

Pamiętaj, że zawsze używamy środkowego stołu, aby rozwiązać relację wiele do wielu. Dlatego do planu włączyliśmy jednostkę Student-Instruktor.

Mapowanie jednostek i atrybutów do tabel i kolumn

Teraz możemy zmapować encje do tabel. Dlatego stworzymy następujące trzy tabele:

1. Student.
2. Instruktor.
3. Student-Instruktor.

Podobnie atrybuty tych jednostek, po zmapowaniu do kolumn, będą wyglądać następująco:

1. Student:identyfikator studenta, imię i nazwisko.
2. Instruktor:identyfikator instruktora, imię.
3. Student-Instruktor:StudentInstructorId, StudentId, InstructorId.

Zwróć uwagę na ilustrację poniżej:

Gratulacje! Pomyślnie nauczyłeś się koncepcji projektowania baz danych. Znamy encje, atrybuty i relacje oraz kroki, aby zmapować je do tabel i kolumn w bazie danych.

Następne artykuły przeprowadzą Cię przez etapy projektowania bazy danych za pomocą SSMS (SQL Server Management Studio).

Rzeczy do zrobienia

Teraz, gdy znasz już podstawy projektowania baz danych, spróbuj następujących rzeczy, aby jeszcze bardziej poprawić swoje umiejętności:

1. Spróbuj dodać inną jednostkę o nazwie Dostawca z atrybutami SupplierId i SupplierName. Sprawdź, czy potrafisz poprawnie zidentyfikować następujące relacje:
   1. Zamówienie dostawcy;
   2. Dostawca-Klient;
   3. Produkt dostawcy.
2. Zaprojektuj bazę danych wraz z identyfikacją jednostek, atrybutów i relacji dla biblioteki. Podpowiedź:Książki są wydawane członkom, a członkowie wypożyczają książki z biblioteki. Członek, Książka, Wydane mogą być bytami.
3. Zidentyfikuj typ następujących relacji tabelarycznych dla podmiotów, jak wspomniano powyżej:
   1. Wydane przez członka;
   2. książka wydana;
   3. Książka członkowska;
   4. Książka-członek.

Przeczytaj także

Naucz się projektowania baz danych w SQL Server Management Studio (SSMS) – część 2