NORMALISASI DATA

NORMALISASI
Istilah Normalisasi berasal dari E. F.Codd, salah seorang perintis teknologi basis data.

selain dipakai sebagai metodologi tersendiri untuk menciptakan struktur tabel 9relasi) dalam basis data (dengan tujuan utnuk mengurangi kemubaziran data) , normalisasi terkadang hanya diipakai sebagai perangkat verifikasi terhadap tabel-tabel yang dihasilkan oleh metodologi lain ( misalnya E-R). Normalisasi memberikan panduan yang sangat membantu bagi pengembang untuk mencegah penciptaan struktur tabel yang kurang fleksibel atau mengurangi keflekxibelan.
Kroenke mendefinisikan normalisasi sbagai proses untuk mengubah suatu relasi yang memiliki masalah tertentu ke dalam dua buah relasi atau lebih yang tida memiliki masalah tersebut. Masalah yang dimaksud olej kroenke ini sering disebut dengan istilah anomali.
( Pada beberapa literatur, istilah relasi yang digunakan pada bab ini terkadang digantikan dengan tabel. Istilah relasi digunakan pada bab ini dikarenakan definisi tentang normalisasi memang menggunakan istilah relasi).
Normalisasi database biasanya jarang dilakukan dalam database skala kecil, dan dianggap tidak diperlukan pada penggunaan personal. Namun seiring dengan berkembangnya informasi yang dikandung dalam sebuah database, proses normalisasi akan sangat membantu dalam menghemat ruang yang digunakan oleh setiap tabel di dalamnya, sekaligus mempercepat proses permintaan data. Berikut ini dipaparkan metodologi logis sederhana untuk menormalkan model data dalam sebuah database, diiringi contoh pembuatan database untuk tugas-tugas matakuliah dalam sebuah fakultas (fiktif) dengan atribut yang disederhanakan.
Proses normalisasi model data dapat diringkas sebagai berikut:
1. Temukan entitas-entitas utama dalam model data.
2. Temukan hubungan antara setiap entitas.
3. Tentukan atribut yang dimiliki masing-masing entitas.
Normalisasi model data dilakukan dengan mengikuti langkah-langkah sederhana, mengubahnya agar memenuhi apa yang disebut sebagai bentuk normal pertama, kedua, lalu ketiga secara berturutan.

Langkah-Langkah Normalisasi
2.1. Bentuk Normal Pertama (1NF)

Sebuah model data dikatakan memenuhi bentuk normal pertama apabila setiap atribut yang dimilikinya memiliki satu dan hanya satu nilai. Apabila ada atribut yang memiliki nilai lebih dari satu, atribut tersebut adalah kandidat untuk menjadi entitas tersendiri. Entitas utama untuk database tugas matakuliah tentu saja Tugas Matakuliah. Sebagian atribut yang dimiliki entitas ini tertera dalam Gambar 1.


Atribut Nama Kelas mencantumkan kelas-kelas di mana tugas tersebut berlaku. Apabila pendaftar untuk sebuah matakuliah melebihi kapasitas ruangan yang dimiliki fakultas, kebijakan yang umum diambil Kepala Program Studi adalah membagi kegiatan perkuliahan untuk matakuliah tersebut menjadi beberapa kelas. Karenanya atribut ini rentan memiliki nilai jamak, dan lebih sesuai menjadi entitas baru atau atribut dari entitas lain. Untuk sementara kita membuat entitas baru, Kelas, dimana sebagian atributnya berasal dari Tugas Matakuliah yang secara logis lebih sesuai menjadi atribut entitas ini. Sementara itu, hampir semua atribut entitas Tugas Matakuliah selain Nama Kelas memiliki nilai tunggal (dengan asumsi setiap matakuliah diampu oleh satu dosen saja).


2.1.a Relasi Antar-Entitas dan Identifier

