1. Normalisasi

2. Suatu data model harus bersih dari : ketidak konsistensian, redundansi, duplikasi dll. Untuk itu diperlukan upaya Normalisasi sehingga setiap atribut pada data model hanya memiliki satu nama yang unik.

3. Normalisasi adalah suatu usaha untuk melakukan analisa terhadap model data untuk mendapatkan bahwa setiap atribut dalam suatu entitas akan sangat bergantungan, atau secara sederhana dapat dikatakan bahwa dalam prakteknya bahwa yang dapat dimasukkan dalam Entitas (Record) Personil atribut (atau field) adalah sesuatu yang menjelaskan tentang personil itu sendiri, bila tidak taruh ditempat lainnya.

4. Misalnya, ada record Personil , maka pada record personil tersebut bisa dimasukkan segala item data yang berkaitan dengan objek data personil tersebut, seperti pada contoh, namun hal tersebut tidak dianjurkan oleh teori basis data Record personil Id_Personil Alamat Umur Jabatan Pengurangan_gaji Tidak boleh, harus dipisahkan menjadi satu record sendiri Tgl_Pembayaran Diuraikan menjadi 2 record :

5. tabel Perosnil tersebut di uraikan (decomposition) menjadi 2 tabel yang terpisah dimana pada tabel Personil yang baru setiap field akan berisi : Id-personil, alamat, umur, jabatan, tidak boleh ada Tgl_pembayaran, Pengurangan-gaji, yang ini harus dibuat satu tabel tersendiri, misalnya dinamakan Tabel Pembayaran memiliki record Pengurangan-Pembayaran dimana field atau atributnya menjelaskan tentang : Id-personil, tgl-pembayaran, pengurangan-gaji dst. Record personil Record Pengurangan_Pembayaran_Gaji Id_Personil Tgl_Pembayaran Pengurangan_Gaji Id_Personil Alamat Umur Jabatan

6. Normalisasi 1 Definisinya adalah : Semua entitas harus memiliki kunci, gabungan dari kombinasi satu atau lebih atribut yang secara unik mengidentifikasikan satu kemunculan dari entitas tersebut. Untuk setiap kemunculan satu entitas maka setiap atribut harus memiliki satu dan hanya satu nilai (value). Atau dengan kata lain sebuah table terpenuhi pada bentuk normal tahap satu bila table tersebut tidak memiliki atribut bernilai banyak /pengulangan grup

7. Persyaratan 1 pada normalisasi 1 adalah bahwa setiap entitas harus punya kunci, contoh nomor_part menunjukkan satu buah part akan tetapi bila yang digunakan nama_kustomer dan telepon_kustomer maka karena nama_kustomer lebih merepotkan selain panjangnya maka lebih mudah menggunakan telepon_kustomer sebagai kunci.

8. Persyaratan 2 pada normalisai 1 adalah setiap entitas harus bebas dari pengulangan grup, contoh 1 : record departemen , kita ketahui bahwa pada satu departemen banyak personil yang bekerja, sehingga apabila recordnya berisikan atribut : Id_departemen dan I d_personil , maka dengan satu Id_departemen akan memunculkan banyak Id-personil ini akan menghasilkan error karena Id_personil akan muncul berulang-ulang dan banyak., maka untuk itu Id_personil harus dikeluarkan dari record departemen dan dijadikan satu record sendiri yang kita namakan, misalnya record personil , adapun hubungan antara departemen dengan personil adalah 1 ke banyak (1 to M).

9. Normalisasi 2 Definisinya adalah : Suatu relasi dikatakan pada normalisasi tahap 2 adalah jika dan hanya jika berada dalam normalisasi 1 dan hanya jika setiap atribut benar2 tergantung fungsional (KF) pada primari key secara utuh. Suatu relasi tidak pada tahap 2 apabila ketergantungannya masih parsial, masih ketergantungan pada selain primer key. Contoh : pada rekord nilai ada pada tahap 2, namun apabila ditambahkan field nama-mahasiswa maka relasi dikatakan tidak pada normalisasi 2, karena nama-mahasiswa tidak tergantung pada kode_kul, hanya tergantung pada NIM, sedangkan kode_kul adalah prime key juga. Untuk itu nama mahasiswa harus dikeluarkan dari rekord nilai.

