Programming

Artikel ini merupakan bagian terakhir dari 3 artikel tentang Data Access Component di lingkungan Windows. 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, atau lebih kita kenal sebagai ADO.NET. ADO.NET

Bersamaan dengan diluncurkannya .NET Framework, Microsoft memperkenalkan model akses data baru yang diberi nama ADO.NET. Singkatan ActiveX Data Object sebenarnya tidak lagi relevan karena ADO.NET bukanlah komponen ActiveX, namun merupakan model yang benar-benar baru dibangun menggunakan .NET framework. Microsoft sepertinya mempertahankan nama ADO karena kasuksesannya yang luar biasa.

ADO.NET tetap memberikan dukungan komunikasi data menggunakan ODBC dan OLE-DB, namun menawarkan pilihan lain yaitu dengan menggunakan Data Provider yang khusus dibangun untuk database tertentu. Data provider ini mampu memberikan kinerja yang lebih baik karena dapat memanfaatkan optimisasi yang ditawarkan oleh vendor database bersangkutan. Dengan menggunakan custom-code yang spesifik untuk database tertentu juga menghilangkan sejumlah overhead yang terjadi ketika menggukan generic-code seperti ODBC dan OLE-DB. Rilis awal yaitu ADO.NET 1.0, baru memberikan dukungan untuk Database SQL Server dan OLE-DB. Riils berikutnya – ADO.NET 1.1 – Microsoft menambahkan dukungan untuk database Oracle dan ODBC. Pada saat yang hampir bersamaan Oracle juga merilis data provider milik mereka sendiri, yaitu ODP.NET 9.2.

Gambar berikut ini menggambarkan cara ADO.NET bekerja.

Berbeda dengan ADO yang menawarkan konsep recordset dan cursor, ADO.NET memperkenalkan model yang benar-benar baru meliputi lima obyek dasar sebagai berikut:

• Connection — berfungsi untuk membuat dan memelihara koneksi ke database. Parameter yang digunakan untuk membuat koneksi bisa jadi ada sedikit perbedaan antara satu database dengan database lainnya.
• Command — berfungi untuk menyimpan query (perintah SQL) yang nantinya akan kirimkan ke database termasuk dengan semua parameter yang diperlukan.
• DataReader — digunakan untuk membaca hasil query yang dikembalikan oleh database. DataReader hanya memberikan akses maju-saja (forward-only) namun sangat cepat untuk membaca seluruh data/record hasil query..
• DataSet — obyek inilah yang membuat ADO.NET sangant berbeda dengan metode data akses yang ada sebelumnya. Obyek ini yang berada di memori dan bertindak sebagai tempat penyimpanan data/record yang didapat dari server database. DataSet sendiri tidak bisa berkomunikasi langsung dengan server database dan tidak mengetahui dari mana data yang disimpannya berasal.
• DataAdapter — obyek inilah yang bertugas menjembatani DataSet dengan database sebenarnya. DataAdapter bertugas untuk menarik data/record dari database dan menyimpan kembali penambahan, perubahan atau penghapusandata/record pada DataSet kembali ke database.

 

ADO.NET membuat lompatan yang sangat besar. Salah satunya adalah adanya dukungan penuh untuk model akses data terputus (disconnected). Mempertahankan sebuah koneksi yang tidak tidak terputus ke database server adalah proses yang cukup mahal harganya. Terutama dari sisi database server yang mengharuskan pengalokasian sumber daya – terutama CPU dan memory – untukkoneksi tersebut. Ketika hanya ada satu koneksi saja yang perlu dipertahankan, mungkin tidak terlalu menjadi masalah, lain halnya jika koneksi yang perlu dipertahankan tidak sedikit, misalkan pada aplikasi web, tentunya jumlah memory dan CPU yang terpakai akan jauh lebih besar. Namun jika kita menggunakan metode akses data yang terputus, sumber daya yang semula terpakai dapat langsung dibebaskan dan dipakai oleh proses lain.