Masalah yang kita hadapi sekarang adalah menghubungkan Tugas Matakuliah dengan Kelas. Satu tugas dapat diberikan pada beberapa kelas yang berbeda; dalam terminologi pemodelan data, ini berarti antara entitas Tugas Matakuliah dan entitas Kelas terdapat relasi 1:N (atau 1-N) untuk nilai N lebih dari satu. Cara paling intuitif untuk menghubungkan kedua entitas tersebut adalah menyertakan identitas satu entitas sebagai atribut entitas lain. Identitas sebuah entitas haruslah unik untuk menghindarkan ambiguitas saat akan merujuk pada satu objek khusus dari entitas tersebut. Entitas Tugas Matakuliah akan menggunakan pengidentifikasi arbitrer berupa angka yang berbeda antara satu objek Tugas Matakuliah dengan objek Tugas Matakuliah lain. Entitas Kelas dapat diidentifikasi dengan matakuliah dan kode kelas yang bersangkutan, sehingga kita cukup menambahkan atribut pengidentifikasi (identifier) dalam kedua entitas. Entitas ini beserta semua atribut baru dan hubungannya dengan Tugas Matakuliah diperlihatkan dalam Gambar 2, dengan menggunakan notasi relasi crows foot (dengan simbol “kaki gagak” menunjuk pada entitas jamak). Sejauh ini tidak ada atribut entitas yang memiliki nilai lebih dari satu, sehingga rasanya cukup aman mengatakan bahwa model ini memenuhi bentuk normal pertama.



2.2. Bentuk Normal Kedua (2NF)

Sebuah model data dikatakan memenuhi bentuk normal kedua apabila ia memenuhi bentuk normal pertama dan setiap atribut non-identifier sebuah entitas bergantung sepenuhnya hanya pada semua identifier entitas tersebut. Apabila kita perhatikan kembali model data yang telah kita hasilkan di atas, segera terlihat bahwa atribut dari entitas Kelas tidak sepenuhnya bergantung pada identitas unik Kelas tersebut. Seorang dosen akan tetap ada meskipun kelas matakuliah yang ia ampu sudah tidak ada lagi. Dalam hal ini, dosen adalah entitas tersendiri (yang nantinya dapat dilekatkan pada entitas Fakultas atau Universitas bilamana kedua entitas tersebut dirasa perlu ada, tergantung pada kebutuhan pemodelan data kita).


2.2.a Sekali Lagi, Tentang Identifier

Dalam dunia nyata, anggapan yang umum adalah seseorang (“individu”) dapat diidentifikasi secara unik dengan namanya. Tentu saja anggapan ini tidak sepenuhnya benar, karena bisa saja sebuah nama (bahkan satu rangkaian nama lengkap) dimiliki oleh lebih dari satu orang;pemodelan data yang melibatkan informasi tentang individu jarang menggunakan nama individu tersebut sebagai satu-satunya pengidentifikasi. Implementasi RDBMS tertentu juga akan lebih cepat memproses query atas suatu tabel apabila tabel tersebut diindeks oleh nilai integer unik daripada bila menggunakan indeks karakter (rangkaian karakter masih harus diumpankan ke fungsi hash agar dapat digunakan sebagai indeks tabel, sementara untuk integer unik tidak harus).
Karena beberapa alasan tersebut, entitas Dosen pada model data kita akan menggunakan pengidentifikasi arbitrer berupa Nomor Induk Pegawai sebagaimana diperlihatkan dalam Gambar 3. Dalam notasi crows foot, relasi non-identifying digambarkan dengan garis putusputus
atau tersamar.




Setelah atribut-atribut dari semua entitas dalam sebuah model data hanya bergantung pada seluruh pengidentifika


2.3. Bentuk Normal Ketiga (3NF)

