Proses Desain Database

Apa itu Desain Database ?

Desain Basis Data adalah kumpulan proses yang memfasilitasi perancangan, pengembangan, implementasi, dan pemeliharaan sistem manajemen data perusahaan. Basis data yang dirancang dengan benar mudah dipelihara, meningkatkan konsistensi data, dan hemat biaya dalam hal ruang penyimpanan disk. Desainer database memutuskan bagaimana elemen data berkorelasi dan data apa yang harus disimpan.

Apa Tujuannya ?

Tujuan utama perancangan basis data adalah untuk menghasilkan model desain logis dan fisik dari sistem basis data yang diusulkan. Model logis berkonsentrasi pada persyaratan data dan data yang akan disimpan terlepas dari pertimbangan fisik. Itu tidak peduli dengan bagaimana data akan disimpan atau di mana akan disimpan secara fisik. Model desain data fisik melibatkan penerjemahan desain logis dari database ke media fisik menggunakan sumber daya perangkat keras dan sistem perangkat lunak seperti sistem manajemen basis data (DBMS).

Mengapa Desain Database Penting?

Ini membantu menghasilkan sistem database

1. Untuk memenuhi persyaratan para pengguna

2. Memiliki sistem database dengan performa tinggi

Perancangan database sangat penting untuk membuat sistem database performa tinggi .

Tahapan Desain Database

Fase 1 : Pengumpulan data dan analisa

Proses identifikasi dan analisa kebutuhan-kebutuhan data disebut pengumpulan data dan analisa.

Untuk menentukan kebutuhan-kebutuhan suatu sistem database, pertama-tama harus mengenal bagian-bagian lain dari sistem informasi yang akan berinteraksi dengan sistem database, termasuk para pemakai yang ada dan para pemakai yang baru serta aplikasi-aplikasinya. Kebutuhan-kebutuhan dari para pemakai dan aplikasi-aplikasi inilah yang kemudian dikumpulkan dan dianalisa.

Aktifitas-aktifitas pengumpulan data dan analisa

1.Menentukan kelompok pemakai dan bidang-bidang aplikasinya.

2.Peninjauan dokumentasi yang ada.

3.Analisa lingkungan operasi dan pemrosesan data.

4.Daftar pertanyaan dan wawancara.

Fase 2 : Perancangan database konseptual

Tujuan dari fase ini adalah menghasilkan conceptual schema untuk database yang tergantung pada sebuah DBMS yang spesifik. Sering menggunakan sebuah high-level data model seperti ER/EER model selama fase ini. Dalam conceptual schema, kita harus merinci aplikasi-aplikasi database yang diketahui dan transaksi-transaksi yang mungkin.

Aktifitas paralel perancangan database secara konseptual

- Perancangan skema konseptual :

menguji kebutuhan-kebutuhan data dari suatu database yang merupakan hasil dari fase 1, dan menghasilkan sebuah conceptual database schema pada DBMS independent model data tingkat tinggi seperti EER (enhanced entity relationship) model.

- Perancangan transaksi :

menguji aplikasi-aplikasi database dimana kebutuhan-kebutuhannya telah dianalisa pada fase 1, dan menghasilkan perincian transaksi-transaksi ini.

Fase 3 : Pemilihan DBMS

Pemilihan database ditentukan oleh beberapa faktor, diantaranya:

- Struktur data

Jika data yang disimpan dalam database mengikuti struktur hirarki, maka suatu jenis hirarki dari DBMS harus dipikirkan.

- Personal yang telah terbiasa dengan suatu sistem

Jika staf programmer dalam suatu organisasi sudah terbiasa dengan suatu DBMS, maka hal ini dapat mengurangi biaya latihan dan waktu belajar.

- Tersedianya layanan penjual

Keberadaan fasilitas pelayanan penjual sangat dibutuhkan untuk membantu memecahkan beberapa masalah sistem.

- Teknik

Keberadaan DBMS dalam menjalankan tugasnya seperti jenis-jenis DBMS (relational, network, hierarchical, dll), struktur penyimpanan, dan jalur akses yang mendukung DBMS, pemakai, dll.

Fase 4 : Perancangan database secara logika (pemetaan model data)

Fase selanjutnya dari perancangan database adalah membuat sebuah skema konseptual dan skema eksternal pada model data dari DBMS yang terpilih. Fase ini dilakukan oleh pemetaan skema konseptual dan skema eksternal yang dihasilkan pada fase 2. Pada fase ini, skema konseptual ditransformasikan dari model data tingkat tinggi yang digunakan pada fase 2 ke dalam model data dari DBMS yang dipilih pada fase 3.

Pemetaan diproses dalam 2 tingkat

- Pemetaan system-independent

Pemetaan ke dalam model data DBMS dengan tidak mempertimbangkan karakteristik atau hal-hal yang khusus yang berlaku pada implementasi DBMS dari

model data tsb.

- Penyesuaian skema ke DBMS yang spesifik

