Understanding Database Building Blocks in SQL Server

Polub ten Blog 3

dodane przez Peter Avila listopad 21, 2012

każdy dom ma kuchnię, co najmniej jedną łazienkę i sypialnię, drzwi wejściowe, system hydrauliczny i inne rzeczy. Te rzeczy mogą być rozmieszczone na różne sposoby i w różnych ilościach, aby produkować różne domy. Tak jest z bazami danych. Są pewne rzeczy, które wszystkie bazy danych mają ze sobą wspólnego. W tym poście przedstawię elementy składowe wszystkich baz danych i pokażę, jak są one montowane. Omówię również trzy zasady, których należy przestrzegać podczas korzystania z elementów konstrukcyjnych.

materiał przedstawiony w tym poście powinien być wartościowy dla każdego, kto ma jakikolwiek rodzaj interakcji z bazami danych, ale jest to bardzo elementarny poziom. Aby uzyskać bardziej kompleksową dyskusję na temat projektowania baz danych, zapoznaj się z moim artykułem, intuicyjne podejście do projektowania baz danych.

Mini-Światy.

zanim przejdziemy do klocków, poświęćmy chwilę, aby zrozumieć termin mini-świat, ponieważ pomoże nam to zrozumieć klocki.

baza danych to model mini-świata. Mini-świat może być gabinetem medycznym, firmą handlową, biblioteką lub wieloma innymi rzeczami. Gdy chcemy uzyskać informacje o mini-świecie, zwracamy się do bazy danych, która go modeluje.

powiedzmy, że idziesz do lekarza na wizytę. Kiedy poinformujesz recepcjonistkę, że masz spotkanie, recepcjonistka spróbuje znaleźć Twoje spotkanie w modelu (bazie danych). Jeśli model był na bieżąco ze swoim mini-światem, powinien być w stanie potwierdzić, że masz spotkanie. Podobnie, jeśli firma chce wiedzieć, który z jej dużych klientów nie złożył zamówień w ciągu ostatnich 6 miesięcy, może zwrócić się do modelu swojego mini-świata, jeśli był on na bieżąco z tym mini-światem.

mini-świat może być całą firmą, lub może być częścią firmy, takiej jak oddział banku lub dział sprzedaży.

pierwszą rzeczą, jaką robi projektant baz danych, jest zrozumienie mini-świata, ponieważ zadaniem projektanta jest zaprojektowanie modelu tego mini-świata. Aby zrozumieć mini-świat, projektant zaczyna od zidentyfikowania elementów składowych, które wejdą w skład bazy danych.

Klocki

1. Byty

byt to coś, co istnieje w mini-świecie i ma cechy, które nas interesują. Na przykład w mini-świecie rejestracji w szkole istnieją jednostki studentów, jednostki kursów, jednostki instruktorów i inne. Uczniowie mają nazwiska, adresy, GPA i inne cechy, które nas interesują. Kursy mają tytuły, kredyty, opłaty i inne. A instruktorzy mają nazwiska, adresy, kwalifikacje i inne. Byty są unikalne. Każdy uczeń jest wyjątkową jednostką; jest John i Mary i tak dalej. Każdy kurs jest unikalną jednostką, a każdy instruktor jest unikalną jednostką.

byty nie muszą być rzeczami fizycznymi. Chociaż nie możesz dotknąć, zobaczyć ani powąchać rejestracji, istnieje ona jednak w mini-świecie rejestracji szkolnej i ma cechy, które nas interesują, takie jak data rejestracji, uczeń, który się zapisał, kurs, na który się zapisał i otrzymana końcowa ocena. Sprzedaż to inne przykłady podmiotów, które nie mają fizycznego komponentu, ale mają interesujące nas cechy (data sprzedaży, klient, sprzedawca, suma zamówienia, sposób wysyłki, warunki płatności itp.).

2. Rodzaje jednostek

