Pelajaran sejarah adalah salah pelajaran favoritku di sekolah, kecuali PSPB :-). Dalam artikel ini saya akan mencoba membahas sejarah perkembangan model komponen data akses (Data Access Component) di lingkungan Windows dan bagaimana evolusinya sampai sekarang… eh… evolusi kan pelajaran biologi ya? bukan sejarah… halah… Artikel ini terbagi menjadi 3 bagian dengan bagian pertama membahas konsep Data Access Universal, bagian kedua membahas lebih detail mengenai Data Access Consumers, dan bagian ketiga membahas model data akses dalam .NET framework. Selamat membaca…
Sejarah Singkat Data Access Universal
Pada awalnya tidak ada keseragaman metode dalam mengakses data. Setiap sistem database memiliki API (Application Programming Interface) dan metode aksesnya sendiri-sendiri. Sebagai contoh Clipper dan Foxpro pada masa DOS, masing masing memiliki bahasa pemrogramannya sendiri, kalaupan ada kesamaan tidaklah terlalu banyak. Kelihatannya tidak terlalu sulit, setiap programmer hanya perlu memahami semua fungsi dalam API database yang dipakainya. Kesulitannya adalah ketika perlu berpindah ke sistem database yang lain. Pengetahuan tentang sistem database lama seakan tidak diperlukan lagi karena harus mempelajari sistem database yang baru dari awal lagi. Lama kelamaan hal seperti ini tidak lagi bisa dilakukan karena semakin banyaknya vendor yang menawarkan sistem database mereka sendiri, dengan segala kelebihan dan kekurangannya tentunya. Sulit bagi programmer untuk bisa memahami seluruhnya kecuali ada semaram standarisasi dalam metode akses database yang berbeda-beda tersebut. Berikut ini adalah standarisasi yang dilakukan dalam platform Windows.
ODBC
Open Database Connectivity (ODBC) membantu programmer memanfaatkan berbagai sistem database tanpa perlu mengetahui detil API yang dari sistem database bersangkutan. Untuk dapat mencapai ini ODBC menyediakan model akses databasenya dan semua vendor sistem database cukup mengimplementasikan model akses tersebut sehingga ODBC dapat mengakses sistem database bersangkutan. Implementasi model akses database ini biasa kita sebut sebagai driver. Dengan cara ini programmer hanya perlu mengetahu API dari ODBC saja untuk dapat mengakses bermacam-macan sistem database.
Dengan cara seperti ini, para programmer dapat dengan mudah berpindah dari satu sistem database ke sistem database lainnya dan memanfaatkan ketrampilan yang sudah mereka dapatkan sebelumnya. Lebih jauh lagi, programmer bisa membuat aplikasi yang tidak terikat pada satu sistem database tertentu. Pendekatan ini baik untuk aplikasi yang dibuat untuk konsumsi umum karena memberikan kebebasan bagi customer bersangkutan dalam memilih sistem database yang akan mereka gunakan, bisa jadi customer bersangkutan sudah menginvestasikan dana cukup besar untuk sistem database tertentu dan tidak ingin mengluarkan dana lagi untuk membeli sistem database lainnya.
ODBC adalah sebuah lompatan besar dalam mempermudah pengembangan aplikasi database. Namun bukan berarti tanpa kelemahan. Pertama, ODBC hanya mendukung akses untuk data yang terstruktur seperti sistem database relational. Untuk data yang tidak terstruktur, atau data dengan sistem hirarki seperti LDAP, kita tidak bisa menggunakan ODBC. Kedua, ODBC hanya dapat menangani perintah SQL, sebagai standar, dan hasilnya harus dapat direpresentasikan dalam bentuk baris dan kolom. Tapi secara umum ODBC bisa dikatakan sukses besar jika dibandingkan dengan kondisi sebelum ODBC diperkenalkan…
OLE DB
Object Linking and Embedding Database (OLE-DB) adalah langkah berikutnya dalam standarisasi metode akses database, dan masih banyak sekali digunakan saat ini. OLE-DB merupakan aplikasi dari pengetahuan yang didapatkan saat mengembangkan ODBC untuk membuat model akses data yang lenih baik. OLE-DB juga menandai perubahan strategi Microsoft untuk menggunakan API berbasis COM sehingga memudahkan OLE-DB digunakan dalam berbagai macam bahasa pemrograman, sekaligus perpindahan ke sistem operasi 32-bit dengan diluncurkannya Windows 95.
Seperti umumnya sebuah program, ODBC menjadi semakin besar dan gemuk karenaberbagai macam perbaikannya. Sedangkan API yang disediakan OLE-DB jauh lebih ringkas serta memberikan performa yang lebih baik dibandingkan ODBC. Uniknya, saat pertama kali diluncurkan, OLE-DB hanya memberikan provider untuk ODBC. Provider OLE-DB untuk ODBC ini hanya sebuah wrapper terhadap API ODBC dan tidak memberikan perbaikan kinerja. Hal ini rupanya ditujukan agar para programmer menjadi terbiasa dengan API yang baru, sambil menunggu tersedianya provider yang lebih efisien dibuat untuk mengakses sistem database langsung tanpa melaui ODBC.
OLE-DB Providers
OLE-DB tidak terlalu bergantung pada struktur fisik sistem database yang diaksesnya, sehingga OLE-DB dapat mendukung sumber database relasional maupun hirarki. OLE_DB juga tidak mengharuskan query dalam bentuk SQL. OLE-DB terbagi dalam 2 bagian, yaitu OLE-DB Provider dan OLE-DB Consumer. ODBC mengharuskan para vendor database membuat provider khusus untuk sistem database mereka, dan ini bukan pekerjaan mudah. Namun dalam OLE-DB, jauh lebih mudah untuk membuat provider kita sendiri dengan format sumber data yang kita tentukan sendiri. Sebuah provider OLE-DB hanya perlu melakukan 4 langkah berikut ini:
- Buka sesi.
- Proses perintah yang diberikan.
- Akses data yang diminta.
- Siapkan hasilnya.
OLE-DB Consumers
Bagian kedua dari OLE-DB framework adalah OLE-DB consumer. Bagian ini merupakan lapisan yang berkominikasi langsung dengan provider. Lapisan ini malukan langkah-langkah berikut:
- Tentukan sumber datanya.
- Buka sesi.
- Berikan perintah.
- Kembalikan hasil yang didapat.
Gambar berikut menunjukkan bagaimana OLE-DB bekerja.
Bersambung ke bagian II (OLE DB Consumers)