mengatur skema yang dihasilkan pada langkah 1 untuk disesuaikan pada implementasi yang khusus di masa yang akan datang dari suatu model data yang

digunakan pada DBMS yang dipilih.

Fase 5 : Perancangan database fisik

Perancangan database secara fisik merupakan proses pemilihan struktur-struktur penyimpanan dan jalur-jalur akses pada file-file database untuk mencapai penampilan yang terbaik pada bermacam-macam aplikasi.Selama fase ini, dirancang spesifikasi-spesifikasi untuk database yang disimpan yang berhubungan dengan struktur-struktur penyimpanan fisik, penempatan record dan jalur akses.

- Response time

Waktu yang telah berlalu dari suatu transaksi database yang diajukan Untuk menjalankan suatu tanggapan. Pengaruh utama pada response time adalah di bawah pengawasan DBMS yaitu : waktu akses database untuk data item yang ditunjuk oleh suatu transaksi. Response time juga dipengaruhi oleh beberapa faktor yang tidak berada di bawah pengawasan DBMS, seperti penjadwalan sistem operasi atau penundaan komunikasi.

- Space Utility

Jumlah ruang penyimpanan yang digunakan oleh file-file database dan struktur-Struktur jalur akses.

- Transaction throughput

Rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem database, dan merupakan parameter kritis dari sistem transaksi (misal, digunakan pada pemesanan tempat di pesawat, bank, dll). Hasil dari fase ini adalah penentuan awal dari struktur penyimpanan dan jalur akses untuk file-file database.

Fase 6 : Implementasi sistem database

Ø Setelah perancangan secara logika dan secara fisik lengkap, kita dapat melaksanakan sistem database.

Ø Perintah-perintah dalam DDL dan SDL(storage definition language) dari DBMS yang dipilih, dihimpun dan digunakan untuk membuat skema database dan file-file database (yang kosong) kemudian database tsb dimuat (disatukan) dengan datanya.

Ø Jika data harus dirubah dari sistem komputer sebelumnya, perubahan-perubahan yang rutin mungkin diperlukan untuk format ulang datanya yang kemudian dimasukkan ke database yang baru.

Ø Transaksi-transaksi database sekarang harus dilaksanakan oleh para programmmer aplikasi.

Didalam merancang basis data, dapat dilakukan dengan berbasis konseptual, logikal, fisikal dan perpaduan diantara ketiganya.

Perancangan database konseptual

Menurut Connoly dan Begg (2010) rancangan basis data konseptual adalah proses pembangunan model data yang digunakan pada suatu perusahaan, dan bebas dari seluruh pertimbangan fisikal. Sebuah rancangan basis data konseptual memiliki Entity types, Relationship type, attributes dan attribute domains, primary keys dan alternate keys, dan integrity constraint. Langkah-langkah dalam pembangunan rancangan basis data konseptual antara lain:

1. Mengidentifikasi Entity type Mengidentifikasikan spesifikasi kebutuhan pengguna dan mengambil kata-kata benda dari spesifikasi tersebut. Selain itu juga dapat diambil objek besar seperti orang, tempat, dan lainnya, kecuali kata-kata benda yang menjadi ukuran dari objek lainnya. Dan juga jangan ambil kata-kata benda yang merupakan sinonim dari objek lainnya. Contoh hasil dari langkah ini antara lain Karyawan, Pelanggan, Servis, Barang dan lain-lain .

2. Mengidentifikasi Relationship types Langkah selanjutnya yaitu mengidentifikasi Relationship di antara Entity types yang sudah ada. ER diagram digunakan sehingga dapat terlihat hubungan antar Entity type dengan jelas.

3. Mengidentifikasi dan mengasosiasikan attributes dengan Entity atau Relationship types tertentu. Cara termudah untuk melakukan identifikasi dan menghubungkan attributes dengan Entity dan Relationship types adalah dengan menanyakan pertanyaan “Informasi apa yang kita butuhkan untuk dipegang”.

4. Menentukan domain atribut Domain adalah kumpulan nilai di mana satu atau lebih attributes menggambarkan nilainya.

5. Menentukan candidate, primary, dan alternate key Dari masing-masing domain atribut yang telah dibuat di tahap sebelumnya, dapat dilanjutkan ke tahap selanjutnya dengan menentukan candidate, primary, dan alternative key. Candidate key merupakan key yang berpeluang untuk menjadi primary key . Primary key adalah key unik yang menjadi kunci utama sebuah entitas untuk relasi ke entitas lain dalam sebuah tabel. Sedangkan alternative key merupakan atribut-atribut pada candidate key yang tidak terpilih menjadi primary key .

6. Mempertimbangkan penggunaan enhanced ER Modelling ( optional ). Tahap ini merupakan proses pertimbangan akan penggunaan enhanced ER Modelling dan besifat opsional untuk dipakai atau tidak.