jednostki tego samego typu należą do jednego typu jednostek. Rodzaj jednostki jest zbiorem jednostek tego typu. Typ jednostki studenckiej jest zbiorem wszystkich studentów. Typ jednostki kursu jest zbiorem wszystkich kursów, A typ jednostki instruktora jest zbiorem wszystkich instruktorów.

typy jednostek są najważniejszą koncepcją w tym poście. Stają się tabelami w bazie danych.

3. Atrybuty

atrybuty podmiotu są cechami tego podmiotu, które są dla nas interesujące. Jak już wspomniano, atrybuty uczniów obejmują imię i nazwisko, adres, średnią ocen i inne. Kursy mają nazwy, zaliczenia, działy, do których należą i inne. I tak dalej z innymi rodzajami jednostek.

składanie klocków

jak te klocki są reprezentowane w bazie danych? Każdy typ jednostki jest reprezentowany przez tabelę w bazie danych. W tej tabeli poszczególne wiersze są unikalnymi jednostkami, a kolumny są atrybutami. Oto przykład tabeli, która reprezentuje typ podmiotu karty kredytowej:

Zasady bloków bazodanowych

podczas pracy z blokami ważne jest przestrzeganie pewnych zasad, które nie tylko ułatwiają pracę z obiektami bazodanowymi, ale także zapobiegają anomaliom danych (anomalie danych wykraczają poza zakres tego postu, ale są szczegółowo omówione w moim artykule, intuicyjne podejście do projektowania baz danych).

Zasada 1: każda tabela powinna reprezentować jeden i tylko jeden typ podmiotu.

w bazie zapisów szkolnych Mini-świat, powyżej, znajdują się następujące tabele: Student, kurs, instruktor, zapisy i inne, po jednym dla każdego typu jednostki zidentyfikowanego w tym mini-świecie. Baza danych biura medycznego mini-świat potrzebuje stołu lekarskiego, stolika pacjenta, stolika na spotkanie, stolika na leki i innych. Jedna tabela dla każdego typu podmiotu.

istnieje wyjątek od tej reguły. Przygotuj się, nadchodzi Twister mózgu: Jeśli dwa typy jednostek mają te same atrybuty, a jednostka w jednym z typów jednostek jest również jednostką w drugim typie jednostek (jeden podmiot jest członkiem obu typów jednostek), wówczas dwa typy jednostek mogą być reprezentowane w jednej tabeli. I znowu: Typ podmiotu profesora i typ podmiotu doradcy mogą być reprezentowane w jednej tabeli, ponieważ doradcy są również profesorami i mają te same atrybuty (nazwa profesora/doradcy, Kwalifikacje profesora/doradcy i inne). I jeszcze raz: Typ encji folderu i typ encji podfolderu mogą być reprezentowane w jednej tabeli, ponieważ wszystkie encje podfolderu są również encjami folderu i mają te same atrybuty (tytuł folderu, rozmiar folderu, liczba elementów w folderze, folder nadrzędny i inne). Jeszcze jedno: typy jednostek pracowniczych i menedżerskich mogą być reprezentowane w tej samej tabeli, ponieważ jednostki pracownicze i menedżerskie mają te same atrybuty, a jednostki zarządzające są również jednostkami pracowniczymi. Ten wyjątek od reguły jest dokładniej analizowany w innym blogu: SQL Server-the Self Join Query.

przy okazji, zauważ, że ta reguła jest powodem, dla którego właściwy sposób nazwania tabeli jest w liczbie pojedynczej. Tabele reprezentują pojedynczy typ podmiotu.

Zasada 2: wszystkie kolumny muszą być atomowe.

Czy zastanawiałeś się kiedyś, dlaczego tabele bazy danych mogą mieć kolumny dla miasta i stanu, ale tylko jedną kolumnę dla adresu? Być może zastanawiałeś się, dlaczego nie ma kolumny dla numeru adresu, a innej dla typu ulicy adresu (Blvd., Aleja itp.), inny numer mieszkania i tak dalej. Dlaczego te kolumny są zwykle łączone w jedną kolumnę adresową? Odpowiedź na wszystkie te pytania leży w zrozumieniu atomiczności.

