Podstawy zarządzania schematami PostgreSQL

Zastanawiasz się, czym są schematy Postgresql i dlaczego są ważne oraz w jaki sposób możesz wykorzystać schematy, aby uczynić implementacje baz danych bardziej niezawodnymi i łatwiejszymi w utrzymaniu? W tym artykule przedstawimy podstawy schematów w Postgresql i pokażemy, jak je tworzyć na kilku podstawowych przykładach. Przyszłe artykuły zagłębią się w przykłady, jak zabezpieczać i używać schematów w rzeczywistych aplikacjach.

Po pierwsze, aby wyjaśnić potencjalne zamieszanie terminologiczne, zrozummy, że w świecie Postgresql termin „schemat” jest być może nieco przeładowany. W szerszym kontekście systemów zarządzania relacyjnymi bazami danych (RDBMS) termin „schemat” może być rozumiany jako odnoszący się do ogólnego logicznego lub fizycznego projektu bazy danych, tj. definicji wszystkich tabel, kolumn, widoków i innych obiektów które stanowią definicję bazy danych. W tym szerszym kontekście schemat może być wyrażony w diagramie relacji encji (ER) lub skrypcie instrukcji języka definicji danych (DDL) używanych do tworzenia instancji bazy danych aplikacji.

W świecie Postgresql termin „schema” może być lepiej rozumiany jako „przestrzeń nazw”. W rzeczywistości w tabelach systemu Postgresql schematy są zapisywane w kolumnach tabeli zwanych „przestrzenią nazw”, co, IMHO, jest dokładniejszą terminologią. Z praktycznego punktu widzenia, ilekroć widzę „schemat” w kontekście Postgresql, po cichu reinterpretuję go jako „przestrzeń nazw”.

Ale możesz zapytać:„Co to jest przestrzeń nazw?” Ogólnie rzecz biorąc, przestrzeń nazw jest dość elastycznym sposobem organizowania i identyfikowania informacji według nazwy. Na przykład wyobraźmy sobie dwa sąsiednie gospodarstwa domowe, Smiths, Alice i Bob oraz Jones, Bob i Cathy (por. rysunek 1). Gdybyśmy używali tylko imion, mogłoby być mylące, o jaką osobę chodziło nam, gdy mówiliśmy o Bobie. Ale dodając nazwisko, Smith lub Jones, jednoznacznie identyfikujemy osobę, którą mamy na myśli.

Często przestrzenie nazw są zorganizowane w zagnieżdżoną hierarchię. Pozwala to na sprawną klasyfikację ogromnych ilości informacji w bardzo drobnoziarnistą strukturę, taką jak np. system nazw domen internetowych. Na najwyższym poziomie „.com”, „.net”, „.org”, „.edu” itp. definiują szerokie przestrzenie nazw, w których znajdują się zarejestrowane nazwy dla określonych podmiotów, na przykład „severalnines.com” i „postgresql.org” są jednoznacznie zdefiniowane. Ale pod każdą z nich znajduje się wiele wspólnych poddomen, takich jak „www”, „poczta” i „ftp”, które same w sobie są duplikatami, ale w obrębie odpowiednich przestrzeni nazw są unikalne.

Schematy Postgresql służą temu samemu celowi organizowania i identyfikowania, jednak w przeciwieństwie do drugiego przykładu powyżej, schematów Postgresql nie można zagnieżdżać w hierarchii. Chociaż baza danych może zawierać wiele schematów, zawsze istnieje tylko jeden poziom, dlatego w bazie danych nazwy schematów muszą być niepowtarzalne. Ponadto każda baza danych musi zawierać co najmniej jeden schemat. Za każdym razem, gdy tworzona jest nowa baza danych, tworzony jest domyślny schemat o nazwie „public”. Zawartość schematu obejmuje wszystkie inne obiekty bazy danych, takie jak tabele, widoki, procedury składowane, wyzwalacze itp. Aby to zwizualizować, zapoznaj się z rysunkiem 2, który przedstawia zagnieżdżenie przypominające matrioszkę, pokazujące, gdzie schematy pasują do struktury Baza danych Postgresql.

