Oracle SQL & PL/SQL - 8. Data Modelling dan Database Design

Posted by admin

September 23, 2008 287 views

Ketika kita menciptakan database, kita perlu secara hati-hati mempertimbangkan komponen-komponennya. Sebagai petunjuk berkaitan dengan desain, kita dapat mengikuti konsep-konsep yang dibahas pada pembahasan kali ini.

System Development Cycle
Database Design
Challenge to Managing Data

8.1. System Development Cycle

Mulai dari konsep sampai produksi, kita membangun database dengan menggunakan system development cycle. Siklus ini terdiri dari beberapa tahapan development.

Pendekatan top-down dan sistematis untuk database development ini mentransformasikan kebutuhan-kebutuhan informasi bisnis ke dalam operational database.

8.1.1. Tahapan Development

Strategi dan Analisis

Mempelajari dan menganalisa kebutuhan bisnis. Mewawancarai user dan manager untuk mengidentifikasi kebutuhan-kebutuhan informasi. Menggabungkan perusahaan dan misi aplikasi sebagai spesifikasi system di masa yang akan datang.
Membangun model dari sistem. Mentransfer cerita yang telah dibangun pada fase strategi dan analisa ke dalam representasi grafis dari kebutuhan-kebutuhan informasi bisnis dan aturan-aturannya. Mengkonfirmasi dan menyaring model dengan para analis dan ahli.

Desain

Mendesain database. Entity relational model memetakan entities ke dalam tables, attributes ke dalam columns, relationships ke dalam foreign keys, dan business rules ke dalam contraints.

Pembangunan dan Dokumentasi

Membangun prototipe sistem. Menulis dan mengeksekusi perintah-perintah untuk menciptakan tables dan objek-objek pendukungnya untuk database.
Menyusun dokumentasi user, help screen text, dan manual operasi untuk mendukung penggunaan dan pengoperasian sistem.

Transisi

Menyaring prototipe. Memindahkan aplikasi ke dalam produksi dengan test terhadap penerimaan user, konversi terhadap data-data yang telah ada, dan operasi paralel.
Melakukan perubahan-perubahan yang diperlukan

Produksi

Menerapkan sistem kepada user. Mengoperasikan production system. Mengawasi performa, dan meningkatkan dan menyaring sistem.

8.2. Database Design

Mendesain sistem database relasional melibatkan proses konversi model ke dalam representasi perangkat lunak yang dapat bekerja. Entities (atau objects) yang dirasakan oleh user ditransformasikan ke dalam table-table di dalam database. Selama proses desain, tujuan kita adalah mendesain reliable, high-performance systems menggunakan segala hal yang dihasilkan oleh segala usaha yang dilakukan pada fase analisis. Faktor-faktor kunci utama berikut ini menjelaskan secara detil mengapa kita harus mendesain kedua hal tersebut.

Performa

Desain awal dari sistem memiliki pengaruh yang sangat besar terhadap performa akhir. Secara umum pengaruhnya jauh lebih besar dibandingkan tuning perbaikan ketika sistem telah berjalan.

Aplikasi Terintegrasi
Sistem aplikasi biasanya dibangun oleh tim developer. Tanpa beberapa spesifikasi desain bagaimana sistem tersebut bekerja, setiap developer akan membangun dengan gaya mereka sendiri. Desain yang baik tidak hanya berguna untuk menaikkan tampilan dan rasanya, tetapi juga menyakinkan bahwa setiap komponen yang menghasilkan sistem aplikasi saling terintegrasi satu dengan yang lain.

Integrasi dengan Sistem Lain

Seringkali terdapat kebutuhan bahwa sistem baru diintegrasikan dengan sistem-sistem yang telah ada, atau bahkan dengan sistem-sistem lain yang baru saja dibangun. Desain yang baik meningkatkan keuntungan-keuntungan integrasi yang telah dijelaskan diatas kedalam sistem secara umum.

Dokumentasi dan Komunikasi

Bagian utama dari pekerjaan seorang desainer adalah mengkomunikasikan keputusan-keputusan desain dengan yang lain. Pada akhirnya, keputusan-keputusan ini perlu didokumentasikan.