kiedy mówimy, że kolumna jest atomowa, mamy na myśli, że nie może być dalej podzielona i nadal zachowuje znaczenie. Stwórzmy kolumnę i nazwijmy ją MegaAddress, która zawiera adres ulicy wraz z miastem i stanem.

ale ponieważ wykonujemy wyszukiwania, sortowanie i inne operacje na częściach tej kolumny (wyszukiwanie według miasta, sortowanie według stanu, drukowanie tylko części adresu ulicy i tak dalej), możemy powiedzieć, że poddziały tej kolumny mają własne znaczenie (StreetAddress, City i State). Tak więc, MegaAddress nie jest atomowy. Lepszym stołem byłby:

a co z kolumną StreetAddress? Powinniśmy podzielić to dalej na StreetNumber, StreetName i StreetType? Tak długo, jak nie robimy nic znaczącego z jego podziałem—jeśli nie sortujemy numerów ulic, nie szukamy wszystkich dróg lub Alej itd.—wtedy kolumna jest atomowa tak jak jest. Ale jeśli zrobimy te rzeczy, wtedy kolumna nie jest atomowa i wtedy, tak, powinniśmy podzielić ją zgodnie z opisem.

zasada 3: kolumny nie mogą być wielowartościowe.

niektóre typy encji zawierają atrybuty wielowartościowe lub atrybut, który może mieć więcej niż jedną wartość. W tabeli kursów może znajdować się atrybut o nazwie Prerequisites. Ponieważ jednostka kursu może mieć więcej niż jeden warunek, atrybut warunek jest atrybutem wielowartościowym. Kiedy tworzymy tabelę dla typu encji kursu, nie będziemy w stanie reprezentować atrybutu warunku jako kolumny w tabeli. Aby poprawnie reprezentować atrybut wielowymiarowy, będziemy musieli utworzyć dla niego inną tabelę i powiązać ją z oryginalną tabelą za pomocą relacji jeden do wielu (relacje są szczegółowo omówione w kursach, których uczę na Interface Tachnical Training Sql100: Wprowadzenie do Transact-SQL i Sql250: Transact – SQL dla programistów oraz w moim artykule intuicyjne podejście do projektowania baz danych). Inne przykłady wielowymiarowych atrybutów obejmują osoby pozostające na utrzymaniu pracownika, kwalifikacje lekarza i tak dalej.

reguła 3 mówi, że dla danego podmiotu (wiersza w tabeli) w każdej kolumnie może być tylko jedna wartość.

podsumowanie

ten post wprowadził pojęcie mini-świata jako aspektów biznesu lub innego środowiska, które modeluje baza danych. Post opisał również tabelę bazy danych jako reprezentującą pojedynczy typ podmiotu, w którym wiersze zawierają pojedyncze jednostki tego samego typu, A kolumny reprezentują atrybuty tych jednostek. Wprowadzono trzy zasady dotyczące tabel. Zasada 1 stanowi, że tabela powinna reprezentować jeden typ podmiotu. Wyjątek od reguły występuje, gdy dwa typy jednostek mają te same atrybuty, a jednostki w jednym typie jednostek są członkami drugiego typu jednostek. W takim przypadku oba typy encji mogą być reprezentowane w tej samej tabeli. Zasada 2 mówi, że wszystkie kolumny tabeli muszą być atomowe, co oznacza, że kolumna nie może być podzielona i nadal zachowuje znaczenie w mini-świecie. Wreszcie, reguła 3 mówi, że kolumny w tabeli nie mogą być wielowartościowe, co oznacza, że dla danego podmiotu (wiersza w tabeli) może być tylko jedna wartość na kolumnę.

miłego oglądania!

Peter Avila

instruktor SQL Server – szkolenie techniczne interfejsu

Phoenix, AZ