TÉMATICKÝ OKRUH TZD, DIS a TIS Číslo otázky : 20. Otázka : Datová vrstva informačního systému. Nezávislý přístup k datům - standardy ODBC/JDBC. Architektura a použití ADO.NET. Obsah : 1. ODBC 2. JDBC 2.1 Rozdělení 2.1.1 Typ 1 2.1.2 Typ 2 2.1.3 Typ 3 2.1.4 Typ 4 2.2 JDBC Ovladač 2.3 Spojení s databází 2.4 Pooling 3. ADO.NET
1. ODBC Je standardem navrženým firmou Microsoft. ODBC jako takové bylo založené na X/Open CLI specifikaci a bylo primárně přístupné pouze přes C/C++ aplikace, případně přes různé wrappery volání z různých vývojových prostředí (Visual Basic, Powerbuilder atd.). ODBC je tedy čisté céčkové API, které nemá žádný objektový základ a je poměrně nepřehledné a nestrukturované. I proto firma Microsoft v podstatě tuto technologii opustila a v.net je přístup k datům a databázím řešen sofistikovaně. Nativní rozhraní je ovladač síťového rozhraní specifický pro daný databázový server. Nativní připojení k MS SQL se většinou realizuje pomocí komponenty ActiveX Data Objects (ADO), což je sada součástí umožňujících přístup k datům přes poskytovatele OLE DB. Existuje také univerzální rozhraní ODBC (Open Database Connectivity), se kterým by se dle norem mělo pracovat stejně pro libovolný SQL server i pro libovolnou ODBC-schopnou aplikaci. Dřívější verze ODBC tvořily jen jakýsi mezistupeň mezi aplikací a nativními ovladači databázového serveru. V současnosti takovéto ztráty výkonnosti nehrozí, neboť i ODBC přistupuje přímo. Je to prostě jen jiný ovladač síťového rozhraní. 2. JDBC Základem konceptu JDBC je využití funkčnosti poskytované JDBC ovladačem, který je následně překládá do nativních volání dané databáze. Díky tomu je aplikační programátor odstíněn od specifického API databáze a může se naučit jednotné rozhraní JDBC, které pak použije pro přístup do libovolné databáze, která poskytuje JDBC ovladač. V dnešní době to jsou prakticky všechny hlavní systémy a ovladače jsou optimalizované a vyvíjené samotnými výrobci databázových strojů.
JDBC navíc není určeno pouze pro přístup k relačním databázím, ale k libovolnému formátu dat, ukládaného ve sloupcové podobě, což mohou být i datové soubory spreadsheetů, textové soubory (např. CSF) atd. Hlavní výhody JDBC: S JDBC není aplikace pevně svázaná s nejakou konkrétní databází Kombinace JDBC API a Java API výrazně zjednušuje a urychluje vývoj aplikací. JDBC skrývá před programátorem komplexnost problematiky přístupu k datům Není potřeba konfigurovat síťové počítače a pracovní stanice, stačí jen mít JDBC ovladač napsaný v Javě a klientské aplikace si sami zavedou ovladače jako součást appletu ze serveru. Technologie JDBC úspěšně využívá internetový adresovací standard URL (Uniform Resource Locator) pro jednoznačné zadání spojení s databází JDBC je jednoduší a bezpečnější neš ODBC a je ideální pro využití v heterogenních sítích 2.1 Rozdělení JDBC specifikace rozpoznává čtyři typy JDBC ovladačů, typ 1 až 4. 2.1.1 Typ 1 Tento typ ovladače využívá lokální ODBC ovladač a přistupuje k němu přes JDBC-ODBC bridge. Taková aplikace vyžaduje nainstalování a nastavení lokálního ODBC ovladače pro danou databázi společně s aplikací v Javě, která tento ODBC ovladač využívá. ODBC ovladače jsou specifické pro každého výrobce databáze, a proto je práce s nimi složitá, je nutné instalovat lokální DLL knihovny, které musí být synchronizovány s ohledem na aktuální použitou databázi, jejich administrace je časově náročná díky nejednotnosti rozhraní, použití a nastavení atd. 2.1.2 Typ 2 Ovladač typu 2 má za úkol překládat požadavky z JDBC do určitého specifického ovladače, který je v nativní podobě nainstalovaný na počítači a který je určen právě pro jeden typ databáze. Dalo by se říci, že JDBC-ODBC bridge je podmnožinou tohoto typu ovladače, s tím, že je čistě vázán jen na ODBC. Pochopitelně se s tímto typem ovladačů pojí stejně výhod a nevýhod jako v případě JDBC-ODBC. Kromě toho ale mohou nastat ještě větší komplikace při administraci a při
nasazení (opět záleží na umístění, zda se jedná o klienta nebo o serverový systém). 2.1.3 Typ 3 Tento typ již nepoužívá žádný nativní kód pro ovladač, ale je založen čistě na Javě a JDBC, které konvertuje svoji komunikaci do síťového protokolu, který se spojuje s centrálním serverem (Network Server), který poskytuje připojení k databázi (obvykle s poolem připojení, viz dále). Tento server konvertuje síťový protokol, kterým komunikuje s klienty, do databázově specifického protokolu, jemuž již databáze rozumí. Takový model je vysoce efektivní, a to jak s ohledem na možnost poolingu připojení a tím i zrychlení dotazování a práce s databází, tak i možnost připojení k sadě heterogenních databázových systémů. 2.1.4 Typ 4 Ovladač typu 4 je napsán celý čistě v Javě s plnou podporou pro optimalizace vzhledem k dané databázi. Výhodou tohoto ovladače je, že klient nemusí být jakkoli konfigurován a nejsou nutné žádné lokální klientské instalace ovladačů. 2.2 JDBC ovladač Ovladač je specifická třída, obvykle poskytována výrobcem databáze. Předtím, než budou provedeny jakékoli operace nad databází, je nutné ovladač nahrát a registrovat. K tomu slouží příkaz Class.forName("jméno_JDBC_ovladače");. Příkladem může být JDBC-ODBC bridge, jehož ovladač se registruje (rozumějte, že se registruje pro použití ve vaší aplikaci) příkazem Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");. Registrace JDBC ovladače je vázána na DriverManager, což je třída s metodami pro správu a práci s JDBC. V podstatě jde o vrstvu mezi aplikačním kódem a JDBC ovladačem, přičemž v této vrstvě je provedena registrace JDBC ovladače ve chvíli, kdy je zavolána výše popsaná metoda forname(). Obecně by měl tento ovladač zavolat při nahrání metodu registerdriver() třídy DriverManager. Ten pak ovladač eviduje a je poskytnut pro práci s databází.
2.3 Spojení s databází Jakmile byl JDBC ovladač nahrán a správně zaregistrován DriverManagerem, je možné navázat spojení s databází. Spojení s databází se identifikuje jako databázové URL, které se skládá z těchto součástí: URL musí být uvedeno jdbc., což je určeno specifikací. Poté může být uveden podprotokol, což je záležitost závislá od daného poskytovatele databáze. Například pro ODBC je nutné uvést odbc.. Poslední částí pak je DSN (Data Source Name), který identifikuje název databáze (u ODBC to je název ODBC zdroje). V zásadě URL jednoznačně identifikuje datový zdroj a lze s ním navázat spojení. K tomu slouží metoda getconnetion(), kterou je nutné zavolat u třídy DriverManager. Jakmile se aplikační kód snaží navázat spojení s databází, DriverManager provádí základní testování ovladače (voláním metody connect, kterou musí ovladač implementovat, jako všechny ostatní z rozhraní java.sql.driver) a předává URL jednotlivým registrovaným ovladačům, přičemž u prvního, který uspěje s připojením na dané URL, získá Connection objekt. Ten je pak následně předán volajícímu kódu. V případě, že jsme autorizovaní k získání připojení a vše je nastaveno správně, metoda getconnection() vrátí požadované spojení, které je základem pro další práci s databázi a přes které se provádí všechny operace nad databází. Jakmile máme spojení s databází, můžeme nad ní začít provádět datové operace. 2.4 Pooling Jedná o poolování objektů Connection, neboli samotných připojení. Protože vytvoření samotného připojení je časově i systémově velmi náročná operace, která by při neustálém provádění při každém dotazu klienta znamenala nepřijatelné zpomalení aplikace, tyto objekty se předvytvářejí a ukládají se po použití zpět do poolu, odkud se zase berou podle potřeb klie nta. Práce s poolingem je dosti aplikačně závislá a liší se podle výrobce aplikačního serveru.
3. ADO.NET ADO.NET (Microsoft ActiveX Data Objects.NET) představuje množinu tříd nabízejících služby pro přístup k datům a tvorbu databázových aplikací. Daty máme nyní na mysli převážně informace uložené v databázích. Ať již se jedná o data v databázích například na Microsoft SQL Serveru či data zpřístupněná přes OLE DB nebo XML. Mezi jeho přednosti patří především jednoduchý způsob použití, rychlost při zpracování a další. Stačí vytvořit spojení se serverem, s kterým budeme chtít pracovat, pomocí zvoleného adaptéru a zadaného dotazu získat z databáze data a ty pak načíst do některé z připravených konstrukcí pro práci s daty z tabulek. ADO.NET ale nemusí pracovat pouze s databázemi na nějakém serveru. Bylo navrhováno současně s XML třídami v prostředí.net Framework. Také díky tomu je možno data načítat i ve formátu XML nebo data zapisovat jako XML soubory spolu s definičním souborem XSD definujícím schéma dané databáze. Nástroje ADO.NET byly navrženy tak, aby se oddělil způsob přístupu k datům od manipulace s daty. K první skupině patří.net Framework data provider obsahující množinu komponent zahrnujících podmnožiny Connection (připojení), Command (množinu příkazů pro vybrání dat), DataReader (načítání dat) a DataAdapter (adaptér pro připojení k databázi). K druhé skupině řadíme mimo jiné objekt DataSet (skládající se z objektů DataTable, DataRow...). Jedná se o objekty uchovávající data načtená z databází. Tyto objekty mohou s daty pracovat stejně jako s daty v databázi. V dalším textu budeme převážně používat objekt typu DataSet. 3.1 Connection přístup k DB Pro to, abychom mohli s databází pracovat, je třeba nejprve vytvořit připojení. V závislosti na používaném serveru vybereme typ připojení. V našem příkladu budeme předpokládat, že používáme Microsoft SQL Server. Proto použijeme typ SqlConnection z jmenného prostoru System.Data.SqlClient. Pro připojení je nutné znát tzv. ConnectionString, tedy řetězec používaný pro připojení k databázovému serveru, ve kterém se uvádí název databáze, login, heslo a další parametry. Tím se vytvoří nový objekt SqlConnection. Po vytvoření objektu se vytvoří část kódu this.sqlconnection = new System.Data.SqlClient.SqlConnection(); kde sqlconnection je jméno instance tak, jak jsme si ji vytvořili. 3.2 Data adapter DataAdapter je užitečný především pro spolupráci s prvky dočasné databázové paměti typu DataSet. Pokud se tedy rozhodneme nepoužít DataSet, například u jednoduchých operací, můžeme s databází spolupracovat přímo bez DataAdapteru. Je na místě oznámit, že je třeba vytvořit tolik prvků SqlDataAdapter, do kolika tabulek databáze se budeme chtít připojovat.
3.3 Data reader V ADO.NET najdete třídy, které jsou velmi podobné těm z ADO - OleDbConnection, OleDbCommand a OleDbDataReader. Tyto objekty spolupracují s definovaným OLE DB providerem jako v klasickém ADO. Pro práci s Microsoft SQL Serverem lze použít i speciální sadu tříd SQLConnection, SQLCommand a SQLDataReader, které poskytují programátorovi vyšší výkon. 3.4 Data set DataSet je výsledkem úsilí spojit klasické ADO s XML datovým formátem. DataSet obsahuje tabulární data jedné nebo více tabulek ve formě XML. Tato data mohou být zpracovávána samostatně nebo mohou mít mezi sebou definovány relace podobně jako v relační databázi. DataSet je třída, která se nestará o spojení s databází nebo o SQL dotazy. Jedná se o klientský nástroj pro zpracování dat.