Tugas 3 - Database Relasional

PENDAHULUAN Database relasional merupakan dasar dari sebagian besar SIA terpadu yang modern. Bab ini menjelaskan konsep database. Penekanannya lebih pada pemahaman struktur sistem database relasional, yang merupakan jenis database terpopuler dalam memproses transaksi. File versus Database Agar dapat benar-benar memahami secara menyeluruh kelebihan database, merupakan hal yang penting untuk memahami terlebih dahulu beberapa prinsip dasar tentang bagaimana data disimpan dalam sistem komputer. Gambar 1-1 memperlihatkan elemen-elemen dasar yang biasanya dinamakan hierarki data. Informasi mengenai atribut suatu entitas, seperti nama pelanggan dan alamatnya, disimpan di dalam field. Semua field yang berisi data mengenai satu entitas (misalnya: satu pelanggan) membentuk catatan (record). Gabungan dari beberapa catatan yang saling berhubungan, seperti seluruh catatan pelanggan membentuk file (misalnya: file pelanggan). Suatu gabungan file yang saling berhubungan dan dikoordinasi secara terpusat, membentuk database. Jenis-Jenis File Ada dua jenis file dasar. Pertama adalah file utama (master file) yang konsepnya hampir sama dengan buku besar dalam SIA manual. File utama menyimpan informasi komulatif mengenai sumber daya organisasi dan pelaku-pelaku dengan siapa mereka berinteraksi. Sebagai contoh, file utama persediaan dan perlengkapan menyimpan informasi mengenai sumber daya yang penting bagi perusahaan. Dalam cara yang hampir sama, file utama pelanggan, pemasok, dan karyawan menyimpan informasi mengenai para pelaku penting utama yang berinteraksi dengan organisasi. File-file utama adalah file permanen; file tersebut telah melalui berbagai periode fiska. Akan tetapi, catatan individual dalam suatu file utama sering kali berubah. Jenis perubahan yang paling umum dibuat dalam catatan difile utama adalah memperbarui data yang mencerminkan pengaruh dari suatu transaksi. Sebagai contoh, saldo suatu akun pelanggan dalam file utama pelanggan diperbarui untuk mencerminkan transaksi

penjualan yang baru dilakuan dan pembayaran yang baru diterima. Catatan yang baru juga dapat ditambahkan ke dalam file utama secara periodik, dan kadang-kadang, catatan individual juga dapat dihapus. Jenis file dasar yang kedua adalah file transaksi (transaction file), yang konsepnya hampir sama dengan jurnal dalam SIA manual. File-file transaksi berisi catatan mengenai setiap transaksi bisnis (event) yang terjadi dalam periode fiskal tertentu. Sebagai contoh, S&S,Inc., nantinya akan memiliki file transaksi yang berisi catatan atas transaksi penjualan dan file transaksi lain yang berisi catatan mengenai pembayaran pelanggan. Kedua file ini akan digunakan untuk memperbarui saldo akun setiap pelanggan yang terdapat dalam file utama pelanggan. File transaksi tidak bersifat permanen, tetap biasanya dipertahankan tetap on-line hanya selama satu periode fiskal. Selama bertahun-tahun banyak perusahaan yang telah membuat file dan program setiap kali kebutuhan atas suatu informasi muncul. Hasilnya adalah peningkatan yang signifikan dalam jumlah file utama yang disimpan oleh suatu organisasi. Pertumbuhan fikle utama ini pada akhirnya menimbulkan masalah. Sering kali data yang sama disimpan di dalam dua atau lebih file utama yang terpisah (lihat Gambar 1-2). Hal ini mempersulit proses untuk mengintegrasikan data secara efektif dan untuk memperoleh pandangan atas data di seluruh perusahaan. Kondisis ini juga menimbulkan masalah karena nilai data tertentu yang disimpan di dalam file yang berbeda bisa tidak konsisten satu sama lain. Sebagai contoh, alamat seorang pelanggan dapat saja diperbarui dengan benar dalam file utama yang digunakan untuk mengirim barang dagangan, tetapi alamat yang lama masih tersimpan di dalam file utama yang digunakan untuk penagihan. Database Sistem database dibangun untuk mengatasi masalah yang berhubungan dengan pertumbuhan file utama. Database adalah suatu gabungan file yang saling berhubungan dan dikoordinasi secara terpusat. Pada gambar 1-2 mengilustarsikan perbedaan antara sistem berdasarkan file dan database. Pendekatan database memperlakukan data sebagai sumber daya organisasi yang seharusnya dipergunakan serrta dikelola oleh seluruh bagian organisasi tersebut, bukan hanya oleh suatu departemen atau fungsi