Fitur lain yang meningkatkan performa akses data adalah diperkenalkannya connection pooling. Mempertahankan sebuah koneksi ke database adalah proses yang mahal, namun membuka dan menutup koneksi database adalah proses yang lebih mahal lagi. Connection pooling mampu mengatasi masalah ini. Ketika koneksi yang kita buat dalam program ditutup, ADO.NET tidak langsung menutup koneksi tersebut, namun menyimpannya dalam sebuah pool sampai jangka waktu tertentu. Pada saat itu ketika ada proses yang membutuhkan koneksi, maka ADO.NET tidak perlu lagi membuat koneksi baru, namun cukup menggunakan koneksi yang sudah tersedia di pool.

Keunggulan lain dari ADO.NET adalah dukungan terhadap XML. Secara internal obyek DataSet menyimpan data di memory dalam bentuk XML. DukunganXML ini memudahkan ADO.NET dalam melakukan proses filtering dan sorting data yang tersimpan di memory. Dukungan XML juga memudahkan proses pengambilan data, penuilsan data kembali ke database dan mengubah ke dalam format lainnya.

 

ADO.NET 2.0

Perkembangan teknologi data akses sudah begitu canggih dengan adanya ADO.NET, namun rupanya Microsoft masih menemukan cara untuk mengembangkannya, yaitu dengan diperkenalkannya ADO.NET 2.0. Perubahan yang ada pada ADO.NET 2.0 tidak seradikal perubahan dari ADO ke ADO.NET, namun lebih berupa panambahan fitur-fitur baru, yang memudahkan para programmer dalam proses pengembangan aplikasi. Desain asal ADO.NET 2.0 masih sama dengan ADO.NET 1.x sehingga semua aplikasi yang sebelumnya dibuat menggunakan ADO.NET 1.x akan 100% kompatibel dengan ADO.NET 2.0.

Salah satu tujuan dari ADO.NET 2.0 adalah peningkatan performa. Bukan berarti performa ADO.NET 1.x buruk, namun peningkatan dapat dilakukan misalnya dengan tambahan dukungan penulisan data beberapa row sekaligus (bulk insert) yang sebelumnya harus dilakukan satu persatu.

Fitur yang tambahan lainnya adalah notifikasi ketika ada perubahan data di database. Fitur lainnya adalah dukungan Multiple Active Result Sets (MARS), dengan cara ini, dengan satu query dapat memberikan beberapa hasil sekaligus, sehingga mengurangi proses komunikasi antar aplikasi dengan database.

ADO.NET 2.0 juga memudahkan programmer untuk membuat aplikasi yang mendukung beberapa produk database dengan menggunakan satu coding saja, artinya coding yang sama mampu mendukung beberapa sistem database sekaligus. Hal ini sangat berguna sekali ketika kita ingin apilkasi ini tidak hanya mendukung satu sistem database saja. Namun perlu diperhatikan, bahwa sintaks SQL tetap spesifik untuk sistem database tertentu, misalkan sintaks Transact-SQL di SQL Server tidak bisa dijalankan di Oracle.

 

ADO.NET 3.0

ADO.NET 3.0 dirilis bersamaan dengan dirilisnya Visual Studio 2008 sebagai bagian dari .NET framework 3.5. Ada loncatan pada versi .NET framework dikarenakan .NET framework 3.0 sebelumnya sudah dirilis sebagai bagian dari Windows Vista, namun versi ADO.NET pada framework 3.0 masih versi 2.0. Salah satu fitur utama dari ADO.NET 3.0 adalah Object Relational Mapping (ORM) dan Language Integration Query (LINQ). Dengan menggunakan OR/M dan LINQ memungkinkan kita mengakses data secara lebih mudah dan transaparan. Sebagai contoh, dalam .NET 2.0 kita masih sibuk dengan proses buka tutup koneksi ke database, maka hal ini tidak akan terlihat lagi dalam .NET 3.0 berkat fitur ORM dan LINQ ini.

Dikarenakan cukup panjangnya bahasan mengenai ORM dan LINQ, maka saya pikir akan kita bahas lebih detail dalam artikel-artikel berikutnya, namun untuk informasi lebih lanjut Anda dapat mengunjungi website Microsoft di http://msdn.microsoft.com/data/ref/linq/

Selesai…

 

Artikel ini merupakan bagian kedua dari 3 artikel tentang Data Access Component di lingkungan Windows. 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.

Data Access Consumers

