Ano ang ginagamit ng ODBC: isang kumpleto at praktikal na gabay

Kung araw-araw kang gumagamit ng datos, maya-maya ay makakatagpo ka ng kinatatakutang acronym na ODBC, at marami sa inyo ang magtataka kung para saan nga ba ito. Ang ODBC ay isa sa mga tahimik na pamantayan na nagpapahintulot sa iba't ibang aplikasyon at database na makipag-ugnayan sa isa't isa , nang hindi mo na kailangang isulat muli ang lahat ng iyong code sa tuwing lilipat ka ng provider.

Bagama't may mga mas bagong teknolohiya ngayon, nananatiling mahalaga ang ODBC sa maraming kapaligiran: mula sa mga kagamitan sa opisina tulad ng Excel o Access , hanggang sa mga solusyon sa BI tulad ng Tableau o Qlik Sense, hanggang sa mga lumang aplikasyon sa enterprise na humahawak pa rin ng mahahalagang datos. Tingnan natin nang mas malapitan kung ano ito, para saan ito ginagamit, kung paano ito gumagana sa loob, at kung paano ito i-configure sa pagsasagawa.

Ano ang ODBC at para saan ba talaga ito ginagamit?

Ang ODBC ay nangangahulugang Open Database Connectivity . Ito ay isang open-standard application programming interface (API) na idinisenyo upang ma-access ang mga database nang pantay-pantay, anuman ang pinagbabatayan na database management system (DBMS).

Ang ideya ay simple ngunit hindi kapani-paniwalang makapangyarihan: isinusulat mo ang iyong aplikasyon nang isang beses, gamit ang mga ODBC call at karaniwang mga pahayag ng SQL, at hinahayaan ang isang driver na magsalita ng "katutubong wika" ng bawat database . Pinapayagan ka nitong lumipat mula sa Access patungo sa SQL Server, mula sa MySQL patungo sa Oracle, o kahit sa isang simpleng text file, nang hindi kinakailangang isulat muli ang lahat ng lohika ng pag-access sa data.

Ang ODBC ay gumaganap bilang tulay sa pagitan ng client application at ng DBMS. Nagpapadala ang application ng mga SQL request gamit ang ODBC API, isinasalin ng driver ang mga request na ito sa isang format na nauunawaan ng partikular na DBMS , at ibinabalik ang mga resulta sa application. Inaalis nito ang pangangailangan para sa programa na malaman ang mga proprietary na katangian ng bawat database.

Ang pamantayang ito ay nagmula noong unang bahagi ng dekada 90 kasama ang SQL Access Group, at ang Microsoft ang pangunahing tagapagpatakbo sa mundo ng Windows , kasama ang unang tagapagpatakbo, ang SIMBA.DLL (binuo kasabay ng Simba noong 1992). Sa kasalukuyan, may mga implementasyon na para sa Windows, UNIX , Linux , OS/2, at macOS, na ginagawang malawakang ginagamit ang ODBC bilang isang cross-platform solution.

Kasaysayan at ebolusyon ng ODBC

Ang kasaysayan ng ODBC ay malapit na nauugnay sa ebolusyon ng pag-access sa datos sa mga kapaligiran ng Microsoft at mga bukas na pamantayan. Ang ODBC ay batay sa ispesipikasyon ng SQL Call-Level Interface (CLI) mula sa The Open Group at ISO/IEC , na nagtakda kung paano dapat idisenyo ang mga database access API sa antas ng tawag.

Ang unang bersyon ng ODBC ay inilabas noong Setyembre 1992 (ODBC 1.0) . Kasama sa mga kasunod na bersyon ang mga bagong kakayahan at pagpapabuti sa pagganap: ODBC 2.0 (bandang 1994), 2.5, ODBC 3.0 (bandang 1995, na may mga pangunahing kontribusyon mula sa IBM at Intersolv), ODBC 3.5 (1997), at ODBC 3.8 noong bandang 2009, na isinama sa Windows 7.

Kasabay nito, sinubukan ng Microsoft na lumampas sa ODBC sa pamamagitan ng paglikha ng iba pang mga modelo ng pag-access ng data: OLE DB, ADO, DAO, RDS, ang Jet engine, at kalaunan ay ADO.NET. Ang unang plano ay para sa mga teknolohiyang tulad ng OLE DB at ADO na palitan ang ODBC bilang pangunahing pamantayan sa pag-access ng data, lalo na sa mga senaryo na mas object-oriented at may mga mapagkukunan ng data na hindi kinakailangang SQL.

