Bagaimana cara merancang basis data yang baik?

Basis data

Basis data (database) adalah suatu kumpulan data yang disusun dalam bentuk tabel-tabel yang saling berkaitan maupun berdiri sendiri dan disimpan secara bersama-sama pada suatu media. Basis data dapat digunakan oleh satu atau lebih program aplikasi secara optimal, data disimpan tanpa mengalami ketergantungan pada program yang akan menggunakannya.

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

Perancangan basis data 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:

  1. 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.

  2. 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.

  3. 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 .

  4. 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:

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

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

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

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

      • 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.

  5. 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.

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

  7. 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:

  1. 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. Contohnya:

      CONSTRAINT StaffNotHandlingTooMuch
      
         CHECK (
      
           NOTEXISTS (
      
               SELECT StaffNo 
               FROM PropertyForRent 
               GROUPBY StaffNo
               HAVINGCOUNT (*)>100
                      )
                 )
      
  2. 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:

      • Heap
      • Hash
      • IndexedSequentialAccessMethod (ISAM)
      • B±Tree
      • 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 :

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

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

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

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

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

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

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

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

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

        • Menghindari peng- index- an pada attribute yang berisi string karakter yang panjang.

      • 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.

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

  3. 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.

  4. 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.