Kamis, 26 April 2012

ENTITY RELATIONSHIP DIAGRAM

          Sekarang penulis akan membahas mengenai ERD (Entity Relational Diagram) nih, teman2. Jadi pada chapter ini, penulis tidak hanya akan membahas mengenai seluk-beluk dari ERD, namun juga akan  menjelaskan bagaimana cara membuat ERD dalam database.
Jadi penulis akan membahas mengenai :
1. Entity Relationship Diagram
2. Entity Relationship Model
         Sebelum kita membuat ERD ada baiknya kita berkenalan dulu lah dengan segala sesuatu yang berhubungan dengan ERD.


Ok, lets get started to watch and learn about ERD!!!


Entity Relationship Diagram (as known as ERD) ialah pemodelan data utama dan akan membantu mengorganisasikan data dalam suatu proyek ke dalam entitas-entitas dan menentukan hubungan antar entitas beserta attribut-attributnya.


Berikut penjelasannya, gan :


Entitas (Entity)
Suatu yang nyata dimana kita akan menyimpan data. Jadi contohnya ialah seperti misalnya ERD mengenai Rumah Sakit, nah Entitas nya yaitu entitas penjaga, entitas perawat, entitas dokter dll.
Ada 2 tipe Entitas :
1. Entitas Kuat, merupakan entitas yang tidak memiliki ketergantungan dengan entitas lain.
2. Entitas Lemah, merupakan entitas yang kemunculannya tergantung pada keberandaan entitas lain pada suatu relasi.




Attribut (Attribute)
Suatu tempat atau objek yang berguna untuk menyimpan data-data.
Contohnya kalau dari ERD Rumah Sakit itu seperti misal Entitas nya ialah entitas Dokter, nah attribut nya dapat berupa NoID_Dokter, Nama_Dokter, Spesialis_Dokter, dll.
Jenis-jenis atribut :

1. Atribut komposit = Atribut yang tidak bisa dipecah lagi menjadi atribut yang lebih kecil
2. Atribut atomic = Atribut yang terdiri atas satu komponen tunggal dan tidak bisa diuraikan lg
3. Single-valued attribute = Atribut yang hanya punya satu nilai untuk suatu entitas.
4. Multi-valued attribute = Atribut yang dapat teridir dari sekumpulan nilai untuk entitas.
5. Atribut Derivatif = Atribut yang dihasilkan dari atribut lain yang tidak berasal dari 1 entitas.




Relasi (Relationship)
Hubungan yang terjadi antara satu atau lebih entitas, jadi istilahnya itu hubungan anatar entitas.
Misalnya ni ya, ambil contoh dari ERD Rumah Sakit, kita ambil Entitas Dokter dengan Entitas Pasien. Nah, entitas dokter itu memiliki relasi dengan entitas pasien sebagai "Merawat/Memeriksa/Menyembuhkan", yang artinya Dokter memeriksa/menyembuhkan Pasien, atau Pasien diperiksa/disembuhkan oleh Dokter. Jadi di dalam relasi, harus ada hubungan yang pasti pada antar entitas yang berelasi. Begitu, kawan, mudah bukan?

Derajat relasi atau kardinalitas :


1. One to One (Satu ke satu) = Setiap anggota entitas E1 hanya boleh berhubungan dengan 1 anggota entitas E2, begitu pula sebaliknya.

2. One to Many (Satu ke Banyak) = Setiap anggota entitas E1 boleh berhubungan lebih dari satu dari anggota entitas E2, begitu pula sebaliknya.

3. Many to Many (Banyak ke Banyak) = Setiap entitas E1 boleh berhubungan dengan banyak anggota entitas E1, demikian juga sebaliknya.







Berikut simbol-simbol yang dapat dipakai dalam pembuatan ERD beserta keterangannya :


Guys, dalam membuat suatu ERD, ada 10 langkah yang harus kita lewati. Berikut langkah-langkah dalam pembuatan ERD, beserta penjelasannya, check it out:



Studi kasus:

Skema Kerja Hotel

Spesifikasi database :
  • Attribut dari PEGAWAI : Nama,NIP,Jabatan,Telpon,Alamat,Tahun_Masuk.
  • Attribut dari TAMU : Nama, Id_Tamu, Alamat, Telpon, Lama_inap
  • Attribut dari KAMAR : No_Kamar, Id_kamar
  • Attribut dari FASILITAS : Id_tipekamar, Jumlah_kamar, Jenis_tipekamar, Other_fasilitas
  • Attribut dari HARGA : Id_harga, Weekdays, Weekend
  • Attribut dari TRANSAKSI_MASUK : Id_Transaksi, Reservasi, Tgl_Checkin
  • Attribut dari TRANSAKSI_KELUAR: Id_Transaksikeluar,Tgl_Checkout