10. Record nilai, pada kondisi I record nilai telah memenuhi tahap 2N tapi bila + tuple /item data/field nama-_mhs (Kondisi II) maka record nilai tidak lagi pada normalisasi 2. Kondisi 2 Kondisi 1 Kode-Kul NIM Kode_Nilai Kode-Kul NIM Kode_Nilai Nama_mhsKode_Nilai

11. Normalisasi 3 Definisinya adalah : Suatu relasi dikatakan pada normalisasi tahap 3 adalah jika dan hanya jika berada pada normalisasi tahap 2 dan setiap atribut bukan key nontransitif tergantung pada primari key. Atau dapat dikatakan bahwa non key atribut tidak boleh tergantung pada non key atribut lainnya. Contoh relasi dalam tabel Mahasiswa :

12. Tabel Mahasiswa Pada relasi tabel mahasiswa maka alamat_mhs adalah atribut komposit , yang berisi nama jalan, nomor rumah, nama_kota, kode_pos., demikian Tgl_lahir tediri atas tangggal, bulan, tahun (defoult system) Nim Nama_mhs Alamat_mhs Tgl_lahir 980001 Ahmad Ablar Jl.Merdeka No.10 Jakarta 40121 2 Jan 1979 980002 Boedipekerti Jl.Gajah Mada No.2 Jakarta 45123 6 Okt 1978 980003 Mathias Mulus Jl.Adil No. 203, Bogor 43212 13 Mei 1978 980004 Buyut Biyung Jl.Gajah Mada No.2 Jakarta 45123 23 Agt 1977

13. Pertama Tabel Mahasiswa atribut komposite dididekomposisikan, Nim Nama_mhs Alamat_Jalan Nama_kota Kode_pos Tgl_lahir Nim Nama_mhs Alamat_mhs Tgl_lahir

14. Didekomposisikan lagi menjadi 2 tabel, Tabel_Mhs dan Tabel_Alamat Tabel Mhs Nim Nama_mhs Alamat_Jalan Nama_kota Kode_pos Tabel Mhs Nim Nama_mhs Alamat_Jalan Nama_Kota Tgl_Lahir Tabel Alamat Alamat_Jalan Nama_kota Kode_pos

15. Karena terdapat 2 mahasiswa yang memiliki alamat sama, maka cukup disimpan satu saja Nim Nama_mhs Alamat_Jalan Nama_Kota Tgl_Lahir 980001 Ahmad Ablar Jl.Merdeka No.10 Jakarta 2 Jan 1979 980002 Boedipekerti Jl.Gajah Mada No.2 Jakarta 6 Okt 1978 980003 Buyut Biyung Jl.Adil No. 203, Bogor 13 Mei 1978 980004 Mathias Mulus Jl.Gajah Mada No. Jakarta 23 Agt 1977 Alamat_mhs Nama_Kota Kode_Pos Jl.Merdeka No.10 Jakarta 40121 Jl.Gajah Mada No.2 Jakarta 45123 Jl.Adil No. 203 Bogor 43212

16. Tabel 2, belum sampai tahap 3 dan belum memenuhi BCNF, karena perlu dipecah/ diuraikan lebih lanjut karena ketiganya dapat merupakan key dari yang lain. Alamat 1 Alamat 2 Alamat_mhs Kode_Pos Kode_Pos Nama_Kota Jl.Merdeka No.10 40121 40121 Jakarta Jl.Gajah Mada No.2 45123 45123 Jakarta Jl.Adil No. 203, 43212 43212 Bogor Jl.Gajah Mada No.2 Jakarta 45123

17. Normalisasi 4 Normalisasi sampai dengan tahap 3 sudah cukup memadai untuk tabel memiliki kualitas baik, namun kadang pembahasan normalisasi tahap 4 dilakukan karena adanya sifat ketergantungan banyak nilai pada satu tabel dan merupakan pengembangan dari ketergantungan fungsional Normalisasi 5 Normalisasi tahap 5 berkaitan dengan relasi antar tabel. Pembahasan 4 dan 5 cukup rumit sehingga tidak terlalu dibahas pada mata kuliah ini.