7. Mengecek model untuk pengulangan Dalam tahap ini, ada tiga langkah yang dikerjakan antara lain:
   

   • Mengecek ulang one-to-one (1:1) Relationship. Dalam melakukan perancangan, mungkin saja terjadi dua Entity yang sebenarnya merepresentasikan objek yang sama di dunia nyata. Hal ini dapat dihilangkan dengan menggabungkan kedua Entity tersebut dan memilih salah satu primary key menjadi primary key pada Entity hasil gabungan.

   • Menghilangkan Relationship yang mengulang Relationship yang mengulang bisa didapatkan dengan melihat apakah ada infomasi dari suatu Relationship dapat didapatkan dari Relationship lainnya.

   • Mempertimbangkan dimensi waktu Agar tidak terjadi redundansi, kita harus memastikan juga bahwa model yang sudah ada agar tetap valid di masa depan nantinya.

8. Memvalidasi model data konseptual dengan transaksi user Data model yang sudah merepresentasikan kebutuhan perusahaan sudah jadi, tapi harus dipastikan kalau transaksi yang dikerjakan perusahaan dapat terpenuhi dengan model tersebut. Hal ini dapat dikerjakan dengan mendeskripsikan transaksi, dan membuat jalur transaksi.

9. Melakukan review model data konseptual dengan user Hal ini dilakukan dengan bertujuan untuk memastikan apakah model yang telah dibuat ini sudah sesuai dengan yang diinginkan user atau belum.

Perancangan basis data logikal

Tahapan yang dilakukan saat merancang basis data logikal adalah:

- Menurunkan Relationship untuk data model logikal Pada tahap ini, Relationship yang ada pada data model konseptual diturunkan menggunakan DBDL untuk relational database . Dengan menggunakan DBDL, kita memberikan nama dari relasi, diikuti dengan simple attribute yang dibungkus dengan tanda kurung. Lalu mengidentifikasi primary key dan alternate key serta foreign key jika ada. Untuk menentukan foreign key, harus diketahui antara “ parent” dan “child” Entity. Lalu mendeskripsikan bagaimana relasi diturunkan untuk struktur yang terjadi pada data model konseptual:

• Strong Entity types Untuk tiap strong Entity type, buat sebuah relasi yang terdiri dari semua simple attribute pada Entity tersebut.

• Weak Entity types Untuk tiap weak Entity type, buat sebuah relasi yang terdiri dari semua simple attribute dari Entity tersebut. Primary key dari Entity ini diturunkan sebagian atau sepenuhnya dari tiap Entity pemilik sehingga identifikasi dari primary key tidak dapat dilakukan hingga setelah semua Relationship dengan Entity pemilik telah dipetakan.

• One-to-many binary Relationship types Untuk relasi 1:* binary Relationship, Entity yang berada di “ one side” menjadi parent, dan yang berada di “many side” menjadi child. Pada child, terdapat attribute primary key dari parent, yang dijadikan sebagai foreign key.

• One-to-one binary Relationship types Dalam menentukan representasi 1:1, yang dilihat bukanlah cardinality, melainkan participation .
  

  • Mandatory participation pada kedua sisi dari 1:1 Relationship Menggabungkan kedua Entity kedalam satu relasi. Salah satu primary key dijadikan primary key dari relasi baru, dan yang satunya dijadikan alternate key.

  • Mandatory participation pada satu sisi 1:1 Relationship Pada sisi yang mandatory, dijadikan child, sedangkan pada sisi yang optional, dijadikan parent.

  • Optional participation pada kedua sisi 1:1 Relationship Untuk kasus ini, penentuan parent dan child tidak diharuskan kecuali didapatkan hubungan yang dapat membantu keputusan.

• One-to-one recursive Relationships types Untuk 1:1 recursive Relationship, tetap menggunakan Entity yang sama untuk relasi tersebut, namun ditambahkan satu attribute baru yang sebenarnya sama dengan primary key , namun diberi nama lain dan dijadikan foreign key.

• Many-to-many binary Relationship types Untuk : Relationship type, buat satu relasi baru yang merepresentasikan Relationship dan memasukkan attribute yang menjadi bagian dari Relationship. Lalu, memasukkan primary key dari kedua Entity untuk dijadikan foreign keys.

• Multi-valued Attributes Merupakan sebuah atribut yang menyimpan banyak nilai- nilai untuk setiap kejadian dari sebuah tipe entitas.

- Validasi relasi dengan normalisasi Relasi yang telah dibuat dibandingkan dengan hasil normalisasi. Normalisasi bertujuan untuk memastikan bahwa set relasi memiliki jumlah attribute minimal yang dibutuhkan untuk menunjang kebutuhan dari perusahaan. Normalisasi melalui beberapa proses untuk memeriksa penggabungan dari attribute- attribute pada relasi dengan langkah-langkah 1NF, 2NF, dan 3NF.

- Validasi relasi dengan transaksi pengguna Tujuan dari langkah ini adalah untuk memvalidasi model data logikal untuk memastikan bahwa model data mampu mendukung transaksi-transaksi yang dibutuhkan, seperti yang ada pada user’s requirements .