Skalabilitas

Tangkal isu-isu performa pada saat desain dibandingkan pada saat produksi. Sebagai contoh, membangun sistem didalam lingkungan yang kecil dan terkontrol tanpa mengujinya pada situasi sesungguhnya atau pada kumpulan data yang besar, merupakan faktor-faktor yang dapat mengungkap cacat-cacat pada desain.

Hindari Menemukan Kembali Roda

Banyak masalah-masalah yang mungkin akan anda hadapi telah ditemukan oleh seseorang sebelum kita. Gunakan desain yang telah sukses sebelumnya jika memungkinkan.

8.2.1. Data Model

Model merupakan landasan dari desain. Para insinyur membangun model mobil sebelum memproduksinya dan membuatnya bekerja pada setiap detilnya. Dengan cara yang sama, desainer sistem mengembangkan model untuk mengeksplorasi ide dan meningkatkan pengertian terhadap desain database.

8.2.1.1. Tujuan Penggunaan Model

Model membantu mengkomunikasikan konsep-konsep yang ada pada pikiran manusia. Model dapat digunakan untuk tujuan-tujuan berikut:

Mengkomunikasikan
Menggolongkan
Menggambarkan
Menetapkan
Meneliti
Menyusun
Menganalisa
Meniru

Sasarannya adalah menghasilkan model yang tepat bagi banyak user, dapat dimengerti oleh user, tetapi mengandung detil-detil yang cukup bagi developer untuk membangun suatu sistem database.

8.3. Entity Relationship Modelling

Entity relationship model berasal dari spesifikasi atau cerita bisnis. Model ini merupakan representasi grafis dari kebutuhan informasi bisnis dan aturan-aturannya.

Entity relationship model memisahkan informasi yang dibutuhkan oleh bisnis dari aktifitas yang dilakukan oleh bisnis. Meskipun bisnis dapat mengubah aktifitasnya, tipe informasinya cenderung terus tetap. Oleh karena itu, struktur dari data juga cenderung terus tetap.

8.3.1. Keuntungan Entity Relationship Model

Mendokumentasikan kebutuhan-kebutuhan informasi perusahaan dengan format yang jelas dan tepat
Menyediakan peta gambar yang mudah dimengerti dalam rangka mendesain database
Mengembangkan dan menyaring model secara mudah
Menyediakan gambaran yang jelas mengenai jangkauan kebutuhan-kebutuhan informasi
Menawarkan kerangka kerja yang efektif untuk mengintegrasikan beberapa aplikasi, pengembangan proyek, dan pembelian paket-paket aplikasi

8.3.2. Komponen-komponen Kunci

Entity Relationship Model tersusun dari entity, attribute, dan relationship

Entity
- Sesuatu yang penting mengenai kebutuhan-kebutuhan informasi dmana yang perlu diketahui. Entity merepresentasikan sesuatu yang penting dari suatu sistem bisnis, atau menjelaskan kategori atau kumpulan data yang saling terkait. Contohnya adalah customer, order, dan employee. Untuk merepresentasikan entity ke dalam model, kita dapat menggunakan ketentuan-ketentuan berikut:
  - Kotak dengan dimensi tertentu
  - Nama entity tunggal dan unik
  - Nama entity dalam huruf kapital
  - Nama-nama sinonim opsional dalam huruf kapital diapit tanda “()”
Attribute
- Sesuatu yang menjelaskan dan mensyaratkan sebuah entity. Attribute menjelaskan entity dan memegang informasi spesifik yang harus diketahui tentang sebuah entity. Sebagai contoh, untuk entity customer, atribute-nya dapat berupa customer number, name, phone number, dan address. Jika sebuah entity tidak memiliki attribute yang harus diketahui dari sudut pandang bisnis, maka ia tidak berada dalam jangkauan kebutuhan sistem, dan sebaiknya ia tidak muncul di dalam model. Setiap attribute dapat berstatus wajib (mandatory) maupun opsional. Keadaan ini disebut denan opsionalitas (optionality). Untuk merepresentasikan attribute di dalam model, kita dapat menggunakan ketentuan-ketentuan berikut:
  - Gunakan nama-nama tunggal dalam huruf kecil
  - Kenali attribute wajib, atau nilai yang harus diketahui dengan menggunakan tanda “*”
  - Kenali attribute opsional (tidak wajib) dengan menggunakan tanda “o”
