Aplikační a programové vybavení Databáze – speciality šéfkuchařů

Databázové systémy Nejpoužívanější relační databázové systémy: Adaptive Server Enterprise (Sybase) DB2 (IBM) Firebird MySQL Oracle Database PostgreSQL SQL Server (Microsoft) SQLite Každý systém implementuje jazyk SQL jinak a žádný úplně. Mezi jednotlivými DBS bývají velké rozdíly. Seznam DBS je zcela nestraně seřazen podle abecedy :)

Rozhraní Pro práci s databázovým systémem se vždy používá nějaké rozhraní: Firemní pouze pro jeden konkrétní DB systém zpravidla více funkcí optimální výkon Obecná obvykle větší podpora standardů použitelné z různých aplikací a pro různé DBS ODBC, ADODB, JDBC, … Každé rozhraní poskytuje funkce pro připojení k databázi, vykonání dotazu, vypsání výsledku dotazu a zjištění chyb.

Datové typy - řetězce character_varying(mohutnost) / varchar(mohutnost) / nvarchar(mohutnost) standardní řetězec, omezený délkou mohutnost se udává v byte [B] char(mohutnost) / character(mohutnost) / nchar(mohutnost) řetězec omezený délkou doplňuje se mezerami operátor LIKE porovnává řetězce bez mezer text / ntext „neomezený“ řetězec Datový typ char je poměrně málo užitečný. Mohutnost datového typu se někde udává v bytech (na serverech, které příliš neberou v úvahu Unicode), jinde ve znacích (např. pro MSSQL datové typy nchar a nvarchar).

Datové typy – celá čísla bigint(šířka) – 8B – -263..263 263 = 9 223 372 036 854 775 808 integer(šířka) – 4B – -231..232 mediumint(šířka) – 3B – -223..223 smallint(šířka) – 2B – -215..215 tinyint(šířka) – 1B – -27..27 celé číslo signed (se znaménkem) – záporné rozsahy unsigned (bez znaménka) – pouze kladná čísla pozor na převod mezi signed a unsigned Při převodu ze signed na unsigned se z velkých čísel stanou záporné hodnoty a naopak. Šířka je řetězcová délka integeru na kterou je hodnota doplněna nulami zleva. Ne všechny DB servery tuto funkci podporují.

Datové typy – desetinná čísla real / float(velikost) plovoucí desetinná čárka velikost <= 24 – 7 číslic, 4 byty velikost > 24 – 15 číslic, 8 bytů number / numeric / decimal(přesnost, měřítko) pevná desetinná čárka přesnost – maximální počet platných číslic měřítko – počet číslic za desetinnou čárkou velikost – 5..17 bytů podle nastavení money -263..263 = 922 337 203 685 477,5808

Datové typy – datum a čas timestamp Datum a čas se ukládá jako časové razítko. Časové razítko je počet milisekund od 1.1.1970. platné pouze do 19.1.2038 03:14:07 Převod na běžný formát data je velice složitý, je nutné počítat se přestupnými dny a sekundami. Timestamp není možné použít k uložení intervalu (rok, měsíc, den, …). Podle SQL standardu by měl typ timestamp obsahovat i časovou zónu. datetime / date / time větší rozsah a přesnost uložení intervalu komplexní datový typ Z toho vyplývá, že na OS Windows není možné uložit datum před 1.1.1970 jako datum. Také je nutno mít na paměti, že není do timestamp možné uložit například jen datum nebo jen čas. Některé DB servery pro tyto účely mají speciální datové typy.

Datové typy – datum je možné použít také formát data aplikace – např. pg_query("UPDATE osoby SET datum_narozeni=". time()); datový typ sloupce je integer výhody: jednoduché, pro jednu aplikaci bezproblémové nevýhody: není atomické, nelze vyhledávat podle části data (lze pouze řadit) obtížně se zobrazuje interval – respektive závisí to na aplikaci vracíme se k problému závislosti dat a aplikace nespolehlivé pokud k databázi přistupuje více aplikací

Datové typy – binární data bit / boolean / binary – jedna hodnota BLOB / image – binární data BLOB – binary large object Detaily práce s binárními daty závisí na použitém rozhraní. Jednodušší případ: Data je možno odesílat (po správném escapování) SQL dotazem a přijímat v rámci jeho výsledků. Od určité velikosti nemusí fungovat správně. Složitější případ: Binární data (může zahrnovat i typ text) je nutné odesílat a přijímat speciálními funkcemi. Většinou je možné binární data odesílat v rámci SQL dotazů, zejména pro velké objemy dat je však stejně výhodnější použít speciální funkce.