- Memeriksa integrity constraint Menurut Connoly dan Begg (2010) integrity constaint adalah constraint yang kita harapkan dapat melindungi basisdata dari perubahan yang membuat basis data menjadi tidak lengkap, tidak akurat, dan tidak konsisten. Tipe-tipe integrity constraint antara lain:

• Required data Beberapa attribute harus selalu memiliki nilai yang valid, dengan kata lain, attribute tersebut tidak dizinkan untuk bernilai null.

• Attribute domain constraints Tiap attribute memiliki domain, yaitu suatu kumpulan nilai yang diperbolehkan.

• Multiplicity Multiplicity merupakan constraint yang berada pada Relationship diantara data dalam basis data.

• Entity integrity Primary key dari suatu Entity tidak boleh bernilai null.

• Referential integrity Sebuah foreign key menghubungkan tiap tuple pada relasi child ke tuple pada relasi parent mengandung nilai candidate key yang sama. Maksud dari refrential integrity adalah jika pada foreign key mengandung nilai, maka nilai tersebut harus merujuk ke tuple yang ada pada parent. Terdapat dua permasalahan mengenai foreign key. Permasalahan pertama adalah menentukan apakah nilai null diperbolehkan pada foreign key. Masalah kedua adalah bagaimana cara memastikan referential integrity . Untuk melakukannya, tentukan existence constraints yang mendefinisikan kondisi dimana suatu candidate key atau foreign key dapat di- insert, update, atau delete. Ada beberapa strategi yang dapat dipertimbangkan:
  

a. NO ACTION : Menahan penghapusan dari relasi parent jika ada child tuple yang terhubung.

b. CASCADE : Saat parent tuple dihapus, secara otomatis menghapus tiap child tuples yang terhubung. Jika child tuple tersebut juga memiliki child tuple yang terhubung, maka ia juga akan ikut terhapus.

c. SET NULL : Saat parent tuple dihapus, nilai foreign key pada semua child tuple yang terhubung akan secara otomatis berubah menjadi null.

d. SET DEFAULT : Saat parent tuple dihapus, nilai foreign key pada semua child tuple yang terhubung akan secara otomatis berubah menjadi nilai default.

e. NO CHECK : Saat parent tuple dihapus, tidak melakukan apa-apa.

• General constraints Terkahir, pertimbangkan constraint yang diketahui sebagai general contraints. Perbaharuan pada Entity mungkin dikendalikan oleh constraint yang mengatur transaksi pada dunia nyata.

- Melakukan review model data logikal dengan user Data model logikal seharusnya sudah lengkap dan terdokumentasi secara penuh. Namun, untuk mengkonfirmasi kebenarannya, pengguna diminta untuk meninjau data model logikal untuk memastikan bahwa mereka menyatakan kalau model tersebut benar. Jika pengguna tidak puas dengan model tersebut, maka perlu dilakukan pengulangan pada beberapa langkah sebelumnya.

- Mempertimbangkan perkembangan di masa depan Suatu model data logikal, seharusnya dapat memenuhi perkembangan data di masa depan.

- Pemilihan Database Management System

Perancangan Basis data Fisikal

Menurut Connoly dan Begg (2010) rancangan basis data fisikal adalah proses produksi sebuah deskripsi dari implementasi sebuah basis data pada penyimpanan sekunder. Rancangan ini mendeskripsikan relasi dasar, organisasi file, dan index yang dipakai untuk mencapai akses data dan tiap integrity constraint dan security measures yang efisien.

Dalam melakukan perancangan basis data fisikal, ada beberapa langkah, antara lain:

- Mentranslasikan data model logikal untuk DBMS tujuan Langkah awal perancangan model data fisikal adalah melakukan translasi pada model data logikal menjadi sebuah bentuk yang dapat diimplementasikan pada DBMS tujuan. Untuk mentranslasikannya, terdapat tiga langkah, yaitu:

• Merancang relasi dasar Pada tahap ini dilakukan penyusunan dan asimilasi informasi tentang relasi yang terbentuk saat melakukan perancangan basisdata logikal. Informasi tersebut diambil dari model data logikal dan data dictionary. Informasi-informasi yang diambil dari model data logikal antara lain nama relasi, daftar simple attribute, primary key, alternate key, foreign key, dan referential integrity constraint untuk tiap foreign key yang teridentifikasi. Sedangkan dari data dictionary , diambil informasi untuk tiap attribute, antara lain domain, optional default value, apakah dapat memiliki nilai null, dan apakah attribute tersebut diturunkan, jika ya, bagaimana cara untuk menghitungnya

• Merancang representasi data turunan Derived data atau data turunan dalah data yang didapatkan dari hasil perhitunag dari data lain. Data ini memiliki tanda “/” pada model data logikal. Mungkin saja pada model tidak terdapat data turunan, tetapi pada data dictionary terdapat data turunan. Untuk memasukkan data turunan kedalam penyimpanan, tergantung keputusan dari perancang, apakah lebih low-cost jika dimasukkan atau tidak. Seberapa besar media penyimpanan yang terpakai bila data turunan disimpan. Berapa lama proses pengambilan data turunan jika tidak disimpan