Sebuah model data dikatakan memenuhi bentuk normal ketiga apabila ia memenuhi bentuk normal kedua dan tidak ada satupun atribut non-identifying (bukan pengidentifikasi unik) yang bergantung pada atribut non-identifying lain. Apabila ada, pisahkan salah satu atribut tersebut menjadi entitas baru, dan atribut yang bergantung padanya menjadi atribut entitas baru tersebut. Dalam model data sederhana yang kita gunakan di sini, tidak ada satupun atribut non-identifying (seperti Deskripsi Tugas Matakuliah, atau Nama Dosen) yang bergantung pada atribut nonidentifying lain. Namun demi adanya contoh, kita misalkan entitas Dosen memiliki atribut informasi Alamat Rumah dan Nomor Telepon Rumah. Keduanya tidak dapat secara unik mengidentifikasi objek tertentu dari entitas Dosen, namun keduanya saling bergantung. Sebagaimana dalam dua langkah normalisasi sebelumnya, jenis kebergantungan seperti ini dapat dihilangkan dengan membuat entitas baru lagi (yang tidak akan diciptakan karena tiga entitas sudah cukup banyak untuk satu artikel). Model terakhir yang kita dapat ini telah memenuhi bentuk normal ketiga (third normal form) dan siap dikonversi menjadi tabel. Namun sebelumnya, kita perlu membahas berbagai jenis relasi yang kerap ditemui dalam pemodelan data, termasuk yang kita temui dalam contoh model data kali ini.

Jenis-jenis Relasi Antar-Entitas

1. Relasi 1-1. Relasi ini jarang ditemui dalam model data yang benar, sehingga saat Anda menemukannya, kemungkinan besar hal itu berarti masih ada yang belum sempurna dari model data Anda; relasi 1-1 sering berarti kedua entitas tersebut sebenarnya adalah kesatuan, satu entitas tunggal. Kemungkinan lain adalah relasi 1-1 ini adalah relasi turunan atau relasi non-identifying (identitas unik satu entitas tidak bergantung pada identitas unik entitas lain) namun jenis relasi kedua ini jarang ditemui.

2. Relasi 1-N. Relasi ini yang paling umum ditemui dalam model data.

3. Relasi M-N. Relasi ini juga sering ditemui dalam model data, dan sering pula dapat dinormalkan lebih jauh lagi. Langkah yang dapat ditempuh untuk menormalkan relasi
M-N:

a. Buat sebuah entitas baru sebagai penghubung antara kedua entitas dengan relasi MN tersebut. Entitas penghubung ini akan memiliki hubungan 1-M dengan masingmasing entitas awal. Identifier entitas penghubung dapat dibuat tersendiri, atau dengan cara mewarisi identifier kedua entitas awal dan membuat keduanya identifier unik entitas penghubung ini. Sering kali akan ada atribut lain yang dimiliki oleh entitas penghubung tersebut. Entitas Kelas dalam contoh model data kita dapat menjadi contoh entitas penghubung. Apabila tidak ada entitas penghubung yang dapat diciptakan, relasi M-N tetap harus diubah untuk menghindari kesulitan dalam konversi model data menjadi skema database fisik.

Menterjemahkan Model Data

Setelah sebuah model data dinormalisasikan dan siap diubah menjadi database fisik, ada
beberapa langkah penterjemahan yang harus dilakukan:
1. Setiap entitas menjadi tabel tersendiri.
2. Setiap atribut menjadi kolom-kolom tabel tersebut, dengan tipe data yang sesuai.
3. Identifier entitas tersebut menjadi kolom ID yang tidak boleh kosong (NOT NULL) dan
berisi indeks yang unik. ID unik ini dalam database dinamakan primary key.
4. Relasi diterjemahkan menjadi foreign key.
Skema fisik model data yang dihasilkan tampak dalam Gambar 4. Perhatikan penghilangan
spasi, penentuan tipe data dan penyeragaman kapitalisasi untuk portabilitas skema untuk
digunakan dalam berbagai implementasi RDBMS yang mungkin berbeda dalam casesensitivity.





