Строеж на приложение, използващо JDBC

Програмата на Java, взаимодействаща с база от данни, обикновено работи по следния примерен план. Първо се извиква методът getConnection за получаване на обект от тип Connection. След това се създава обект от тип Statement и се подготвя SQL заявка.

SQL заявките могат да бъдат изпълнявани директно (обект от тип Statement) или да бъдат компилирани (обект от тип PreparedStatement). SQL заявките могат да бъдат и извиквания на съхранени процедури (stored procedures) (обект от тип CallableStatement). При изпълняване на метода executeQuery( ), резултатът е обект от тип ResultSet. SQL заявки като UPDATE и DELETE не връщат резултат, затова за тях се използва методът executeUpdate( ). Той връща резултат от тип int, съдържащ броя променени записи. Обектът от тип ResultSet съдържа записи с данни, които могат да бъдат обходени с метода next( ). В случая на приложение, работещо с транзакции, могат да се използват методите rollback( ) и commit( ) за потвърждаване или отменяне на промените, предизвикани от SQL заявката.

Какво всъщност осигурява JDBC?

Според някои автори (Marty Hall, 1999), “JDBC предоставя стандартна библиотека за достъп до релационни бази данни. Използвайки JDBC API интерфейса, можете да осъществявате достъп до множество различни SQL бази данни чрез един и същ Java синтаксис. Важно е да се отбележи, че въпреки че JDBC стандартизира механизма за свързване с бази от данни, синтаксисът за изпращане на заявки и за изпълнение на транзакции, както и структурата на данните, представляващи резултатите, JDBC не се опитва да стандартизира SQL синтаксиса. Така че можете да използвате произволни SQL разширения. Но тъй като повечето заявки следват стандартния SQL синтаксис, употребата на JDBC позволява да промените хостове на бази от данни, портове и дори производителя с минимални промени във вашия код”.

ADO

Вашите данни могат да съставляват съдържанието на страницата или да определят как ще изглежда тя, но каквато и да е дейността им, те са основната част от нея. Ако изграждате Web страница около хранилище на данни (data store), то за да промените страницата си, ще трябва сами да промените данните.

Идеята на ADO (Active Data Objects) — да предоставят общ набор програмни интерфейси на хранилищата на данни, защото трябва да има само един начин за достъп до данните. Идеята не е нова, тя взема най-доброто от съществуващите технологии за достъп до бази данни и ги обединява в една технология, която да отговаря на съвременните и бъдещи изисквания. Възможността да се справи с бъдещите изисквания е особено важна. Много други технологии, като DAO и ODBC, са съвсем подходящи за използване от много приложения, но развитието на Интернет поставя проблеми пред тях.

ADO са компоненти, които позволяват да се работи с базите данни. Може да се използват както за да си направи Web страница, базирана на някакви данни, така и за да се изгради изцяло интерактивен сайт за електронна търговия, например.

Какво точно представляват OLE DB и ADO?

Ще отговорим на този въпрос като направим сравнение с някои съществуващи технологии за достъп до данни.

Както обяснихме по-горе, ODBC е Application Programming Interface (API - приложен програмен интерфейс), който позволява достъп до релационни бази данни, като Access и SQL. Тъй като ODBC e API, за много npoграмисти особено за тези на Visual Basic, тя изглежда трудна за употреба. Remote Data Objects (RDO - отдалечени обекти с данни) са ActiveX обекти, които стоят в ODBC и предоставят всички възможности, осигурявани от ODBC, но в лесна за използване форма.

OLE DB е базовата технология, която служи за интерфейс между нашите програми и източника на данни. Системата е доста заплетена и се използва само от програмистите на С и C++. ADO, както предполага името, представляват съвкупност от ActiveX обекти, които предоставят лесен достъп до OLE DB. Следователно можем да приравним OLE DB c ODBC и ADO c RDO.

Въпреки че Microsoft създават нова технология за достъп до данни, те не отписват автоматично старите. Идеята на OLE DB е не да премахне съществуващите технологии, а да ги доразвие.

OLE DB и архитектурата на ADO