• Merancang general constraints Pada dunia nyata, banyak batasan-batasan data yang perlu diikuti. Hal ini dinamakan general constraint. Untuk membuat general constraint , banyak DBMS yang sudah menyediakan fasilitas yang memudahkan pembuatannya. Pembuatan general constraint dapat dilakukan dengan menuliskan SQL pada SQL CREATE TABLE.

• Merancang organisasi file dan index Salah satu tujuan dari rancangan basisdata fisikal adalah untuk menyimpan dan mengakses data secara efisien. Walaupun beberapa struktur penyimpanan dapat melakukan bulk loading kedalam basisdata, tapi akan tidak menjadi efisien setelah itu. Untuk itulah dibutuhkan pemilihan struktur penyimpanan untuk mengatur basisdata dan pilih yang lain untuk operasional.

• Menganalisa transaksi Untuk menganalisa transaksi, dilakukan identifikasi kriteria performa seperti:

- Transaksi yang berjalan sering dan akan terkena dampak yang signifikan pada performa

- Transaksi yang penting untuk operasi bisnis

- Di saat ada permintaan database yang tinggi

- Untuk mencari area basis data yang memiliki masalah dalam akses yang banyak dengan cara Pemetaan semua jalur transaksi ke relasi; Mencari tahu frekuensi informasi;

- Menganalisa penggunaan data

• Memilih organisasi file Agar akses data lebih efisien, perlu diadakan pemilihan organisasi file . Beberapa pilihan organisasi file antara lain:

a. Heap

b. Hash

c. IndexedSequentialAccessMethod (ISAM)

d. B±Tree

e. Clusters

• Memilih index Satu pendekatan untuk memilih organisasi file yang baik untuk sebuah relasi adalah dengan cara menjaga tuple tak terurut dan membuat sebanyak mungkin secondary indexes . Selain itu, bisa juga menurutkan tuple pada sebuah relasi dengan cara menentukan sebuah primary atau cluster index .

-> Menentukan index

-> Memilih secondary indexes

Secondary indexes menyediakan mekanisme untuk menentukan key tambahan untuk sebuah relasi dasar yang bias dipakai untuk mengambil data dengan lebih efisien.

-> Panduan untuk memilih sebuah “ wish-list” dari index Panduan untuk memilih “ wish-list” index antara lain :

1. Jangan mengindex relasi kecil. Lebih efisien untuk melakukan pencarian relasi pada memory daripada membuat struktur index tambahan.

2. Melakukan peng- index- an pada primary key dari sebuah relasi jika itu bukan sebuah key dari organisasi file.

3. Menambahkan sebuah secondary index pada foreign key, jika sering diakses.

4. Menambahkan secondary key pada tiap attribute yang sering dipakai sebagai secondary key.

5. Menambahkan secondary index pada attribute yang sering terlibat pada kriteria selection atau join, ORDER BY, GROUP BY, dan operasi lain yang menyangkut dengan sorting.

6. Menambahkan secondary index pada attribute yang terlibat di built-in aggregate function, bersamaan dengan tiap attribute yang dipakai untuk function itu.

7. Menambahkan secondary index pada attribute yang mengeluarkan hasil di sebuah index-only plan.

8. Menghindari peng- index- an pada attribute atau relasi yang sering diperbaharui.

9. Menghindari peng- index- an pada attribute jika query akan mengambil banyak tuple pada sebuah relasi.

10. Menghilangkan peng- index- an pada attribute yang berisi string karakter yang panjang.

11. Menghilangkan index dari wish-list Index tidak selalu meningkatkan efisiensi pada saat mengakses data. Untuk itu diperlukan penghilangan pada index yang malah mengurangi efisiensi tersebut.

12. Memperkirakan kebutuhan disk space Perancang harus memperkirakan banyaknya disk space yang diperlukan untuk menyimpan database , seandainya hardware baru harus diadakan.

- Merancang View untuk pengguna Langkah ini bertujuan untuk melakukan perancangan pada view untuk pengguna yang diidentifikasi saat pengumpulan kebutuhan dan analisa tahapan dalam siklus hidup pengembangan sistem basis data.

- Merancang mekanisme security Langkah ini bertujuan untuk melakukan perancangan mekanisme keamanan untuk basisdata yang sudah ditentukan oleh pengguna saat tahap pengumpulan kebutuhan di siklus hidup pengembangan sistem basis data.

Kita dapat menggunakan siklus waterfall sebagai dasar untuk model pengembangan database yang menggabungkan tiga asumsi:

1. Kita dapat memisahkan pengembangan database - yaitu spesifikasi dan pembuatan skema untuk menentukan data dalam database - dari proses pengguna yang menggunakan database.

