A. Proses Desain Database
1. Analisis Persyaratan: Langkah pertama dalam mendesain sebuah aplikasi database adalah 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. Dengan kata lain, kita harus tahu apa yang diinginkan pengguna database tersebut. Biasanya ini adalah sebuah proses informal yang melibatkan partisipasi kelompok pengguna, studi tentang lingkungan pegoprasian saat ini dan bagaimana perkiraan perubahan lingkungan tersebut, analisis dokumen yang ada dalam suatu aplikasi yang diharapkan akan diganti atau dilengkapi oleh database, dan seterusnya. Banyak metodologi yang diusulkan untuk menyusun dan menampilkan informasi yang dikumpulkan pada langkah tersebut. Beberapa alat otomatis pun telah dikembangkan untuk mendukung proses ini.
2. Desain Database Konseptual: Informasi dikumpulkan pada saat analisis persyaratan digunakan untuk mengembangkan deskripsi data tingkat tinggi yang harus disimpan dalam database, bersama dengan batasan yang telah diketahui untuk menetapkan penyimpanan data tersebut. Langkah ini sering dilakukan dengan menggunkan model ER. Model ER adalah salah satu dari model data tingkat tinggi, atau semantik, yang digunakan dalam desain database. Tujuannya adalah menciptakan gambaran sederhana tentang data yang mirip dengan pemikiran pengguna dan pengembang mengenai data tersebut (orang dan proses yang dinyatakan dalam data tersebut). Hal tersebut menfasilitasi diskusi di antara orang-orang yang terlibat dalam proses desain, bahkan mereka yang tidak mempunyai latar belakang teknis. Pada saat yang sama, desain awal harus akurat untuk membantu ketapatan translasi ke dalam sebuah model data yang didukung oleh sistem database komersial (yang dalam prakteknya berarti model relasional).
3. Desain Database Logika: Kita harus memilih sebuah DBMS untuk mengimplementasikan desain database kita, dan mengubah konsep desain database menjadi sebuah skema database dalam model data dari DBMS terpilih. Kitah hanya akan memperhatikan DBMS relasional, dan dengan demikian tugas desain logika adalah mengubah skema ER menjadi skema database relasional.
4. Perbaikan Skema: Langkah keempat dalam desain dataase adalah analisis sekumpulan relasi dalam skema database relasional untuk mengidentifikasi permasalahan yang muncul, dan memperbaikinya. Berbeda dengan alaisis persyaratan dan langkah-langkah desain konseptual, yang secara esensial bersifat subjektif, perbaikan skema dapat dipandu oleh beberapa teori yang kuat dan bagus. Langkah keempat ini, para akademis IT lebih sering disebut dengan Normalisasi.
5. Desain Database Fisik: pada langkah ini, kita juga mempertimbagkan beban kerja umum yang diharapkan dapat didukung oleh datagbase kita dan memperbaiki deswain database di masa mendatang untuk memastikan terpenuhinya kriteria performa yang diinginkan. Langkah ini hanya mencakup pembuatan indeks pada beberapa tabe dan mengelompokkan beberapa tabel, atau bahkan melibatkan desain ulang yang substansial terhadap beberapa bagian skema database yang didapat dari langkah pertama desain database.
6. Desain Aplikasi dan Keamanan: Semua proyek perangkat lunak yang melibatkan sebuah DBMS harus mempertimbangkan aspek aplikasi yang berada di luar database itu sendiri. Metodologi desain seperti UML mencoba menekankan desain perangkat lunak dan siklus pengembangan yang lengkap. Secara singkat, kita harus bisa mengidentifikasi entitas (contohnya pengguna, grup-grup pengguna, dan bagian-bagian lain) dan proses-proses yang terlibat dalam aplikasi. Kita harus menggambarkan peran setiap entitas dalam setiap proses yang akan direfleksikan pada beberapa tugas aplikasi, sebagai bagian dari aliran kerja lengkap untuk tugas tersebut. Untuk tiap peran, kita harus bisa mengidentifikasi bagian database yang harus bisa diakses dan yang tidak bisa diakses, dan kitah harus bisa menganmbil langkah untuk memastikan bahwa aturan akses terseut dilakukan. DBMS memberikan beberapa mekanisme untuk membantu langkah tersebut.
B. Diagram Hubungan Entitas/ ER/ Entity Relationship
Diagram Hubungan Entitas atau entity relation diagram merupakan model data berupa notasi grafis dalam pemodelan data konseptual yang menggambarkan hubungan antara penyimpan.
C. Model Data REA (Relationship Even & Agent)
Database yang memenuhi aturan normalisasi diperlukan untuk menunjang Sistem Informasi Akuntansi (SIA) terkomputerisasi. Alat yang biasa digunakan untuk merancang database adalah Entity Relationship Model (Model E-R). Namun aturan penggambaran diagram tidak begitu jelas, sehingga mempersulit perancang data untuk membentuk database yang memenuhi aturan normalisasi. Model REA merupakan pengembangan dari Model E-R. Model REA menerapkan prinsip give-toget, sehingga mempermudah pembentukan model data.
D. Diagram Kasus dari ER dan REA
1. Diagram Kasus ER
Desain sebuah generalisasi – spesialisasi hirarki untuk sebuah perusahaan kendaraan bermotor. Perusahaan menjual sepeda motor, passenger car, van, dan bis. Tentukan penempatan atribut Anda pada setiap level hirarki.
Jelaskan perbedaan antara total constraint dan partial constraint!
• Total constraint adalah constraint yang mana data dalam entitas yang memiliki constraint tersebut terhubung secara penuh ke dalam entitas dari relasinya.
• Constraint partial adalah constraint yang mana data dalam entitas yang memiliki constraint tersebut terhubung ke dalam entitas dari relasinya.
kasus dari relasi
Relasi :
• Entity 1 to entity 2 : kardinalitas : one to many dengan detail minimal 0 dan maksimalnya banyak. Dependensi : entitas 1 dan entitas 2 tidak saling ketergantungan.
• Entity 2 to entity 1 : kardinalitas : many to one dengan detail minimal 1 dan maksimalnya 1. Dependensi : entitas 1 dan entitas 2 tidak saling ketergantungan.
Contoh kasus :
Keterangan : tabel Pembeli dan Mobil dengan relasi membeli. Pembeli boleh tidak membeli mobil, tetapi juga boleh membeli banyak mobil. Satu mobil boleh tidak ada yang membeli, tapi seandainya ada yang membeli, maksimal hanya ada satu orang pembeli.
2. Diagram Kasus REA
Contoh kasus proses pembuatan database pencatatan keuangan sebuah depertemenstore dengan menggunakan R.E.A