След като дадохме кратко обяснение на това какво представляват OLE DB и ADO, трябва да видим и къде е мястото им в цялостната картина. Диаграмата показва мястото на двете технологии по отношение на приложенията и хранилищата на данни:

В началото имаме приложение. Под него са ADO и/или OLE DB, които осигуряват достъп до данните. Причина за наличието и на ADO, и на OLE DB е, че OLE DB е базовата технология. OLE DB обаче не е проектирана да се използва от всички езици; така че ADO стои върху OLE DB и осигурява интерфейс за тези езици, като Visual Basic и скриптовете, които нямат директен достъп до OLE DB. Освен това ADO осигурява по-лесен програмен интерфейс от OLE DB, така че дори и езиците, които могат да използват OLE DB директно, като C++ и Java, могат да използват ADО, за да опростят достъпа до данни.

Тъй като ADО е СОМ компонент, може да се използва и от всеки съответстващ на COМ език като Delphi, или скриптовите езици, поддържащи Active Scripting интерфейс. Така че, въпреки че ADO, бидейки разработка на Microsoft, все още не е платформено независим, той е езиково независим.

Защо се налага да се използват OLE DB и ADO?

OLE DB и ADO осигуряват достъп до данни, но какво им е лошото на старите методи?

OLE DB и ADO ca проектирани да осигуряват достьп до хранилище на данни, а не до бази от данни. Въпреки че базите данни все още са най-разпространената форма на съхранение на данни, не е задължително те да съдържат всичките ви данни. Системите за обмен на съобщения се използват широко за съхранение на данни; започват да се появяват и Directory Services (директорийни услуги), които съдържат данни за потребителите, машините и т.н. Web сървърите съхраняват огромни обеми информация. Списъкът може да бъде продължен, така че се появява необходимостта от съществуването на начин за достъп до всички тези различни типове данни.

Другата причина за предпочитането на OLE DB и ADO е развитието на Интернет приложенията и динамичната структура на мрежата. Старите методи за достъп до данни не са проектирани да обработват данни, когато не са постоянно свързани с източника им. OLE DB и ADO са създадени да превъзмогнат това - те осигуряват несвързани набори от записи.

Консуматори и доставчици

На диаграмата на ADO архитектурата се вижда, че ADO се намират между приложението и хранилището на данни. Какво значат термините консуматори (Consumers) и доставчици (Providers)?

“Доставчикът предоставя данните, а консуматорът ги използва (консумира).

Хранилището на данни доставя данните, с които работят приложенията, използващи базите данни, като OLE DB може да общува с различни хранилища на данни, а всяко хранилище е свързано с OLE DB доставчик (Provider).” (Homer, Sussman, Francis, …, 1999 - Profesional ASP 3.0)

Идеята за несвързани доставчици не е нова, но прави програмирането по-лесно. Програмата се пише така, че да може да взаимодейства с ADO или OLE DB, a OLE DB взаимодейства с доставчика. По този начин е достатъчно да научаването само на един набор от правила за достъп до данни, независимо къде се съхраняват те.

Доставчици на OLE DB можете да намерите от Microsoft, от други производители за други хранилища на данни, а можете и да напишете свой доставчик.

Доставчици и драйвери

OLE DB достъп до съществуващите ODBC източници на данни се осигурява чрез включването на OLE DB доставчик за данни. Ползата от него се дължи на факта, че ODBC е по-широко разпространена от OLE DB и съществуват повече ODBC драйвери, отколкото OLE DB доставчици.

Диаграмата показва разликата между доставчиците от драйверите:

Доставчиците са на нивото OLE DB, а драйверите - на нивото ODBC.

Видове бази данни за Web

Тъй като по-голямата част от базите данни имат почти едни и същи характеристики – релационни са, достъпът до тях се осигурява чрез ODBC (или чрез някои от разновидностите му – JDBC и OLE DB, в зависимост от приложението), езикът за заявки е SQL (или негов диалект). Затова от гледна точка на изграждането на Web база от данни, има някои различия между възможните избори на бази от данни, които не се отнасят до платформа, цена и представителни характеристики.

Като цяло базите данни могат да бъдат разделени на две категории: настолни (desktop), за малко потребители и корпоративни (enterprise), за много потребители.

Настолни бази данни