19. Bentuk Table yang tidak memenuhi bentuk normal (tidak dinormalisasi contohnya) Table DATAKARYAWAN No_KYW, NAMAKARYAWAN, DEPARTEMEN, SEKSI, ALAMAT, KOTA Dalam menentukan normalisasi suatu database akan bergantung pada Functional Dipendency dari setiap Tuple (Field/Column) yang akan menentukan seberapa normal Satu Table.

20. Dari Gambaran diatas Table DDATAKARYAWAN merupakan Table yang tidak dinormalisasi. Karena kita tidak melihat adanya Functional Dipendency Kalo kita lihat kemungkinan ketergantungan fungsinal (  artinya tergantung pada) yang berlaku adalah : No  NAMAKARYAWAN, DEPARTEMEN DEPARTEMEN  SEKSI NAMAKARYAWAN  ALAMAT KOTA  ALAMAT Akibat kita melakukan design table yang tidak dinormalisasi seperti diatas kita kan mengalami kesulitan untuk membentuk suatu relasi antara table.

21. Jika boboy kita hapus dari Table Kita maka Data departemen Sales juga akan terhapus berikut Kota bekasi (Integritas data Terganggu). Padahal Departemen sales tetap ada meskipun tidak memiliki karyawan demikian juga dengan kota bekasi. Sehingga untuk kasus ini perlu di normalisasi menjadi table berikut. No_Kyw Nama_Karyawan Departemen Seksi Alamat Kota 1 A. Hanif IT Application Dev Cideng Jakarta 2 Kusmawanti IT Application Dev Cideng Jakarta 3 Boboy Sales Telesales Ancol Bekasi

22. Table karyawan Table Departemen Table Seksi Table Kota NoKyw Namakaryawan KodeDepartemen KodeSeksi Alamat KodeKota KodeDepartemen NamaDepartement KodeDepartemen KodeSeksi NamaSeksi KodeKota NamaKota

23. Dengan struktur hasil normalisasi ini memungkinkan data integrity akan tetap terjamin. Untuk meningkatkan performance dan data integrity ini proses normalisasi dilakukan dan sebagian besar dilakukan dalam OLTP. Setiap ketergantungan fungsional pada colum di suatu table pada implementasinya akan memungkinkan column tersebut dinominasilkan menjadi KEY baik itu Primary Key maupun secondary Key, dan dari sinilah konsep penentuan Key dan Index dimulai pada tahapan design. yang pada akhirnya akan mementukan waktu akses yang diperlukan untuk mendapatkan suatu informasi dari table yang kita design. sini kita baru mulai menentukan desain database yang mempertimbangkan performance.

24. kapan denormalisasi dilakukan? Biasanya Untuk OLAP dan DataWarehouse Pendekatan designnya berbeda dengan OLTP sebagian besar table dibuat denormalized untuk lebih meningkatkan performace. Desaign yang dibuat menggunakan Star schema atau snowflake Schema. The design of a data warehouse database and online analytical processing (OLAP) cubes is fundamentally different than a transactional processing database (OLTP). The data warehouse is specifically designed to facilitate super fast query times and multi-dimensional analysis. The following table summarizes the major differences between OLTP and OLAP system design.

25. OLTP System Online Transaction Processing (Operational System) OLAP System Online Analytical Processing (Data Warehouse) Source of data Operational data; OLTPs are the original source of the data. Consolidation data; OLAP data comes from the various OLTP Databases Purpose of data To control and run fundamental business tasks To help with planning, problem solving, and decision support What the data Reveals A snapshot of ongoing business processes Multi-dimensional views of various kinds of business activities Inserts and Updates Short and fast inserts and updates initiated by end users Periodic long-running batch jobs refresh the data Queries Relatively standardized and simple queries Returning relatively few records Often complex queries involving aggregations Processing Speed Typically very fast Depends on the amount of data involved; batch data refreshes and complex queries may take many hours; query speed can be improved by creating indexes Space Requirements Can be relatively small if historical data is archived Larger due to the existence of aggregation structures and history data; requires more indexes than OLTP Database Design Highly normalized with many tables Typically de-normalized with fewer tables; use of star and/or snowflake schemas Backup and Recovery Backup religiously; operational data is critical to run the business, data loss is likely to entail significant monetary loss and legal liability Instead of regular backups, some environments may consider simply reloading the OLTP data as a recovery method

