Ptáte se, co jsou to schémata Postgresql, proč jsou důležitá a jak můžete pomocí schémat zvýšit robustnost a udržovatelnost svých databázových implementací? Tento článek vás seznámí se základy schémat v Postgresql a na několika základních příkladech vám ukáže, jak je vytvářet. V dalších článcích se budeme věnovat příkladům, jak schémata zabezpečit a používat v reálných aplikacích.
Nejprve si pro vyjasnění případných terminologických nejasností uvědomme, že ve světě Postgresql je pojem „schéma“ možná poněkud nešťastně přetížený. V širším kontextu relačních systémů pro správu databází (RDBMS) lze termín „schéma“ chápat jako celkový logický nebo fyzický návrh databáze, tj. definici všech tabulek, sloupců, pohledů a dalších objektů, které tvoří definici databáze. V tomto širším kontextu může být schéma vyjádřeno v diagramu entit a vztahů (ER) nebo ve skriptu příkazů jazyka pro definici dat (DDL), který se používá k vytvoření databáze aplikace.
Ve světě Postgresql lze termín „schéma“ lépe chápat jako „jmenný prostor“. Ve skutečnosti jsou v systémových tabulkách Postgresql schémata zaznamenána ve sloupcích tabulky nazvaných „jmenný prostor“, což je IMHO přesnější terminologie. Z praktického hlediska, kdykoli vidím v kontextu Postgresql slovo „schéma“, mlčky ho přetlumočím jako „jmenný prostor“.
Můžete se ale zeptat: „Co je to jmenný prostor?“. Obecně je jmenný prostor poměrně flexibilní prostředek pro uspořádání a identifikaci informací podle jména. Představte si například dvě sousedící domácnosti, Smithovy, Alici a Boba, a Jonesovy, Boba a Cathy (viz obrázek 1). Pokud bychom používali pouze křestní jména, mohlo by být matoucí, kterou osobu máme na mysli, když mluvíme o Bobovi. Ale přidáním příjmení Smith nebo Jones jednoznačně určíme, kterou osobu máme na mysli.
Často jsou jmenné prostory uspořádány ve vnořené hierarchii. To umožňuje efektivní klasifikaci obrovského množství informací do velmi jemné struktury, jako je například systém názvů internetových domén. Na nejvyšší úrovni definují „.com“, „.net“, „.org“, „.edu“ atd. široké jmenné prostory, v jejichž rámci jsou registrovány názvy konkrétních entit, takže například „severalnines.com“ a „postgresql.org“ jsou jednoznačně definovány. Pod každým z nich však existuje řada společných subdomén, jako například „www“, „mail“ a „ftp“, které jsou samy o sobě duplicitní, ale v rámci příslušných jmenných prostorů jsou jedinečné.
Schémata Postgresql slouží ke stejnému účelu uspořádání a identifikace, avšak na rozdíl od druhého výše uvedeného příkladu nelze schémata Postgresql vnořovat do hierarchie. Ačkoli databáze může obsahovat mnoho schémat, existuje vždy pouze jedna úroveň, a proto v rámci databáze musí být názvy schémat jedinečné. Každá databáze také musí obsahovat alespoň jedno schéma. Při každé instanci nové databáze se vytvoří výchozí schéma s názvem „public“. Obsah schématu zahrnuje všechny ostatní databázové objekty, jako jsou tabulky, pohledy, uložené procedury, triggery atd. Pro názornost si prohlédněte obrázek 2, který znázorňuje vnoření podobné panence matrjošce a ukazuje, kam schémata zapadají do struktury databáze Postgresql.
Kromě prostého uspořádání databázových objektů do logických skupin, aby byly lépe spravovatelné, slouží schémata k praktickému účelu zamezení kolize názvů. Jedno z provozních paradigmat zahrnuje definici schématu pro každého uživatele databáze tak, aby byl zajištěn určitý stupeň izolace, prostor, kde mohou uživatelé definovat své vlastní tabulky a pohledy, aniž by se navzájem rušili. Dalším přístupem je instalace nástrojů třetích stran nebo rozšíření databáze do jednotlivých schémat, aby byly všechny související komponenty logicky pohromadě. V pozdějším článku této série bude podrobně popsán nový přístup k robustnímu návrhu aplikací, který využívá schémata jako prostředek indirekce k omezení odhalení fyzického návrhu databáze a místo toho představuje uživatelské rozhraní, které řeší syntetické klíče a usnadňuje dlouhodobou údržbu a správu konfigurace podle toho, jak se vyvíjejí požadavky na systém.
Jdeme dělat nějaký kód!
Nejjednodušší příkaz pro vytvoření schématu v databázi je
CREATE SCHEMA hollywood;Tento příkaz vyžaduje práva create v databázi a nově vytvořené schéma „hollywood“ bude vlastnit uživatel, který příkaz vyvolá. Složitější volání může obsahovat volitelné prvky určující jiného vlastníka a může dokonce obsahovat příkazy DDL instancující objekty databáze v rámci schématu, a to vše v jednom příkazu!
Obecný formát je
CREATE SCHEMA schemaname ]kde „username“ je ten, kdo bude schéma vlastnit, a „schema_element“ může být jeden z určitých příkazů DDL (podrobnosti najdete v dokumentaci Postgresql). Pro použití volby AUTHORIZATION jsou vyžadována práva superuživatele.
Tak například pro vytvoření schématu s názvem „hollywood“ obsahujícího tabulku s názvem „films“ a zobrazení s názvem „winners“ jedním příkazem můžete provést
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;Další databázové objekty lze následně vytvořit přímo, například další tabulka by byla do schématu přidána pomocí
CREATE TABLE hollywood.actors (name text, dob date, gender text);Všimněte si ve výše uvedeném příkladu předřazení názvu tabulky před název schématu. To je nutné, protože standardně, tedy bez explicitní specifikace schématu, se nové databázové objekty vytvářejí v rámci toho, co je aktuálním schématem, kterým se budeme zabývat příště.
Připomeňme si, že v prvním výše uvedeném příkladu jmenného prostoru jsme měli dvě osoby jménem Bob a popsali jsme, jak je dekonfliktovat nebo odlišit uvedením příjmení. Ale v rámci každé z domácností Smithových a Jonesových zvlášť každá rodina chápe „Bob“ jako označení toho, kdo patří k dané domácnosti. Takže například v rámci každé příslušné domácnosti nemusí Alice oslovovat svého manžela jako Boba Jonese a Cathy nemusí o svém manželovi mluvit jako o Bobu Smithovi: každá může říkat jen „Bob“.
Aktuální schéma Postgresql je něco jako domácnost ve výše uvedeném příkladu. Na objekty v aktuálním schématu se lze odkazovat nekvalifikovaně, ale odkazování na podobně pojmenované objekty v jiných schématech vyžaduje kvalifikování jména předřazením názvu schématu, jak je uvedeno výše.
Aktuální schéma je odvozeno z konfiguračního parametru „search_path“. Tento parametr uchovává čárkou oddělený seznam názvů schémat a může být prozkoumán příkazem
SHOW search_path;nebo nastaven na novou hodnotu příkazem
SET search_path TO schema ;První název schématu v seznamu je „aktuální schéma“ a je místem, kde se vytvářejí nové objekty, pokud jsou zadány bez kvalifikace názvu schématu.
Čárkou oddělený seznam názvů schémat slouží také k určení pořadí vyhledávání, podle kterého systém vyhledává existující nekvalifikované pojmenované objekty. Například zpět do čtvrti Smith a Jones, doručení balíku adresovaného pouze „Bobovi“ by vyžadovalo návštěvu v každé domácnosti, dokud by nebyl nalezen první obyvatel se jménem „Bob“. Všimněte si, že to nemusí být zamýšlený příjemce. Stejná logika platí i pro Postgresql. Systém vyhledává tabulky, pohledy a další objekty v rámci schémat v pořadí podle search_path a poté se použije první nalezený objekt odpovídající jménu. Pojmenované objekty kvalifikované pro schéma jsou použity přímo bez odkazu na search_path.
Ve výchozí konfiguraci dotaz na konfigurační proměnnou search_path odhalí tuto hodnotu
SHOW search_path; Search_path-------------- "$user", publicSystém interpretuje první výše uvedenou hodnotu jako aktuální jméno přihlášeného uživatele a vychází vstříc dříve zmíněnému případu použití, kdy je každému uživateli přiděleno schéma s uživatelským jménem pro pracovní prostor odděleně od ostatních uživatelů. Pokud žádné takové schéma s uživatelským jménem nebylo vytvořeno, je tato položka ignorována a „veřejné“ schéma se stává aktuálním schématem, ve kterém jsou vytvářeny nové objekty.
Takže, zpět k našemu předchozímu příkladu vytvoření tabulky „hollywood.actors“, pokud bychom název tabulky nekvalifikovali názvem schématu, pak by byla tabulka vytvořena ve veřejném schématu. Pokud bychom předpokládali vytvoření všech objektů v rámci určitého schématu, pak by mohlo být vhodné nastavit proměnnou search_path například jako
SET search_path TO hollywood,public;usnadňující zkrácené zadávání nekvalifikovaných názvů pro vytváření nebo přístup k objektům databáze.
Existuje také systémová informační funkce, která vrátí aktuální schéma pomocí dotazu
select current_schema();V případě ztučnění pravopisu může vlastník schématu změnit název, pokud má uživatel také práva pro vytváření databáze, pomocí
ALTER SCHEMA old_name RENAME TO new_name;A konečně pro odstranění schématu z databáze, existuje příkaz drop
DROP SCHEMA schema_name;Příkaz DROP selže, pokud schéma obsahuje nějaké objekty, takže je třeba nejprve odstranit je, nebo můžete volitelně rekurzivně odstranit celý obsah schématu pomocí volby CASCADE
DROP SCHEMA schema_name CASCADE;Tyto základy vám pomohou začít rozumět schématům!