tertentu saja. Fokusnya adalah integrasi data dan pembagian data dengan seluruh pemakaian yang berhak memakainya. Integrasi data dicapai dengan mengkombinasikan beberapa file utama ke dalam “kolam” (poll) data yang dapat diakses oleh berebagai program aplikasi. Gambar 1.2 memperlihatkan bahwa hal ini dapat dicapai dengan mempergunakan sebuah program yang disebut sebagai database management system (DBMS). Program ini bertindak sebagai interface antara database dengan berbagai program aplikasi. Kombinasi database, DBMS, dan program aplikasi yang mengakses database melalui DBMS disebut sebagai sistem database. Gambar 1.2 Sistem berdasarkan Sistem vs Database Pendekatan Berdasarkan File

Pendekatan Database

SISTEM DATABASE Sistem database memisahkan tampilan logis dan fisik data. Tampilan logis adalah bagaimana pemakai atau programer secara konseptual mengatur dan memahami data. Sebagai contoh, seorang manajer penjualan mengkonseptualisasikan seluruh informasi mengenai para pelanggan, yang menyimpannya dalam bentuk tabel. Tampilan fisik merujuk pada bagaimana dan di mana data secara fisik diatur dan disimpan dalam disk, tape, CD-ROM, atau media lainnya. Skema Skema (schema) mendeskripsikan struktur logis database, terdapat tiga tingkatan skema, yaitu: konseptual, eksternal, dan internal. Skema tingkat konseptual (concepual level schema) adalah tampilan seluruh database pada tingkat organisasi. Skema ini mendaftar elemen-elemen data dan hubungan antar mereka. Skema tingkat eksternal terdiri dari satu set tampilan individual bagi pemakai dari berbagai bagian database, yang setiap bagiannya merupakan subskema. Skema tingkat internal menyediakan tampilan tingkat rendah dari database. Skema ini mendeskripsikan bagaimana data sebenarnya disimpan dan diakses, termasuk informasi mengenai petunjuk (pointer), indeks, panjang catatan, dan seterusnya. DBMS mempergunakan pemetaan untuk menerjemahkan permintaan data dari seorang pemakai atau suatu program aplikasi ke petunjuk (pointer), indeks, dan alamat yang dibutuhkan agar secara fisik dapat mengakses data. Kamus Data Salah satu komponen kunci dari DBMS adalah kamus data (data dictionary), yang mencakup informasi mengenai struktur database. Setiap elemen data yang disimpan dalam database, seperti nomor pelanggan, memiliki catatan di kamus data yang mendeskripsikan elemen tersebut. DBMS biasanya memelihara kamus data. Bahkan, kamus data ini sering kalimerupakan salah satu aplikasi pertama dari sistem database yang baru

diimplementasikan. Masukan (inputs) untuk kamus data mencakup elemen data yang baru atau yang sudah dihapus, serta perubahan nama,deskripsi, atau penggunaan elemen yang ada. Keluaran (outputs) mencakup berbagai laporan yang berguna bagi programer, perancang database, dan pemakai sistem informasi. Bahasa-bahasa DBMS Setiap DBMS harus menyediakan sarana untuk pelaksanaan tiga fungsi dasar, yaitu: menciptakan, mengubah, dan mempertanyakan database. Bahasa definisi data (data definition language-DDL) digunakan untuk (1) membangun kamus data, (2) mengawalib atau menciptakan database, (3) mendesakripsikan pandangan logis untuk setiap pemakai atau programer, dan (4) memberikan batasan untuk keamanan field atau catatan pada database. Bahasa manipulasi data (data manipulation language-DML) digunakan untuk perawatan data, yang mencakup operasi seperti pembaruan (updating), penyisipan (inserting), dan penghapusan (deleting) suatu bagian dari database. Bahasa permintaan data (data query language-DQL) dipergunakan untuk menyelidiki database. Apabila DML dipergunakan untuk mengubah isi database, maka DQL hanya dipergunakan untuk mengambil data, menyortir data, menyusun data, dan menyajikan suatu bagian dari database sebagai respons atas permintaan data. Banyak DBMS yang juga memasukkan penulisan laporan (report writer), yaitu sebuah bahasa yang menyederhanakan pembuatan laporan. Umumnya, pemakai hanya perlu menspesifikasikan elemen data yang ingin mereka cetak dan bagaimana format laporan tersebut. Penulis laporan kemudian akan mencari dalam database yang dispesifikasikan, mengekstrasi bagian data tersebut, dan mencetaknya sesuai dengan format yang yang telah ditentukan oleh pemakai. DATABASE RELASIONAL DBMS dikarakterisasikan melalui jenis model logis data yang mendasarinya. Model data adalah perwakilan abstrak dari isi suatu database. Kebanyakan DBMS yang

