Database Temporal
Content
« Pengenalan Database Temporal: Database temporal merupakan database non-relational yang terintegrasi dengan aspek waktu, misalnya model data temporal dan versi temporal dari bahasa query terstruktur. Lebih spesifik lagi aspek temporalnya biasa sudah termasuk waktu yang valid dan waktu transaksi. Atribut-atribut ini muncul bersamaan pada form data bitemporal.
Waktu yang valid ditunjukkan dengan periode waktu kejadian yang sama dengan waktu pada dunia sebenarnya Waktu transaksi adalah periode waktu saat menyimpan suatu kejadian ke database
Data bitemporal mengkombinasikan waktu valid dan waktu transaksi Keterangan: kedua periode waktu tidak harus sama untuk suatu kejadian yang sama. Misalkan kita menyimpan databse pada database temporal pada abad ke 18. Waktu yang valid adalah diantara 1701 dan 1800. Sedangkan waktu transaksi dihitung pada saat kita memasukan suatu kejadian ke dalam databse, contoh 21 Januari 1998. « Mengapa Kita Butuh Database Temporal: Sejak dua decade terakhir, model data relational sudah menjadi sangat popular karena simpel dan memiliki fondasi matematis yang solid. Namun, model data relational seperti yang dikatakan Codd[Cod70] tidak menyimpan address dari dimensi temporal suatu data. Data yang seharusnya dibedakan dari waktunya tetap diperlakukan sama dengan data lainnya. Hal ini tidak memenuhi aplikasi yang harus membedakan nilai data pada waktu lampau, saat ini, dan/atau data pada masa depan—padahal dikehidupan nyata kita akan sering berurusan dengan data seperti ini. Kenyataannya, kebanyakan aplikasi membutuhkan data temporal untuk keperluan tertentu. « Tujuan Utama dari Database Temporal:
Mengidentifikasi tipe data yang cocok dengan waktu Mencegah hilang/berubahnya deskripsi suatu objek tertentu Menyediakan aljabar query untuk mengatasi data temporal Tetap compatible dengan database lama yang tidak menggunakan data temporal « Apa yang Dapat Kita Lakukan dengan Database Temporal: Mudah dalam mengerjakan data temporal Merecord setiap perubahan data dengan baik sekali Setiap pendeskripsian objek dapat didefinisikan tanpa ada perubahan yang tidak diinginkan Memiliki model relational untuk mendeskripsikan data temporal Memiliki aljabar query untuk mengatasi data temporal
Tetap mampu mengatasi data static (tanpa dimensi waktu) pada database temporal Aljabar database yang lama tetap dapat berjalan di database temporal Aljabar query yang baru untuk mengkontrol dimensi waktu mirip dengan aljabar database yang lama
« Solusi lain tentang Database Temporal:
Menambahkan waktu valid Menambahkan waktu transaksi Menambahkan kedua hal di atas
Pendekatan lainnya Post 2 (23 Juni 2009) Untuk memperjelas pengertian mengenai database temporal, maka saya akan memasukan sebuah contoh yang membandingkan penanganan suatu kasus bila dibuat database secara biasa dan dengan database menggunakan database temporal. Contoh kasus yang diambil berasal dari biografi singkat tokoh buatan bernama Joel Wahyudi. Joel Wahyudi lahir pada tanggal 3 April 1975 di rumah sakit Medicine County, sebagai anak dari Hendro Wahyudi dan Irma Wahyudi yang bertempat tinggal di Smallville. Hendro Wahyudi dengan bangga mendaftarkan kelahiran anak pertamanya tanggal 4 April 1975 di kota Smallville. Joel tumbuh besar menjadi seorang pelajar cemerlang dan lulus dengan sangat baik pada tahun 1993. Setelah kelulusan, ia pergi untuk hidup sendiri di kota Bigtown. Meski Joel pindah pada tanggal 26 Agustus 1994, ia lupa untuk mendaftarkan perubahan alamatnya secara resmi. Hingga akhirnya pada akhir musim, ibunya mengingatkan Joel untuk mendaftarkan kepindahannya, yang kemudian ia lakukan beberapa hari setelahnya yaitu pada 27 Desember 1994. Meskipun Joel memiliki masa depan yang sangat menjanjikan, namun kisahnya berakhir dengan tragis. Joel Wahyudi mengalami kecelakaan tertabrak truk pada 1 April 2001. Yang pada hari itu juga langsung dilaporkan berita kematiannya secara resmi. «Menggunakan Database Standar: Untuk menyimpan kehidupan Joel Wahyudi di sebuah (non-temporal) tabel database, kita menggunakan table Person(Name,Address). Untuk memudahkan, Name kita buat menjadi primary key dari tabel Person. Ayah Joel secara resmi melaporkan kelahiran anaknya pada 4 April 1975. Hal ini berarti pada sebuah kantor di Smallville, dimasukan data berikut ke database pada tanggal saat itu: Person(Joel Wahyudi,Smallville). Perhatikan bahwa tanggalnya sendiri tidak dimasukan ke database. Setelah lulus kemudian Joel pindah, namun ia lupa mendaftarkan alamat barunya. Data milik Joel pada database tidak berubah sampai 27 Desember 1994, yaitu ketika akhirnya ia mendaftar ke kantor di Bigtown. Kantor di Bigtown mengupdate alamatnya di database. Tabel Person saat ini berisi Person(Joel Wahyudi,Bigtown). Perhatikan bahwa informasi alamat Joel di Smallville
telah ditimpa. Maka tidak ada cara untuk mengakes informasi yang hilang tersebut melalui database. Setiap kantor yang mengakses databse pada 28 Desember 1994 akan mendapatkan Joel tinggal di Bigtown. Secara teknis: jika sebuah komputer melakukan query SELECT ADDRESS FORM PERSON WHERE NAME=’Joel Wahyudi’ pada 26 Desember 1994, menghasilkan: Smallville. Menjalankan query yang sama pada 2 hari selanjutnya menghasilkan Bigtown. Sampai dengan kematian trgaisnya, database akan menyatakan Joel tinggal di Bigtown. Pada 1 April 2001 akhirnya petugas menghapus Joel Wahyudi dari databse. Maka pemanggilan query di atas tidak akan menghasilkan hasil apapun. Tanggal Yang terjadi di dunia nyata Perubahan di Database Tampilan di Database 3 April Tidak ada Person dengan nama Kelahiran Joel Tidak ada 1975 Joel Wahyudi 4 April Hendro melaporakan kelahiran Inserted:Person(Joel Joel Wahyudi tinggal di 1975 anaknya ke kantor secara resmi Wahyudi, Smallville) Smallville Setelah kelulusan, Joel pindah ke 26 Agustus Joel Wahyudi tinggal di Bigtown, namun lupa untuk Tidak ada 1994 Smallville meregristasikan alamat barunya 26 Joel Wahyudi tinggal di Desember Tidak ada Tidak ada Smallville 1994 27 Joel mendaftarkan alamat Updated:Person(Joel Joel Wahyudi tinggal di Desember barunya Wahyudi, Bigtown) Bigtown 1994 1 April Deleted:Person(Joel Tidak ada Person dengan nama Joel meninggal 2001 Wahyudi) Joel Wahyudi Post 3 (1 July 2009) «Menggunakan Database Temporal dengan Waktu yang Valid: Waktu yang valid (valid time) yang berarti waktu sebernarnya di dunia nyata. Pad contoh di atas, tabel Person mendapat dua fields tambahan, yaitu Valid-From dan Valid-To, yang menjelaskan kapan Address seseorang berlaku di dunia nyata. Pada 4 April 1975, Hendro dengan bangga mendaftarkan kelahiran anak pertamanya. Maka petugas akan memasukkan data tersebut ke database yang menjelaskan Joel bertempat tinggal di Smallville sejak 3 April. Perlu diketahui meski data dimasukkan pada 4 April, namun database menjelaskan bahwa informasi tersebut berlaku sejak tanggal 3. Petugas belum mengetahui apakah atau kapan Joel akan berpindah ke tempat lain, sehingga pada field Valid-To di database diisi dengan infinity (∞). Pemasukkan data ke basisdata berupa: Person(Joel Wahyudi, Smallville, 3-Apr-1975, ∞). Pada tanggal 27 Desember 1994, Joel melaporkan alamat barunya di Bigtown yang sudah ia tinggali sejak 26 Agustus 1994. Petugas di kantor Bigtown tidak merubah alamat milik Joel di database. Sang petugas menambahkan yang baru: Person (Joel Wahyudi, Big Town, 26-Aug-1994, ∞). Masukan data milik Joel sebelumnya (Joel Wahyudi, Smallville, 3-Apr-1975, ∞) kemudian diupdate (tidak dihapus!). karena diketahui Joel sudah tidak tinggal di
Smallville pada 26 Agustus 1994, maka kolom Valid-To dapat terisi. Database kemudian memiliki dua buah entry milik Joel Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994). Person(Joel Wahyudi, Bigtown, 26-Aug-1994, ∞). Saat Joel meninggal, database diupdate sekali lagi. Entry terbaru akan diupdate menyatakan bahwa Joel tidak tinggal di Bigtown lagi. Tidak ada entry yang ditambahkan karena tidak pernah dilaporkan surge sebagai alamat baru. Maka database sekarang akan seperti ini Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994). Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Apr-2001). «Menggunakan Database Temporal dengan Waktu Transaksi: Waktu transaksi adalah penggunaan database temporal menggunakan waktu pada saat transaksi dilakukan. Dengan ini kita dapat menggunakan queri-queri yang menampilkan status database pada waktu tertentu. Maka ada dua tambahan kolom di tabel Person: Transaction-From dan Transaction-To. Transaction-From merupakan waktu saat transaksi dilakukan, sedangkan Transaction-To adalah waktu transaksi dibatalkan (atau menggunakan tak terhingga jikan belum akan dibatalkan). Apakah yang akan terjadi jika alamat seseorang yang ada di database merupakan alamat yang salah? Anggap seorang petugas secara tidak sengaja memasukkan alamat atau tanggal yang salah? Atau, anggap orang yang memasukkan data berbohong ketika memberi informasi untuk keperluan tertentu. Setelah mengetahui data yang benar, maka petugas harus kembali mengupdate database tersebut. Sebagai contoh, dari 1 Juni 1995 hingga 3 September 2000 Joel Wahyudi pindah ke Beachy. Namun untuk menghindari membayar pajak kota Beachy yang sangat mahal, Joel tidak pernah melapor ke yang berwewenang. Akhirnya, hal tersebut terungkap pada 2 Februari 2001 saat ada pengecekan pembayaran pajak, bahwa dia sebenarnya tinggal di Beachy selama ini, maka para petugas mengupdate database menjadi seperti ini: Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Jun-1995). Person(Joel Wahyudi, Beachy, 1-Jun-1995, 3-Sep-2000). Person(Joel Wahyudi, Bigtown, 3-Sep-2000, 1-Apr-2001). Maka 2 data yang sudah ada di update, dan sebuah data baru dimasukkan menyimpan keberadaannya di Beachy. Bagaimanapun, hal ini tidak meninggalkan catatan di database yang menyatakan Joel tinggal di Bigtown dari 1 Juni 1995 hingga 3 September 2000, yang mungkin sangat penting untuk alasan mengaudit data (atau untuk menjadi bukti pada investigasi kantor pajak). Di sini kita dapat melihat waktu transaksinya. Kita harus menyimpan setiap data ketika dimasukkan dan ketika dibatalkan. Maka dari itu, kita memperoleh data seperti berikut: Person(Joel Wahyudi, Smallville, 3-Apr-1975, ∞, 4-Apr-1975, 27-Dec-1994). Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994, 27-Dec-1994, ∞ ). Person(Joel Wahyudi, Bigtown, 26-Aug-1994, ∞, 27-Dec-1994, 2-Feb-2001 ). Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Jun-1995, 2-Feb-2001, ∞ ). Person(Joel Wahyudi, Beachy, 1-Jun-1995, 3-Sep-2000, 2-Feb-2001, ∞ ). Person(Joel Wahyudi, Bigtown, 3-Sep-2000, ∞, 2-Feb-2001, 1-Apr-2001 ).
Person(Joel Wahyudi, Bigtown, 3-Sep-2000, 1-Apr-2001, 1-Apr-2001, ∞ ). Jadi, kita tidak hanya menyimpan apa yang terjadi di waktu yang berbeda, tetapi kita juga menyimpan data yang berubah secara resmi pada waktu yang berbeda. Permasalah utama pada database dengan waktu transaksi adalah saat mengembangkan queri-queri temporal dibawah penggunaan skemanya. Untuk mencapai pengarsipan data yang sempurna, sangat penting untuk menyimpan data dibawah skema awal ketika database dibuat. Namun, sesimpel apapun queri temporal, riwayat sebuah atributnya tetap butuh ditulis manual di setiap versi skemanya, dan mungkin ratusan kasus seperti pada kasus MediaWiki (http://yellowstone.cs.ucla.edu/schemaevolution/index.php/Schema_Evolution_Benchmark). Proses ini membutuhkan usaha yang sangat besar dari pengguna untuk merapihkan database tersebut. Penyelesaian umumnya dilakukan dengan menyediakan penulis queri secara otomatis. Post 4 (24 July 2009) Sebelum melanjutkan ke topik selanjutnya, perlu diingat satu konsep penting tentang ke presisian waktu yang di simpan di database temporal. Konsep ke presisian dari sebuah database temporal disebut granularity of the time (serpihan waktu). Granularity merupakan unit terkecil durasi waktu yang disimpan pada database temporal kita. Contoh serpihan waktunya yaitu satu hari, satu jam, atau satu detik. «Konsep Utama dalam Memahami Database Temporal Telah kita ketahui dua tipe waktu utama dalam konsep database temporal, yaitu waktu transaksi (transaction time) dan waktu yang valid (valid time), memungkinkan 3 bentuk database temporal : Historical, Rollback, dan Bitemporal. Sebuah database temporal historical dapatmensuport valid time, tapi tidak dapat menggunakan transaction time. Tipe kedua yaitu rollback database, database ini kebalikannya dari database historical, yaitu menggunakan transaction time dan tidak dapat menggunakan valid time. Rollback database sangat berguna dalam data recovery setelah jika terdapat kerusakan pada temporal database. Sebuah database rollback juga diperlukan jika database tidak di proteksi untuk menjaga keamanan data. Sehingga saat ini pada pasar tingkat dunia, minimal biasanya menyediakan beberapa fitur rollback. Temporal database yang sebenarnya adalah database bitemporal. Database ini mensuport keduanya, yaitu transaction time dan valid time, sehingga menghasilkan kombinasi bentuk database historical dan rollback. Database bitemporal mampu mengatasi permasalahan dimensi waktu; dalam tingkat DBMS yaitu transaction time, dalam tingkat data yaitu valid time, dan dalam tingkat user menggunakan user-defined time. «Tujuan Utama bagi Database Temporal… Kemampuan Query Salah satu faktor terpenting dalam menggunakan database yang mensuport dimensi temporal, yaitu kemampuan untuk menjalankan data dengan query. Saat ini yang umum digunakan untuk database conventional (relational) adalah Structured Query Language atau yang biasa kenal dengan SQL. SQL sudah menjadi bahasa standar di industri untuk Relational Database Management Systems (RDBMS) karena kemudahan dalam menggunakannya yang sintaksnya mirip dengan bahasa Inggris
langsung. SQL termasuk user friendly dan dapat digunakan untuk berbagai keperluan. Bagaimanapun penambahan element temporal ini meningkatkan kompleksitas query pada data temporal. Dengan penambahan elemen time, dalam kemampuannya saat ini SQL tidak dapat memproses query query tersebut seperti biasanya pada kondisi database klasik (relational). Bahasa query yang baru atau perluasan dari SQL sangat diperlukan di sini. Perlu diketahui, salah satu permasalahan terbesar yang diteliti saat-saat ini adalah di bagian temporal database. Hari-hari ini, tidak sedikit bahasa-bahasa dan perluasan bahasa-bahasa query yang mengajukan dan membahas topik ini. Topik ini cukup memerlukan perhatian khusus, dan salah satu contohnya akan diberikan berikut ini. Bahasa query temporal yang baru harus dapat mensuport kemampuan SQL tanpa mengurangi kemampuan sebelumnya. SQL sudah memberi bantuan yang sangat besar dan mendominasi RDBMS saat ini karena, seperti yang kita ketahui sebelumnya, SQL cocok untuk banyak keperluan bisnis dan merupakan bahasa yang user friendly. Salah satu bahasa query yang paling diharapkan adalah bahasa query yang mensuport dimensi waktu dan tetap memungkinkan user memasukan query tanpa menetapkan dimensi waktunya (hal tersebut menhindari biaya lebih). Dan bahasa tersebut bukanlah sebuah bahasa yang baru, melainkan perluasan dari bahasa SQL. Satu contoh yang paling menarik adalah TSQL. TSQL yang merupakan Temporal Structured Query Language dapat berjalan tanpa harus memasukkan kriteria waktu. Karena demikian, ketentuan-ketentuan utama dari query TSQL masih sama dengan ketentuan-ketentuan di SQL: yaitu ‘SELECT’ dan ‘FORM’. Jika perlu juga terdapat ‘WHERE’, ‘GROUP BY’, ‘HAVING’, dan ‘ORDER BY’. Kriteria tambahan pada TSQL dapat berupa ‘WHEN’ atau ‘WHILE’. Kedua nama query tersebut bermaksud menjelaskan perbedaan kondisi waktu. Klausa ‘WHEN’ menjelaskan perincian “sepotong waktu” untuk data yang valid atau tidak valid tergantung hasil yang diinginkan. Saat ini, pengajuan untuk menambahkan TSQL ke ANSI dan ISO milik SQL standar sedang dipertimbangkan oleh pihak-pihak yang mengaudit. Post 5 (8 Agustus 2009) Setelah membahas teori-teori mengenai database temporal, pada bagian terakhir ini saya akan menggabungkan bagian teori dengan bagian praktiknya langsung mengenai database temporal. Di sini,akan dijelaskan mengenai beberapa tipe bisnis yang dapat mendapat keuntungan lebih dengan bantuan database temporal. «Data Warehouse Data warehouse atau pergudangan data bukan merupakan bisnis per se (bukan bisnis itu sendiri, tapi mengambil dari bisnis lain). Data warehouse ini merupakan usaha yang sangat luas, yaitu bisnis yang diperuntukan menyimpan seluruh informasi dari beberapa perusahaan. Data warehouse terbukti sangat berguna sebagai tempat penyimpanan informasi yang dikumpulkan dengan tools data mining dan digunakan untuk sumber informasi. Seperti yang sudah kita ketahui, elemen waktu sangat penting untuk berbagai bisnis, dan dalam sebuah data warehouse dimensi waktu dapat disimpan dan digunakan dalam peng query an data. Sebenarnya apa yang data warehouse lakukan dengan adanya database temporal? Menurut Ralph Kimball, setiap data warehouse memiliki dimensi waktu yang membuat setiap data warehouse menjadi database warehouse [Kimball
1997+,*Snodgrass 1998+.”Dimensi waktu adalah unik dan merupakan dimensi yang kuat dalam setiap kumpulan data dan usaha data warehouse”*Kimball 1997+. «Laboratorium Ilmiah Jenis bisnis yang kedua adalah lab ilmiah (scientific laboratory). Setiap lab tentu melakukan banyak uji coba dan banyak versi untuk percobaan yang sama, dan setiap percobaan sering kali melibatkan urutan waktu yang sangat teliti. Agar informasinya tidak ada yang hilang, tentunya harus disimpan dalam sebuah database. Karena elemen waktu di test ini jelas tidak bisa dihilangkan, sehingga informasi yang disimpan di sini harus disimpan dalam database temporal. Satu keuntungan dalam menyimpan informasi ujicoba ilmiah pada temporal database yang mendukung bahasa query temporal adalah, sebuah pola baru dan pengetahuan baru dapat digali dari basis data [Loomis 1997]. «Sales dan Marketing Kedua bisnis ini sangat berkantung pada temporal database, karena keberhasilan sales dan marketing sangat bergantung pada waktu yang tepat. Waktu untuk pendekatan dengan pelanggan dan kapan untuk mengiklankan di lokasi tertentu sangat diperlukan, dan kemampuan untuk meramalkan informasi ini jauh lebih baik disediakan database temporal daripada database klasik biasa. «Multimedia Jenis bisnis yang terakhir adalah multimedia. Multimedia merupakan salah satu area bisnis yang paling cepat berkembang saat ini, terutama melalui jalus internet. Seseorang saat ini dengan mudah menonton film dari internet, dimana gambar video tersebut sudah tersimpan di database multimedia yang harus disinkronisasikan dengan data audio yang mungkin berada di database yang sama atau berbeda. Pengsinkronisasian ini, seperti kata tersebut sendiri, jelas melibatkan elemen waktu. “Karen multimedia berbasis waktu, sinkronisasi sangat di butuhkan. Jika diimplementasikan dengan baik, maka komponen-komponen media tersebut akan ditampilkan dengan ketepatan dari sinkronisasi yang baik*David+”. “Objekobjek multimedia memiliki relasi dan ruang temporary yang harus dijaga saat ditampilkan beberapa data memiliki batasan waktu nyata (real time) saat menyampaian ke stasiun clien*Ozsu+”. Karena itu, database untuk multimedia, seperti data warehouse, merupakan instance dari database temporal juga. Sebagai penutup, akan dibahas sedikit mengenai database temporal di masa mendatang. Dengan meningkatnya persaingan di lingkungan bisnis, pengetahuan akan informasi antar organisasi menjadi sumber yang berharga. Salah satu elemen kunci dari informasi ini adalah dimensi waktu. Untuk mendapatkan informasis ini, dalam bisnis harus digunakan database temporal. Dalam menerapkan kemampuan menyimpan variable waktu pada bisnis yang ada, akan terdapat dua hal yang berpengaruh. Pertama, kebanyakan produsen basis data komersial akan berlombalomba memasukkan kemampuan temporal data di produk basis data mereka. Kedua, extension temporal database akan dimasukkan ke ANSI dan ISO SQL standar yang sudah ada. Hal ini akan memungkinkan pengguna untuk mengambil keuntungan dari fitur temporal baru pada produk database yang biasa mereka gunakan. Pada titik ini, sebagian besar dari produsen database komersil akan menggunakan database temporal. Hal ini memungkinkan pengetahuan akan informasi yang lebih lengkap dan lebih baik dapat disimpan dan diambil dari
database temporal, yang membuat bisnis-bisnis beralih menggunakan temporal database untuk bersaing dengan bisnis lainnya.
Pengertian Basis Data Relasional Basis Data relasional menggunakan tabel dua dimensi yang terdiri atas baris dan kolom untuk memberi gambaran sebuah berkas data. Contoh Tabel dan keterhubungannya : MHS NPM 10296832 10296126 31296500 41296525 50096487 21196353 MKUL KDMK KK021 KD132 KU122 NILAI NPM 10296832 10296126 31296500 41296525 21196353 50095487 10296832
Nama Nurhayati Astuti Budi Prananingrum Pipit Quraish MTKULIAH P. Basis Data SIM Pancasila KDMK KK021 KD132 KK021 KU122 KU122 KD132 KD132 MID 60 70 55 90 75 80 40
Alamat Jakarta Jakarta Depok Bogor Bekasi Bogor SKS 2 3 2 FINAL 75 90 40 80 75 0 30
Keuntungan Basis Data Relasional 1. Bentuknya sederhana 2. Mudah melakukan berbagai operasi data · Istilah dalam Basis Data Relasional : Relasi : Sebuah tabel yang terdiri dari beberapa kolom dan beberapa baris. Atribut : Kolom pada sebuah relasi Tupel : Baris pada sebuah relasi Domain : Kumpulan nilai yang valid untuk satu atau lebih atribut Derajat (degree): Jumlah atribut dalam sebuah relasi Cardinality : Jumlah tupel dalam sebuah relasi
Relational Key Super key : Satu atribut/kumpulan atribut yang secara unik mengidentifikasi sebuah tupel di dalam relasi
Candidate key : Atribut di dalam relasi yang biasanya mempunyai nilai unik Primary key : Candidate key yang dipilih untuk mengidentifikasikan tupel secara unik dalam relasi
Alternate key : Candidate key yang tidak dipilih sebagai primary key Foreign key : Atribut dengan domain yang sama yang menjadi kunci utama pada sebuah relasi tetapi pada relasi lain atribut tersebut hanya sebagai atribut biasa
Relational Integrity Rules 1. Null Nilai suatu atribut yang tidak diketahui dan tidak cocok untuk baris (tuple) tersebut
2. Entity Integrity Tidak ada satu komponen primary key yang bernilai null. 3. Referential Integrity Suatu domain dapat dipakai sebagai kunci primer bila merupakan atribut tunggal pada domain yang bersangkutan. Bahasa Pada Basis data Relational Menggunakan bahasa query à pernyataan yang diajukan untuk mengambil informasi Terbagi 2 : 1. Bahasa Formal Bahasa query yang diterjemahkan dengan menggunakan simbol-simbol matematis. Contoh: Aljabar relasional Kalkulus relasional · Aljabar Relasional Bahasa query prosedural à pemakai menspesifikasikan data apa yang dibutuhkan dan bagaimana untuk mendapatkannya.
· Kalkulus Relasional Bahasa query non-prosedural à pemakai menspesifikasikan data apa yang dibutuhkan tanpa menspesifikasikan bagaimana untuk mendapatkannya. Terbagi 2 : (1) Kalkulus Relasional Tupel (2) Kalkulus Relasional Domain 2. Bahasa Komersial Bahasa Query yang dirancang sendiri oleh programmer menjadi suatu program aplikasi agar pemakai lebih mudah menggunakannya (user friendly). Contoh : • QUEL Berbasis pada bahasa kalkulus relasional · QBE Berbasis pada bahasa kalkulus relasional · SQL Berbasis pada bahasa kalkulus relasional dan aljabar relasional · Contoh-contoh Basis Data Relasional :
- DB2 à IBM - ORACLE à Oracle - SYBASE à Powersoft - INFORMIX à Informix - Microsoft Access à Microsoft
Waktu yang valid ditunjukkan dengan periode waktu kejadian yang sama dengan waktu pada dunia sebenarnya Waktu transaksi adalah periode waktu saat menyimpan suatu kejadian ke database
Data bitemporal mengkombinasikan waktu valid dan waktu transaksi Keterangan: kedua periode waktu tidak harus sama untuk suatu kejadian yang sama. Misalkan kita menyimpan databse pada database temporal pada abad ke 18. Waktu yang valid adalah diantara 1701 dan 1800. Sedangkan waktu transaksi dihitung pada saat kita memasukan suatu kejadian ke dalam databse, contoh 21 Januari 1998. « Mengapa Kita Butuh Database Temporal: Sejak dua decade terakhir, model data relational sudah menjadi sangat popular karena simpel dan memiliki fondasi matematis yang solid. Namun, model data relational seperti yang dikatakan Codd[Cod70] tidak menyimpan address dari dimensi temporal suatu data. Data yang seharusnya dibedakan dari waktunya tetap diperlakukan sama dengan data lainnya. Hal ini tidak memenuhi aplikasi yang harus membedakan nilai data pada waktu lampau, saat ini, dan/atau data pada masa depan—padahal dikehidupan nyata kita akan sering berurusan dengan data seperti ini. Kenyataannya, kebanyakan aplikasi membutuhkan data temporal untuk keperluan tertentu. « Tujuan Utama dari Database Temporal:
Mengidentifikasi tipe data yang cocok dengan waktu Mencegah hilang/berubahnya deskripsi suatu objek tertentu Menyediakan aljabar query untuk mengatasi data temporal Tetap compatible dengan database lama yang tidak menggunakan data temporal « Apa yang Dapat Kita Lakukan dengan Database Temporal: Mudah dalam mengerjakan data temporal Merecord setiap perubahan data dengan baik sekali Setiap pendeskripsian objek dapat didefinisikan tanpa ada perubahan yang tidak diinginkan Memiliki model relational untuk mendeskripsikan data temporal Memiliki aljabar query untuk mengatasi data temporal
Tetap mampu mengatasi data static (tanpa dimensi waktu) pada database temporal Aljabar database yang lama tetap dapat berjalan di database temporal Aljabar query yang baru untuk mengkontrol dimensi waktu mirip dengan aljabar database yang lama
« Solusi lain tentang Database Temporal:
Menambahkan waktu valid Menambahkan waktu transaksi Menambahkan kedua hal di atas
Pendekatan lainnya Post 2 (23 Juni 2009) Untuk memperjelas pengertian mengenai database temporal, maka saya akan memasukan sebuah contoh yang membandingkan penanganan suatu kasus bila dibuat database secara biasa dan dengan database menggunakan database temporal. Contoh kasus yang diambil berasal dari biografi singkat tokoh buatan bernama Joel Wahyudi. Joel Wahyudi lahir pada tanggal 3 April 1975 di rumah sakit Medicine County, sebagai anak dari Hendro Wahyudi dan Irma Wahyudi yang bertempat tinggal di Smallville. Hendro Wahyudi dengan bangga mendaftarkan kelahiran anak pertamanya tanggal 4 April 1975 di kota Smallville. Joel tumbuh besar menjadi seorang pelajar cemerlang dan lulus dengan sangat baik pada tahun 1993. Setelah kelulusan, ia pergi untuk hidup sendiri di kota Bigtown. Meski Joel pindah pada tanggal 26 Agustus 1994, ia lupa untuk mendaftarkan perubahan alamatnya secara resmi. Hingga akhirnya pada akhir musim, ibunya mengingatkan Joel untuk mendaftarkan kepindahannya, yang kemudian ia lakukan beberapa hari setelahnya yaitu pada 27 Desember 1994. Meskipun Joel memiliki masa depan yang sangat menjanjikan, namun kisahnya berakhir dengan tragis. Joel Wahyudi mengalami kecelakaan tertabrak truk pada 1 April 2001. Yang pada hari itu juga langsung dilaporkan berita kematiannya secara resmi. «Menggunakan Database Standar: Untuk menyimpan kehidupan Joel Wahyudi di sebuah (non-temporal) tabel database, kita menggunakan table Person(Name,Address). Untuk memudahkan, Name kita buat menjadi primary key dari tabel Person. Ayah Joel secara resmi melaporkan kelahiran anaknya pada 4 April 1975. Hal ini berarti pada sebuah kantor di Smallville, dimasukan data berikut ke database pada tanggal saat itu: Person(Joel Wahyudi,Smallville). Perhatikan bahwa tanggalnya sendiri tidak dimasukan ke database. Setelah lulus kemudian Joel pindah, namun ia lupa mendaftarkan alamat barunya. Data milik Joel pada database tidak berubah sampai 27 Desember 1994, yaitu ketika akhirnya ia mendaftar ke kantor di Bigtown. Kantor di Bigtown mengupdate alamatnya di database. Tabel Person saat ini berisi Person(Joel Wahyudi,Bigtown). Perhatikan bahwa informasi alamat Joel di Smallville
telah ditimpa. Maka tidak ada cara untuk mengakes informasi yang hilang tersebut melalui database. Setiap kantor yang mengakses databse pada 28 Desember 1994 akan mendapatkan Joel tinggal di Bigtown. Secara teknis: jika sebuah komputer melakukan query SELECT ADDRESS FORM PERSON WHERE NAME=’Joel Wahyudi’ pada 26 Desember 1994, menghasilkan: Smallville. Menjalankan query yang sama pada 2 hari selanjutnya menghasilkan Bigtown. Sampai dengan kematian trgaisnya, database akan menyatakan Joel tinggal di Bigtown. Pada 1 April 2001 akhirnya petugas menghapus Joel Wahyudi dari databse. Maka pemanggilan query di atas tidak akan menghasilkan hasil apapun. Tanggal Yang terjadi di dunia nyata Perubahan di Database Tampilan di Database 3 April Tidak ada Person dengan nama Kelahiran Joel Tidak ada 1975 Joel Wahyudi 4 April Hendro melaporakan kelahiran Inserted:Person(Joel Joel Wahyudi tinggal di 1975 anaknya ke kantor secara resmi Wahyudi, Smallville) Smallville Setelah kelulusan, Joel pindah ke 26 Agustus Joel Wahyudi tinggal di Bigtown, namun lupa untuk Tidak ada 1994 Smallville meregristasikan alamat barunya 26 Joel Wahyudi tinggal di Desember Tidak ada Tidak ada Smallville 1994 27 Joel mendaftarkan alamat Updated:Person(Joel Joel Wahyudi tinggal di Desember barunya Wahyudi, Bigtown) Bigtown 1994 1 April Deleted:Person(Joel Tidak ada Person dengan nama Joel meninggal 2001 Wahyudi) Joel Wahyudi Post 3 (1 July 2009) «Menggunakan Database Temporal dengan Waktu yang Valid: Waktu yang valid (valid time) yang berarti waktu sebernarnya di dunia nyata. Pad contoh di atas, tabel Person mendapat dua fields tambahan, yaitu Valid-From dan Valid-To, yang menjelaskan kapan Address seseorang berlaku di dunia nyata. Pada 4 April 1975, Hendro dengan bangga mendaftarkan kelahiran anak pertamanya. Maka petugas akan memasukkan data tersebut ke database yang menjelaskan Joel bertempat tinggal di Smallville sejak 3 April. Perlu diketahui meski data dimasukkan pada 4 April, namun database menjelaskan bahwa informasi tersebut berlaku sejak tanggal 3. Petugas belum mengetahui apakah atau kapan Joel akan berpindah ke tempat lain, sehingga pada field Valid-To di database diisi dengan infinity (∞). Pemasukkan data ke basisdata berupa: Person(Joel Wahyudi, Smallville, 3-Apr-1975, ∞). Pada tanggal 27 Desember 1994, Joel melaporkan alamat barunya di Bigtown yang sudah ia tinggali sejak 26 Agustus 1994. Petugas di kantor Bigtown tidak merubah alamat milik Joel di database. Sang petugas menambahkan yang baru: Person (Joel Wahyudi, Big Town, 26-Aug-1994, ∞). Masukan data milik Joel sebelumnya (Joel Wahyudi, Smallville, 3-Apr-1975, ∞) kemudian diupdate (tidak dihapus!). karena diketahui Joel sudah tidak tinggal di
Smallville pada 26 Agustus 1994, maka kolom Valid-To dapat terisi. Database kemudian memiliki dua buah entry milik Joel Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994). Person(Joel Wahyudi, Bigtown, 26-Aug-1994, ∞). Saat Joel meninggal, database diupdate sekali lagi. Entry terbaru akan diupdate menyatakan bahwa Joel tidak tinggal di Bigtown lagi. Tidak ada entry yang ditambahkan karena tidak pernah dilaporkan surge sebagai alamat baru. Maka database sekarang akan seperti ini Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994). Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Apr-2001). «Menggunakan Database Temporal dengan Waktu Transaksi: Waktu transaksi adalah penggunaan database temporal menggunakan waktu pada saat transaksi dilakukan. Dengan ini kita dapat menggunakan queri-queri yang menampilkan status database pada waktu tertentu. Maka ada dua tambahan kolom di tabel Person: Transaction-From dan Transaction-To. Transaction-From merupakan waktu saat transaksi dilakukan, sedangkan Transaction-To adalah waktu transaksi dibatalkan (atau menggunakan tak terhingga jikan belum akan dibatalkan). Apakah yang akan terjadi jika alamat seseorang yang ada di database merupakan alamat yang salah? Anggap seorang petugas secara tidak sengaja memasukkan alamat atau tanggal yang salah? Atau, anggap orang yang memasukkan data berbohong ketika memberi informasi untuk keperluan tertentu. Setelah mengetahui data yang benar, maka petugas harus kembali mengupdate database tersebut. Sebagai contoh, dari 1 Juni 1995 hingga 3 September 2000 Joel Wahyudi pindah ke Beachy. Namun untuk menghindari membayar pajak kota Beachy yang sangat mahal, Joel tidak pernah melapor ke yang berwewenang. Akhirnya, hal tersebut terungkap pada 2 Februari 2001 saat ada pengecekan pembayaran pajak, bahwa dia sebenarnya tinggal di Beachy selama ini, maka para petugas mengupdate database menjadi seperti ini: Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Jun-1995). Person(Joel Wahyudi, Beachy, 1-Jun-1995, 3-Sep-2000). Person(Joel Wahyudi, Bigtown, 3-Sep-2000, 1-Apr-2001). Maka 2 data yang sudah ada di update, dan sebuah data baru dimasukkan menyimpan keberadaannya di Beachy. Bagaimanapun, hal ini tidak meninggalkan catatan di database yang menyatakan Joel tinggal di Bigtown dari 1 Juni 1995 hingga 3 September 2000, yang mungkin sangat penting untuk alasan mengaudit data (atau untuk menjadi bukti pada investigasi kantor pajak). Di sini kita dapat melihat waktu transaksinya. Kita harus menyimpan setiap data ketika dimasukkan dan ketika dibatalkan. Maka dari itu, kita memperoleh data seperti berikut: Person(Joel Wahyudi, Smallville, 3-Apr-1975, ∞, 4-Apr-1975, 27-Dec-1994). Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994, 27-Dec-1994, ∞ ). Person(Joel Wahyudi, Bigtown, 26-Aug-1994, ∞, 27-Dec-1994, 2-Feb-2001 ). Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Jun-1995, 2-Feb-2001, ∞ ). Person(Joel Wahyudi, Beachy, 1-Jun-1995, 3-Sep-2000, 2-Feb-2001, ∞ ). Person(Joel Wahyudi, Bigtown, 3-Sep-2000, ∞, 2-Feb-2001, 1-Apr-2001 ).
Person(Joel Wahyudi, Bigtown, 3-Sep-2000, 1-Apr-2001, 1-Apr-2001, ∞ ). Jadi, kita tidak hanya menyimpan apa yang terjadi di waktu yang berbeda, tetapi kita juga menyimpan data yang berubah secara resmi pada waktu yang berbeda. Permasalah utama pada database dengan waktu transaksi adalah saat mengembangkan queri-queri temporal dibawah penggunaan skemanya. Untuk mencapai pengarsipan data yang sempurna, sangat penting untuk menyimpan data dibawah skema awal ketika database dibuat. Namun, sesimpel apapun queri temporal, riwayat sebuah atributnya tetap butuh ditulis manual di setiap versi skemanya, dan mungkin ratusan kasus seperti pada kasus MediaWiki (http://yellowstone.cs.ucla.edu/schemaevolution/index.php/Schema_Evolution_Benchmark). Proses ini membutuhkan usaha yang sangat besar dari pengguna untuk merapihkan database tersebut. Penyelesaian umumnya dilakukan dengan menyediakan penulis queri secara otomatis. Post 4 (24 July 2009) Sebelum melanjutkan ke topik selanjutnya, perlu diingat satu konsep penting tentang ke presisian waktu yang di simpan di database temporal. Konsep ke presisian dari sebuah database temporal disebut granularity of the time (serpihan waktu). Granularity merupakan unit terkecil durasi waktu yang disimpan pada database temporal kita. Contoh serpihan waktunya yaitu satu hari, satu jam, atau satu detik. «Konsep Utama dalam Memahami Database Temporal Telah kita ketahui dua tipe waktu utama dalam konsep database temporal, yaitu waktu transaksi (transaction time) dan waktu yang valid (valid time), memungkinkan 3 bentuk database temporal : Historical, Rollback, dan Bitemporal. Sebuah database temporal historical dapatmensuport valid time, tapi tidak dapat menggunakan transaction time. Tipe kedua yaitu rollback database, database ini kebalikannya dari database historical, yaitu menggunakan transaction time dan tidak dapat menggunakan valid time. Rollback database sangat berguna dalam data recovery setelah jika terdapat kerusakan pada temporal database. Sebuah database rollback juga diperlukan jika database tidak di proteksi untuk menjaga keamanan data. Sehingga saat ini pada pasar tingkat dunia, minimal biasanya menyediakan beberapa fitur rollback. Temporal database yang sebenarnya adalah database bitemporal. Database ini mensuport keduanya, yaitu transaction time dan valid time, sehingga menghasilkan kombinasi bentuk database historical dan rollback. Database bitemporal mampu mengatasi permasalahan dimensi waktu; dalam tingkat DBMS yaitu transaction time, dalam tingkat data yaitu valid time, dan dalam tingkat user menggunakan user-defined time. «Tujuan Utama bagi Database Temporal… Kemampuan Query Salah satu faktor terpenting dalam menggunakan database yang mensuport dimensi temporal, yaitu kemampuan untuk menjalankan data dengan query. Saat ini yang umum digunakan untuk database conventional (relational) adalah Structured Query Language atau yang biasa kenal dengan SQL. SQL sudah menjadi bahasa standar di industri untuk Relational Database Management Systems (RDBMS) karena kemudahan dalam menggunakannya yang sintaksnya mirip dengan bahasa Inggris
langsung. SQL termasuk user friendly dan dapat digunakan untuk berbagai keperluan. Bagaimanapun penambahan element temporal ini meningkatkan kompleksitas query pada data temporal. Dengan penambahan elemen time, dalam kemampuannya saat ini SQL tidak dapat memproses query query tersebut seperti biasanya pada kondisi database klasik (relational). Bahasa query yang baru atau perluasan dari SQL sangat diperlukan di sini. Perlu diketahui, salah satu permasalahan terbesar yang diteliti saat-saat ini adalah di bagian temporal database. Hari-hari ini, tidak sedikit bahasa-bahasa dan perluasan bahasa-bahasa query yang mengajukan dan membahas topik ini. Topik ini cukup memerlukan perhatian khusus, dan salah satu contohnya akan diberikan berikut ini. Bahasa query temporal yang baru harus dapat mensuport kemampuan SQL tanpa mengurangi kemampuan sebelumnya. SQL sudah memberi bantuan yang sangat besar dan mendominasi RDBMS saat ini karena, seperti yang kita ketahui sebelumnya, SQL cocok untuk banyak keperluan bisnis dan merupakan bahasa yang user friendly. Salah satu bahasa query yang paling diharapkan adalah bahasa query yang mensuport dimensi waktu dan tetap memungkinkan user memasukan query tanpa menetapkan dimensi waktunya (hal tersebut menhindari biaya lebih). Dan bahasa tersebut bukanlah sebuah bahasa yang baru, melainkan perluasan dari bahasa SQL. Satu contoh yang paling menarik adalah TSQL. TSQL yang merupakan Temporal Structured Query Language dapat berjalan tanpa harus memasukkan kriteria waktu. Karena demikian, ketentuan-ketentuan utama dari query TSQL masih sama dengan ketentuan-ketentuan di SQL: yaitu ‘SELECT’ dan ‘FORM’. Jika perlu juga terdapat ‘WHERE’, ‘GROUP BY’, ‘HAVING’, dan ‘ORDER BY’. Kriteria tambahan pada TSQL dapat berupa ‘WHEN’ atau ‘WHILE’. Kedua nama query tersebut bermaksud menjelaskan perbedaan kondisi waktu. Klausa ‘WHEN’ menjelaskan perincian “sepotong waktu” untuk data yang valid atau tidak valid tergantung hasil yang diinginkan. Saat ini, pengajuan untuk menambahkan TSQL ke ANSI dan ISO milik SQL standar sedang dipertimbangkan oleh pihak-pihak yang mengaudit. Post 5 (8 Agustus 2009) Setelah membahas teori-teori mengenai database temporal, pada bagian terakhir ini saya akan menggabungkan bagian teori dengan bagian praktiknya langsung mengenai database temporal. Di sini,akan dijelaskan mengenai beberapa tipe bisnis yang dapat mendapat keuntungan lebih dengan bantuan database temporal. «Data Warehouse Data warehouse atau pergudangan data bukan merupakan bisnis per se (bukan bisnis itu sendiri, tapi mengambil dari bisnis lain). Data warehouse ini merupakan usaha yang sangat luas, yaitu bisnis yang diperuntukan menyimpan seluruh informasi dari beberapa perusahaan. Data warehouse terbukti sangat berguna sebagai tempat penyimpanan informasi yang dikumpulkan dengan tools data mining dan digunakan untuk sumber informasi. Seperti yang sudah kita ketahui, elemen waktu sangat penting untuk berbagai bisnis, dan dalam sebuah data warehouse dimensi waktu dapat disimpan dan digunakan dalam peng query an data. Sebenarnya apa yang data warehouse lakukan dengan adanya database temporal? Menurut Ralph Kimball, setiap data warehouse memiliki dimensi waktu yang membuat setiap data warehouse menjadi database warehouse [Kimball
1997+,*Snodgrass 1998+.”Dimensi waktu adalah unik dan merupakan dimensi yang kuat dalam setiap kumpulan data dan usaha data warehouse”*Kimball 1997+. «Laboratorium Ilmiah Jenis bisnis yang kedua adalah lab ilmiah (scientific laboratory). Setiap lab tentu melakukan banyak uji coba dan banyak versi untuk percobaan yang sama, dan setiap percobaan sering kali melibatkan urutan waktu yang sangat teliti. Agar informasinya tidak ada yang hilang, tentunya harus disimpan dalam sebuah database. Karena elemen waktu di test ini jelas tidak bisa dihilangkan, sehingga informasi yang disimpan di sini harus disimpan dalam database temporal. Satu keuntungan dalam menyimpan informasi ujicoba ilmiah pada temporal database yang mendukung bahasa query temporal adalah, sebuah pola baru dan pengetahuan baru dapat digali dari basis data [Loomis 1997]. «Sales dan Marketing Kedua bisnis ini sangat berkantung pada temporal database, karena keberhasilan sales dan marketing sangat bergantung pada waktu yang tepat. Waktu untuk pendekatan dengan pelanggan dan kapan untuk mengiklankan di lokasi tertentu sangat diperlukan, dan kemampuan untuk meramalkan informasi ini jauh lebih baik disediakan database temporal daripada database klasik biasa. «Multimedia Jenis bisnis yang terakhir adalah multimedia. Multimedia merupakan salah satu area bisnis yang paling cepat berkembang saat ini, terutama melalui jalus internet. Seseorang saat ini dengan mudah menonton film dari internet, dimana gambar video tersebut sudah tersimpan di database multimedia yang harus disinkronisasikan dengan data audio yang mungkin berada di database yang sama atau berbeda. Pengsinkronisasian ini, seperti kata tersebut sendiri, jelas melibatkan elemen waktu. “Karen multimedia berbasis waktu, sinkronisasi sangat di butuhkan. Jika diimplementasikan dengan baik, maka komponen-komponen media tersebut akan ditampilkan dengan ketepatan dari sinkronisasi yang baik*David+”. “Objekobjek multimedia memiliki relasi dan ruang temporary yang harus dijaga saat ditampilkan beberapa data memiliki batasan waktu nyata (real time) saat menyampaian ke stasiun clien*Ozsu+”. Karena itu, database untuk multimedia, seperti data warehouse, merupakan instance dari database temporal juga. Sebagai penutup, akan dibahas sedikit mengenai database temporal di masa mendatang. Dengan meningkatnya persaingan di lingkungan bisnis, pengetahuan akan informasi antar organisasi menjadi sumber yang berharga. Salah satu elemen kunci dari informasi ini adalah dimensi waktu. Untuk mendapatkan informasis ini, dalam bisnis harus digunakan database temporal. Dalam menerapkan kemampuan menyimpan variable waktu pada bisnis yang ada, akan terdapat dua hal yang berpengaruh. Pertama, kebanyakan produsen basis data komersial akan berlombalomba memasukkan kemampuan temporal data di produk basis data mereka. Kedua, extension temporal database akan dimasukkan ke ANSI dan ISO SQL standar yang sudah ada. Hal ini akan memungkinkan pengguna untuk mengambil keuntungan dari fitur temporal baru pada produk database yang biasa mereka gunakan. Pada titik ini, sebagian besar dari produsen database komersil akan menggunakan database temporal. Hal ini memungkinkan pengetahuan akan informasi yang lebih lengkap dan lebih baik dapat disimpan dan diambil dari
database temporal, yang membuat bisnis-bisnis beralih menggunakan temporal database untuk bersaing dengan bisnis lainnya.
Pengertian Basis Data Relasional Basis Data relasional menggunakan tabel dua dimensi yang terdiri atas baris dan kolom untuk memberi gambaran sebuah berkas data. Contoh Tabel dan keterhubungannya : MHS NPM 10296832 10296126 31296500 41296525 50096487 21196353 MKUL KDMK KK021 KD132 KU122 NILAI NPM 10296832 10296126 31296500 41296525 21196353 50095487 10296832
Nama Nurhayati Astuti Budi Prananingrum Pipit Quraish MTKULIAH P. Basis Data SIM Pancasila KDMK KK021 KD132 KK021 KU122 KU122 KD132 KD132 MID 60 70 55 90 75 80 40
Alamat Jakarta Jakarta Depok Bogor Bekasi Bogor SKS 2 3 2 FINAL 75 90 40 80 75 0 30
Keuntungan Basis Data Relasional 1. Bentuknya sederhana 2. Mudah melakukan berbagai operasi data · Istilah dalam Basis Data Relasional : Relasi : Sebuah tabel yang terdiri dari beberapa kolom dan beberapa baris. Atribut : Kolom pada sebuah relasi Tupel : Baris pada sebuah relasi Domain : Kumpulan nilai yang valid untuk satu atau lebih atribut Derajat (degree): Jumlah atribut dalam sebuah relasi Cardinality : Jumlah tupel dalam sebuah relasi
Relational Key Super key : Satu atribut/kumpulan atribut yang secara unik mengidentifikasi sebuah tupel di dalam relasi
Candidate key : Atribut di dalam relasi yang biasanya mempunyai nilai unik Primary key : Candidate key yang dipilih untuk mengidentifikasikan tupel secara unik dalam relasi
Alternate key : Candidate key yang tidak dipilih sebagai primary key Foreign key : Atribut dengan domain yang sama yang menjadi kunci utama pada sebuah relasi tetapi pada relasi lain atribut tersebut hanya sebagai atribut biasa
Relational Integrity Rules 1. Null Nilai suatu atribut yang tidak diketahui dan tidak cocok untuk baris (tuple) tersebut
2. Entity Integrity Tidak ada satu komponen primary key yang bernilai null. 3. Referential Integrity Suatu domain dapat dipakai sebagai kunci primer bila merupakan atribut tunggal pada domain yang bersangkutan. Bahasa Pada Basis data Relational Menggunakan bahasa query à pernyataan yang diajukan untuk mengambil informasi Terbagi 2 : 1. Bahasa Formal Bahasa query yang diterjemahkan dengan menggunakan simbol-simbol matematis. Contoh: Aljabar relasional Kalkulus relasional · Aljabar Relasional Bahasa query prosedural à pemakai menspesifikasikan data apa yang dibutuhkan dan bagaimana untuk mendapatkannya.
· Kalkulus Relasional Bahasa query non-prosedural à pemakai menspesifikasikan data apa yang dibutuhkan tanpa menspesifikasikan bagaimana untuk mendapatkannya. Terbagi 2 : (1) Kalkulus Relasional Tupel (2) Kalkulus Relasional Domain 2. Bahasa Komersial Bahasa Query yang dirancang sendiri oleh programmer menjadi suatu program aplikasi agar pemakai lebih mudah menggunakannya (user friendly). Contoh : • QUEL Berbasis pada bahasa kalkulus relasional · QBE Berbasis pada bahasa kalkulus relasional · SQL Berbasis pada bahasa kalkulus relasional dan aljabar relasional · Contoh-contoh Basis Data Relasional :
- DB2 à IBM - ORACLE à Oracle - SYBASE à Powersoft - INFORMIX à Informix - Microsoft Access à Microsoft