Para programmer yang menggunakan bahasa yang mendukung pointer – seperti C, C++ dan sebagainya – dapat berkomunikasi dengan database langsung menggunakan API yang disediakan ODBC atau OLE-DB. Namun untuk programmer yang menggunakan bahasa pemrograman yang tidak mendukung pointer – seperti Visual Basic -memerlukan lapisan lain. Disinilah DAO, RDO, ADO, and ADO.NET dapat berperan.

DAO

Bersamaan dengan diluncurkannya Visual Basic 2.0, para programmer diperkenalkan dengan sebuah metode akses data baru yang dikenal sebagai Data Access Objects (DAO). Ini adalah usaha pertama Microsoft membuat Data Access Consumer. Walaupun versi awal kemampuannya sangat terbatas, Namun ini adalah awal sejumlah library yang memudahkan programmer dalam mengakses data karena sangat membantu programmer dengan bahasa tingkat tinggi seperti Visual Basic untuk memanfaatkan keunggulan ODBC. Sebelumnya ODBC API hanya bisa diakses melalui bahasa dengan elvel lebih rendah seperti C dan C++.

DAO dikembangkan menggunakan library JET. JET sendiri adalah library/engine yang digunakan oleh Microsoft untuk membangun aplikasi database Microsoft Access. DAO bersungsi sebagai lapisan yang menghubungkan aplikasi dengan database itu sendiri. Tujuannya tentu untuk memudahkan kerja programmer.

Varsi awal dari DAO ini sudah dimasukkan dalam paket pemrograman Visual Basic 2.0, namun secara resmi baru diberikan nama DAO 1.0 ketika Microsoft Access 1.0 diluncurkan. Versi ini baru mendukung koneksi langsung ke database Access dan ODBC. Versi 2.0 kemudian diluncurkan untuk mendukung OLE-DB dan versi 2.5 dan 3.0 juga akhirnya diluncurkan untuk mendukung ODBC 2.0 dan sistem operasi 32-bit yang baru diluncurkan, Windows 95.

Gambar berikut ini menunjukkan bagaimana DAO bekerja.

 

Namun ada satu kelemahan mendasar yang dimiliki oleh DAO, yaitu DAO hanya dapat berkomunikasi langsung dengan JET engine. Untuk mengakses database selain Microsoft Access menggunakan ODBC maka harus berkomunikasi dahulu dengan JET engine. Hal ini membuat kinerja DAO dianggap kurang memuaskan.

 

RDO

Remote Data Objects (RDO) adalah upaya Microsoft mengatasi lambatnya kinerja DAO. Saat perlu mengakses database selain MS Access maka RDO langsung berkomunikasi dengan ODBC tanpa menggunakan JET engine. Dengan cara ini kinerja RDO jauh meningkat dibandingkan dengan DAO. JET hanya digunakan ketika akan mengakses database MS Access.

Gambar berikut menunjukkan bagaimana RDO bekerja.

 

Hal lain yang menjadi keunggulan RDO adalah fitur client-side cursor saat melakukan navigasi data. Berlawanan dengan DAO yang hanya mendukung server-side cursor. Fitur ini mampu mempercepat kinerja aplikasi dan mengurangi beban koneksi aplikasi pada server database.

Namun secara umum RDO tidak mendapatkan tanggapan yang serius dari para pengembang perangkat lunak. RDO utamanya ditujukan untuk bagi customer komersil untuk membangun aplikasi berskala enterprise, serta bagi para pengembang yang tidak mau menggunakan DAO karena kinerjanya yang buruk. Dengan alasan ini RDO hanya tersedia pada Visual Basic Enterprise Edition. Akibatnya tidak semua programmer memiliki akses untuk memanfaatkannya. Programmer yang membangun aplikasi kecil yang tidak terlalu bermasalah dengan kinerja juga enggan berpindah ke RDO. Ditambah lagi dengan diluncurkannya ODBCDirect – sebuah add-on untuk DAO yang mampu meningkatkan kinerja DAO – membuat popularitas RDO semakin berkurang di kalangan pengembang perangkat lunak.

ADO

 

Microsoft memperkenalkan ActiveX Data Objects (ADO) untuk menyediakan API dengan level yang lebih tinggi saat memanfaatkan OLE-DB untuk berkumonikasi dengan database. Microsoft juga belajar banyak dari pengalaman sewaktu mengembangkan DAO dan RDO untuk membuat API yang lebih ringan, dan lebih efisien. ADO ditujukan untuk menggantikan DAO dan RDO. Pada saat awal diluncurkan ADO (dan OLE-DB) diyakini sebagai solusi untuk mengakses berbagai macam database sampai email, file teks bahkan spreadsheet.