Dan perintah SQL untuk menciptakan ketiga tabel tersebut adalah:
CREATE TABLE dosen (
nip INTEGER NOT NULL AUTO_INCREMENT,
nama_lengkap VARCHAR(20) NOT NULL,
nomor_kontak VARCHAR(20) NULL,
PRIMARY KEY(nip)
)
TYPE=InnoDB;
CREATE TABLE kelas (
kode INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nama_matakuliah INTEGER UNSIGNED NOT NULL,
id_tugas_matakuliah INTEGER NOT NULL,
id_dosen INTEGER NOT NULL,
ruang_kuliah VARCHAR(5) NULL,
PRIMARY KEY(kode, nama_matakuliah, id_tugas_matakuliah),
INDEX kelas_FKIndex1(id_dosen),
INDEX kelas_FKIndex2(id_tugas_matakuliah)
)
TYPE=InnoDB;
CREATE TABLE tugas_matakuliah (
id INTEGER NOT NULL,
deskripsi TEXT NULL,
batas_penyerahan DATETIME NULL,
PRIMARY KEY(id)
)
TYPE=InnoDB;
Script SQL di atas menggunakan tipe data dan konfigurasi tabel yang didukung oleh MySQL. Deklarasi TYPE=InnoDB untuk setiap tabel adalah agar MySQL menggunakan InnoDB yang mendukung penggunaan foreign key. Tanpa deklarasi tersebut MySQL secara default akan menggunakan mesin penyimpan MyISAM yang tidak dapat mendukung foreign key.


4.1. Foreign Key

Beberapa catatan khusus mengenai penterjemahan relasi menjadi foreign key:

1. Relasi 1-1 diterjemahkan menjadi “identifier salah satu tabel menjadi foreign key dalam tabel lain”. Keputusan mengenai tabel mana yang harus menerima identifier tabel lain dapat diambil sesuai keinginan, dan secara teori tidak begitu berpengaruh. Namun,
seringkali pertimbangan praktis yang akan menentukan tabel mana yang akan berisi
foreign key.

2. Khusus untuk penggunaan MySQL sebagai penyimpan database: sampai MySQL versi 5.0 hanya storage engine InnoDB yang mendukung penggunaan foreign key. Mesin penyimpanan lain yang digunakan MySQL versi 5.0 atau dibawahnya (seperti MyISAM atau BDB) tidak mendukung konfigurasi FOREIGN KEY dalam perintah SQL CREATE TABLE, dan akan mengabaikannya apabila ia ditemui.

Contoh Penggunaan Database
Ternormalisasi

Untuk model data non-trivial, database ternormalisasi hampir selalu berisi lebih dari satu tabel, sehingga demi kemudahan pengelolaan, biasanya satu database hanya berisi tabel-tabel yang terkait dalam satu model data saja. Di bawah ini terdapat contoh query SQL untuk database ternormalisasi untuk membedakan dengan model data yang hanya menggunakan satu tabel.
INSERT INTO dosen(nama_lengkap,nip) VALUES('Jusuf Kalla',127001);
INSERT INTO kelas(id_dosen, kode) VALUES(127001, 1);
INSERT INTO kelas(id_dosen, kode) VALUES(127001, 2);
Perintah INSERT di atas akan menambah data dosen baru dan dua kelas yang diampu beliau.
INSERT INTO tugas_matakuliah(id, deskripsi,batas_penyerahan)
VALUES(102,
'Implementasikan sebuah compiler untuk bahasa Small-C,
lengkap dengan detail grammar yang digunakan.
Compiler tersebut harus menghasilkan kode assembler
8086
yang dapat dikompilasi oleh Turbo Assembler atau
NASM.',
'2006-12-01');
UPDATE kelas,dosen SET id_tugas_matakuliah=102
WHERE kelas.id_dosen=dosen.nip AND
dosen.nama_lengkap='Jusuf Kalla';
Perintah INSERT dan UPDATE di atas menambah data tugas baru dari dosen tertentu dan memperbarui data untuk setiap kelas yang diampu dosen tersebut.
SELECT t.deskripsi, t.batas_penyerahan
FROM tugas_matakuliah t, kelas k, dosen d
WHERE k.id_tugas_matakuliah=t.id AND
k.id_dosen=d.nip AND
d.nama_lengkap='Jusuf Kalla';
Perintah SELECT di atas akan menampilkan informasi tentang deskripsi sebuah tugas yang
diberikan pada kelas-kelas matakuliah yang diampu oleh dosen tersebut, ditambah dengan
informasi tanggal penyerahan tugas terakhir.