Relationship
- Hubungan antara entity yang memperlihatkan opsionalitas atau derajat. Setiap entity harus memiliki relationship yang merepresentasikan kebutuhan-kebutuhan informasi dan aturan-aturan bisnis. Relationship merupakan hubungan dua-arah diantara dua entity, atau diantara entity dengan dirinya sendiri. Ketika sebuah entity memiliki hubungan relasi dengan dirinya sendiri, maka disebut recursive.
- Sintaks Relationship
  - Setiap source entity [may be | must be] relationship name [one and only one | one or more ] destination entity
  - Catatan: Aturan tersebut dibaca searah jarum jam
- Aturan Diagram Relationship
  - Dashed line (—)
    - Elemen opsional yang mengindikasikan “may be”
  - Solid line (-)
    - Elemen wajib yang mengindikasikan “must be”
  - Crow’s foot (kaki burung gagak)
    - Elemen derajat yang mengindikasikan “one or more”
  - Single line (-)
    - Elemen derajat yang mengindikasikan “one and only one”
- Recursive Relationship
  - Relationship di antara entity dan dirinya sendiri disebut recursive relationship. Direpresentasikan oleh “pig’s ear” (telinga babi).
- Tipe-tipe Relationship
  - One-to-one
    - Derajat satu dan hanya satu pada kedua arah. Tipe ini jarang, dan mungkin benar-benar merupakan entity yang sama, atau attribute dari entity. Contoh: Relasi antara suami dan istri.
  - Many-to-one
    - Derajat satu atau lebih pada satu arah dan derajat satu dan hanya satu pada arah lainnya. Tipe ini sangat umum. Contoh: Relasi antara penumpang dan pesawat.
  - Many-to-many
    - Derajat satu atau lebih pada kedua arah. Tipe ini sangat umum. Contoh: Relasi antara karyawan dan keahlian.