ADO juga memperkenalkan metode baru dalam mengakses database. Pada masa DAO dan RDO, para programmer harus mengerjakan beberapa langkah yang cukup rumit sebelum bisa menjalankan sebuah perintah sederhana. Sebagai contoh, untuk menjalanakan sebuah perintah SQL dalam RDO, programmer tidak bisa serta merta membuat obyek rdoQuery, tapi sebelumnya hanrus membuat obyek rdoEngine, kemudian rdoEnvironment sebagai child-nya, kemudian rdoConnection baru kemudian obyek rdoQuery bisa dibuat. Dalam DAO situasinya tidak jauh berbeda. Dalam ADO, semua langkah-langkah ini dipermudah. Programmer dapat langsung membuat obyek command dengan memberikan parameter connection dan langsung menjalankannya. Obyek command bahkan dapat berdiri sendiri walaupun obyek connection belum dibuatkan.

Salah satu kelebihan lain adalah ADO menyediakan provider model. Provider model membuat ADO mampu berkomunikasi dengan sumber data selain OLE-DB. Model ini juga memudahkan pengembang perangkat lunak independen membuat provider mereka sendiri, provider ini nantinya akan digunakan ADO untuk berkomunikasi dengan sumber data bersangkutan. Sebagai contoh adalah provider ODBC. Ketika programmer ingin menakses sember data ODBC, maka ADO akan berkomunikasi langsung dengan ODBC, tidak melalui OLE-DB. Metode akses langsung ini semakin meningkatkan kinerja yang diberikan ADO dibandingkan dengan Data Consumer pendahulunya.

Gambar berikut menunjukkan bagaimana ADO bekerja.

 

ADO juga memberikan sejumlah kemudahan bagi para programmer yang merasa kesulitan dengan model akses data yang diberikan DAO dan RDO. Kemudahan itu antara lain adalah:

• Kemampuan melakukan Batch Update — Untuk pertam kalinyam perubahan data pada beberapa record sekaligus bisa dilakukan di memori terlebih dahulu, perubahan ini kemudian bisa dilakukan secara permanen ke database dengan perintahUpdateBatch.
• Dukungan Disconnected Data Access — dengan melakukan perubahan data tanpa terhubung dengan server (disconnected state) mampu mengurangi beban pada server database, hasil perubahan kemudian dapat dilakukan secara permanen menggunakan Batch Update.
• Dukungan Multiple Recordsets — ADO juga mampu menjalankan query yang menghasilkan beberapa kumpulan data (multiple recordset) sekaligus. Pada ADO.NET fitur ini dikenal dengan nana Multiple Active Result Sets (MARS).

Walaupun begitu banyak perbaikan yang ditawarkan ADO, bukan berarti tidak memiliki kelemahan. Sebagai contoh adalah dukungan Disconnected Data Access yang tidak terkalu populer dikalangan programmer, bahkan mungkin ada yang tidak mengetahuinya. Para programmer lebih memilih untuk membiarkan koneksi database tetap terbuka sambil melakukan perubahan terhadap data.

Para programmer yang mencoba langsung menutup koneksi database setelah mengambil data mendapati bahwa mereka harus membuka kembali koneksi database kembali untuk meneruskan perubahan data di memori secara permanen ke database. Proses buka tutup koneksi database ini rupanya merupakan proses yang cukup memakan waktu sehingga justru menurunkan kinerja aplikasi secara keseluruhan. Sebagai akibatnya, para programmer lebih memilih membiarkan satu koneksi ke database tetap terbuka dan memanfaatkan koneksi ini untuk semua proses akses database pada aplikasi.

Bersambung ke bagian III (ADO.NET)

 

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:

1. Buka sesi.
2. Proses perintah yang diberikan.
3. Akses data yang diminta.
4. 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:

1. Tentukan sumber datanya.
2. Buka sesi.
3. Berikan perintah.
4. Kembalikan hasil yang didapat.

Gambar berikut menunjukkan bagaimana OLE-DB bekerja.

Bersambung ke bagian II (OLE DB Consumers)