Step by step pembuatan Enrity Relationship Diagram Skema Kerja Hotel

Menentukan attribut dari setiap entity :


Menentukan Primary Key dari setiap entity :



Menentukan Relationship antar entity :

Menentukan Cardinality Rasio :


Hasil dari ER Diagram :

Selasa, 17 April 2012

DESAIN DATABASE



        Buat para Database designer atau Database Administrator (DBA) mendesain database ialah hal yang sudah biasa mereka lakukan, namun bagaimana buat kita-kita yang baru saja mempelajari database, atau belum pernah sekalipn mendesain database?
        Maka disini saya ingin sharing bagaimana langkah-langkah mendesain sebuah database.

Langkah-langkah mendesain sebuah database;


  1. Pengumpulan data dan analisis.
    Langkah pertama dalam mendesain sebuah aplikasi database ialah memahami dan mengetahui data yang harus disimpan di dalam database, aplikasi apa yang harus dibangun diatasnya, dan jenis operasi apa yang lebih banyak digunakan, dan subjek untuk melakukan persyaratan yang ada.
    Untuk menspesifikasikan kebutuhan, yang pertama dilakukan ialaha mengidentifikasi bagian lain di dalam sistem informasi yang berinteraksi dengan sistem database. Termasuk pengguna yang baru atu yang sudah lama beserta aplikasinya, kebutuhan-kebutuhan tersebut 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.

    Teknik yang digunakan dalam penspesifikasian kebutuhan secara formal :
    1. OOA (Object Oriented Analysis)
    2. DFD (Data Flow Diagram)
    3. HIPO (Hierarchical Input Process Output)
    4. SADT (Structured Analysis & Design)
  2. Perancangan database secara konseptual
    Tujuan dari tahap ini adalah untuk menghasilkan skema konseptual untuk database yang tidak tergantung pada sistem manajemen database/DBMS yang spesifik. Penggunaan model data tingkat tinggi seperti ER/ER sering digunakan di dalam tahap ini. Untuk menciptakan gambaran yang sederhana tentang data yang mirip dengan pemikiran pengguna dan pengembang mengenai data tersebut.
    Di dalam skema konseptual dilakukan perincian aplikasi-aplikasi database dan transaksi-transaksi yang diketahui.

    Ada dua kegiatan di dalam perancangan database secara konseptual :
    1. Perancangan Skema Konseptual
            Pada tahap ini kegiatn yang dilakukan mengecek tentang kebutuhan-kebutuhan data yang dihasilkan dari tahap 1, dimana tujuan dari proses perancangan skema konseptual ialah Menyatukan pemahaman struktur database, pengertian semantik, keterhubungan antar entitas dan attribut serta batasan-batasan. Dengan membuat sebuah skema database konseptual dengan menggunakan model data ER/EER tanpa tergantung dengan sistem manajemen database.

    Ada 4 strategi dalam perancangan skema konseptual :
    1. Top Down
    2. Bottom Up
    3. Inside Out
    4. Mixed


           Skema ini dapat dihasilkan dengan menggabungkan bermacam-macam kebutuhan user dan secara langsung membuat skema database atau dengan merancang skema-skema yang terpisah dari kebutuhan tiap-tiap user dan kemudian menggabungkan skema-skema tsb.
            Model data yang digunakan pada perancangan skema konseptual ialaha DBMS-independent, dan langkah selanjutnya adalah memilih sebuah DBMS untuk melaksanakan rancangan tsb.

    2. Perancangan Transaksi
            Kegunaan tahap ini ialah Merancang karakteristik dari transaksi-transaksi yang akan di implementasikan tanpa tergantung dengan DBMS yang telah dipilih. Transaksi-transaksi ini digunakan untuk memanipulasi database sewaktu diimplementasikan.
    Pada tahap ini diidentifikasikan input,output dan fungsional. Transaksi ini antara lain : Retrieval, Update, Delete, Select dll.
  3. Pemilihan Sistem Manajemen Database / DBMS
            Langkah dalam memilih DBMS:
    a. Define Terms of Reference of Study
    b. Shorlist 2 or 3 product
       Dengan memperhatikan budget yang tersedia, dukungan vendor, kompatible software.
    c. Evaluate product
        - Data definition
        - Physical definition (Struktur file, indexing, data compression, enkripsi).
        - Accessbility (Bahasa query, multi user, security)


            Pemilihan sistem manajemen database ditentukan oleh beberapa faktor, antara lain:
    1. Faktor Teknik
        - Tipe model data
        - Struktur penyimpanan dan jalur pengaksesan yang didukung DBMS.
        - Tipe interface dan programmer
        - Tipe bahasa Querry


    2. Faktor Ekonomi
        - Biaya penyediaan hardware dan software
        - Biaya konversi pembuatan database
        - Biaya personalia
        - Biaya pelatihan
        - Biaya pengoperasian
        - Biaya pemeliharaan


    3. Faktor Organisasi
        - Struktur data
        - Personal yang terbiasa dengan sistem yang terdahulu
        - Ketersediaan dari service vendor
  4. Perancangan database secara logika (Transformasi model data)
            Fase selanjutnya dari perancangan database ialah 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. Fase ini, skema konseptualnya ditransformasikan dari model data tingkat tinggi yang digunakan pada fase 2 ke dalam model data dari DBMS yang dipilih pada fase 3.
             Teknik untuk mengevaluasi dari perancangan ini digunakan normalisasi. Proses ini akan menjamin bahwa data yang dihasilkan sudah tidak memiliki data yang rangkap, yang mengakibatkan anomali update pada saat implementasi.
    Ada 2 proses yaitu :
    1. Transformasi yang tidak tergantung pada sistem.
    2. Penyesuaian skema ke sistem manajemen database yang spesifik.

    Hasil dari fase ini memakai perintah-perintah DDL dalam bahasa DBMS yang dipilih yang menentukan tingkat skema konseptual dan eksternal dari sistem database. Tapi jika perintah DDL tersebut termasuk dalam parameter-parameter perancangan fisik, maka perintah-perintah DDL yang lengkap harus menunggu sampai tahap perancangan database secara fisik telah lengkap.
  5. Perancangan database secara fisik
    Merupakan proses pemilihan struktur penyimpanan yang spesifik dan pengaksesan file-file database untuk mencapai kinerja yang terbaik di bermacam-macam aplikasi.

    Kriteria pemilihan perancangan fisik :
    1. Waktu Respon (Response Time)
         Waktu transaksi database selama eksekusi untuk menerima respon.
    2. Penggunaan ruang penyimpanan (Space Utility)
         Jumlah ruang penyimpanan yang digunakan oleh basis data file.
    3. Terobosan yang dilakukan file transaksi (Transaction Throughput).
         Rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem database.

    Denormalisasi merupakan proses yang dilakukan pada database yang sudah dinormalisasi, dengan cara memodifikasi struktur tabel dan mengabaikan kerangkapan data (yang terkontrol) untuk meningkatkan kinerja database.
  6. Implementasi Sistem Database
    Setelah perancangan secara logika dan 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). Lalu database tsb dimuat dengan datanya.
        Realisasi fisik database dan desain aplikasi :
  • Program aplikasi untuk transaksi database dengan mengimplementasikan DML yang di embeded pada host programming (Cth Visual Basic, C++, Java, COBOL).
  • Kontrol security dan integritas, dengan menggunakan SDL atau menggunakan utilities dari DBMS.