Query
Query adalah pertanyaan atau permintaan informasi tertentu dari sebuah basisdata yang ditulis dalam format tertentu. Terdapat tiga metode utama untuk membuat query:
1. dengan memilih parameter yang telah disediakan pada menu. Metode ini paling mudah digunakan namun paling tidak fleksibel karena pengguna hanya dapat menggunakan pilihan parameter yang terbatas.

2. query by example (QBE) adalah metode query yang disediakan sistem dalam bentuk record kosong dan pengguna dapat menentukan field dan nilai tertentu yang akan digunakan dalam query.

3. bahasa query (query language) adalah bahasa khusus yang digunakan untuk melakukan query pada sebuah basisdata. Metode ini paling rumit tetapi paling fleksibel.

Query dapat digunakan pada beberapa keadaan. Kebanyakan aplikasi nyatanya adalah permintaan-permintaan secara langsung dari user yang memerlukan informasi tentang bentuk maupun isi dari database. Apabila permintaan user terbatas pada sekumpulan query-query standar, maka query-query tersebut dapat dioptimisasi secara manual oleh pemrograman prosedur-prosedur pencarian gabungan dan membatasi input dari user pada sebuah ukuran menu. Tetapi bagaimanapun juga, sebuah sistem optimisasi query otomatis menjadi penting apabila query-query khusus ditanyakan dengan menggunakan bahasa query yang digunakan secara umum seperti SQL.
Aplikasi yang kedua dari query terjadi pada transaksi-transaksi yang mengubah data yang disimpan berdasarkan nilainya saat itu. Pada akhirnya, query seperti ekspresi-ekspresi dapat digunakan secara internal dalam sebuah DBMS, sebagai contoh adalah untuk mengecek kebenaran akses dan menyamakan kebenaran akses-akses yang terjadi.
Membicarakan tentang query, sangat erat hubungannya dengan cara penulisan query tersebut ke dalam sebuah bentuk bahasa yang mudah dimengerti. Pada umumnya, bahasa query yang digunakan untuk mengekspresikan sebuah pernyataan dari query adalah SQL (Structure Query Language).
SQL adalah sebuah bahasa database yang luas yang memiliki statement-statement (pernyataan) untuk definisi data, query dan update data (memperbaharui data). SQL mempunyai satu statement dasar untuk mendapatkan kembali informasi dari sebuah database. Statement dasar dari SQL adalah SELECT.
Bentuk dasar dari statement SELECT biasa disebut dengan blok select from where yang terbentuk dari tiga macam klausa yaitu SELECT, FROM dan WHERE yang mempunyai bentuk sebagai berikut :
SELECT
FROM
WHERE
Dimana adalah sebuah daftar dari nama-nama attribute yang nilai-nilainya didapatkan oleh query. Sedangkan adalah sebuah daftar dari nama-nama relasi yang diperlukan oleh proses sebuah query. adalah sebuah kondisi ekspresi boolean yang mengidentifikasikan tuple-tuple yang akan dikembalikan oleh query.

Hubungan Database Dengan Pemrosesan Query
Database adalah kumpulan dari data-data yang berhubungan satu sama lainnya yang digunakan untuk pencarian suatu data tertentu pada saat SQL query dijalankan. Sebuah database dirancang, dibuat dan ditempati oleh data dengan tujuan tertentu. Di dalam sistem database relasional, tabel-tabel dari database saling berhubungan satu sama lainnya. Dan sebuah tabel database akan selalu memiliki attribute names (nama-nama attribute), relation names (nama-nama relasi), dan tuples (record-record).
Attribute digunakan untuk mengidentifikasikan sebuah nama yang diikutsertakan dalam relasi dan menspesifikasikan domain (tipe data sederhana yang menentukan sebuah pemisahan data). Sedangkan tuples adalah kumpulan dari record-record di dalam sebuah database. Relation name mendefinisikan attribute-attribute yang diperlukan dalam predikat dan mendefinisikan arti dari predikat tersebut.