Oprócz prostego organizowania obiektów bazy danych w logiczne grupy w celu ułatwienia zarządzania nimi, schematy służą praktycznemu celowi unikania kolizji nazw. Jeden paradygmat operacyjny obejmuje zdefiniowanie schematu dla każdego użytkownika bazy danych, aby zapewnić pewien stopień izolacji, przestrzeń, w której użytkownicy mogą definiować własne tabele i widoki bez ingerencji w siebie. Innym podejściem jest instalowanie narzędzi innych firm lub rozszerzeń baz danych w poszczególnych schematach, aby wszystkie powiązane komponenty były logicznie razem. W kolejnym artykule z tej serii szczegółowo opisano nowatorskie podejście do solidnego projektowania aplikacji, wykorzystujące schematy jako środek pośredni do ograniczenia narażenia fizycznego projektu bazy danych, a zamiast tego przedstawia interfejs użytkownika, który rozwiązuje klucze syntetyczne i ułatwia długoterminową konserwację i zarządzanie konfiguracją w miarę ewolucji wymagań systemowych.

Zróbmy trochę kodu!

Najprostszym poleceniem tworzenia schematu w bazie danych jest

CREATE SCHEMA hollywood;

To polecenie wymaga uprawnień do tworzenia w bazie danych, a właścicielem nowo utworzonego schematu „hollywood” będzie użytkownik wywołujący polecenie. Bardziej złożone wywołanie może zawierać opcjonalne elementy określające innego właściciela, a nawet może zawierać instrukcje DDL tworzące instancje obiektów bazy danych w ramach schematu w jednym poleceniu!

Ogólny format to

CREATE SCHEMA schemaname [ AUTHORIZATION username ] [ schema_element [ ... ] ]

gdzie „nazwa użytkownika” oznacza, kto będzie właścicielem schematu, a „element_schematu” może być jednym z niektórych poleceń DDL (szczegóły można znaleźć w dokumentacji Postgresql). Do korzystania z opcji AUTORYZACJI wymagane są uprawnienia superużytkownika.

Na przykład, aby utworzyć schemat o nazwie „hollywood” zawierający tabelę o nazwie „films” i widok o nazwie „zwycięzcy” w jednym poleceniu, możesz to zrobić

CREATE SCHEMA hollywood
    CREATE TABLE films (title text, release date, awards text[])
    CREATE VIEW winners AS
        SELECT title, release FROM films WHERE awards IS NOT NULL;

Dodatkowe obiekty bazy danych mogą być później tworzone bezpośrednio, na przykład dodatkowa tabela zostałaby dodana do schematu za pomocą

CREATE TABLE hollywood.actors (name text, dob date, gender text);

Zauważ w powyższym przykładzie przedrostek nazwy tabeli z nazwą schematu. Jest to wymagane, ponieważ domyślnie, to znaczy bez wyraźnej specyfikacji schematu, nowe obiekty bazy danych są tworzone w ramach bieżącego schematu, który omówimy dalej.

Przypomnij sobie, jak w powyższym przykładzie z przestrzenią imion mieliśmy dwie osoby o imieniu Bob i opisaliśmy, jak je rozdzielić lub rozróżnić, dołączając nazwisko. Ale w każdym z gospodarstw domowych Smith i Jones z osobna, każda rodzina rozumie, że „Bob” odnosi się do tego, który pasuje do tego konkretnego gospodarstwa domowego. Na przykład w kontekście każdego gospodarstwa domowego Alice nie musi zwracać się do swojego męża jako Bob Jones, a Cathy nie musi zwracać się do swojego męża jako Bob Smith:każda z nich może po prostu powiedzieć „Bob”.