baru disebut sebagai database relasional, kerena menggunakan model relasional data yang dikembangkan oleh Dr. E. F. Codd pada tahun 1970. Model relasional data (relational data model) mewakili semua yang disimpan di database, dalam bentuk tabel. Secara teknis, tabel-tabel ini dinamakan hubungan (oleh karenanya dinamakan sebagai model data relasional), tetapi kami akan menggunakan keduanya sebagai konsep yang sama. Selanjutnya, ingatlah bahwa model relasional data hanya hanya mendeskripsikan bagaimana data yang muncul dalam skema tingkat konseptual dan eksternal. Datanya sendiri benar-benar disimpan dalam tabel, tetapi disimpan dalam cara yang dideskripsikan dalam skema tingkat internal. Setiap baris dalam sebuah hubungan, yaitu yang disebut dengan tuple (yang seirama bunyinya dengan couple/pasangan), berisi data mengenai keberadaan spesifik jenis entitas yang diwakili oleh tabel. Jenis-jenis Atribut Tabel-tabel dalam database relasional memiliki tiga jenis atribut. Kunci utama (primary key) adalah atribut, atau kombinasi dari beberapa atribut, yang secara unik mengidentifikasi baris tertentu dalam sebuah tabel. Kunci luar (foreign key) adalah atribut yang muncul dalam suatu tabel, yang juga merupakan kunci utama dalam tabel lainnya. Kunci-kunci luar digunakan untuk menghubungkan tabel-tabel. Atribut lainnya yang bukan berupa atribut kunci (non-key attribute) di dalam setiap tabel, menyimpan informasi penting mengenai entitasnya. Persyaratan Dasar untuk Model Data Relasional Model data relasional menekankan beberapa persyaratan untuk struktur tabel-tabelnya: 1. Setiap kolom dalam sebuah baris harus berlainan nilainya. 2. Kunci utama (primary key) tidak boleh bernilai nol. 3. Kunci luar (foreign key), jika tidak bernilai nol, harus memiliki nilai yang sesuai dengan nilai kunci utama di hubungan yang lain.

4. Seluruh atribut yang bukan merupakan kunci dalam sebuah tabel harus mendeskripsikan objek yang diidentifikasi oleh kunci utama. Keempat syarat ini akan menghasilkan database yang terstruktur dengan baik yang memungkinkan konsistensi data, dan meminimalkan serta mengendalikan pengulangan data.

Masalah yang berhubungan dengan penyimpanan seluruh data dalam suatu tabel Salah satu masalah dengan penyimpanan seluruh data didalam suatu tabel adalah timbulnya banyak pengulangan. Sebagai contoh, amatilah nomor faktur penjualan 10002 dalam gambar 4-7. Oleh karena terdapat dua jenis barang persediaan yang dijual, maka banyak bagian data--seperti tanggal penjualan, nama pelanggan dan data lainnya, serta data penjual--dicatat berkali-kali. Oleh karenanya, apabila terdapat banyak penjualan atas monitor 19 inci, informasi mengenai barang ini, seperti informasi mengenai deskripsinya dan daftar harganya, diulang-ulang setiap kali seseorang membeli monitor dengan ukuran tersebut. Oleh karena volume penjualan bisa menjadi tinggi dalam toko retail (Gambar 47 hanya berisi lima faktur penjualan), pengulangan semacam ini dapat membuat pemeliharaan file memakan waktu lama dan cenderung dapat timbul kesalahan, yang sebenarnya tidak perlu terjadi. Terdapat tiga jenis masalah yang dapat muncul. Pertama disebut sebagai anomali pembaruan, karena perubahan yang dilakukan atas nilai data tidak dicatat dengan benar. Sebagai contoh, mengubah alamat seorang pelanggan membutuhkan pencarian atas seluruh tabel, setiap kali alamat pelanggan tersebut muncul maka harus diubah. Apabila terlewat satu baris saja, akan menimbulkan inkonsistensi database, karena akan terdapat beberapa baris dengan alamat yang berbeda-beda, untuk pelanggan yang sama. Kondisi ini juga dapat menimbulkan kesalahan dalam proses analisis, seperti perhitungan atas berbagai pelanggan yang membeli sesuatu dalam periode waktu tertentu. Dua jenis masalah lainnya sehubungan dengan pendekatan yang diperlihatkan dalam Gambar 4-7, yaitu disebabkan oleh kondisi data pelanggan, penjualan, dan