26. Analisa Buble (gelembung)

27. Suatu cara analisa untuk mendapatkan model data yang bersih dari redundansi, duplikasi data yang tidak dijinkan dalam struktur data base yang benar adalah dengan menggunakan bubble (gelembung),. Menggunakan buble (gelembung), yaitu dengan cara menggantikan suatu field, element data, item data sebagai sebuah gelembung seperti terlihat dibawah ini : Gaji Pelanggan Kd_keahlian Nama Jalan Invoice

28. Hubungan antar Data Item Data item sendiri tidaklah menarik, data item menjadi lebih menarik apabila dihubungkan kepada data item yang lainnya, misalnya : Nama_karyawan dan Gaji Satu basis data tidak hanya berisikan data item tetapi juga hubungan antara data item tesebut. Nm_karywan Gaji

30. karyawan Gaji 1 1 karyawan Pacar 1 M karyawan Pacar 1 M Gaji 1 1

31. Hubungan Dua Arah Lelaki Wanita 1 1 Lelaki Wanita 1 M Lelaki Wanita M 1 Lelaki Wanita M M Perkawinan Biasa Poligami Poliandri Grup Perkawinan

32. Atau bentuk seperti : karyawan Nama_Istri 1 M Departemen 1 1 No_Gaji 1 1 1 1

34. Diagram gelembung memperlihatkan hubungan banyak ke satu atau satu ke satu A B E D I H G C F

35. Kunci utama (primari key) adalah gelembung (buble) dengan satu atau link satu ke satu yang menuju ke gelembung lain, dalam hal ini A, C, F adalah kunci utama (Prime key) sedangkan B, D, E, G, H dan I bukan atribut utama.. Record adalah gabungan dari data item yang secara logika menjelaskan objek dari record tersebut.contoh : Supplier# Nama_Sup Alamat_Sup Detil_Sup

36. Alamat_Sup merupakan atibut komposit untuk itu perlu di dekomposisikan agar lebih detil menjadi : Supplier# Nama_Sup Jalan Detil_Sup Kode_pos Kota Propinsi

37. Bagaimana seandainya kita ingin mengetahui dua data ietem sekaligus dari dua record yang berbeda serta memberikan data item tambahan, seperti pada contoh berikut : harga part tergantung dari jenis_part dan supplier-nya, sedangkan Jenis_part dan supplier adalah dua record yang berbeda. Supplier# + Part# Part# Part detil Harga Supplier# Supplier detil

38. KONSTRUKSI

39. PEMBUATAN PROTOTIPE Pembuatan prototipe adalah salah satu teknik dalam Rekayasa Sistem Informasi yang dapat dilakukan dengan cepat dan mudah untuk segera mengetahui kesalahan yang masih ada pada sistem yang di bangun Prototipe dibuat dengan disain yang baik dan benar oleh tim pembangun sistem informasi (Tim SI dan End User). Hasilnya untuk di implementasikan setelah mendapatkan persetujuan tertulis dari end user Penelaahan prototipe dilaksanakan dalam satu sesi yang dinamakan JAD (Joint Application Design) dan JRP (Joint Requirement Planning) dimana akan duduk pihak-pihak Manajemen. End User, dan Profesional Information Sistem untuk mendapatkan komentar atau perbaikan

40. TIME BOX METODOLOGI

41. Satu metodologi yang dinilai cepat dalam membangun sistem Informasi dinamakan Time Box, Metodologi Time Box melibatkan dengan aktif end user dalam mendisain prototipe sistem yang dibangun dalam satu Box iterasi, dimana user diminta untuk memverifikasi setiap hasil yang diberikan oleh Tim Profesional SI, sebagaimana gambar berikut: …………..

42. Definisi Sistem Evaluasi Sistem Bangun dan kembangkan prototipe Review oleh User Jika sistem tidak sesuai untuk di implementasikan Jika sistem butuh perubahan kecil Proposal Timebox Pengembangan Iterative Implementasi sistem Review untuk menentukan prioritas implementasi Joint Resource Planning dan IE Joint Application Design digunakan unuk perencanaan