2. Kita dapat menggunakan arsitektur tiga skema sebagai dasar untuk membedakan aktivitas yang terkait dengan skema.

3. Kami dapat merepresentasikan batasan untuk menerapkan semantik data satu kali dalam database, bukan dalam setiap proses pengguna yang menggunakan data tersebut.

Dengan menggunakan asumsi-asumsi ini dan gambar diatas, kita dapat melihat bahwa diagram ini merepresentasikan model aktivitas dan keluarannya untuk pengembangan database. Ini berlaku untuk semua kelas DBMS, bukan hanya pendekatan relasional.

Pengembangan aplikasi database adalah proses mendapatkan kebutuhan dunia nyata, menganalisis kebutuhan, merancang data dan fungsi sistem, dan kemudian mengimplementasikan operasi dalam sistem.

Step 1 : Requirements Gathering

Langkah pertama adalah pengumpulan persyaratan . Selama langkah ini, perancang database harus mewawancarai pelanggan (pengguna database) untuk memahami sistem yang diusulkan dan mendapatkan serta mendokumentasikan data dan persyaratan fungsional. Hasil dari langkah ini adalah dokumen yang mencakup persyaratan rinci yang disediakan oleh pengguna. Menetapkan persyaratan melibatkan konsultasi dengan, dan kesepakatan di antara, semua pengguna tentang data persisten apa yang ingin mereka simpan bersama dengan kesepakatan tentang arti dan interpretasi elemen data. Administrator data memainkan peran kunci dalam proses ini karena mereka meninjau masalah bisnis, hukum, dan etika dalam organisasi yang berdampak pada persyaratan data.

Dokumen persyaratan data yang digunakan untuk mengkonfirmasi pemahaman persyaratan dengan pengguna. Untuk memastikan bahwa ini mudah dimengerti, ini tidak boleh terlalu formal atau terlalu banyak kode. Dokumen tersebut harus memberikan ringkasan singkat tentang semua persyaratan pengguna - bukan hanya kumpulan persyaratan individu - karena tujuannya adalah untuk mengembangkan satu database bersama. Persyaratan tidak harus menjelaskan bagaimana data akan diproses, tetapi lebih pada apa item datanya, atribut apa yang mereka miliki, batasan apa yang berlaku dan hubungan yang ada di antara item data.

Step 2 : Analysis

Analisis data dimulai dengan pernyataan kebutuhan data dan kemudian menghasilkan model data konseptual. Tujuan dari analisis adalah untuk mendapatkan gambaran rinci dari data yang sesuai dengan kebutuhan pengguna sehingga sifat data tingkat tinggi dan rendah dan penggunaannya dapat ditangani. Ini termasuk properti seperti kisaran nilai yang memungkinkan yang dapat diizinkan untuk atribut (misalnya, dalam contoh database sekolah, kode mata pelajaran siswa, judul mata pelajaran dan poin kredit).

Model data konseptual memberikan representasi formal bersama dari apa yang dikomunikasikan antara klien dan pengembang selama pengembangan database - ini difokuskan pada data dalam database, terlepas dari penggunaan akhirnya data tersebut dalam proses pengguna atau implementasi data di lingkungan komputer tertentu. Oleh karena itu, model data konseptual berkaitan dengan makna dan struktur data, tetapi tidak dengan detail yang memengaruhi cara penerapannya.

Model data konseptual kemudian adalah representasi formal dari data apa yang harus dimuat dalam database dan batasan yang harus dipenuhi oleh data tersebut. Ini harus dinyatakan dalam istilah yang tidak bergantung pada bagaimana model dapat diimplementasikan. Hasilnya, analisis berfokus pada pertanyaan, "Apa yang dibutuhkan?" bukan “Bagaimana ini bisa dicapai?”

Step 3: Logical Design

Desain database dimulai dengan model data konseptual dan menghasilkan spesifikasi skema logis; ini akan menentukan tipe spesifik dari sistem database (jaringan, relasional, berorientasi objek) yang diperlukan. Representasi relasional masih independen dari DBMS tertentu; itu adalah model data konseptual lainnya. Kita dapat menggunakan representasi relasional dari model data konseptual sebagai masukan untuk proses desain logis. Output dari tahap ini adalah spesifikasi relasional terperinci, skema logis, dari semua tabel dan batasan yang diperlukan untuk memenuhi deskripsi data dalam model data konseptual. Selama aktivitas desain inilah pilihan dibuat untuk tabel mana yang paling sesuai untuk merepresentasikan data dalam database. Pilihan ini harus mempertimbangkan berbagai kriteria desain termasuk, misalnya, fleksibilitas untuk perubahan, kontrol duplikasi dan cara terbaik untuk merepresentasikan kendala. Ini adalah tabel yang ditentukan oleh skema logis yang menentukan data apa yang disimpan dan bagaimana mereka dapat dimanipulasi dalam database.