Tujuan perancangan database :
  • Untuk memenuhi kebutuhan akan informasi dari pengguna dan aplikasi.
  • Menyediakan stuktur informasi yang natural dan mudah dimengerti oleh pengguna
  • Mendukung kebutuhan pemrosesan dan beberapa obyek kinerja dari suatu sistem database.
Secara khusus proses perancangan berisikan 2 aktifitas paralel. Aktifitas yang pertama melibatkan perancangan dari is data dan struktur database, sedangkan aktifitas kedua mengenai perancangan pemrosesan database dan aplikasi-aplikasi perangkat lunak.

Dua aktifitas ini saling berkaitan, misalnya mengidentifikasikan data sistem yang akan disimpan dalam database dengan cara menganalisa aplikasi-aplikasi database. Dan juga saling mempengaruhi satu sama lain. Contohnya tahap perancangan database secara fisik, pada saat memilih struktur penyimpandan dan jalur akses dari file suatu database dimana bergantung dengan aplikasi-aplikasi yang akan menggunakan file tersebut.

Ke-enam tahap yang telah disebutkan sebelumnya dapat diproses secara tidak berurutan. Dalam beberapa hal, dapat dilakukan modifikasi perancangan kembali ke tahap yang pertama (feedback loop) setelah melakukan tahap selanjutnya.