Gayunpaman, iba ang realidad sa merkado: pinanatili ng ODBC ang posisyon nito bilang de facto na pamantayan para sa pag-access sa mga mapagkukunan ng SQL . Ang malawak na suporta mula sa mga vendor tulad ng Oracle at IBM, ang cross-platform na katangian nito, at ang malawak na hanay ng mga umiiral na aplikasyon ay nagsisiguro na nanatili itong ginustong pagpipilian para sa maraming proyekto.

Ngayon, kapag pinag-uusapan natin ang pag-access sa mga SQL database, ang dalawang pangunahing pamantayan na nananatiling ganap na may bisa ay ang ODBC at JDBC . Ang iba pang mga modelo tulad ng OLE DB o ilang mga ADO layer ay nawalan na ng gaanong kaugnayan at sa maraming mga kaso ay tinatalikuran na o nananatili na lamang para sa pagiging tugma sa mga mas lumang aplikasyon.

Arkitektura ng ODBC: kung paano ito gumagana sa loob

Para lubos na maunawaan kung para saan ang ODBC, makakatulong na tingnan ang arkitektura nito. Nagpapakilala ang ODBC ng isang intermediate layer sa pagitan ng application at ng DBMS upang ang app ay hindi direktang makipag-ugnayan sa database, kundi sa isang karaniwang API.

Sa pangkalahatang termino, ang daloy ay ito: ang aplikasyon ay nagpapadala ng mga kahilingan sa SQL sa ODBC Driver Manager, na siyang hahanap at maglo-load ng naaangkop na driver para sa target na database , isinasalin ng driver ang kahilingan sa katutubong protocol ng DBMS, pinoproseso ng database ang query, at ang mga resulta ay ibinabalik sa parehong landas pabalik sa aplikasyon.

Ang arkitekturang ito ay hindi lamang nagbibigay-daan sa kalayaan ng vendor kundi tinutugunan din ang mga isyu tulad ng compatibility ng bersyon, paghawak ng error, conversion ng uri ng data, at mga pagkakaiba sa syntax ng SQL sa pagitan ng mga engine. Ang lahat ay ginawang transparent hangga't maaari para sa developer ng application.

Sa konteksto ng Windows, ang ODBC ay bahagi ng Windows Open Services Architecture (WOSA) , isang open services architecture kung saan ang mga desktop application ay maaaring kumonekta sa iba't ibang computing environment nang hindi kinakailangang muling isulat para sa bawat platform.

Pangunahing bahagi ng ODBC

Ang karaniwang implementasyon ng ODBC sa mga sistema ng Microsoft at maraming plataporma ay sumusunod sa isang karaniwang istruktura. Maaari nating makilala ang ilang pangunahing bahagi na nagtutulungan upang maibigay ang bukas na koneksyon na ito.

Sa isang banda, nariyan ang ODBC API , isang hanay ng mga call function, error code, at karaniwang SQL convention na ginagamit ng application upang gumana sa data. Tinutukoy ng API na ito kung paano binubuksan ang mga koneksyon, ipinapadala ang mga query, kinukuha ang mga resulta, at pinamamahalaan ang mga transaksyon, nang hindi umaasa sa partikular na DBMS.

Ang isa pang mahalagang elemento ay ang ODBC Driver Manager (sa Windows, ang Odbc32.dll library). Ang dynamic link library na ito ay nasa pagitan ng application at ng mga partikular na driver, naglo-load nang malinaw, at responsable sa paghahanap, paglo-load, at pag-download ng mga naaangkop na driver, pati na rin ang pamamahala ng mga bersyon at compatibility.

Susunod, mayroon tayong mga ODBC database driver . Ang bawat DBMS (SQL Server, Oracle, MySQL, DB2, atbp.) ay may sariling driver, kadalasan sa anyo ng isa o higit pang mga DLL. Ang mga driver na ito ang siyang aktwal na nagsasalin ng mga ODBC API call sa mga native DBMS call, na humahawak sa mga partikular na SQL syntax, mga internal na uri ng data, at mga partikularidad ng bawat engine.

Sa ilang mga kapaligiran, ginagamit din ang isang ODBC cursor library (hal., Odbccr32.dll sa Windows), na inilalagay sa pagitan ng Driver Manager at ng mga driver mismo upang pangasiwaan ang pag-scroll sa mga set ng resulta, mga advanced na cursor, at iba pang mga operasyon sa nabigasyon ng data.