Definice struktury databáze SQL příkaz CREATE CREATE TABLE nazev_tabulky ( sloupec datovy_typ [NOT NULL] [DEFAULT hodnota] [PRIMARY KEY] [,sloupec datovy_typ …] ) CREATE TABLE kontakty ( id serial PRIMARY KEY, osoba integer NOT NULL REFERENCES osoby, typ integer REFERENCES typy_kontaktu, kontakt varchar(200) NOT NULL )

Definice struktury databáze Prakticky není možné využívat SQL pro definici databáze mezi jednotlivými DBS. Každý DB systém používá jiné datové typy Generovaný primární klíč je implementován různě Jednotlivé DBS používají rozšíření, která významně ovlivňují práci s DB (např. MySQL – MyISAM × InnoDB) SQL pro definici struktury se používá nejčastěji pro import a export struktury v rámci jednoho DBS. Pro převod dat mezi DB systémy je nutné používat nástroje pro migraci (migration toolkit)

Automatický generovaný klíč (ID) nejčastěji používaný typ primárního klíče abstraktní identifikátor záznamu nezávislý na vnějších podmínkách odpadají problémy se složeným klíčem kromě něj by měl existovat ještě jiný klíč (definice relace) Žádný databázový systém neodpovídá přesně standardu. Mezi jednotlivými databázovými systémy jsou velké rozdíly. Problémy se složeným klíčem zahrnují zejména odkazování na konkrétní záznam. Složený klíč znamená, že kombinace hodnot ve všech sloupcích uvedených v klíči musí být unikátní. Tedy například při editaci vlastností osoby je nutné do podmínky WHERE vložit jmeno='x' AND prijmeni='y' AND prezdivka='z' k plné identifikaci osoby. Použití ID tedy zjednodušuje program.

ID - MySQL sloupci se přiřadí speciální atribut auto_increment při vložení dat INSERT dotazem se klíč automaticky aktualizuje i v případě, že je hodnota zadaná (např. při importování) SELECT LAST_INSERT_ID(); pouze jeden sloupec v tabulce může mít atribut nastaven musí být klíčem CREATE TABLE tabulka ( id int(5) unsigned NOT NULL auto_increment)

