Analisis dan Implementasi Perbandingan Penggunaan Storage serta Response
Time pada Temporal Database dan Relational Database
Yogiek Indra Kurniawan Politeknik Telkom, Bandung
siyogiek@gmail.com Abstrak
Pada saat ini banyak aplikasi yang membutuhkan data dari masa lampau dan data pada masa yang akan datang. Data-data ini biasanya digunakan untuk menelusuri event-event yang terjadi untuk melihat trend dan menemukan kesalahan-kesalahan di masa lampau sehingga mencegah terjadinya kesalahan yang sama. Temporal Database merupakan salah satu solusi dalam penanganan data-data di masa lampau maupun di masa yang akan datang. Temporal database adalah database yang merepresentasikan data dengan dimensi waktu berupa valid time. Dalam paper ini, dilakukan implementasi temporal database serta relational database yang memperhitungkan aspek historical data. Setelah melakukan implementasi, dilakukan analisis mengenai penggunaan storage, query dalam pengaksesan setiap data yang memperhitungkan aspek historical data, baik data definition language (DDL), data manipulation language (DML) maupun query untuk retrieve data serta kelebihan dan kekurangan untuk masing-masing basis data tersebut. Setelah dilakukan analisis, didapatkan kesimpulan bahwa penggunaan query untuk
temporal database dapat dilakukan pada relational database dengan beberapa penyesuaian. Selain itu, temporal database memiliki kelebihan dalam hal penggunaan storage dan response time untuk query DDL
serta DML, tetapi untuk response time pada query retrieve data membutuhkan waktu yang lebih lama daripada relational database.
Kata kunci: temporal database, relational database, query, valid time, storage, response time.
Abstract
At present, many applications that require data from the data on past and future. These data are usually used to trace the events that happened to look at trends and find the mistakes in the past so as to prevent the occurrence of the same mistakes. Temporal database is one of the solutions to handling of data in the past and in the future. Temporal database is a database with data representing the valid time dimension. In this paper, doing implementate of temporal databases and relational databases that takes into account the historical aspects of the data. After doing the implementation, analysis will be conducted on storage utilization, the query to access any data that takes into account the historical aspects of the data, both Data Definition Language (DDL), Data Manipulation Language (DML) and queries to retrieve data as well as advantages and disadvantages for each of these databases. After analyzing, it was concluded that the use of queries for temporal databases can be done in a relational database with some adjustments. In addition, temporal databases have advantages in terms of storage utilization and query response time for DDL and DML, but the response time on queries to retrieve data takes longer than a relational database. Keywords: temporal database, relational database, query, valid time, storage, response time
1. Pendahuluan
Pada saat ini banyak aplikasi yang membutuhkan data dari masa lampau dan data pada masa yang akan datang. Data ini biasanya digunakan untuk menelusuri event-event yang terjadi untuk melihat trend dan menemukan kesalahan-kesalahan di masa lampau sehingga mencegah terjadinya kesalahan yang sama. Sayangnya, pada database
relational yang sering digunakan sekarang, kurang
mendukung hal seperti ini.
Salah satu solusi untuk pemecahan masalah di atas adalah dengan penggunaan temporal database.
Temporal database adalah sebuah basis data yang
mendukung aspek temporal di luar waktu yang didefinisikan oleh pengguna, dengan satu atau lebih
dimensi waktu [4]. Hal ini memungkinkan perubahan data terhadap waktu tidak akan menghapus data dari masa lampau. Sedangkan pendekatan lain yang dapat dilakukan untuk pemecahan masalah di atas adalah dengan menambahkan atribut waktu pada basis data
relational.
Dalam penelitian ini akan dilakukan implementasi data historical dengan menggunakan
temporal database serta relational database yang
dimodifikasi serta menganalisis query-query pada kedua basis data tersebut. Selain itu, dilakukan analisis dari aspek penggunaan storage serta
response time untuk mengukur keefektifan penggunaan masing-masing basis data.
Permasalahan yang dijadikan objek dalam penelitian ini adalah melakukan implementasi dan analisis query dalam temporal database
dibandingkan dengan query pada relational database yang memperhitungkan aspek historical data, serta mengetahui perbandingan keefektifan penggunaan
temporal database dengan relational database
dalam hal penggunaan storage dan response time. 2. Dasar Teori Temporal Database
Basis data temporal adalah basis data yang mendukung aspek temporal di luar waktu yang didefinisikan oleh pengguna [4]. Basis data temporal memungkinkan pengasosiasian fakta dengan waktu. Basis data temporal merupakan pengayaan dari basis data relational yang memperhitungkan aspek waktu. Pada basis data konvensional, tidak mengurus aspek historis keberlakuan data di basis data.
Sedangkan basis data relational adalah seperangkat program komputer yang dikonstruksi untuk memanejemen suatu basisdata sebagai sekumpulan data yang disimpan secara terstruktur dan dapat dikenai opreasi-operasi tertentu atas data sebagai suatu permintaan (query) dalam bentuk tabel-tabel dua dimensi yang saling berelasi.
Basis data temporal mendukung penanganan aspek waktu yang kompleks dan dapat menyimpan aspek historis suatu data. Data akan ditandai dengan waktu keberlakuannya di dunia nyata, sehingga setiap data akan memiliki “sejarah” mulai dari masa lampau sampai masa yang akan datang. Selain itu, terdapat operator khusus untuk waktu yang tidak terdapat di basis data konvensional, seperti operator untuk mengetahui dua periode waktu yang overlap atau bersinggungan.
2.1 Dimensi Waktu
Pada basis data temporal, dikenal tiga dimensi waktu [5][8] :
1. User-defined time
User-defined time adalah waktu yang
semantiknya ditentukan oleh pengguna. Sebagai contoh, sebuah table yang menyimpan data pegawai dapat mempunyai dua atribut bertipe date, untuk menyimpan data tanggal lahir dan tanggal mulai bekerja. Dua atribut tersebut mempunyai nilai yang dimasukkan oleh user,sehingga termasuk
user-defined time.
2. Transaction time
Transaction time adalah waktu keberlakuan
data di basis data. Secara teknis, ini adalah waktu saat data dimasukkan ke basis data sampai dengan data diubah atau dihapus dari basis data. Nilai keberlakuan data ini dicatat secara otomatis saat terjadi operasi terhadap data, yaitu insert, update, dan delete, sehingga user tidak bisa memanipulasi
transaction time dari setiap data. 3. Valid time
Valid time adalah waktu keberlakuan data di
oleh penguna. Sebagai contoh, suatu data bahwa pegawai bernama Yogiek mendapat gaji Rp 10.000.000,00 dapat ditentukan keberlakuannya dari tanggal 1 Januari sampai dengan akhir tahun. Representasi valid time bisa bermacam-macam tergantung dari user. Domainnya mencakup masa lalu hingga masa depan.
2.2 Query untuk Operasi Relasi Temporal Ada beberapa bahasa query temporal yang telah diajukan pada berbagai literatur, seperti TSQL2, ChronoBase, SQL+T TMQL, TOSQL dan TQuel [1]. Salah satu bahasa yang mendapatkan dukungan terbesar dalam riset mengenai basis data
temporal adalah TSQL2. Query yang dipakai dalam
penelitian ini adalah TSQL2 yang mengacu kepada web resmi TimeDB, yaitu timeconsult yang dibuat oleh Andreas Steiner [6][7].
2.2.1 Create Table
Operasi create table adalah operasi yang digunakan untuk mendefinisikan dan membuat relasi. Pada basis data temporal, selain klausa standar CREATE TABLE untuk membuat relasi, perlu ditentukan juga jenis relasi dalam klausa AS
TEMPORAL_DIMENSION seperti berikut : CREATE TABLE table_name (
{ column_name data_type [DEFAULT
default_value]
[column_constraint[…] ] | table_constraint} [, …] ) [AS temporal_dimension]
Bagian temporal_dimension berisi VALIDTIME. Statement create table tanpa deklarasi dimensi waktu akan menghasilkan relasi
snapshot. Contoh penggunaan query create table
untuk membuat relasi temporal dapat dilihat seperti berikut :
CREATE TABLE pegawai ( Nip char(9) PRIMARY KEY, Nama varchar(30) not null, Gaji integer
) AS VALIDTIME;
2.2.2 Insert
Operasi insert adalah operasi yang digunakan untuk memasukkan tuple baru ke dalam basis data. Pada relasi temporal, perlu dimasukkan nilai valid
time yang dituliskan dalam klausa VALID seperti
berikut
VALIDTIME PERIOD [v_start-v_end)
INSERT INTO table_name [(column_name [, …])] VALUES ( value [, …]);
VALIDTIME PERIOD digunakan untuk time
interval. Contoh penggunaan query insert pada relasi temporal dapat dilihat sebagai berikut. Query
tersebut memasukkan data pegawai bernama Yogiek dengan gaji 10000000 yang berlaku mulai tanggal 1 Januari 2010 sampai batas waktu yang belum ditentukan.
VALIDTIME PERIOD [2010/01/01-forever) INSERT INTO pegawai(nip,nama,gaji) VALUES (‘113060210’,’Yogiek’,10000000);
2.2.3 Delete
Operasi delete digunakan untuk menghapus suatu tuple. Pada relasi temporal, delete dapat dilakukan untuk periode valid time tertentu. Artinya, keberlakuan data pada periode waktu tersebut dihilangkan. Query temporal untuk delete dapat dilihat sebagai berikut:
[NONSEQUENCED] VALIDTIME PERIOD
[v_start – v_end) DELETE FROM table_name [WHERE condition]
Pada relasi dengan format time interval, jika nilai valid time tidak dideklarasikan, waktu keberlakuan data yang dihilangkan adalah [beginning, forever]. Nilai ‘beginning’ adalah waktu saat masa lampau. Contoh query delete pada relasi
temporal dapat dilihat sebagai berikut. Pada query
tersebut, tuple dengan nip=’113060210’ dihilangkan keberlakuan datanya untuk tanggal 1 Januari 2011 sampai tanggal 31 Januari 2011.
NONSEQUENCED VALIDTIME PERIOD
[2011/01/01 – 2011/01/31)
DELETE FROM pegawai WHERE nip=’113060210’;
2.2.4 Update
Operasi update adalah operasi yang digunakan untuk memperbaharui nilai dalam suatu tuple. Pada basis data temporal, update untuk nilai valid time dapat dilakukan dengan delete data dengan valid
time start dan valid time end yang ditentukan. Untuk update data yang tidak melibatkan valid time dapat
dilakukan dengan update biasa. Query untuk update adalah sebagai berikut:
UPDATE table_name
{SET column_name = value [, …] } [WHERE condition]
Contoh penggunaan query update pada dapat dilihat sebagai berikut. Pada query berikut ini, tuple yang mengandung nip=’113060210’ diubah gajinya menjadi 5000000 dan keberlakuannya datanya diubah menjadi 1 Februari 2010 sampai 31 Desember 2010 dan 1 Febuari 2011 sampai selamanya.
NONSEQUENCED VALIDTIME PERIOD
[2010/01/01 – 2010/01/31)
DELETE FROM pegawai WHERE nip=’113060210’; UPDATE pegawai
SET gaji=5000000 WHERE nip=’113060210’;
2.2.5 Select
Operasi select digunakan untuk me-retrieve
tuple dalam relasi sesuai dengan kondisi yang
diinginkan. Pada relasi temporal, tuple dapat diseleksi berdasarkan keberlakuan valid time. Query untuk operasi select pada relasi temporal dapat dilihat sebagai berikut :
[VALIDTIME PERIOD [v_start-v_end)]
SELECT [SNAPSHOT] [DISTINCT]
column_name [, …] FROM table_name [, …] [WHERE condition]
2.3 Operator Perbandingan pada TSQL2 Operator perbandingan temporal yang diterima pada query tergantung pada bahasa query yang digunakan. Terdapat beberapa definisi yang berbeda untuk operator yang sama. Sebagai contoh, definisi “overlaps” berbeda pada operator perbandingan Allen dan TSQL2. Operator untuk perbandingan interval valid time pada TSQL2 dapat dilihat pada tabel 2.15. definisi operator perbandingan temporal yang digunakan dalam paper ini adalah definisi pada tabel tersebut.
TABEL 2.1
DEFINISI OPERATOR PERBANDINGAN INTERVAL Operator Definisi
A PRECEDES B END (A) lebih awal daripada BEGIN (B)
A=B A dan B bernilai sama A OVERLAPS B Irisan A dan B tidak kosong A CONTAINS B Setiap event di B terdapat pada
A
A MEETS B A PRECEDES B dan tidak ada event antara END (A) dan BEGIN (B)
3. Analisis Hasil Pengujian 3.1 Perancangan Basis Data
Terdapat banyak aplikasi yang dapat menggunakan temporal database, seperti aplikasi Pertokoan, aplikasi pemantauan cuaca, aplikasi rumah sakit, aplikasi bursa saham dan lain sebagainya. Aplikasi-aplikasi tersebut dapat menggunakan temporal database karena adanya perubahan data setiap waktu. Sehingga untuk aspek
historical data, aplikasi-aplikasi tersebut dapat dipergunakan.
Dalam penelitian ini, aplikasi yang diimplementasikan adalah aplikasi pemantauan data pada pertokoan. Terdapat 2 buah aplikasi dengan basis data yang berbeda. Hal ini untuk mendukung aspek historis dari masing-masing basis data. Perancangan desain basis data ini didasarkan pada ER Diagram yang dibuat oleh Daniel Graziotin dan Thomas Steingruber dalam “Computer Shop
warehouse ER Diagram”[2] dengan beberapa
perubahan sebagai berikut:
1. Menambahkan entitas lokasi sebagai tempat dan jabatan dari pegawai
2. Menambahkan entitas gudang sebagai tempat barang disimpan.
3. Menambahkan entitas member (pelanggan). 4. Mengurangi entitas shop (toko) dan order
(pemesanan).
3.1.1 Perancangan Basis Data Temporal
Berikut ini adalah rancangan schema diagram dalam basis data temporal dari studi kasus sistem pertokoan :
Gambar 1 Skema diagram Temporal Database Pada rancangan schema diagram diatas, data yang menunjukkan basis data temporal diletakkan di
table pegawai, member, barang dan supplier. Pada 4 table tersebut memperhatikan aspek historical data
sebagai berikut : 1. Table pegawai
Pada table pegawai, akan diperlihatkan historis mengenai gaji dari seorang pegawai serta id_lokasi yang menunjukkan jabatan dan tempat bekerja dari seorang pegawai.
2. Table member
Pada table member, akan diperlihatkan historis mengenai alamat dan status dari suatu member. 3. Table barang
Pada table barang, akan diperlihatkan historis mengenai stock,harga beli dan harga jual dari suatu barang.
4. Table supplier
Pada table supplier, akan diperlihatkan historis mengenai alamat dan status dari supplier yang bersangkutan.
Untuk memberikan dimensi waktu valid time pada 4 buah tabel tersebut, maka ditambahkan atribut vts_timedb dan vte_timedb.
3.1.2 Perancangan Basis Data Relational Berikut ini adalah rancangan schema diagram dalam basis data relational untuk mendukung aspek
historical data dari studi kasus sistem pertokoan
yang menyertakan dimensi waktu temporal pada tabel pegawai, member, barang dan supplier dengan mengacu pada basis data temporal sebelumnya sebagai berikut :
Gambar 2 Skema diagram Relational Database
Pada rancangan schema diagram diatas, untuk mendukung aspek data temporal pada tabel pegawai,
member, barang, dan supplier, maka pada setiap table tersebut akan dimunculkan sebuah tabel historis untuk menyimpan setiap perubahan data
yang terjadi pada tabel-tabel tersebut, sebagai berikut:
1. Table pegawai
Pada table pegawai akan dibuat sebuah table bernama history_pegawai yang memiliki kolom id_pegawai untuk mengacu pada tabel pegawai, kolom gaji, lokasi dan id_lokasi yang menunjukkan jabatan dan tempat bekerja dari seorang pegawai untuk memperlihatkan historis dari data di tabel pegawai.
2. Table member
Pada table member akan dibuat sebuah tabel bernama history_member yang memiliki kolom id_member untuk mengacu ke tabel member serta alamat dan status dari suatu member untuk memperlihatkan historis dari data di tabel member. 3. Table barang
Pada table barang,dibuat sebuah tabel bernama history_barang yang memiliki kolom id_barang sebagai foreign key untuk mengacu ke tabel barang serta kolom stock, harga_beli dan harga_jual untuk memperlihatkan historis data di tabel barang. 4. Table supplier
Pada table supplier, dibuat sebuah tabel bernama history_supplier yang memiliki kolom id_supplier sebagai foreign key untuk mengacu ke tabel supplier serta kolom alamat dan status sebagai data historis dari tabel supplier.
3.2 Implementasi Perangkat Lunak
Pembangunan sistem perangkat lunak untuk pengujian, menggunakan beberapa perangkat lunak, antara lain :
1. Sistem Operasi : Microsoft Windows 7 Home Premium 64-bit
2. Database : Oracle 10g Release 2 (10gR2) 3. Parser dan Translator : TimeDB 2.2 4. Kakas Pemrograman : NetBeans IDE 6.8 5. Software Development Kit : J2SE SDK 1.6 6. Library tambahan : ojdbc14.jar
3.3 Skenario Pengujian
Skenario pengujian untuk perangkat lunak yang dibangun terdiri dari beberapa pengujian. Skenario pengujian pertama adalah dengan memasukkan data yang sama pada kedua buah database, yaitu pada temporal database maupun
relational database. setelah itu, dilihat jumlah
penggunaan storage (penyimpanan) pada harddisk untuk masing-masing database.
Skenario pengujian kedua adalah pengujian
query. Pada pengujian kedua ini, query TSQL2 pada temporal database akan dibandingkan dengan query
SQL92 pada relational database [3] yang menerapkan aspek historical data. Setelah itu dianalisis query-query tersebut dan dibandingkan mengenai response time yang dibutuhkan oleh masing-masing query di tiap database.
3.4 Analisis Perangkat Lunak
3.4.1 Analisis Query dan Response Time
Query temporal lebih mudah dan singkat
dibandingkan dengan query relational jika data yang diakses adalah data historis. Selain itu, untuk query
temporal memiliki operator waktu yang lebih
lengkap, sedangkan pada relational harus menerjemahkan sendiri operator waktu tersebut menjadi query yang dimengerti oleh relational. Sedangkan kekurangan dari query temporal yang diimplementasikan dalam penelitian ini adalah query
temporal tidak mendukung adanya update. Sehingga
jika terdapat update pada valid time, maka harus dilakukan penyesuaian dengan menggunakan query
delete. Selain itu, query temporal kurang familiar,
karena temporal database masih belum terlalu di-eksplorasi di masa sekarang.
Sedangkan untuk response time, dari semua
query yang telah diberikan, relational database
relatif lebih unggul pada saat query retrieve data, tetapi untuk query DDL dan DML pada tabel
temporal, pengujian response time menunjukkan
keunggulan temporal database. Hasil perhitungan
response time di atas, dapat digambarkan sebagai
berikut:
Gambar 3 Hasil perbandingan Response time
Relational dan Temporal
Pada dasarnya, query untuk temporal database maupun relational database adalah sama ketika DMBS diakses oleh masing-masing database.
Hanya saja, pada temporal database harus melewati sebuah middleware untuk parsing dan translasi
query terlebih dahulu.
Gambar 4 Proses pada Middleware Proses yang terjadi adalah sebagai berikut:
1. Penghitungan waktu akses dimulai ketika Aplikasi mengirimkan query TSQL2 ditunjukkan dengan nomor (1). Pada Eksekutor, query
tersebut diteruskan menuju Converter.
2. Proses paling penting pada middleware
ditunjukkan oleh nomor (3), karena pada
converter terjadi proses parsing (pemecahan query menjadi token-token) serta proses translasi
(pengubahan token-token menjadi query SQL’92 yang dimengerti oleh RDBMS)
3. Query SQL’92 akan diteruskan menuju eksekutor untuk dijalankan pada RDBMS. 4. Hasil dari eksekusi query SQL’92 pada RDBMS
akan dikirim menuju Eksekutor dan dilanjutkan menuju ke Converter. Pada Converter, akan terjadi proses parsing dan translasi dari hasil pada Relational menuju ke hasil pada Temporal. 5. Hasil berupa table temporal itulah yang
dikirimkan menuju aplikasi, dan dihitung waktu dari awal sampai akhir eksekusi.
Sedangkan pada relational DB, aplikasi langsung mengakses ke RDBMS. Proses yang terjadi dapat digambarkan seperti gambar dibawah ini:
Gambar 5 Proses pada Aplikasi Relational Proses yang terjadi adalah sebagai berikut:
1. Waktu akan dihitung ketika aplikasi mengirimkan query SQL ’92 menuju ke RDBMS.
2. RDBMS akan mengirimkan hasil query ke aplikasi. Waktu akan dihitung sebagai response
time ketika hasil telah diterima oleh aplikasi.
Pada query DDL dan DML, proses pada
temporal database hanya terjadi 1 arah dari aplikasi
menuju RDBMS, tanpa kembali lagi menuju ke aplikasi, dapat ditunjukkan dengan proses nomor (1) sampai dengan nomor (5). Oleh sebab itu, query
temporal menghasilkan response time lebih cepat
daripada query relational, karena pada relational
database terjadi 2 kali proses pada setiap mengakses
tabel temporal, yaitu pada tabel utama dan tabel history.
Sedangkan pada query retrieve data, proses pada TemporalDB adalah setiap table result, baris per baris data yang dihasilkan oleh RDBMS, akan selalu ditranslasikan ke bentuk TSQL2 menuju aplikasi. Hasil dari translasi tersebutlah yang ditampilkan pada aplikasi. Hal ini menyebabkan waktu yang dibutuhkan oleh TemporalDB pun menjadi lebih lama dibandingkan dengan
RelationalDB karena pada RelationalDB, proses
hanya terjadi sekali. Saat table result dihasilkan oleh RDBMS, maka dikirim ke aplikasi RelationalDB dan hasil itulah yang ditampilkan oleh aplikasi. 3.4.2 Analisis Storage
Storage yang dibahas disini adalah penggunaan
media penyimpanan pada masing-masing basis data dengan pemakaian data yang yang sama. Hal ini digunakan untuk mengukur efektivitas penggunaan media penyimpanan pada masing-masing model basis data.
Pada Awal sebelum data dimasukkan,dibuat 2
buah tablespace yang merepresentasikan
penggunaan storage awal untuk 2 buah basis data yang ingin dibandingkan. Didapat data sebagai berikut:
Gambar 6 penggunaan storage awal
Setelah dimasukkan data dengan pemakaian data yang sama, didapat perbandingan penggunaan
storage sebagai berikut:
Gambar 7 Perbandingan penggunaan storage akhir Dari gambar diatas, dapat dilihat bahwa penggunaan storage untuk basis data relational akan memerlukan penggunaan space yang lebih besar dibandingkan dengan penggunaan basis data
relational. Hal ini dikarenakan pada basis data relational harus membuat tabel baru untuk menyimpan historis dari data. Selain itu harus dibuat beberapa trigger untuk memasukkan data historis pada tabel baru tersebut. Sedangkan pada basis data
temporal, data tersebut cukup diwakili pada sebuah
tabel temporal saja. Pada tabel temporal tersebut bisa terdapat 2 buah data dengan primary key yang sama asalkan memiliki valid start dan valid end yang berbeda.
4. Kesimpulan dan Saran 4.1. Kesimpulan
Berdasarkan rangkaian desain, implementasi, pengujian, pengukuran dan analisis yang telah dilakukan, maka dapat disimpulkan bahwa:
1. Berdasarkan analisis query yang telah dilakukan, penggunaan query pada temporal database dapat diimplementasikan pada relational database
dengan beberapa pengubahan pada setiap
query-query yang dilakukan.
2. Penggunaan Storage untuk temporal database lebih sedikit daripada penggunaan storage untuk
relational database yang menerapkan aspek historical data karena setiap tabel dan isi dari
data pada relational database harus di-copy untuk mendapatkan history dari data tersebut. 3. Salah satu kekurangan dari temporal database
adalah membutuhkan waktu akses yang lebih lama daripada relational database pada query
retrieve data karena pada temporal database
harus melewati sebuah middleware untuk
parsing dan translasi query terlebih dahulu untuk
setiap hasil dari tabel data. Sedangkan untuk
query DDL dan DML pada tabel temporal akan
lebih cepat pada temporal database, hal ini disebabkan pada temporal database hanya mengakses 1 tabel, sedangkan pada relational
database akan mengakses 2 buah tabel.
4. Berdasarkan pengujian dan analisis, temporal
database memiliki kelebihan dalam pengaksesan query-query untuk mengakses data temporal
karena jika menggunakan relational database harus dilakukan beberapa modifikasi pada query untuk mendapatkan hasil yang sama dengan
query pada temporal database.
4.2. Saran
Pada paper ini dapat disampaikan beberapa saran sebagai berikut:
1. Temporal database hanya efektif untuk studi kasus yang menggunakan aspek historical data, untuk studi kasus umum, akan lebih baik jika menggunakan relational database.
2. Untuk meningkatkan performansi dalam
temporal database, sebaiknya menggunakan penggabungan antara temporal database dan
relational database dengan cara menggunakan
tabel temporal untuk tabel-tabel yang membutuhkan data historis, sehingga dengan seperti itu, response time masih tetap handal, tetapi masih bisa menggunakan aspek historical
data.
Daftar Pustaka
[1] Chomicky,Jan. Temporal Query Language: a Survey. January 24,1995
[2] Graziotin,Daniel, Steingruber,Thomas. “Computer Shop
Warehouse ER Diagram”.
http://archimedes.inf.unibz.it/teaching2007/ida/team11/files/m l-1/ComputerShopWarehouse-ERdiagram.jpg (Diakses pada tanggal 8 November 2011).
[3] Hawryskiewycz, Igor T., Relational Database Design: an
Introduction.University of Technology, Sydney. 1990.
[4] Jensen,C.S., Introduction to Temporal Database Research. 2001.
[5] Jensen, C.S, Clifford,J., Gadia,S.K., Segev,A.,Snodgrass,R.T.,
A Glosary of Temporal Database Concepts. January,1993
[6] Steiner,Andreas. TimeDB.
http://timeconsult.com/Software/Software.html (Diakses pada tanggal 8 November 2010)
[7] Steiner,Andreas. TimeDB 2.0 Beta 4 Documentation.
Timeconsult. 1999.
[8] Widagdo,Tricya E. Slide Kuliah Basis Data Non Relational,