Panghuli, mayroon tayong ODBC Data Source Manager , isang graphical o configuration tool na nagbibigay-daan sa iyong tukuyin at baguhin ang mga data source (DSN) ng system. Mula doon, ikaw ang magpapasya kung aling driver ang gagamitin, kung aling server o file ang kokonektahan, at kung anong mga authentication parameter ang gagamitin.

Mga application na pinagana ng ODBC at mga uri ng data source

Anumang software na maaaring magbukas ng koneksyon gamit ang karaniwang API ay maaaring ituring na isang application na pinagana ng ODBC . Sa totoong mundo, kabilang dito ang lahat mula sa mga office suite hanggang sa mga tool sa analytics at mga custom na application ng enterprise.

Kabilang sa mga karaniwang halimbawa ang Microsoft Excel , Microsoft Access , Power BI, Tableau, Crystal Reports, Qlik Sense, at napakaraming aplikasyon sa pamamahala (ERP, CRM, mga patayong solusyon, atbp.) na kailangang magbasa o magsulat ng datos sa iba't ibang sistema.

Upang paganahin ang application na ma-access ang data, ginagamit ang mga ODBC data source. Pinagsasama ng mga source na ito ang pinagmulan ng data sa mga kinakailangang impormasyon sa koneksyon: lokasyon ng server, pangalan ng database, username, password, at mga opsyon na partikular sa driver . Karaniwang naka-encapsulate ang configuration na ito sa isang Data Source Name (DSN) o isang connection string.

Sa Windows, ang mga pinagmumulan ng datos ng ODBC ay pinamamahalaan sa pamamagitan ng ODBC Data Source Manager . Doon, maaari mong i-configure ang iba't ibang uri ng mga DSN, bawat isa ay may sariling saklaw at storage mode , na nagbibigay ng malaking kakayahang umangkop kapag nagde-deploy ng mga aplikasyon sa mga indibidwal na computer o shared server.

Isang mahalagang detalye ay ang mga klase at library ng pag-access sa data ay maaaring gumana sa anumang mapagkukunan na may magagamit na ODBC driver . Kabilang dito ang mga relational database, ISAM engine, Excel spreadsheet, text file, o kahit na mga live na mapagkukunan ng data na naglalantad ng kanilang data sa isang tabular format na maa-access sa pamamagitan ng SQL.

Mga uri ng DSN at mga string ng koneksyon sa ODBC

Kapag pinag-uusapan natin ang pag-configure ng ODBC, halos palaging lumalabas ang konsepto ng DSN. Pinagsasama-sama ng DSN (Data Source Name) ang lahat ng datos na kinakailangan upang buksan ang koneksyon : kung aling driver ang gagamitin, kung aling server ang itinuturo nito, kung aling partikular na database, mga kredensyal, at mga karagdagang opsyon.

Sa mga sistema ng Windows, mayroong tatlong uri ng DSN. Iniimbak lamang ng mga User DSN ang configuration sa Registry para sa kasalukuyang profile ng user, kaya tanging ang account na iyon lamang ang makakagamit sa mga ito. Kapaki-pakinabang ang mga ito kapag gusto mong ihiwalay ang mga koneksyon ayon sa user at pigilan ang iba na makita ang configuration.

Ang mga System DSN ay nakaimbak din sa Registry, ngunit nakikita ng lahat ng gumagamit ng computer, kabilang ang mga serbisyo ng system. Ang mga ito ang inirerekomendang opsyon para sa mga server o shared installation, dahil pinapayagan nila ang iba't ibang account na gamitin ang parehong mga setting ng koneksyon nang walang duplikasyon.

Sa kabilang banda, may mga file-based DSN , na nag-iimbak ng impormasyon sa koneksyon sa isang text file na may .dsn extension sa halip na sa Registry. Ang mga DSN na ito ay karaniwang mas flexible, dahil maaari itong kopyahin sa ibang mga computer na may parehong driver na naka-install, o ilagay sa isang shared server upang i-centralize ang configuration.

Bukod sa mga shareable DSN, may mga non-shareable file DSN na nasa iisang makina at nagsisilbing pointer sa isang DSN ng makina . Nagbibigay-daan ito sa iyong gamitin ang mga umiiral na data source nang hindi inilalantad sa publiko ang buong configuration.