persediaan tidak dipeliharasecara independen dari data faktur penjualan. Salah satu masalah yang berhubungan dengan kondisi ini disebut sebagai anomali penyisipan (insert anomaly) karena tidak ada cara untuk menyimpan informasi mengenai pelanggan prospektif sampai mereka benar-benar melakukan pembelian. Kolom faktur penjualan akan tetap kosong, sampai seorang pelanggan melakukan pembelian. Nomor faktur penjualan adalah bagian dari kunci utama dalam Gambar 4-7, jadi sebenarnya tidak boleh kosong. Masalah kedua berhubungan dengan cara tabel dalam Gambar 4-7 didesain, atau disebut pula sebagai anomali penghapusan, karena kondisi ini menimbulkan hasil yang tidak diharapkian saat menghapus sebuah baris di tabel tersebut. Apabila seorang pelanggan hanya membuat satu pembelian yang terdiri dari satu jenis barang saja, usaha menghapus baris tersebut dari tabel dalam Gambar 4-7 akan mengakibatkan hilangnya seluruh informasi mengenai pelanggan tersebut. Solusi masalah: penggunaan serangkaian tabel Masalah-masalah yang berhubungan dengan usaha untuk menyimpan seluruh data dalam satu tabel, seperti yang diperlihatkan dalam Gambar 4-7, dapat dihindari dengan membuat serangkaian tabel seperti yang diperlihatkan dalam Gambar 4-6. Gambar 4-6 memiliki satu tabel untuk setiap entitas terpisah yang dibutuhkan. Pertama-tama perhatikan bahwa pengulangan data berkurang banyak dalam desain ini. Sebagai contoh, seluruh atribut yang bukan merupakan kunci, seperti alamat pelanggan dan harga per unit barang persediaan, hanya disimpan sekali. Hal ini menghindari timbulnya masalah anomali pembaruan. Akan tetapi, lihatlah bahwa pengurangan tidak seluruhnya ditiadakan. Beberapa bagian, seperti nomor faktur penjualan dan nomor barang, muncul beberapakali dalam satu tabel. Akan tetapi, atribut-atribut ini muncul lebih dari sekali apabila mereka berfungsi sebagai kunci luar. Jadi, peraturan integritas referensi memastikan bahwa tidak akan ada masalah anomali pembaruan dengan kunci-kunci luar tersebut. Fitur penting dari skema yang diperlihatkan dalam Gambar 4-6 adalah data mengenai berbagai kebutuhan disimpan di dalam tabel-tabel terpisah. Hal ini mempermudah penambahan data baru ke dalam sistem tersebut. Sebagai contoh,

informasi mengenai pelanggan prospektif dapat disimpan dengan hanya menambahkan baris baru dalam tabel pelanggan. Jadi, serangkaian tabel dalam Gambar 4-6 terhindar dari masalah anomali pencatatan. Skema yang diperlihatkan dalam Gambar 4-6 jugamenyederhanakan penghapusan informasi.

Dua Pendekatan dalam Desain Database Terdapat dua cara dasar untuk mendesai database relasional yang terstruktur dengan baik, seperti yang ditunjukkan dalam Gambar 4-6. Salah satunya dinamakan normalisasi, yang dimulai dengan asumsi bahwa semua data pada awalnya disimpan dalam satu tabel besar. Pendekatan ini kemudian diikuti dengan serangkaian peraturan untuk memisah-misahkan tabel awal tadi menjadi serangkaian tabel yang dinormalisasi. Tujuannya adalah menghasilkan serangkaian tabel yang dapat dikategorikan sebagai bentuk normal ketiga (third normal form-3NF), karena tabel-tabel seperti ini bebas dari masalah anomali pembaruan, penyisipan, serta penghapusan. Cara alternatif untuk mendesain database relasional yang terstruktur dengan baik adalah dengan menggunakan pembuatan model data semantik. Dalam pendekatan ini, desainer database menggunakan pengetahuan mereka mengenai bagaimana proses bisnis biasanya berlangsung dan mengenai kebutuhan informasi yang berhubungan dengan proses transaksi, untuk membuat gambar grafis mengenai hal-hal yang seharusnya dimasukkan dalam database yang didesainnya. Pembuatan model data semantik memiliki dua kelebihan utama daripada membangun database hany6a dengan mengikuti peraturan-peraturan proses normalisasi. Pertama, cara ini memfasilitasi desain yang efisien atas database proses transaksi, karena cara ini mempergunakan pengetahuan desainer sistem mengenai proses dan kegiatan bisnis. Kedua, cara ini memfasilitasi komunikasi dengan para calon pemakai sistem tersebut, karena model grafis yang dihasilkan secara emplisit mewakuli informasi mengenai proses bisnis dan kebijakan organisasi. Komunikasi semacam ini

sangat penting untuk memastikan bahwa sistem yang dihasilkan sesuai dengan kebutuhan para pemakai yang sebenrnya.