Desainer database yang akrab dengan database relasional dan SQL mungkin tergoda untuk langsung menerapkannya setelah mereka menghasilkan model data konseptual. Namun, transformasi langsung dari representasi relasional ke tabel SQL tidak selalu menghasilkan database yang memiliki semua properti yang diinginkan: kelengkapan, integritas, fleksibilitas, efisiensi, dan kegunaan. Model data konseptual yang baik merupakan langkah pertama yang penting menuju database dengan properti ini, tetapi tidak berarti bahwa transformasi langsung ke tabel SQL secara otomatis menghasilkan database yang baik. Langkah pertama ini akan secara akurat merepresentasikan tabel dan batasan yang diperlukan untuk memenuhi deskripsi model data konseptual, dan dengan demikian akan memenuhi persyaratan kelengkapan dan integritas, tetapi mungkin tidak fleksibel atau menawarkan kegunaan yang buruk.Melenturkan adalah istilah yang dimaksudkan untuk menangkap gagasan simultan tentang menekuk sesuatu untuk tujuan yang berbeda dan melemahkan aspeknya saat dibengkokkan.

Gambar dibawah akan meringkas langkah-langkah iteratif (berulang) yang terlibat dalam desain database, berdasarkan gambaran umum yang diberikan. Tujuan utamanya adalah untuk membedakan masalah umum tentang tabel apa yang harus digunakan dari definisi terperinci dari bagian-bagian penyusun setiap tabel - tabel-tabel ini dianggap satu per satu, meskipun tabel-tabel tersebut tidak independen satu sama lain. Setiap iterasi yang melibatkan revisi tabel akan mengarah ke desain baru; secara kolektif mereka biasanya disebut sebagai desain potongan kedua , bahkan jika proses iterasi lebih dari satu loop.

- Pertama, untuk model data konseptual tertentu, tidak semua persyaratan pengguna yang diwakilinya harus dipenuhi oleh satu database. Ada berbagai alasan untuk pengembangan lebih dari satu database, seperti kebutuhan untuk operasi independen di lokasi yang berbeda atau kontrol departemen atas data "mereka". Namun, jika kumpulan database berisi data duplikat dan pengguna perlu mengakses data di lebih dari satu database, maka ada kemungkinan alasan mengapa satu database dapat memenuhi beberapa persyaratan, atau masalah yang terkait dengan replikasi dan distribusi data perlu diperiksa.

- Kedua, salah satu asumsi tentang pengembangan database adalah bahwa kita dapat memisahkan pengembangan database dari perkembangan proses pengguna yang memanfaatkannya. Hal ini didasarkan pada harapan bahwa, setelah database diimplementasikan, semua data yang diperlukan oleh proses pengguna yang teridentifikasi saat ini telah ditentukan dan dapat diakses; tetapi kami juga membutuhkan fleksibilitas untuk memungkinkan kami memenuhi perubahan persyaratan di masa mendatang. Dalam mengembangkan database untuk beberapa aplikasi, dimungkinkan untuk memprediksi permintaan umum yang akan disajikan ke database sehingga kami dapat mengoptimalkan desain kami untuk permintaan yang paling umum.

- Ketiga, pada tingkat rinci, banyak aspek desain dan implementasi database bergantung pada DBMS tertentu yang digunakan. Jika pilihan DBMS ditetapkan atau dibuat sebelum tugas desain, pilihan tersebut dapat digunakan untuk menentukan kriteria desain daripada menunggu sampai implementasi. Artinya, dimungkinkan untuk menggabungkan keputusan desain untuk DBMS tertentu daripada menghasilkan desain umum dan kemudian menyesuaikannya dengan DBMS selama implementasi.

Tidak jarang menemukan bahwa satu desain tidak dapat secara bersamaan memenuhi semua properti database yang baik. Jadi penting bahwa perancang telah memprioritaskan properti ini (biasanya menggunakan informasi dari spesifikasi persyaratan); misalnya, untuk memutuskan apakah integritas lebih penting daripada efisiensi dan apakah kegunaan lebih penting daripada fleksibilitas dalam perkembangan tertentu. Di akhir tahap desain kami, skema logis akan ditentukan oleh pernyataan SQL data definition language (DDL), yang menjelaskan database yang perlu diimplementasikan untuk memenuhi kebutuhan pengguna.

Step 4 : Implementation

Implementasi melibatkan pembangunan database sesuai dengan spesifikasi skema logis. Ini akan mencakup spesifikasi skema penyimpanan yang sesuai, penegakan keamanan, skema eksternal, dan sebagainya. Implementasi sangat dipengaruhi oleh pilihan DBMS yang tersedia, perangkat database dan lingkungan operasi. Ada tugas tambahan di luar sekadar membuat skema database dan menerapkan batasan - data harus dimasukkan ke dalam tabel, masalah yang berkaitan dengan pengguna dan proses pengguna perlu ditangani, dan aktivitas manajemen yang terkait dengan aspek yang lebih luas dari manajemen data perusahaan perlu ditangani. didukung. Sesuai dengan pendekatan DBMS, kami ingin sebanyak mungkin masalah ini ditangani dalam DBMS. Kami melihat beberapa masalah ini secara singkat sekarang.