ID – MS SQL sloupci se přiřadí speciální atribut is_identity při vložení dat INSERT dotazem se klíč automaticky aktualizuje SELECT IDENT_CURRENT('nazev_tabulky'); v případě, že je hodnota sloupce zadaná, je nutné použít příkazy: SET IDENTITY INSERT on – povolí vkládání dat SET IDENTITY INSERT off – ukončí vkládání dat vkládání dat do generovaného klíče může být povoleno pouze pro jednu tabulku CREATE TABLE tabulka ( id int(5) unsigned NOT NULL is_identity,

ID - PostgreSQL Sloupci se přiřadí speciální datový typ SERIAL Automaticky se vytvoří sekvence pro generování hodnot klíče. Při vložení dat INSERT dotazem se klíč automaticky aktualizuje. SELECT currval('nazev_sekvence') V případě, že je hodnota sloupce explicitně zadaná se klíč neaktualizuje! CREATE TABLE tabulka ( id serial NOT NULL,

Autoincrement, Identiy, Currval ? Pro zjištění hodnoty ID posledního vloženého záznamu se musí používat předdefinované funkce. Nefunguje: SELECT MAX(id) FROM tabulka Zjištění hodnoty musí být thread-safe viz Obrázky: http://akela.mendelu.cz/~xpopelka/cs/apv/ost/sekvence-currval.pdf http://akela.mendelu.cz/~xpopelka/cs/apv/ost/sekvence-max.pdf http://akela.mendelu.cz/~xpopelka/cs/apv/ost/sekvence-max-soubeh.pdf

Referenční integritní omezení integritní omezení – NOT NULL, UNIQUE, PRIMARY KEY, CHECK cizí klíč zpravidla představuje referenční integritní omezení nelze změnit záznam v jedné tabulce bez aktualizace záznamů, které se na něj odkazují Příklad: sloupec osoba v tabulce kontakty se odkazuje na tabulku osoby při smazání osoby je žádoucí upravit i všechny připojené kontakty CASCADE – smazat RESTRICT / NO ACTION - nepovolit smazání osoby SET NULL – nastavit hodnoty ve sloupci na NULL CREATE TABLE kontakty ( osoba integer NOT NULL REFERENCES osoby ON DELETE CASCADE osoby-kontakty vs. osoby- adresy NOT NULL – není povoleno nezadání hodnoty. Tedy sloupec musí být vždy uveden v INSERT dotazu, nebo musí mít nastavenou výchozí hodnotu. Problém, je že toto neřeší, jestli je uvedená hodnota neprázdná – tedy prázdný řetězec je přípustný. UNIQUE – hodnoty ve sloupci jsou unikátní, tedy sloupec je klíčem. PRIMARY KEY – sloupec je primární klíč, je automaticky unikátní.

Referenční integritní omezení Adresy Při odstranění adresy se stane id_adresy=11 neplatné. ON DELETE SET NULL smaže pouze referenci, pravděpodobně není žádoucí smazat odkazující se záznam. id_adresy mesto ulice 11 Brno Polní 12 Praha Jarní Osoby id_osoby jmeno id_adresy 1 Pavel 11 NULL 2 Karel 12 Při odstranění Karla z databáze se stane id_osoby=2 neplatné. ON DELETE CASCADE smaže i záznamy, které se na tuto hodnotu odkazují. Při odstranění adresy zřejmě nechceme smazat osobu, protože by to odpovídalo tomu, že když se někdo přestěhuje a nevíme kam, tak ho vymažeme z databáze. Co udělat se závislým záznamem v databázi však záleží jen a pouze na funkcionalitě aplikace, respektive na požadavcích zákazníka. Proto jsou cizí klíče v databázi nastaveny ve výchozím stavu na NO ACTION, protože nelze nijak automatizovaně rozhodnout jak se má cizí klíč chovat. Kontakty id_kontakty kontakt id_osoby 21 karel@example.com 2 22 karlik@example.com 23 pavel@example.com 1

Úprava struktury databáze Struktura databáze je uložena ve speciální databázi INFORMATION_SCHEMA Pro DBS, které INFORMATION_SCHEMA nepodporují je možné použít příkazů DESCRIBE, SHOW, LIST, ALTER, RENAME, DROP, MODIFY, ADD… Příklad: SHOW TABLES FROM databaze; SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' ; Dlužno podotknout, že dříve ve standardu příkazy pro úpravy databáze nebyly (a ani dnes není situace jasná), takže to různé firmy řešily různě a těžko dnes někomu vyčítat, že jeho řešení neodpovídá standardu.

Omezení počtu řádků dotazu Nestandardní (PgSQL, MySQL): SELECT ... LIMIT n; SELECT vyska FROM osoby ORDER BY vyska DESC LIMIT 10; Standardní (SQL Server): SELECT [TOP | BOTTOM n] FROM ... SELECT TOP 10 vyska FROM osoby ORDER BY vyska DESC; A další: SELECT vyska FROM osoby ORDER BY vyska DESC WHERE ROWNUM <= 10;

Index volba primárního klíče souvisí se způsobem ukládání dat v DBS ISAM (Index Sequential Access Method) využívá se indexových souborů (telefonní seznam) u moderních DBS už se využívají jiné metody, pro snížení časové složitosti operací datový soubor index jméno příjmení rodné číslo Chlastislav Peruňka 647423/3452 Sosna Orbnicová 624783/7332 Růžeslav Mekota 737902/7145 id pozice 1 2 563 3 1124 Datový soubor tabulky může být velmi velký (několik GB), hledání určitého záznamu v takovém souboru by trvalo neúměrně dlouho. Proto se vytváří pomocný indexový soubor, který obsahuje pouze odkazy na místo kde jsou skutečná data. Indexový soubor se vytváří pro klíče relace. V současnosti se tento způsob ukládání dat již moc nepoužívá, ale metody které se používají dnes mají v zásadě stejné praktické důsledky pro používání. Jedná se tedy o to, že na sloupci, který je často používán k vyhledávání řádků v tabulce se vytvoří index, čímž se vyhledávání značně zrychlí. Indexy je potřeba vytvářet opravdu pouze tam kde jsou nutné, protože zbytečné indexy 1) znamenají nezanedbatelné plýtvání místem 2) výrazně zpomalují aktualizace DB.

Volně dostupné relační DBS Firebird: http://www.firebirdsql.org/ MySQL http://dev.mysql.com/ Microsoft SQL Server (Express edice) http://msdn2.microsoft.com/en-us/sql/default.aspx Oracle (Express edice) http://www.oracle.com/technology/products/database/oracle10g/index.html PostgreSQL http://www.postgresql.org/ SQLite http://www.sqlite.org/

http://kantorek.webzdarma.cz/