Sa maraming wika (halimbawa, Visual Basic o C#), maaari mo ring piliing huwag magtakda ng DSN at sa halip ay magpasa ng direktang connection string sa ODBC Driver Manager . Kasama sa string na ito ang parehong mga parameter tulad ng isang DSN ngunit naka-embed sa code, na nagpapadali sa pamamahagi ng aplikasyon kapalit ng ilang administratibong kakayahang umangkop.

Praktikal na configuration ng ODBC sa Windows

Ang karaniwang proseso para sa pagsisimula sa ODBC sa Windows ay sumusunod sa ilang malinaw na hakbang. Una, kailangan mong i-install ang naaangkop na ODBC driver para sa target na DBMS . Minsan ito ay kasama mismo ng Windows (halimbawa, mga generic na driver para sa SQL Server o Access), at sa ibang pagkakataon ito ay ibinibigay ng database vendor o isang espesyalisadong third party.

Kapag na-install na ang driver, buksan ang tool na "Data Sources (ODBC)" mula sa Control Panel → Administrative Tools. Magbubukas ang utility na ito ng ODBC Data Source Manager, kung saan maaari kang pumili kung gagawa ng user, system, o file DSN, depende sa iyong mga pangangailangan sa seguridad at pagbabahagi.

Ang susunod na hakbang ay i-click ang “Add”, piliin ang kaukulang driver (halimbawa, “SQL Server”, “Microsoft Access Driver (*.mdb, *.accdb)” , atbp.) at sundin ang wizard: karaniwan ay tatanungin ka ng naglalarawang pangalan ng source, ang server o file na tinuturo nito, at sa maraming pagkakataon ay mga credential o authentication mode.

Sa mga 64-bit na kapaligiran, dapat bigyang-pansin ang arkitektura: ang isang 64-bit na instalasyon ng Windows ay may kasamang dalawang bersyon ng ODBC Manager (Odbcad32.exe) : ang 64-bit na bersyon sa %systemdrive%\Windows\System32 at ang 32-bit na bersyon sa %systemdrive%\Windows\SysWOW64. Ang isang 32-bit na driver ay lilitaw lamang sa 32-bit manager, at pareho rin ito sa mga 64-bit na driver.

Ang mga aplikasyon tulad ng Access, Qlik Sense, at Tableau ay kumokonekta sa mga panlabas na database . Ang ilan ay nag-aalok din ng sarili nilang mga konektor na naglalaman ng mga lisensyadong ODBC driver (halimbawa, ang ODBC Connector Package ng Qlik) upang hindi na kailangang dumaan pa sa Windows Data Source Manager ang user.

Paggamit ng ODBC gamit ang mga tool tulad ng Access, Qlik Sense, o Tableau

Sa Microsoft Access, ang ODBC ay ginagamit upang mag-link o mag-import ng data mula sa mga panlabas na mapagkukunan kung saan ang Access ay walang built-in na native driver , tulad ng SQL Server, Oracle, o mga third-party na database. Ang proseso ay ang mga sumusunod: Kumokonekta ang Access sa ODBC Driver Manager, na gumagamit ng partikular na driver (halimbawa, ang SQL Server driver), at ang koneksyon sa database ay binubuksan.

Gamit ang Qlik Sense, mayroon tayong dalawang opsyon. Sa isang banda, maaari nating gamitin ang mga konektor na kasama sa Qlik ODBC Connector Package , na nagpapakita ng mga na-optimize na "Qlik-xxx" driver at direktang kino-configure mula sa Qlik interface, nang hindi dumadaan sa Windows ODBC manager. Sa kabilang banda, maaari tayong manu-manong mag-install ng ODBC driver para sa DBMS at lumikha ng user o system DSN na gagamitin ng Qlik Sense kapag lumilikha ng koneksyon ng data.

Sa Qlik Sense Desktop, maaaring ipakita ng listahan ng DSN ang parehong mga DSN na nilikha sa Windows at ang mga internal driver ng package (na kinilala gamit ang unlapi na "Qlik-"). Ang mga internal driver na ito ay hindi maaaring gamitin upang lumikha ng mga generic na koneksyon ng ODBC sa labas ng Qlik ecosystem; ang mga ito ay eksklusibong inilaan para sa mga konektor ng database na kasama sa mismong produkto.

Sa kaso ng Tableau, mayroong isang koleksyon ng mga pinong naka-tune na native connector para sa mga partikular na database (Snowflake, SQL Server, Oracle, atbp.), ngunit mayroon ding generic na ODBC connector na inaalok kapag kailangan mong ma-access ang isang database kung saan walang partikular na connector. Ginagamit ng connector na ito ang pamantayan ng ODBC upang makipag-ugnayan sa halos anumang source na nagpapatupad ng SQL at ng ODBC API.

Kapag kumokonekta sa pamamagitan ng ODBC, nagsasagawa ang Tableau ng isang discovery phase kung saan kinukuwestiyon nito ang ODBC driver upang matukoy ang mga sinusuportahang kakayahan nito : mga scalar at aggregation function, date handling, mga kakayahan sa subquery, mga available na uri ng JOIN, paglikha ng mga pansamantalang talahanayan, atbp. Batay sa tugon ng driver, inuuri ng Tableau ang koneksyon bilang ganap na gumagana, may maliliit na limitasyon, may malalaking limitasyon, o ganap na hindi magagamit.

Relasyon sa pagitan ng ODBC at JDBC

Sa loob ng ecosystem ng pag-access ng datos, ang ODBC ay may natural na katumbas nito sa mundo ng Java: ang JDBC (Java Database Connectivity) . Pareho silang naghahangad ng iisang layunin: ang magbigay ng pamantayan para sa mga aplikasyon na kumonekta sa iba't ibang database gamit ang SQL, ngunit may mga pamamaraang iniangkop sa kanilang kapaligiran.

Bagama't ang ODBC ay pangunahing inilaan para sa mga aplikasyong nakasulat sa C, C++, o iba pang mga wika na sumusuporta sa API nito at malawakang ginagamit sa Windows (bagaman ginagamit din sa iba pang mga platform), ang JDBC ay bahagi mismo ng Java ecosystem at cross-platform ayon sa kahulugan, na tumatakbo sa virtual machine.

Ang arkitektura ng JDBC ay nahahati sa isang API layer , na binubuo ng mga Java interface at klase na ginagamit ng mga developer, at isang driver layer na nagpapatupad ng mga interface na iyon at nakikipag-ugnayan sa aktwal na database. Mayroong apat na uri ng mga JDBC driver: Type 1 (ODBC bridge), Type 2 (native/partial API), Type 3 (network protocol), at Type 4 (100% Java "thin" driver).

Ang lumang JDBC-ODBC bridge driver (Type 1) ay nagpapahintulot sa mga Java application na ma-access ang mga database sa pamamagitan ng ODBC . Ito ay naging kapaki-pakinabang bilang isang transisyonal na solusyon, ngunit sa paglipas ng panahon ay naging hindi na ito kanais-nais dahil sa pagganap at pagiging kumplikado, at mula noon ay nawala na sa mga modernong bersyon ng Java.

Sa JDBC, ang isang koneksyon sa database ay itinatatag gamit ang isang URL na naka-format bilang jdbc::/// kasama ang mga opsyonal na katangian. Halimbawa: jdbc:mysql://localhost:3306/mydatabase. Mula sa URL na ito, hahanapin ng Java DriverManager ang naaangkop na driver at bubuksan ang koneksyon, katulad ng kung paano pinipili ng ODBC Manager ang driver sa ODBC environment.

Sa mga praktikal na pagkakaiba, ang ODBC at JDBC ay pangunahing nakikilala sa pamamagitan ng wika at ecosystem na kanilang tinatarget . Ang ODBC ay lubos na nagsasama sa Windows at mga katutubong aplikasyon, habang ang JDBC ay maayos na nagsasama sa mundo ng Java, sumusuporta sa mga uri ng datos na partikular sa Java, at nagbibigay ng sarili nitong mga kagamitan tulad ng ResultSet para sa paghawak ng mga resulta. Sa ilang mga sitwasyon, ang isang Type 4 JDBC driver ay maaaring mag-alok ng lubos na mapagkumpitensyang pagganap sa pamamagitan ng pag-aalis ng mga intermediate layer.

Sa huli, ang pagpili sa pagitan ng isa at ng isa pa ay natutukoy ng teknolohiya ng aplikasyon: Ang mga aplikasyon ng Java ay may posibilidad na gumamit ng JDBC; ang mga katutubong aplikasyon, ODBC . Sa anumang kaso, pareho silang kumakatawan sa parehong pilosopiya ng standardized, vendor-agnostic access.

Ang ODBC ay nananatiling isang mahalagang bahagi sa palaisipan ng pag-access ng data: pinapayagan nito ang mga programa ng lahat ng uri na kumonekta sa iba't ibang database sa pamamagitan ng isang karaniwang API, itinatago ang mga pagkakaiba ng bawat engine salamat sa mga driver nito, umaangkop sa mga tool na kasing-iba ng Access, Qlik Sense o Tableau, at nabubuhay kasama ng iba pang mga pamantayan tulad ng JDBC sa mundo ng Java. Kaya, kung naiintindihan mo kung paano gumagana ang ODBC, nasa kalagitnaan ka na ng maayos na paglipat sa halos anumang modernong kapaligiran ng database.