Optimisasi Query
Optimisasi Query adalah suatu proses untuk menganalisa query untuk menentukan sumber-sumber apa saja yang digunakan oleh query tersebut dan apakah penggunaan dari sumber tersebut dapat dikurangi tanpa merubah output. Atau bisa juga dikatakan bahwa optimisasi query adalah sebuah prosedur untuk meningkatkan strategi evaluasi dari suatu query untuk membuat evaluasi tersebut menjadi lebih efektif. Optimisasi query mencakup beberapa teknik seperti transformasi query ke dalam bentuk logika yang sama, memilih jalan akses yang optimal dan mengoptimumkan penyimpanan data.
Optimisasi query merupakan bagian dasar dari sebuah sistem database dan juga merupakan suatu proses untuk menghasilkan rencana akses yang efisien dari sebuah query di dalam sebuah database. Secara tidak langsung, sebuah rencana akses merupakan sebuah strategi yang nantinya akan dijalankan untuk sebuah query, untuk mendapatkan kembali operasi-operasi yang apabila dijalankan akan menghasilkan database record query. Ada tiga aspek dasar yang ditetapkan dan mempengaruhi optimisasi query, yaitu : search space, cost model dan search strategy.
Search space adalah sekumpulan rencana-rencana akses yang sama secara logika yang dapat digunakan untuk mengevaluasi sebuah query. Semua rencana-rencana dalam search space query mengembalikan hasil yang sama biarpun beberapa rencana lebih efisien dibandingkan dengan rencana yang lainnya.
Cost model menandakan sebuah harga untuk tiap rencana dalam search space. Harga dari rencana tersebut adalah sebuah perkiraan dari sumber-sumber yang digunakan pada saat rencana dijalankan, dimana harga yang lebih rendah, merupakan yang terbaik dari rencana-rencana yang ada.
Search strategy adalah sebuah perincian dari rencana-rencana mana dalam search space yang akan diperiksa. Apabila search space-nya kecil, maka strategi yang dapat diteruskan adalah menghitung dan mengevaluasi setiap rencana. Meskipun kebanyakan search space bahkan untuk query-query yang sederhana adalah sangat besar, akan tetapi query optimizer selalu memerlukan aturan heuristik untuk mengontrol nomer dari rencana-rencana yang akan diperiksa.

Sejarah Singkat Optimisasi Query
Optimisasi query lahir sejak sebelum tahun 1970. Pada saat itu yang dikenal dengan jaman kegelapan (dark age), optimisasi query masih dilakukan secara manual oleh manusia. Selain itu, pada jaman tersebut database relasional juga belum dikenal sehingga diperlukan seseorang yang benar-benar ahli dalam database untuk melakukan optimisasi query. Jadi pada jaman kegelapan hingga tahun 1970-an, optimisasi query masih dilakukan oleh manusia dan masih menggunakan cara yang benar-benar kuno.
Seiring dengan perkembangan jaman di mana teknologi menjadi semakin maju, maka sekitar pertengahan tahun 1970-an sampai pada pertengahan tahun 1980-an optimisasi query tidak lagi dilakukan secara manual, tetapi dilakukan oleh suatu sistem yang dikenal dengan sistem R yang kemudian menjadi berkembang pada optimisasi perintah JOIN, sekumpulan tahapan untuk optimisasi query selanjutnya. Hingga saat ini, optimisasi query terus berkembang bersamaan dengan bermunculannya teknik-teknik baru yang digunakan dalam proses optimisasi query meskipun pada dasarnya hanya ada dua macam teknik utama yang biasanya digunakan dalam mengoptimisasi sebuah query. Bisa dikatakan bahwa optimisasi query merupakan tulang punggung dari sebuah sistem karena ketepatgunaan suatu sistem sangat tergantung dari optimizernya.
Hampir semua DBMS menggunakan sistem optimisasi query untuk mengurangi waktu eksekusi query sehingga kerja sistem dapat dioptimalkan dan penggunaan sumber-sumber dapat diminimumkan. Selain itu, akes dari disk yang sangat lambat dibandingkan dengan akses memory membuat optimisasi query menjadi semakin penting.
Tujuan Optimisasi Query
Prinsip ekonomi yang diperlukan untuk sebuah query adalah mengoptimisasi prosedur-prosedur, mencoba untuk memaksimumkan output dari sejumlah sumber-sumber yang diberikan ataupun untuk meminimumkan penggunaan sumber untuk memberikan output.
Tujuan dari optimisasi query adalah berbeda-beda untuk setiap sistem. Ada yang menggunakan optimisasi query untuk meminimumkan waktu proses sedangkan pada situasi lain bisa juga optimisasi query diperlukan untuk waktu respon, meminimumkan I/O dan meminimumkan penggunaan memory. Tetapi pada dasarnya, tujuan dari optimisasi query adalah menemukan jalan akses yang termurah untuk meminimumkan total waktu pada saat proses sebuah query. Untuk mencapai tujuan tersebut, maka diperlukan optimizer untuk melakukan analisa query dan untuk melakukan pencarian jalan akses.
Nama Field Tipe
NIM Integer
Nama Varchar(30)
Alamat Varchar (80)