UID (Unique Identifier)
- Unique Identifier merupakan suatu kombinasi dari attributes atau relationship, atau keduanya, yang berfungsi sebagai pembeda penampakan dari setiap entity. Penampakan dari setiap entity harus secara unik dapat diidentifikasi.
  - Kenali setiap attribute yang menjadi bagian dari UID dengan menggunakan simbol angka (#)
  - Kenali UID kedua dengan menggunakan simbol angka yang diapit tanda petik tunggal (’#')
- Unique Identifier Melalui Relationship
  Sebuah entity dapat secara unik diidentifikasi melalui sebuah relationship. Gunakan UID bar untuk mengindikasikan bahwa sebuah relationship merupakan bagian dari unique identifier entity. Relationship yang termasuk dalam UID harus memiliki sifat mandatory dan hanya satu dalam hubungan yang berpartisipasi di dalam UID.
  - Contoh ketika kita melakukan pesanan pembelian, kita memiliki order number dan item dengan unique line item number. Tetapi ketika pesanan pembelian lainnya dilakukan, item number tersebut tidak lagi unik. Maka dari itu, item tersebut secara unik diidentifikasi oleh attribute number-nya dan order number tertentu dimana item tersebut berelasi.
  Order number, Item number, Product number
  100, 1, 209
  100, 2, 399
  100, 3, 876
  101, 1, 630
  101, 2, 297

8.4. Normalisasi

Sebelum menciptakan desain database, kita harus meminimalkan masalah-masalah redundansi data dengan melakukan normalisasi terhadap data model. Kita perlu memodifikasi data model untuk mendukung kebutuhan fungsional yang berbeda dan memodifikasi desain database dengan melakukan normalisasi penyimpanan data sebelum kita menciptakan database.

8.4.1. Keuntungan-keuntungan Normalisasi

Meminimalkan redundansi data
Mengurangi permasalahan-permasalahan integritas
Mengidentifikasi entity, relationship, serta table yang terlewatkan

8.4.2. Aturan Normalisasi

First normal form (1NF)
- Seluruh attribute haruslah bernilai tunggal dan tidak berulang
Second normal form (2NF)
- Setiap attribute harus bergantung kepada seluruh unique identifier (UID) entity-nya
Third normal form (3NF)
- Tidak boleh terdapat non-UID yang bergantung kepada non-UID lainnya

8.5. Integrity Constraint dan Key

Pastikan bahwa user hanya melakukan operasi-operasi yang mengijinkan database berada pada keadaan yang konsisten dengan menerapkan integrity constraint. Seluruh data integrity constraint sebaiknya diterapkan oleh database server atau software aplikasi. Key (kunci) dapat disamakan dengan integrity constraint. Tiga tipe key adalah primary key, unique key, dan foreign key.

8.5.1. Tipe-tipe Integrity Constraint

Entity
- Tidak boleh terdapat bagian dari primary key yang NULL, dan nilainya haruslah unique (berbeda antara satu dengan lainnya)
Referential
- Nilai-nilai foreign key haruslah sesuai dengan nilai primary key yang diacunya, atau NULL
Column
- Nilai-nilai pada column haruslah sesuai dengan tipe data yang telah didefinisikan untuk column tersebut
User-defined
- Nilai-nilai harus tunduk kepada aturan bisnis (business rules)

8.5.2. Tipe-tipe Key

Primary Key
Setiap row (record) pada table secara unique diidentifikasi oleh column atau kumpulan column yang disebut primary key (PK). Primary key didefinisikan untuk tidak mengijinkan adanya nilai duplikat dan tidak dapat bernilai NULL.
Primary key yang terdiri dari beberapa column disebut dengan composite primary key atau compound primary key. Column-column dari composite primary key haruslah unique secara kombinasi, meskipun nilainya secara individual dapat memiliki duplikat. Tidak ada bagian dari primary key yang boleh memiliki nilai NULL.
Candidate Key
Sebuah table dapat memiliki beberapa candidate keys. Candidate key merupakan column atau kombinasi dari column yang dapat berfungsi sebagai primary key untuk table.
Pilihlah satu candidate key untuk dijadikan sebagai primary key untuk table. Candidate key lainnya akan menjadi alternate key atau unique key. Mereka haruslah UNIQUE dan NOT NULL.
Foreign Key
Foreign key (FK) merupakan column atau kombinasi column dalam suatu table yang mengacu kepada primary key atau unique key pada table yang sama atau pada table lainnya. Foreign key berbasiskan pada nilai-nilai data dan murni logical, dan bukanlah physical pointer. Nilai dari sebuah foreign key haruslah sesuai dengan primary key atau unique key yang diacunya, atau bisa juga NULL. Jika suatu foreign key merupakan bagian dari primary key, ia tidak dapat berisi nilai null karena tidak boleh ada bagian dari primary key yang bernilai NULL. Contoh: Pada table ITEM, column ORD_ID tidak dapat berisi nilai null karena ia merupakan bagian dari primary key.

8.6. Mendesain Database

Tahapan desain database menghasilkan spesifikasi-spesifikasi desain bagi relational database, termasuk definisi untuk table, index, view, dan ruang penyimpanannya.

8.6.1. Memetakan Entity Relationship Model ke Table Instance Chart

Memetakan Entity ke Table
Buat table instance chart untuk table baru. Table instance chart sebaiknya mengandung kolom untuk nama table, nama column, key types, null dan unique, informasi foreign key, column datatype dan maximum length, dan contoh data. Simpan nama tablenya.
Memetakan Attribute ke Column
Petakan setiap attribute dalam entity relationship model ke nama column pada table, Tambahkan contoh data ke chart untuk menunjukkan isi dari table didalam format visual. Petakan mandatory attribute, yang ditandai dengan asterisk (*), ke column yang didefinisikan sebagai NOT NULL (NN).
Jangan menamai column dengan SQL reserved words, seperti NUMBER. Berilah nama column dengan singkatan-singkatan yang konsisten, seperti NO atau NUM (tetapi tidak keduanya) untuk menghindari kebingungan programmer dan user.
Memetakan Unique Identifier ke Primary Key
Petakan UID yang telah diidentifikasi pada entity relationship model dengan simbol angka (#) ke primary key column dan tandai key tersebut sebagai PK. Petakan UID yang mengandung single attribute ke single-column PK. Tandai not null dan unique dengan NN dan U. Petakan UID yang mengandung banyak attribute ke composite PK. Tandai column-column tersebut dengan NN dan U1. Jika terdapat primary key alternatif, tandai dengan NN dan U, tetapi pilihlah hanya satu PK.
Jika UID terkandung dalam relationship (diindikasikan dengan UID bar), tambahkan column FK untuk setiap relationship dan tandai dengan PK dan FK. Tambahkan column-column FK pada akhir table instance chart atau pada sisi kanan dari seluruh column, bahkan meskipun FK merupakan bagian dari PK. Pilihlah nama yang unik untuk setiap FK column dan tambahkan contoh data.
Memetakan Relationship ke Foreign Key
Langkah terakhir adalah memetakan relationship ke foreign key. Terdapat dua tipe relationship yang perlu diperhatikan: Many-to-one dan one-to-one. Jika suatu relationship merupakan bagian dari UID, maka kita telah memetakannya. Pastikan bahwa kita menandai mandatory relationship dengan NN. Pilihlah nama yang unik untuk foreign key columnt tersebut.
- Many-to-one Relationship
  Petakan many-to-one relationship dengan cara meletakkan primary key pada sisi “one” dan meletakkan foreign key pada sisi “many”. Teknik ini juga dapat diaplikasikan pada recursive relationship.
- One-to-one Optional Relationship
  Kita dapat meletakkan foreign key pada salah satu sisi relationship untuk relationship jenis ini. Pastikan untuk menambahkan U.
- One-to-one Mandatory Relationship
  Letakkan unique foreign key pada table sisi mandatory dan tandai dengan NN untuk memaksakan kebutuhan mandatory dan U untuk memaksakan one-to-one relationship.

8.6.2. Kebutuhan-kebutuhan Tambahan

Mendesain index, dimana merupakan objek database yang menyediakan akses cepat dan langsung ke row pada table. Kita mungkin juga perlu menciptakan index untuk alternate key, foreign key, dan column-column yang sering digunakan pada kondisi pencarian data.
Menentukan definisi view, dimana merupakan table logical yang berbasiskan pada satu atau lebih table atau view. View dapat membatasi akses, meningkatkan presentasi informasi, dan dapat berisi query kompleks yang telah diciptakan sebelumnya.
Rencanakan ruang penyimpanan fisik, dimana merupakan jumlah total ruang yang diperlukan untuk menyimpan data dari table pada database.
Meredefinisikan integrity constraint

8.6.3. Simbol-simbol untuk Mendokumentasikan Table Instance Chart

PK
- Primary key
FK
- Foreign key
FK1, FK2
- Dua foreign key pada table yang sama
FK1, FK1
- Dua column dalam composite foreign key yang sama
NN
- Not null
U
- Unique
U1, U2
- Dua column yang unique secara kombinasi

8.6.4. Pedoman

Nama table sebaiknya mudah dilacak kembali ke nama entity-nya. Nama jamak entity kadangkala digunakan karena table akan berisi banyak row.
Nama column sebaiknya mudah dilacak kembali ke entity relationship model. Nama column yang pendek akan mengurangi waktu yang dibutuhkan SQL command parsing.
Kita sebaiknya membangun sendiri aturan penamaan serta standarnya.

Silahkan melanjutkan membaca pembahasan Menciptakan Table

Catatan:
Untuk mempraktekkan artikel-artikel mengenai Oracle SQL & PL/SQL Anda dapat mendownload script table disini, lalu jalankan sesuai live demo (browser Anda harus mendukung Flash Player).