Artykuł ten opisuje przegląd najważniejszych obiektów dostępnych w SQL Server. Ma na celu pokazać ich różnorodność, wyjaśnić ich ogólne przeznaczenie. Chcę tutaj głównie zaznajomić początkujących użytkowników baz danych ze środowiskiem i obiektami, które można spotkać lub które mogą się przydać w kontekście pisania zapytań.
Serwer czyli System Zarządzania Bazą Danych (SZBD)
Od tego trzeba zacząć. System zarządzania bazami danych (Relational DataBase Management System RDBMS) – to kompletne środowisko w którym tworzymy, zarządzamy i pracujemy na bazach. Najpopularniejszymi są MS SQL Server, Oracle, MySQL, DB2, PostrgeSQL.
Wszystkie obiekty na serwerze tworzą strukturę hierarchiczną – serwer (instancja) jest na czele tej hierarchii.
Zawiera w sobie wszystkie komponenty odpowiedzialne za pracę systemu bazodanowego. Realizuje procesowanie zapytań, zarządzanie składowaniem danych, dostępem itd. . Jest to podobnie jak system operacyjny (tyle że warstwę wyżej w modelu ISO), całe środowisko w którym poruszamy się mówiąc o pracy z bazami danych.
Na danej fizycznej maszynie, możemy mieć zainstalowanych wiele różnych serwerów bazodanowych (np. kilka instancji MS SQL Server). Mówiąc o RDBMS SQL Server – jest to usługa systemowa, czyli aplikacja działająca w tle, realizująca wszystkie zadania związane z obsługą baz danych.
Wszystkie obiekty opisane poniżej, są tworzone i zarządzane właśnie na danym serwerze bazodanowym.
Baza danych
Na każdym serwerze, możemy utworzyć wiele baz danych. W implementacji SQL Server, spotkamy się z bazami systemowymi (master, model, msdb, tempdb) oraz nazwijmy je „regularnymi”, użytkownika – czyli np. bazy sklepu internetowego, firmy produkcyjnej etc..
Hierarchię obiektów dobrze obrazuje drzewo widoczne w oknie Object Explorera w Microsoft SQL Server Management Studio.
Każda baza, wraz ze wszystkimi danymi, które zawiera, jest składowana niezależnie, w przynajmniej dwóch plikach (pliku bazy i pliku logu transakcyjnego).
Wszystkie obiekty bazodanowe, muszą posiadać unikalną nazwę, w ramach bazy danych. W pełni kwalifikowana nazwa każdego obiektu jest czteroczłonowa, zgodna ze schematem :
<nazwa_serwera>.<nazwa_bazy_danych>.<nazwa_schematu>.<nazwa_obiektu>
Dzięki temu, jest ona jednoznacznie określona. W skryptach, zapytaniach SQL, możemy odwoływać się do obiektów w różnych bazach i na różnych serwerach – stąd w zależności od potrzeb stosujemy krótszą lub dłuższą formę.
Minimalną zalecaną nazwą po której odwołujemy się do określonego obiektu, jest nazwa dwuczłonowa – czyli <nazwa_schematu>.<nazwa_obiektu>.
Schemat
Ponieważ wszystkie obiekty tworzone są w ramach jakiegoś schematu – ważne abyś dowiedział się o nich na początku. Schemat to niezależna warstwa, związana z zarządzaniem bezpieczeństwem. Jest to kontener, w ramach którego tworzone są obiekty. Dzięki temu, nadając uprawnienia do danego schematu, możemy kontrolować uprawnienia na poziomie wszystkich obiektów należących do niego. Każdy użytkownik posiada schemat domyślny, który jest rozpatrywany wtedy, gdy odwołujemy się do obiektu tylko po jego nazwie.
Żeby sprawdzić jaki jest domyślny schemat w ramach bazy, można użyć do tego, prostej funkcji systemowej :
select SCHEMA_NAME() as DefaultSchema;
Mój schemat domyślny to dbo.Następujące zapytanie, zwróci komunikat o błędzie :
use AdventureWorks2008
go
select FirstName,LastName from Person
Msg 208, Level 16, State 1, Line 2 Invalid object name 'Person'.
Stanie się tak, ponieważ nie użyłem w zapytaniu nazwy schematu w którym zawarta jest tabela Person. Został więc określony mój schemat domyślny czyli dbo. W tym zapytaniu odniosłem się do tabeli dbo.Person, której nie ma w bazie AdventureWorks2008.
Jest to bardzo ważna zasada, aby pamiętać o tym, że odwołujemy się zawsze do nazwy obiektu razem z nazwą schematu w której ten obiekt się znajduje. Zapytanie więc powinno wyglądać następująco :
Select * from Person.Person
Tabela
Podstawowymi obiektami w każdej bazie są tabele. W tym miejscu zaczyna się tak naprawdę modelowanie rzeczywistości na postać relacyjną. Tabela – to definicja pewnej klasy obiektów które chcemy przechowywać. Każda tabela zawiera zbiór elementów opisany za pomocą atrybutów (kolumn). Każdy atrybut (kolumna), jest określany typem danych (np. data urodzin powinna być opisana jako typ danych daty, a liczba. Widzimy więc jak mocno hierarchizowana jest ta struktura.
Tabela to obiekt nadrzędny w stosunku do :
- kolumn czyli atrybutów, opisujących elementy przechowywane w tabeli,
- kluczy – czyli relacji do innych tabel,
- ograniczeń (constraints) służących do zapewnienia integralności danych,
- procedur wyzwalanych (triggers) – obiektów programistycznych, za pomocą których możemy realizować rozmaite cele, np. archiwizowanie modyfikowanych elementów.
- indeksów i statystyk – obiekty poprawiające wydajność zapytań.
W zapytaniach odwołujemy się tylko do nazw tabel, kolumn. Potrzebna jest także wiedza na temat kluczy w kontekście pisania kwerend do wielu tabel (po jakich kolumnach będziemy łączyć ze sobą tabele). Pozostałe obiekty dotyczą projektu samej tabeli, zapewnienia integralności danych (typy danych użyte w kolumnach, ograniczenia i procedury wyzwalane) i służą do optymalizacji zapytań (statystyki i indeksy).
Nie będę ich tu szczegółowo opisywał bo wykraczają poza zakres tego kursu. Nie są bezpośrednio związane z DQL czyli pisaniem zapytań.
Widok
Widok inaczej perspektywa (określenie używane w ORACLE), to po prostu zapisana kwerenda, czyli inne spojrzenie (stąd pewnie nazwa widok) na tabele. Są one nazywane czasem wirtualnymi tabelami – bo przecież zapytanie zwraca nam taką „wirtualną tabelę”. Rezultatem jest przecież zawsze pewien zbiór elementów. Są wygodnym sposobem, na ukrywanie potencjalnie skomplikowanej struktury bazy przed użytkownikami (dla wygody jak również dla bezpieczeństwa). Odwołujemy się do nich w zapytaniach jak do zwykłej tabeli.
Widoki, to niezmaterializowane tabele wirtualne. W ogólności nie poprawiają wydajności zapytań, chyba że utworzymy na nich indeksy.
Synonim
To aliasy nazw obiektów. Pozwalają nadać istniejącym obiektom bardziej ludzkie imię 🙂 lub po prostu uniezależnić aplikacje od zmian w strukturze bazy. Szczególnie pomocne przy migracjach lub modyfikacjach środowiska. Są alternatywnymi nazwami obiektów takich jak tabele, widoki, funkcje, procedury składowane.
Obiekty programistyczne
W ramach bazy, możemy tworzyć różne obiekty programistyczne. Ich przeznaczenie jest bardzo szerokie. Ograniczę się tylko do bardzo ogólnego ich opisu bo nie stanowią tematu tego kursu.
Stored Procedures
Procedury składowane to niezależne jednostki, skrypty T-SQL, realizujące dowolne funkcje programistyczne. Mogą np. importować dane z pliku, dokonując przy okazji szeregu weryfikacji (czyszczenia), wykonywać określone czynności administracyjne, utrzymaniowe. Procedury mogą przyjmować parametry i zwracać zbiory wynikowe. Dzięki nim (podobnie jak funkcją), możemy zaszyć logikę biznesową na serwerze SQL tworząc wielowarstwową strukturę aplikacji.
Procedury składowane nie mogą być używane w kwerendach, choć za ich pomocą można także realizować dostęp do danych (mogą zwracać wynik kwerendy, zapisanej w ich ciele).
Assemblies
SQL Server umożliwia integrację środowiska CLR. Możemy tworzyć obiekty programistyczne w .NET i używać ich w ramach serwera bazy danych. Jest to znakomite uzupełnienie możliwości języka SQL (który jest zoptymalizowany do działania na zbiorach) językami obiektowymi.
Database Triggers
Jest to specjalny typ procedur wyzwalanych, które mogą być wywoływane na wskutek operacji DDL czyli związane z dowolną modyfikacją obiektów bazodanowych (tworzący. Możemy za ich pomocą np. logować czy też kontrolować wszelkie zmiany w strukturze.
Funkcje
SQL Server oferuje szereg dostępnych wbudowanych funkcji systemowych. Funkcje w ogólności szeregujemy ze względu na wynik jaki zwracają na skalarne lub tabelaryczne.
Funkcje skalarne, zwracają w wyniku jednoelementowy zbiór opisany jednym atrybutem np. funkcja getdate(), która zwraca aktualną datę i czas systemowy. Stosować możemy je np. w klauzuli SELECT czy w warunku filtracji WHERE. Wszędzie tam, gdzie wartością oczekiwaną jest wartość skalarna.
Funkcje tabelaryczne mogą zwracać zbiór wieloelementowy. Stosować możemy je np. we FROM, ale już nie w SELECT. Dobry przykładem jest funkcja OPENQUERY, za pomocą której możemy np. dobrać się w kwerendzie do zawartości danych w pliku excel.
Oprócz funkcji wbudowanych, systemowych, mamy możliwość tworzenia własnych metod. Są trzy rodzaje funkcji użytkownika – skalarne, tabelaryczne proste i tabelaryczne złożone. Dzięki nim zrealizujemy dowolne cele programistyczne. W dalszej części tego kursu opisuję w detalach zastosowanie
Types
Typy danych użytkownika – to typy pochodne z już istniejących. Jeśli np. stosujemy w bazie typ danych char(12) i używamy go w różnych tabelach wiele razy – możemy go zdefiniować jako typ użytkownika globalny i wszędzie tam gdzie będzie potrzebny po prostu używać po nazwie własnej.
Rules
Ten typ obiektu będzie wycofane w przyszłych wersjach SQL Server.
Idea reguł jest bardzo podobna do typów użytkownika. Są to definicje ograniczeń (constraintów), które możemy podpiąć do różnych kolumn, tabel.
Defaults
Ten typ obiektu będzie wycofane w przyszłych wersjach SQL Server.
Wartości domyślne – to trzeci typ obiektów wielokrotnego użytku do określania struktury i własności kolumn po regułach i typach użytkownika. Jest on niezależnym obiektem, który może być „podpięty” pod dowolne kolumny tabel jako definicja ich wartości domyślnej. Zgodnie z nią, będą uzupełniane kolumny w momencie dodawania wierszy jeśli w danym elemencie nie będzie jawnie określona wartość.
Sequences
Sekwencje to nowy typ obiektów w SQL Server 2012. Są to liczniki, generatory kolejnych liczb, nadające numery według określonego porządku, które nie są zależne od konkretnej tabeli.
Pozostałe obiekty
Przedstawione powyżej obiekty są tylko podzbiorem z dostępnych struktur, które oferuje SQL Server. Istnieje szereg obiektów związanych z bezpieczeństwem, usługami Brokera (kolejki, wiadomości etc.) czy indeksami pełnotekstowymi.