Tabel 1. Tabel Mahasiswa

Nama Field Tipe
NIM Integer
MataKuliah Varchar(30)

Tabel 2. Tabel Kuliah

Untuk memasukkan data ke tabel-tabel tersebut diatas, dibuat program pengisi data dengan menggunakan delphi 6.

Untuk melihat kinerja system dengan 2 model query yaitu cross product dan subset query, dibuat query berikut:

a. Query dengan model cross product diwakili oleh query berikut ini:
SELECT M.NIM, M.Nama, M.Alamat
FROM Mahasiswa M, Kuliah K
WHERE M.NIM = K.NIM

b. Query dengan model subset query diwakili oleh query berikut ini:
SELECT NIM, Nama, Alamat
FROM Mahasiswa
WHERE NIM in ( SELECT NIM FROM Kuliah)

Kedua query tersebut akan menghasilkan informasi yang sama, yaitu menampilkan data NIM, Nama dan Alamat dari tabel Mahasiswa yang NIM-nya terdapat dalam table Kuliah.

Untuk menyimpan hasil percobaan query data, dibuat tabel waktu dengan struktur sebagai berikut:

Tabel Waktu

Nama Field Tipe Keterangan
Jml Integer Jumlah record hasil query
Q1 Integer Waktu yang diperlukan untuk query dengan menggunakan cross product
Q2 Integer Waktu yang diperlukan untuk query dengan menggunakan subset query

Tabel 3. Tabel Waktu

Untuk menghitung waktu yang diperlukan untuk mengakses data, dibuat sebuah program aplikasi dengan menggunakan Delphi.

Bahasa Query

Bahasa query (query language) adalah bahasa khusus yang digunakan untuk melakukan query pada basis data. Contoh penggunaan bahasa query adalah: SELECT ALL WHERE kota=”Yogyakarta” AND umur<40. Query tersebut meminta semua record dari basis data yang sedang digunakan (misalkan basisdata konsumen) yang bertempat tinggal di Yogyakarta dan berumur lebih dari 40 tahun (kota dan umur adalah nama field yang telah didefinisikan). Standar bahasa query yang banyak digunakan adalah SQL (structured query language). Metode ini paling rumit tetapi paling fleksibel dibandingkan metode query yang lain, query dengan parameter yang telah tersedia dan query by example.

Tweet

Jangan sampai ketinggalan postingan-postingan terbaik dari Dr.RK. Berlangganan melalui email sekarang juga:

Atau sobat juga bisa follow Dr.RK dengan mengklik tombol di bawah ini:

Artikel keren lainnya:

Ditulis oleh RAHMAD'S WEBSITE pada tanggal Tuesday 24 March 2009