Dalam praktiknya, implementasi skema logis dalam DBMS tertentu membutuhkan pengetahuan yang sangat mendetail tentang fitur dan fasilitas khusus yang ditawarkan DBMS. Dalam dunia yang ideal, dan sesuai dengan praktik rekayasa perangkat lunak yang baik, tahap pertama implementasi akan melibatkan pencocokan persyaratan desain dengan alat implementasi terbaik yang tersedia dan kemudian menggunakan alat tersebut untuk implementasi. Dalam istilah database, ini mungkin melibatkan pemilihan produk vendor dengan varian DBMS dan SQL yang paling sesuai dengan database yang perlu kita implementasikan. Namun, kita tidak hidup di dunia yang ideal dan lebih sering daripada tidak, pilihan perangkat keras dan keputusan terkait DBMS akan dibuat dengan baik sebelum pertimbangan desain database. Karena itu,

Step 5 : Realizing the Design

Setelah desain logis dibuat, kita membutuhkan database kita untuk dibuat sesuai dengan definisi yang telah kita buat. Untuk implementasi dengan DBMS relasional, ini mungkin akan melibatkan penggunaan SQL untuk membuat tabel dan batasan yang memenuhi deskripsi skema logis dan pilihan skema penyimpanan yang sesuai (jika DBMS mengizinkan tingkat kontrol tersebut).

Salah satu cara untuk mencapai ini adalah dengan menulis pernyataan SQL DDL yang sesuai ke dalam file yang dapat dijalankan oleh DBMS sehingga ada catatan independen, file teks, dari pernyataan SQL yang mendefinisikan database. Metode lain adalah bekerja secara interaktif menggunakan alat database seperti SQL Server Management Studio atau Microsoft Access. Apapun mekanisme yang digunakan untuk mengimplementasikan skema logis, hasilnya adalah database, dengan tabel dan batasan, ditentukan tetapi tidak akan berisi data untuk proses pengguna.

Step 6 : Populating the Database

Setelah database dibuat, ada dua cara untuk mengisi tabel - baik dari data yang ada atau melalui penggunaan aplikasi pengguna yang dikembangkan untuk database.

Untuk beberapa tabel, mungkin ada data dari database atau file data lain. Misalnya, dalam membuat database untuk rumah sakit, Anda mengharapkan sudah ada beberapa catatan dari semua staf yang harus dimasukkan ke dalam database. Data juga dapat dibawa dari lembaga luar (daftar alamat sering kali dibawa dari perusahaan eksternal) atau dihasilkan selama tugas entri data yang besar (mengubah catatan manual hard copy menjadi file komputer dapat dilakukan oleh lembaga entri data). Dalam situasi seperti itu, pendekatan paling sederhana untuk mengisi database adalah dengan menggunakan fasilitas impor dan ekspor yang terdapat di DBMS.

Fasilitas untuk mengimpor dan mengekspor data dalam berbagai format standar biasanya tersedia (fungsi ini juga dikenal di beberapa sistem sebagai data bongkar muat). Mengimpor memungkinkan file data disalin langsung ke dalam tabel. Ketika data disimpan dalam format file yang tidak sesuai untuk menggunakan fungsi import, maka perlu disiapkan program aplikasi yang membaca data lama, mengubahnya seperlunya dan kemudian memasukkannya ke dalam database menggunakan kode SQL yang diproduksi khusus untuk alasan tersebut. Transfer sejumlah besar data yang ada ke dalam database disebut sebagai beban massal. Pemuatan data secara massal mungkin melibatkan pemuatan data dalam jumlah yang sangat besar, satu tabel pada satu waktu sehingga Anda mungkin menemukan bahwa ada fasilitas DBMS untuk menunda pemeriksaan kendala hingga akhir pemuatan massal.

Langkah-langkah untuk Mengembangkan Diagram ER

1. Dokumentasikan semua entitas yang ditemukan selama tahap pengumpulan-informasi.

2. Dokumentasikan semua atribut yang dimiliki setiap entitas. Pilih kandidat dan kunci utama. Pastikan bahwa semua atribut non-kunci untuk setiap entitas secara fungsional bergantung pada kunci utama.

3. Kembangkan diagram ER awal dan tinjau dengan personel yang sesuai. (Ingatlah bahwa ini adalah proses berulang.)

4. Buat entitas baru (tabel) untuk atribut multinilai dan grup berulang. Gabungkan entitas (tabel) baru ini ke dalam diagram ER. Tinjau dengan personel yang tepat.

5. Verifikasi pemodelan ER dengan menormalkan tabel.

Penjelasan lebih lanjut : Bahasa Query Terstruktur SQL

Sumber :

Bagaimana cara merancang basis data yang baik?

Database Design Tutorial: Learn Data Modeling

PPt "Perancangan Basis Data" oleh Safitri Wijaya