Obecny schemat Postgresql przypomina dom w powyższym przykładzie. Do obiektów w bieżącym schemacie można odwoływać się bez kwalifikacji, ale odwoływanie się do obiektów o podobnych nazwach w innych schematach wymaga zakwalifikowania nazwy przez przedrostek nazwy schematu, jak powyżej.

Bieżący schemat pochodzi z parametru konfiguracyjnego „search_path”. Ten parametr przechowuje rozdzieloną przecinkami listę nazw schematów i można go sprawdzić za pomocą polecenia

SHOW search_path;

lub ustaw nową wartość za pomocą

SET search_path TO schema [, schema, ...];

Pierwsza nazwa schematu na liście to „bieżący schemat” i jest miejscem, w którym tworzone są nowe obiekty, jeśli określono je bez kwalifikacji nazwy schematu.

Lista rozdzielonych przecinkami nazw schematów służy również do określenia kolejności wyszukiwania, według której system lokalizuje istniejące niekwalifikowane nazwane obiekty. Na przykład, wracając do dzielnicy Smith and Jones, przesyłka zaadresowana tylko do „Boba” wymagałaby odwiedzin w każdym gospodarstwie domowym, dopóki nie zostanie znaleziony pierwszy mieszkaniec o imieniu „Bob”. Pamiętaj, że może to nie być zamierzony odbiorca. Ta sama logika dotyczy Postgresql. System wyszukuje tabele, widoki i inne obiekty w schematach w kolejności wyszukiwania_ścieżka, a następnie używany jest pierwszy znaleziony obiekt dopasowania nazwy. Nazwane obiekty kwalifikowane schematem są używane bezpośrednio bez odniesienia do ścieżki_wyszukiwania.

W konfiguracji domyślnej zapytanie o zmienną konfiguracyjną search_path ujawnia tę wartość

SHOW search_path;
 Search_path
--------------
 "$user", public

System interpretuje pierwszą wartość pokazaną powyżej jako nazwę aktualnie zalogowanego użytkownika i uwzględnia wspomniany wcześniej przypadek użycia, w którym każdemu użytkownikowi przydzielany jest schemat o nazwie użytkownika dla obszaru roboczego oddzielonego od innych użytkowników. Jeśli nie utworzono takiego schematu o nazwie użytkownika, ten wpis jest ignorowany, a schemat „publiczny” staje się bieżącym schematem, w którym tworzone są nowe obiekty.

Wracając zatem do naszego wcześniejszego przykładu tworzenia tabeli „hollywood.actors”, gdybyśmy nie zakwalifikowali nazwy tabeli do nazwy schematu, tabela zostałaby utworzona w schemacie publicznym. Jeśli przewidzieliśmy utworzenie wszystkich obiektów w określonym schemacie, wygodnie byłoby ustawić zmienną search_path, taką jak

SET search_path TO hollywood,public;

ułatwienie skrótu wpisywania niekwalifikowanych nazw w celu tworzenia lub uzyskiwania dostępu do obiektów bazy danych.

Istnieje również funkcja informacji o systemie, która zwraca aktualny schemat z zapytaniem

select current_schema();

W przypadku nieprawidłowej pisowni właściciel schematu może zmienić nazwę, pod warunkiem, że użytkownik ma również uprawnienia do tworzenia bazy danych, za pomocą przycisku

ALTER SCHEMA old_name RENAME TO new_name;

I wreszcie, aby usunąć schemat z bazy danych, możesz użyć polecenia drop

DROP SCHEMA schema_name;

Polecenie DROP nie powiedzie się, jeśli schemat zawiera jakiekolwiek obiekty, więc należy je najpierw usunąć lub opcjonalnie można rekursywnie usunąć całą zawartość schematu za pomocą opcji CASCADE

DROP SCHEMA schema_name CASCADE;

Te podstawy pozwolą Ci zacząć rozumieć schematy!