Perancangan Sistem Informasi

Presentasi berjudul: "Perancangan Sistem Informasi"— Transcript presentasi:

1 Perancangan Sistem Informasi
Terminologi Sistem Basis Data Daur Hidup (Life Cycle) yang Umum dari Aplikasi Basis Data Proses Design Sistem Basis Data Database Design and Implementation Studi kasus Perancangan Database Teknik Normalisasi

2 Kompetensi pembelajaran
Mahasiswa dapat merancang basis data sesuai dengan sistem informasi yang dibangun. Mahasiswa dapat merancang basis data menggunakan pemodelan ERD atau Normalisasi (Pendekatan terstruktur)

3 Materi Konsep Sistem Basis Data Keuntungan dan kerugian basis data
Peranan Basis Data dalam Sistem Informasi Fungsi dan Tujuan Perancangan Basis Data Abstraksi Data Rancangan Data Logis Rancangan Database menggunakan pemodelan ER-Diagram Rancangan Database menggunakan Teknik Normalisasi Rancangan Data Fisik Spesifikasi Tabel

4 TERMINOLOGI SISTEM BASIS DATA

5 Definisi Basis Data Basis data (database) merupakan kumpulan dari data yang saling berhubungan dengan yang lainnya, tersimpan di perangkat keras komputer dan digunakan perangkat lunak untuk memanipulasinya. Database merupakan salah satu komponen yang penting dalam sistem informasi, karena merupakan basis dalam menyediakan informasi bagi para pemakai. Penerapan database dalam sistem informasi disebut dengan database system.

6 Definisi Basis Data secara konsep basis data atau database adalah kumpulan dari data-data yang membentuk suatu berkas (file) yang saling berhubungan (relation) dengan tata cara yang tertentu untuk membentuk data baru atau informasi. Atau Basis data (database) merupakan kumpulan dari data yang saling berhubungan (relasi) antara satu dengan lainnya yang diorganisasikan berdasarkan skema atau struktur tertentu.

7 Tujuan Pemanfaatan Basis Data (1)
1. Kecepatan dan Kemudahan (Speed) Yakni agar pengguna basis data bisa: menyimpan data melakukan perubahan/manipulasi terhadap data menampilkan kembali data dengan lebih cepat dan mudah dibandingkan dengan cara biasa (baik manual ataupun elektronis). 2. Efisiensi Ruang Penyimpanan (Space) Dengan basis data kita mampu melakukan penekanan jumlah redundansi (pengulangan) data, baik dengan menerapkan sejumlah pengkodean atau dengan membuat relasi-relasi antara kelompok data yang saling berhubungan.

8 Tujuan Pemanfaatan Basis Data (2)
3. Keakuratan (Accuracy) Agar data sesuai dengan aturan dan batasan tertentu dengan cara memanfaatkan pengkodean atau pembentukan relasi antar data bersama dengan penerapan aturan/batasan (constraint) tipe data, domain data, keunikan data dsb. 4. Ketersediaan (Availability) Agar data bisa diakses oleh setiap pengguna yang membutuhkan, dengan penerapan teknologi jaringan serta melakukan pemindahan/penghapusan data yang sudah tidak digunakan / kadaluwarsa untuk menghemat ruang penyimpanan.

9 Tujuan Pemanfaatan Basis Data (3)
5. Kelengkapan (Completeness) Agar data yang dikelola senantiasa lengkap baik relatif terhadap kebutuhan pemakai maupun terhadap waktu, dengan melakukan penambahan baris-baris data ataupun melakukan perubahan struktur pada basis data; yakni dengan menambahkan field pada tabel atau menambah tabel baru. 6. Keamanan (Security) Agar data yang bersifat rahasia atau proses yang vital tidak jatuh ke orang / pengguna yang tidak berhak, yakni dengan penggunaan account (username dan password) serta menerapkan pembedaan hak akses setiap pengguna terhadap data yang bisa dibaca atau proses yang bisa dilakukan.

10 Tujuan Pemanfaatan Basis Data (4)
6. Kebersamaan (Sharability) Agar data yang dikelola oleh sistem mendukung lingkungan multiuser (banyak pemakai), dengan menjaga / menghindari munculnya problem baru seperti inkonsistensi data (karena terjadi perubahan data yang dilakukan oleh beberapa user dalam waktu yang bersamaan) atau kondisi deadlock (karena ada banyak pemakai yang saling menunggu untuk menggunakan data).

11 Pemakai Basis Data (1) Secara umum, seluruh sistem dalam kehidupan bisa menggunakan konsep basis data dalam pengelolaan informasi, karena semua sistem tersebut tak bisa lepas dari fakta. Bidang-bidang fungsional yang memanfaatkan basis data dalam hal efisiensi, akurasi dan kecepatan operasi antara lain adalah: - Kepegawaian, untuk berbagai perusahaan yang memiliki banyak pegawai Pergudangan (inventory), untuk perusahaan manufaktur (pabrik), grosir (reseller), apotik dll - Akuntansi, untuk berbagai perusahaan Akuntansi, untuk berbagai perusahaan Layanan pelanggan (Customer care), untuk perusahaan yang berhubungan dengan banyak pelanggan (bank, konsultan dll)

12 Pemakai Basis Data (2) Bentuk-bentuk Perusahaan yang memanfaatkan Basis Data: - Perbankan, dalam melakukan pengelolaan data nasabah, tabungan, pinjaman, pembuatan laporan akuntansi, pelayanan informasi pada nasabah dll - Pendidikan / sekolah, dalam melakukan pengelolaan data siswa, penjadwalan kegiatan, perkuliahan, nilai dll. - Rumah Sakit, dalam melakukan pengelolaan histori penyakit / pengobatan pasien, menangani pembayaran perawatan dll. - Telekomunikasi, dalam melakukan pengelolaan data administrasi kabel / data pelanggan, menangani gangguan dll. - Dan lain sebagainya

13 Cara Konvensional Penyimpanan Data Cara Moderen Kelebihan: a. ? b. ?
Kekurangan: a. ? b. ? Kelebihan: a. ? b. ? Penyimpanan Data File Kekurangan: a. ? b. ? Cara Moderen Kelebihan: a. ? b. ? Memanfaatkan Teknologi Informasi (Komputer) Database Kekurangan: a. ? b. ?

14 Posisi DBMS dalam Sistem Basis Data
User Program Aplikasi Software Proses Software Akses File Management Sistem Database Bahasa SQL Mengatur pemrosesan database baik Keluar /masuk Keterangan : 1. User adalah pemakai 2. Program aplikasi adalah tampilan menu utama 3. Software proses adalah SQL Server atau Microsoft Access.

15

16 Sistem Basis Data Berkas/Tabel/File/relasi Baris/record Kolom/Field
Item value Tabel Mahasiswa NPM Nama Alamat 001 Roma Irama Bandung Budi Anduk Jakarta 003 Luna Maya Palembang Basisi data

17 Abstraksi Data Tingkat fisik
Tingkat fisik adalah tingkat terendah dari abstraksi yang menjelaskan tentang penyimpanan data. Pada tingkat fisik, struktur data tingkat rendah yang kompleks dijelaskan secara detail. Tingkat logik Tingkat abstraksi selanjutnya yang menjelaskan data apa saja yang disimpan dalam basis data dan hubungan yang ada pada data-data tersebut. Keseluruhan basis data dijelaskan dalam bentuk sejumlah kecil struktur data yang sederhana. Walaupun implementasi dari struktur sederhana pada tingkat logik mungkin melibatkan struktur yang kompleks di tingkat fisik, pengguna dari tingkat logik tidak diharuskan untuk mengerti kompleksitas ini. Abstraksi tingkat logik digunakan oleh database administrator sebagai orang yang harus memutuskan informasi yang akan disimpan dalam suatu basis data. Tingkat view Tingkat view adalah tingkat tertinggi dari abstraksi yang menjelaskan hanya sebagian dari keseluruhan basis data. Sebagian besar pemakai basis data tidak akan menghiraukan seluruh informasi, tetapi pemakai tertentu perlu mengakses sebuah bagian dari basis data. Supaya interaksi pemakai dengan sistem dapat menjadi lebih sederhana, abstraksi tingkat view didefinisikan. Sistem dapat menyediakan banyak view untuk basis data yang sama.

18 Abstraksi Data View Level View Level View Level View Level View Level

19 PROSES DESIGN SISTEM BASIS DATA

20 Daur Hidup (Life Cycle) yang Umum dari Aplikasi Basis Data
Definisi Sistem Database Design Implementasi Loading/Konversi Data Konversi Aplikasi Testing & Validasi Operations Control & Maintenance

21 Daur Hidup (Life Cycle) dari Aplikasi Basis Data
Definisi Sistem:  ruang lingkup basis data  pemakai  aplikasi Design:  logical design  ER/EER  physical design untuk suatu DBMS

22 Daur Hidup (Life Cycle) dari Aplikasi Basis Data
Implementasi:  membuat basis data (kosong)  membuat program aplikasi Loading/ Konversi Data:  memasukkan data ke dalam basis data  mengkonversi file yang sudah ada ke dalam format basis data dan kemudian memasukkannya dalam basis data

23 Daur Hidup (Life Cycle) dari Aplikasi Basis Data
Konversi Aplikasi: Semua aplikasi dari sistem sebelumnya dikonversikan ke dalam sistem basis data. Testing dan Validasi: Sistem yang baru harus ditest dan divalidasi (diperiksa keabsahannya).

24 Daur Hidup (Life Cycle) dari Aplikasi Basis Data
Operasi: Pengoperasian basis data dan aplikasinya. Monitoring dan Maintenance: Selama operasi, sistem dimonitor dan diperlihara. Baik data maupun program aplikasi masih dapat terus tumbuh dan berkembang.

25 Proses Design Sistem Basis Data
Basis Data biasanya merupakan salah satu bagian dari suatu sistem informasi yang besar yang antara lain terdiri dari: Data Perangkat lunak DBMS Perangkat keras komputer Perangkat lunak dan sistem operasi komputer Program-program aplikasi Pemrogram, dll

26 Proses Design Basis Data
Pengumpulan dan analisa requirement Design basis data conceptual Pemilihan DBMS Mapping dari conceptual ke logical Physical Design Implementasi

27 Proses Design Basis Data (cont’d)
Keenam phase dalam proses design tidak perlu dilaksanakan secara mutlak, mungkin ada umpan balik antar phase dan dalam masing-masing phase

28 Proses Design Paralel Proses design terdiri dari dua proses yang paralel yaitu: proses design dari data dan struktur dari basis data (data driven) proses design dari program aplikasi dan pemrosesan basis data (process driven)

29 Mengapa Harus Paralel Karena kedua proses tersebut saling bergantungan. Contoh: Menentukan data item yang akan disimpan dalam basis data tergantung dari aplikasi basis data tersebut, juga dalam menentukan struktur dan akses path. Design dari program aplikasi tergantung dari struktur basis datanya. Biasanya condong ke salah satu.

30 Phase 1: Pengumpulan Data & Analisa Requirement
Pengidentifikasian group pemakai dan area aplikasi Penelitian kembali dokumen-dokumen yang sudah ada yang berhubungan dengan aplikasi  form, report, manual, organization chart, dsb Analisa lingkungan operasi dan kebutuhan dari pemrosesan, seperti tipe transaksi, input/output, frekuensi suatu transaksi, dsb Transfer informasi informal ke dalam bentuk terstruktur menggunakan salah satu bentuk formal dari requirement specification (bentuk diagram) seperti Flow Chart, DFD, UML Diagram, dll. Hal ini dilakukan untuk mempermudah pemeriksaan kekonsistenan, ketepatan, dan kelengkapan dari spesifikasi.

31 Phase 2: Design Conceptual
Phase 2A: Design Conceptual Schema High level data model, bukan implementation-level data model Memberikan gambaran yang lengkap dari struktur basis data yaitu arti, hubungan, dan batasan-batasan. Conceptual schema bersifat tetap Alat komunikasi antar pemakai basis data, designer, dan analis

32 Phase 2: Design Conceptual (cont’d)
Phase 2A: Design Conceptual Schema Harus bersifat: Mampu menyatakan relationship, batasan-batasan Diagram Formal, minimum dalam menyatakan spesifikasi data (tidak ada duplikasi) Simple Conceptual data model harus DBMS independent  ER/EER

33 Strategi untuk Design Schema
Top Down: - mulai dengan beberapa high level entity type - bagi lagi (top down) menjadi beberapa lower-level entity type dan relationship type Bottom Up: - mulai dengan atribut - kelompokkan menjadi entity type & relationship type - tambahkan relationship-relationship baru bila ada

34 Strategi untuk Design Schema (cont’d)
Inside Out: bentuk khusus dari bottom-up mula-mula ditentukan entity type yang merupakan pusat/bagian terpenting tambahkan entity type dan relationship lain yang berhubungan satu sama lain

35 Strategi untuk Design Schema (cont’d)
Mixed: requirement dibagi-bagi menggunakan strategi top down sebagian dari schema di-design dari partisi-partisi menggunakan strategi bottom-up bagian-bagian dari komponen-komponen tersebut kemudian digabungkan

36 Examples of bottom-up refinement
Examples of bottom-up refinement. (a) Discovering and adding new relationships. (b) Discovering a new category (union type) and relating it.

37 Phase 2b: Design Transaksi
Pada saat suatu basis data di-design, aplikasi dari transaksi utama harus sudah diketahui Transaksi-transaksi baru dapat didefinisikan kemudian Tentukan karakteristik dari transaksi dan periksa apakah basis data sudah memuat semua informasi untuk melaksanakan transaksi

38 Phase 2b: Design Transaksi (cont’d)
Transaksi dapat dibagi dalam 3 bagian yaitu: - retrieval - update - mixed Phase 2a dan 2b sebaiknya dilaksanakan secara paralel dengan menggunakan umpan balik agar didapat design schema dan transaksi yang stabil

39 Phase 3: Pemilihan DBMS Pemilihan DBMS ditentukan oleh sejumlah faktor antara lain: faktor teknis: storage, akses path, user interface, programmer, bahasa query faktor ekonomi: software, hardware, maintenance, training, operasi, konversi, teknisi, dll faktor organisasi: kompleksitas, data, sharing antar aplikasi, perkembangan data, pengontrolan data

40 Phase 4: Mapping dari Data Model
Memetakan conceptual model ke dalam DBMS Menyesuaikan schema dengan DBMS pilihan Hasil pemetaan biasanya berupa DDL

41 Phase 5: Physical Design
Struktur storage, akses path untuk mendapatkan performance yang baik Kriteria baik dapat dilihat dari: - response time - pemakaian storage - throughput (jumlah transaksi per unit waktu) Perlu tuning untuk memperbaiki performance berdasarkan statistik pemakaian

42 Phase 6: Implementasi Sistem Basis Data
DDL dan SDL dari DBMS dikompilasi membentuk schema basis data dan basis data yang masih kosong Basis data dapat dimuati (di-load) dari sistem yang lama Transaksi dapat diimplementasikan oleh program aplikasi dan dikompilasi Siap dioperasikan

43 Rancangan Basis Data Alat bantu perancangan basis data dengan pendekatan terstruktur ERD (Entity Relationships Diagram) Teknik Normalisasi Alat bantu perancangan basis data dengan pendekatan berorientasi objek Diagram UML, menggunakan Diagram Class

44 Database Design and Implementation

45 ERD ERD: Entity Relationship Diagram
Mencerminkan model database: struktur dari entities (tabel-tabel) dan relationships (hubungan-hubungan) di antara entities tersebut.

46 Entity-Relationship Model
E-R Models are Conceptual Models of the database. They can not be directly implemented in a database. Desainnya mendekati pengamatan/penerimaan user terhadap data. Didasarkan atas OBJECT riil dunia nyata dan hubungan antar object-object tersebut. Entity-Relationship model terdiri dari Entity, Relationship, dan Attribute.

47 Versi ERD Peter Chen Entitas Nama_relasi James Martin Atribut Relasi
(MIN,MAX) Peter Chen Nama_entitas Atribut 1 Atribut 2 .. Atribut N Nama_relasi James Martin

48 Komponen ERD Entitas Atribut Relasi

49 Entitas Merupakan obyek yang mewakili sesuatu dalam dunia nyata dan dapat dibedakan antara satu dengan lainnya (unique). Memiliki atribut yang mendeskripsikan karakteristik dari objek tersebut. Dapat berupa: Fisik (mobil, rumah, manusia, pegawai dsb) Abstrak/konsep (department, pekerjaan, mata kuliah dsb) Kejadian (pembelian, penjualan, peminjaman, dll) Notasi : Nama_Entity nama_entity

50 Varian Entitas : Strong Entity (entitas kuat)
Himpunan entitas yg tidak memiliki ketergantungan dg entitas yang lain. Notasi : Nama_entitas

51 Varian Entitas : Weak Entity (entitas Lemah)
Himpunan entitas yg keberadaannya ketergantungan dengan entitas yang lain. Himpunan entitas yg demikian tidak memp. atribut yg berfungsi sebagai key yg benar-benar menjamin keunikan entitas. Notasi dan contoh : tanggungan Entitas tanggungan disebut sebagai entitas lemah karena jika data seorang pegawai dihapus maka data tanggungannya juga akan terhapus. Keberadaan data tanggungan tergantung pada data di pegawai

52 ATRIBUTE karakteristik dari entity atau relationship yang menyediakan detail tentang entity atau relationship tersebut sehingga dapat dibedakan. Nilainya jarang berubah. Merupakan karakteristik dari sebuah entitas (biasanya berhubungan dengan field dalam sebuah tabel). Penentuan atribut bagi suatu entitas didasarkan pada relevansinya terhadap entitas tersebut.

53 Attribut Atribut dalam ERD dilambangkan dengan bentuk elips Atribut
Nama_Entity Atribut 1 Nama_entitas Atribut 2 Entitas Atribut Pegawai NIP, Nama, Alamat, Agama, jenis kelamin Departemen No, Nama, lokasi

54 Macam-macam Atribut Simple Attribute dan Composite Attribute
Single Valued Attribute dan Multi Valued Attribute Mandatory Attribute Derived Attribute (Attribut Turunan) Key Attribute (Atribut Kunci)

55 Simple Attribute dan Composite Attribute
Atribut sederhana/ Simple Attribute : atribut yang tidak dapat dibagi-bagi menjadi atribut yang lebih mendasar. Contoh : atribut harga dari entity barang. Atribut komposit/ Composite Attribute : atribut yang terdiri dari beberapa atribut yang lebih mendasar. Contoh : Entity mahasiswa memiliki atribut nama yang terdiri dari nama depan (first name), nama tengah (middle name) dan nama belakang (last name).

56 Single Valued Attribute dan Multi Valued Attribute
Atribut Berharga Tunggal (Single-valued Attribute) : atribut yang hanya mempunyai satu harga untuk suatu entitas tertentu. Contoh : atribut umur. Atribut Berharga Banyak (Multi-valued Attribute) : atribut yang dapat terdiri dari sekumpulan harga untuk suatu entitas tertentu. Contoh : atribut hobi.

57 Derived Attribute (Attribut Turunan)
Atribut Derivatif : suatu atribut yang dihasilkan dari atribut lain. Contoh : atribut umur yang dapat dihasilkan dari atribut tgl_lahir.

58 Key Attribute (Atribut Kunci)
Satu atau beberapa atribut yang mempunyai nilai unik sehingga dapat digunakan untuk membedakan data pada suatu baris/record dengan baris lain pada suatu entitas Macam key attribute: Superkey Candidat Key Primary key

59 Macam key attribute Superkey: satu atau gabungan beberapa atribut yang dapat membedakan setiap baris data dalam sebuah tabel secara unik Contoh  Superkey untuk entitas pegawai: NoKTP, Nama, Alamat, JenisKel, Gaji NoKTP, Nama, Alamat, JenisKel NoKTP, Nama, Alamat NoKTP, Nama Nama (jika dapat dijamin kalau tidak ada nama yang sama antara satu baris dengan baris yang lain) NoKTP Candidat Key: superkey yang jumlah atributnya paling sedikit Contoh  candidat key untuk entitas pegawai Primary key: suatu candidat key yang dipilih menjadi kunci utama karena sering dijadikan acuan untuk mencari informasi, ringkas, menjadi keunikan suatu baris Contoh : NoKTP antara satu pegawai dengan pegawai lain pasti berbeda, dalam hal ini noKTP dapat digunakan sebagai suatu key Notasi :

60 Kardinalitas Menjelaskan jumlah keterhubungan satu entity dengan entity yang lainnya. (1 : 1) : satu entitas pada tipe entitas A berhubungan dengan paling banyak satu entitas pada tipe entitas B dan juga sebaliknya. Contoh : seorang manager hanya memimpin satu departemen dan begitu sebaliknya. M1 M2 M3 manager R1 R2 R3 manages D1 D2 D3 departement manager departement manages 1

61 Kardinalitas (1 : N / N : 1) : suatu entitas di A dihubungkan dengan sejumlah entitas di B. Contoh : banyak karyawan berkerja untuk satu depertement atau satu departement memiliki banyak karyawan yang bekerja untuknya. E1 E2 E3 E4 E5 E6 employee R1 R2 R3 R4 R5 R6 works_for D1 D2 D3 departement employee departement works_for N 1

62 Kardinalitas (M : N) : setiap entitas A dapat berhubungan dengan banyak entitas B dan sebaliknya setiap entitas B juga dapat berhubungan dengan banyak entitas A. Contoh : satu proyek mempunyai banyak karyawan, satu karyawan boleh bekerja di beberapa proyek. E1 E2 E3 E4 employee R1 R2 R3 R4 R5 R6 works_on P1 P2 P3 project employee project works_on M N

63 Kardinalitas

64 Versi ERD Peter Chen Entitas Nama_relasi James Martin Atribut Relasi
(MIN,MAX) Peter Chen Nama_entitas Atribut 1 Atribut 2 .. Atribut N Nama_relasi James Martin

65 Derajat Max/Min Relasi
Derajat relasi maksimum, yaitu yang menunjukan hubungan (korespondensi) maksimum yang boleh terjadi antara himpunan entitas yang satu terhadap himpunan entitas yang lain. Derajat relasi minimum, yaitu yang menunjukan hubungan (korespondensi) minimum yang boleh terjadi antara himpunan entitas yang satu terhadap himpunan entitas yang lain. Derajat Max/Min Notasi ( 0 , N ) atau ( 1 , N ) ( 1 , 1 ) ( 0, 1 )

66

67

68

69 Varian Relasi Relasi Tunggal (Unary Relation) DOSEN
Merupakan relasi yang terjadi dari sebuah himpunan entitas ke himpunan entitas yang sama Nama Nama 1 Mendampingi DOSEN N

70 Varian Relasi Relasi Biner (BinaryRelation)
Merupakan relasi yang paling umum digunakan Satu relasi menghubungkan dua entitas Kode_MK NIP Nama_Dos NIP Nama_Mk Kode_MK mengajar Dosen 1 N Mt. Kuliah ……… SKS Jml_sks SMT Alamat Kelas Jml_Mk

71 Varian Relasi Relasi Multi Entitas (N-Ary Relation) Dosen Mt. Kuliah
Merupakan relasi yang menghubungkan lebih dari dua entitas. Kode_MK NIP Nama_Dos NIP Nama_Mk Kode_MK mengajar Dosen Mt. Kuliah ……… Kode_R SKS SMT Alamat Kelas Ruang Kode_R Nama_R

72 Varian Relasi Relasi Ganda (Redudant Relation)
Relasi yang muncul antara dua himpunan entitas tidak hanya satu relasi, tetapi ada lebih dari satu relasi NIP Kode_MK Kode_MK Nama_Dos mengajar NIP Nama_Mk Dosen Mt. Kuliah Kode_MK NIP menguasai SKS Alamat SMT Kelas

73 Generalisasi/Specialisasi (GENSPEC)
SPESIALISASI Dari sebuah himpunan entitas kemudian melakukan pengelompokan yang melahirkan himpunan entitas baru (proses Top Down) Dosen ISA Dosen Tetap Dosen Tidak Tetap

74 Generalisasi/Specialisasi (GENSPEC)
Dari beberapa himpunan entitas kemudian menjadi satu himpunan entitas (proses Bottom Up) Mahasiswa ISA Mahasiswa S1 Mahasiswa D3

75 AGREGASI …….1 Sebuah relasi terbentuk tidak hanya dari entitas, tapi juga mengandung unsur lain dari relasi Mengambarkan sebuah relasi yang secara langsung menghubungkan sebuah himpunan entitas dengan sebuah himpunan relasi dalam diagram

76 AGREGASI ……2 Mengambil MHS Mt. Kuliah Mengikuti Praktikum

77 AGREGASI…….3 Mengambil MHS Mt. Kuliah Mengikuti Praktikum

78 Keuntungan Penggunaan ERD dalam Pemodelan Data
Memudahkan perancang dalam hal menganalisis sistem yang akan dikembangkan Memudahkan perancang saat merancang basis data Rancangan basis data yang dikembangkan berdasarkan ERD umumnya telah berada dalam bentuk yang optimal Dalam banyak kesempatan penggunaan simbol – simbol grafis akan lebih mudah di pahami oleh para pemakai daripada bentuk naratif Dengan menggunakan ERD pemakai umumnya akan lebih mudah memahami sistem dan basis data yang dirancang oleh pemakai.

79 kelemahan dari penggunaan ERD
Kebutuhan media yang sangat luas Sering kali ERD tampil sangat ruwet

80 Tahap Pembuatan Database
Tahap 1: Tentukan entities (object-object dasar) yang perlu ada di database Tahap 2: Tentukan attributes (sifat-sifat) masing- masing entity sesuai kebutuhan database Tahap 3: Tentukan relationships (hubungan- hubungan) di antara entities tersebut Tahap 4: Pembuatan ERD Tahap 5: Proses normalisasi database Tahap 6: Implementasi Database

81 Tahap 1: Tentukan Entities
Sifat-sifat entity: Signifikan: memang perlu disimpan di database Umum: tidak menunjuk pada sesuatu yang khusus Fundamental: dapat berdiri sendiri sebagai entity yang dasar dan independent Unitary: merupakan satu kesatuan yang tidak dapat dipecah lagi

82 Tahap 2: Tentukan Attributes
Tentukan sifat-sifat (fields atau kolom) yang dimiliki tiap entity, serta tipe datanya. Attribute yang sesuai harus: Signifikan: memang penting dan perlu dicatat di dalam database Bersifat langsung (direct), bukan derived. Contoh attribute direct: tanggal_lahir Contoh attribute derived: umur

83 Tahap 2 (lanjutan) Tentukan attribute yang menjadi Primary Key untuk entity yang bersangkutan. Jika satu attribute tidak cukup, gabungan beberapa attribute bisa menjadi Composite Primary Key. Jika Composite Primary Key banyak (lebih dari 3 attribute), sebaiknya menambahkan attribute buatan yang menjadi Primary Key yang tunggal.

84 Tahap 3: Tentukan Relationships
Tentukan jenis hubungan di antara entity yang satu dengan entities yang lain. Macam hubungan ada 3: One-to-one (1:1) One-to-many (1:n) Many-to-many (m:n)

85 Tahap 3 (lanjutan) Dalam membentuk hubungan di antara 2 entities, tentukan attribute mana yang digunakan untuk menghubungkan kedua entities tersebut. Tentukan entity mana yang menjadi tabel utama, dan entity mana yang menjadi tabel kedua. Attribute (dari tabel utama) yang menghubungkannya dengan tabel kedua menjadi Foreign Key di tabel kedua.

86 Tahap 4: Pembuatan ERD Buat Entity Relationship Diagram (ERD) berdasarkan hasil dari Tahap Ada berbagai macam notasi untuk pembuatan ERD. Anda bisa menggunakan software khusus untuk menggambar ERD.

87 Tahap 5: Normalisasi Proses normalisasi database terhadap setiap tabel, ada 3 tahap: First normalization Second normalization Third normalization

88 Tahap 6: Implementasi Berdasarkan ERD yang sudah dinormalisasi, buatlah database dengan MySQL, PostgreSQL, Oracle, dst. Bisa secara manual: menggunakan bahasa SQL untuk create database, table, dst. Bisa secara semi-manual: menggunakan client berbasis GUI (MySQLFront, PgAdmin, dst.) Bisa menggunakan CASE tool: Berdasarkan ERD yang ada, software CASE tool langsung membuat databasenya (Rational Rose, DbDesigner, dst.)

89 Aturan untuk Model Database
Tiap baris harus berdiri sendiri (independent): tidak tergantung baris-baris yang lain, dan urutan baris tidak mempengaruhi model database. Tiap baris harus unik: tidak boleh ada 2 atau lebih baris yang sama persis. Kolom harus berdiri sendiri (independent): tidak tergantung kolom-kolom yang lain, dan urutan kolom tidak mempengaruhi model database. Nilai tiap kolom harus berupa satu kesatuan: tidak berupa sebuah daftar.

90 B A C 1 1 F1: A F2: B + C F1: A + B F2: C F1: A F2: B + C F1: A + B
X Y Y X F1: A F2: B + C F1: A + B F2: C F1: A F2: B + C X ... Y ... X F1: A + B F2: C X ... Y Y ...

91 B 1 N A C X Y Y X F1: A F2: B + C F1: A F2: B + C X ... Y ... X

92 B A C M N F1: A , F2: B , F3:C F1: A F2: C F1: B X Y Y X Y ... X ...

93 Studi kasus Perancangan Database
Perancangan Sistem Informasi Studi kasus Perancangan Database

94 Tahap Pembuatan Database
Tahap 1: Tentukan entities (object-object dasar) yang perlu ada di database Tahap 2: Tentukan attributes (sifat-sifat) masing-masing entity sesuai kebutuhan database Tahap 3: Tentukan relationships (hubungan-hubungan) di antara entities tersebut Tahap 4: Pembuatan ERD Tahap 5: Proses normalisasi database Tahap 6: Implementasi Database

95 Penjualan : Pelanggan, Penjualan, Barang Persediaan : Barang, Kategori
Tahap 1: Tentukan entities (object-object dasar) yang perlu ada di database Penjualan : Pelanggan, Penjualan, Barang Persediaan : Barang, Kategori Pembeliaan : Pemasok, Pembeliaan

96 Tahap 2: Tentukan attributes (sifat-sifat) masing -
Tahap 2: Tentukan attributes (sifat-sifat) masing masing entity sesuai kebutuhan database Pelanggan : kd_plg, nm_plg, tgl_lahir, gol_dar, jns_klm, alm_plg, kota, kd_pos, no_telp Penjualan : No_faktur, tgl_faktur Obat : kd_brg, merk, tgl_kedaluarsa, jumlah, satuan, harga Kategori : kd_ktg, nm_ktg Pemasok : kd_pemasok, nm_pemasok, ct_prsn, no_telp, no_fax Pembeliaan : No_order, tgl_order

97 Tahap 3 : Tentukan relationships (hubungan -
Tahap 3 : Tentukan relationships (hubungan hubungan) di antara entities tersebut Pelanggan – penjualan Penjualan – Barang Barang - Kategori Barang – pembeliaan Pembeliaan – pemasok

98 Pelanggan – penjualan Satu konsumen meminta satu atau banyak nomor faktur penjualan obat, satu atau banyak nomor faktur penjualan obatdapat diminta oleh satu dan hanya satu konsumen

99 Penjualan – Barang Satu nomor faktur penjualan obat mencatat satu atau banyak obat, satu obat dicatat pada nol, satu, atau banyak nomor faktur penjualan.

100 Barang - Kategori Satu atau banyak obat dimiliki oleh satu dan hanya satu kategori, satu kategori memiliki satu atau banyak obat.

101 Barang – pembeliaan Satu nomor faktur pembelian obat mencatat satu atau banyak obat, satu obat dicatat pada satu atau banyak nomor faktur penjualan.

102 Pembeliaan – pemasok Satu Supplier mendapatkan satu atau banyak nomor faktur pembelian obat, satu atau banyak nomor faktur pembelian obat didapatkan dari satu dan hanya satu supplier.

103 ERD Lengkap Penjualan Obat

104 Tahap 6: Implementasi Database
Spesifikasi Tabel Konsumen Field name Data type size Null / not null Descrption Kd Plg [PK] Int - Not null Otomatis bertambah dimulai dari 1000, 1001… Nm_plg Char 35 Not Null Nama Lengkap Pelanggan Jns_klm 1 Hanya Boleh diisi satu karakter yaitu : L/P Alm_plg 40 Alamat Pelanggan (nama jalan/lorong dan nmr rumah) Kota 15 Ketika tidak diisi secara otomatis field kota akan terisi dengan kota Palembang namun bila pelanggan mengisi, field kota sesuai dengan yang di isi oleh pelanggan Kd_pos 7 Kode Pos Pelanggan No_tlp 12 Nomor Telepon pelanggan

105 Tahap 6: Implementasi Database
Spesifikasi Tabel Obat Field name Data type size Null / not null Descrption No_obat [PK] Int - Not null Otomatis bertambah dimulai dari 1000, 1001… Merk varchar 35 Not Null Nama Lengkap Pelanggan Tgl_kedaluars datetime Tanggal kedaluarsa obat Jumlah Jumlah persediaan Obat Satun 20 Jenis satuan obat Harga Harga obat ditambah dengan keuntungan

106 Tahap 6: Implementasi Database
Spesifikasi Tabel Beli_Obat Field name Data type size Null / not null Descrption Jml_beli Int - Not null Jumlah pembelian per item produk obat yang dibeli Hara_beli int Not Null Harga dasar sebelum ditambah dengan keuntungan Kd_obat Berelasi dengan kd_obat pada tabel obat No_beli Berelasi dengan no_beli pada tabel pembelian Spesifikasi Tabel Jual_Obat Field name Data type size Null / not null Descrption Jml_jual Int - Not null Jumlah penjualan per item produk obat yang dijual Hara_jual Not Null Harga pada saat penjualan ditambah keuntungan Kd_obat Berelasi dengan kd_obat pada tabel obat No_Fak Berelasi dengan no_fak pada tabel penjualan

107 Tahap 6: Implementasi Database
Spesifikasi Tabel Penjualan Field name Data type size Null / not null Descrption No_fak Int - Not null Otomatis bertambah dimulai dari 1000, 1001… Tgl_jual Char 35 Not Null Tanggal dilakukan penjualan barang Kd_plg Berelasi dengan kd_plg pada tabel pelanggan Spesifikasi Tabel Pembelian Field name Data type size Null / not null Descrption No_beli Int - Not null Otomatis bertambah dimulai dari 1000, 1001… Tgl_beli Char 35 Not Null Tanggal dilakukan pembelian barang Kd_spl Berelasi dengan kd_spl pada tabel supplier

108 Tahap 6: Implementasi Database
Spesifikasi Tabel Kategori Field name Data type size Null / not null Descrption No_ktg [PK] Int - Not null Otomatis bertambah dimulai dari 100, 101… Nm_ktg Char 35 Not Null Nama Lengkap Pelanggan Spesifikasi Tabel Suppier Field name Data type size Null / not null Descrption No_spl [PK] Int - Not null Otomatis bertambah dimulai dari 1000, 1001… Nm_spl Varchar 35 Not Null Nama Lengkap Pelanggan Ct_prsn 40 Nama personal dari perusahaan yang dapat dihubungi No_tlp 12 Nomor telepon. Tidak boleh diisi huruf, harus angka No_fax Nomor fak. Tidak boleh diisi huruf, harus angka

109 Implementasi rancangan ke Teknologi DBMS
SQL Server SQL

110 SQL --Membuat database create database latihan --Mengaktifkan database
use latihan --Melihat database yang telah dibuat sp_helpdb

111 SQL --Membuat tabel pelanggan create table pelanggan (
kd_plg nchar (5) not null, constraint plg_PK primary key (kd_plg), nm_plg char (30) not null, jns_klm char (1) not null constraint ck_jk check (jns_klm = 'P' or jns_klm = 'L'), alm_plg char (35) null, agama varchar (20) not null constraint aga_ma check (agama in ('Islam','Kristen','Katolik','Hindu','Budha','lainnya')), kota char (30) null constraint kot_a default 'Palembang', no_telp char (12) null ) alter table pelanggan with nocheck add constraint ck_JK check (jns_klm = 'P' or jns_klm = 'L')

112 SQL -- membuat tabel kategori create table kategori (
kd_ktg nchar (5) not null primary key, nm_ktg char (30) not null, status char (15) null ); -- membuat tabel barang create tabLe barang ( kd_brg nchar (5) not null, constraint brg_PK primary key (kd_brg), nm_brg char (30) not null, jml_brg numeric constraint jml_h check (jml_brg >= 0 ), satuan char (15), harga numeric constraint hrg_b check (harga >= 0 ), kd_ktg nchar (5), constraint kategori_barang_fk foreign key (kd_ktg) references kategori (kd_ktg)

113 SQL -- membuat tabel penjualan create table penjualan (
no_fak int not null IDENTITY (1000,1), constraint jual_PK primary key (No_fak), tgl_jual datetime, kd_plg nchar (5), constraint jual_pelanggan_fk foreign key (kd_plg) references pelanggan (kd_plg) ); -- membuat tabel det_jual create table det_jual ( jumlah_jual numeric, no_fak int , kd_brg nchar (5), constraint barang_jual_fk foreign key (kd_brg) references barang (kd_brg), constraint jual_barang_fk foreign key (no_fak) references penjualan (no_fak)

114 Teknik Normalisasi 114 114

115 Definisi Normalisasi Normalisasi merupakan teknik analisis data yang mengorganisasikan atribut-atribut data dengan cara mengelompokkan sehingga terbentuk entitas yang non-redundant, stabil, dan fleksible. Normalisasi dilakukan sebagai uji coba pada suatu relasi secara berkelanjutan untuk menentukan apakah relasi itu sudah baik, yaitu dapat dilakukan proses insert,update,delete, dan modifikasi pada satu atau beberapa atribut tanpa mempengaruhi integritas data dalam relasi tersebut.

116 Tujuan dari Normalisasi
Untuk menghilangkan kerangkapan data Untuk mengurangi kompleksitas Untuk mempermudah pemodifikasian data

117 Proses Normalisasi Data diuraikan dalam bentuk tabel, selanjutnya dianalisis berdasarkan persyaratan tertentu ke beberapa tingkat. Apabila tabel yang diuji belum memenuhi persyaratan tertentu, maka tabel tersebut perlu dipecah menjadi beberapa tabel yang lebih sederhana sampai memenuhi bentuk yang optimal.

118 Dependency Fungsional Fungsional penuh Transitif Total

119  Ketergantungan Fungsional
Suatu atribut Y mempunyai ketergantungan fungsi terhadap atribut X, jika dan hanya jika setiap nilai X berhubungan dengan sebuah nilai Y. Definisi diatas dituangkan dalam bentuk notasi X  Y Dibaca : X secara fungsional menentukan Y

120 Ketergantungan Fungsional Penuh
Suatu atribut Y mempunyai ketergantungan fungsional penuh terhadap atribut X, jika Y mempunyai dependensi fungsional terhadap X Y tidak memiliki dependensi terhadap bagian dari X Notasi : X  Y

121 Ketergantungan transitif
Atribut Z mempunyai dependensi transitif terhadap X bila: Y memiliki dependensi fungsional terhadap X Z memiliki dependensi fungsional terhadap Y X  Y  Z

122  Dependensi Total Suatu atribut Y mempunyai ketergantungan total pada atribut X jika: Y memiliki ketergantungan fungsi terhadap X X memiliki ketergantungan fungsi terhadap Y Notasi : X  Y

123 Tahapan Normalisasi Bentuk Tidak Normal Menghilangkan perulangan group
Bentuk Normal Pertama (1NF) Menghilangkan ketergantungan sebagian Bentuk Normal Kedua (2NF) Menghilangkan ketergantungan transitif Bentuk Normal Ketiga (3NF) Menghilangkan anomali-anomali hasil dari ketergantungan fungsional Bentuk Normal Boyce-Codd (BCNF) Menghilangkan Ketergantungan Multivalue Bentuk Normal Keempat (4NF) Menghilangkan anomali-anomali yang tersisa Bentuk Normal Kelima

124 Ketergantungan Fungsional
Definisi Atribut Y pada relasi R dikatakan tergantung fungsional padaatribut X (R.X ---> R.Y), jika dan hanya jika setiap nilai X pada relasi R mempunyai tepat satu nilai Y pada R. R= Relasi / Tabel Y,X = Atribut didalam Tabel R.

125 Contoh Ketergantungan
Tabel PEMASOK-BARANG Ketergantungan fungsional dari tabel PEMASOK- BARANG adalah : No_Pem ---> Nama_Pem No_Pem Nama_Pem P01 Imam_x P02 Yazix P03 Hana

126 FUNCTIONAL DEPENDENCY (FD)
Contoh: Functional Dependency: NRP  Nama Mata_Kuliah, NRP  Nilai Non Functional Dependency: Mata_Kuliah  NRP NRP  Nilai

127 Ketergantungan Fungsional Penuh
Atribut Y pada relasi R dikatakan tergantung fungsional penuh pada atribut X pada relasi R, jika Y tidak tergantung pada subset dari X ( bila X adalah key gabungan). Suatu atribut Y mempunyai dependensi sepenuhnya terhadap atribut X jika Y mempunyai dependensi terhadap X Y tidak mempunyai dependensi terhadap bagian dari X

128 KIRIM-BARANG( No_pem, Na_pem, No_bar, Jumlah)
Ketergantungan fungsional : No-pem --> Na-pem No-bar, No-pem --> Jumlah (Tergantung penuh thd keynya) No_pem Na_pem No_bar Jumlah P01 Bahana B01 1000 B02 1400 B03 2000 P02 Sinar Mulia P03 Harapan

129 Ketergantungan Transitif
Atribut Z pada relasi R dikatakan tergantung transitif pada atribut X , jika atribut Y tergantung pada atribut X pada relasi R dan atribut Z tergantung pada atribut Y pada relasi R. (X  Y, Y  Z , maka X Z )

130 Pengertian Dependensi Transitif
Suatu atribut Z mempunyai dependensi transitif terhadap X jika: Y memiliki dependensi terhadap X dan Z memiliki dependensi terhadap Y X → Z X→Y→Z

131 Contoh Dependensi Transitif
Kuliah Ruang Tempat Waktu Jaringan Komputer Merapi Gedung Utara Senin, Pengantar Basis Data Merbabu Selasa, Matematika I Rama Gedung Selatan Rabu, Sistem Pakar Sinta Kamis, Kecerdasan Buatan Selasa, Kuliah → { Ruang, Waktu } Ruang → Tempat Kuliah → Ruang → Tempat

132 Id_Pelanggan Nama Salesman Area Id_Pelanggan Nama Salesman Area A-001
Andi Farkan Jateng A-002 Kurnia Jati Dian Jabar B-001 Fika Dewi Joned Jatim B-002 Gani Wirawan C-001 Cici Kusuma Id_Pelanggan Nama Salesman Area

133 No_Pesan No_Urut Kode_Item Nama_Item Jumlah No_Pesan No_Urut Kode_Item
06008 1 P1 Pensil 5 2 P2 Buku Tulis 10 3 P3 Penggaris 6 4 P4 Penghapus 06009 P5 Pulpen P6 Spidol 06010 No_Pesan No_Urut Kode_Item Nama_Item Jumlah

134 Id_Pelanggan Nama Salesman Area A-001 Andi Farkan Jateng A-002 Kurnia Jati Dian Jabar B-001 Fika Dewi Joned Jatim B-002 Gani Wirawan C-001 Cici Kusuma Anomali penyisipan: Seorang salesman baru yang bertugas di Jateng tidak dapat dimasukkan dalam tabel sampai salesman tersebut mendapatkan seorang pelanggan Anomali penghapusan: Jika pelanggan A-002 dihapus, informasi bahwa Dian menangani daerah Jabar ikut hilang Anomali peremajaan: Jika katakanlah Farkan mendapat penugasan baru untuk menangani daerah Kalimantan, maka sejumlah baris harus diremajakan agar data tetap konsisten

135 Normalisasi dengan Ketergantungan Fungsional
Dalam perspektif Normalisasi, sebuah basis data dapat dikatakan baik, jika setiap tabel yang menjadi unsur pembentuk basis data tersebut juga telah berada dalam keadaan baik atau normal. Sebuah tabel dapat dikategorikan baik (efisien) atau normal, jika telah memenuhi 3 kriteria berikut: Jika ada dekomposisi (penguraian) tabel, maka dekomposisi-nya dijamin aman (Lossless-Join Decomposotion). Terpeliharanya ketergantungan fungsional pada saat perubahan data (Dependency Preservation). Tidak melanggar Boyce-Code Normal Form (BCNF). Jika kriteria ketiga (BCNF) tidak dapat terpenuhi, maka paling tidak tabel tersebut tidak melanggar bentuk normal tahap ketiga (3nd Normal Form/3NF). Kriteria tersebut merupakan kriteria minimal untuk mendapatkan predikat efisien/normal bagi sebuah tabel.

136 Akan tetapi, dapat juga menerapkan kriteria-kriteria lain yang juga tercakup dalam kerangka normalisasi, walaupun bukan merupakan kriteria-kriteria utama, yang terdiri dari: Bentuk Normal tahap Pertama (1nd Normal Form/1NF) Bentuk Normal tahap Kedua (2nd Normal Form/2NF) Bentuk Normal tahap Ketiga (3nd Normal Form/3NF) Bentuk Normal tahap Keempat (4nd Normal Form/4NF) Bentuk Normal tahap Kelima (5nd Normal Form/5NF) Dekomposisi sendiri merupakan langkah yang paling sering ditempuh dalam proses Normalisasi, jika sebuah tabel tidak memenuhi Bentuk Normal tertentu. Sebuah tabel yang merangkum semua kelompok data yang saling berhubungan biasa disebut sebagai tabel Universal (universal/star table). Tabel Universal (Universal / Star Table) sebuah tabel yang merangkum semua kelompok data yang saling berhubungan dan bukan merupakan tabel yang baik.

137 Berikut contoh sebuah tabel universal yang merupakan rangkuman data mahasiswa, kuliah, dosen, nilai dan jadwal

138 Pengulangan informasi
Dari table universal tersebut, dengan memperhatikan kesamaan dan ketidak samaan data diantara baris-baris data juga dengan memahami hubungan alamiah antar data, kita dapat membentuk KF sebagai berikut: Nim  nama_mhs Nim  alamat_mhs Nim  tgl_lahir Kode_kul  nama_kul Kode_kul  sks Kode_kul  semester Kode_kul  waktu Kode_kul  tempat Kode_kul nama_dos Nama_dos  alamat_dos Nim, kode_kul  indeks_nilai Jika kita memusatkan diri pada table universal tersebut, paling tidak ada 3 kelemahan mendasar yang dapat kita lihat, yaitu: Pengulangan informasi Yang terjadi pada atribut nama_mhs, alamat_mhs dan tgl_lahir yang dinyatakan berulang-ulang sesuai dengan data atribut nim, begitu juga dengan atribut nama_kul, tempat, waktu dan seterusnya.

139 Potensi inkonsistensi data pada operasi pengubahan
Yang terjadi jika ada perubahan pada data nama_mhs, dimana perubahan ini harus dijalarkan keseluruh baris data pada table tersebut untuk nim yang sama. Jika perubahan ini tidak dilakukan, maka KF yang telah ditetapkan akan tergangu, karena kelak akan ada 2 row atau lebih dengan nim yang sama, tapi nama_mhs nya berbeda. Tersembunyinya informasi tertentu Tabel universal dibangun atas dasar keterkaitan antar item-item data. Karena itu table semacam ini tidak akan mampu menampilkan informasi tentang item-item data yang kebetulan belum memiliki keterkaitan dengan item data yang lain. Kelemahan-kelemahan tersebut mengiring kita untuk melakukan dekomposisi, yakni melakukan pemilihan table tersebut menjadi beberapa table dengan mempertimbangkan ketergantungan fungsional yang telah kita dapatkan, dekomposisi dilakukan agar setiap table yang kita gunakan hanya memiliki 1 (satu) KF saja , lebih tepatnya KF minimum

140 Lossless Join Decomposition
Dekomposisi merupakan upaya untuk mendapatkan table yang baik, tapi bila tidak berhati-hati upaya ini justru dapat menghasilkan kesalahan. Dekomposisi yang benar terjadi jika table-tabel hasil dekomposisi kita gabungkan kembali dapat menghasilkan table awal sebelum didekomposisi. Dekomposisi yang benar semacam ini disebut Lossless-Join Decomposition atau Lossless Decomposition (dapat di Indonesia-kan dengan istilah Dekomposisi Aman). Berikut sebuah contoh yang menghasilkan dekomposisi yang tidak aman (Lossy-Join Decomposition). Misalnya ada sebuah table ABC, yang didefinisikan dengan 2 buah table KF yaitu AB dan BC. Kedua KF tersebut diperoleh dari pengamatan terhadap data yang kurang memadai atau karena asumsi yang kurang tepat. A B C A1 100 C1 A2 200 C2 A3 300 C3 A4 C4 Memang dengan isi seperti itu, pernyatan KF yang kedua BC tidak sepenuhnya tepat, karena pada row 2 dan row 4, dengan nilai untuk atribut B yang sama, nilai untuk atribut C nya berbeda.

141 A B C A1 100 C1 A2 200 C2 A3 300 C3 A4 C4

142 Tapi yang ingin kita tekankan disini adalah adanya 2 buah KF itu, mendorong kita untuk medekomposisi table ABC menjadi 2 buah table, yaitu table AB dan Tabel BC sbb: Tabel AB A B A1 100 A2 200 A3 300 A4 Hasil gabungan table AB dan BC A B C A1 100 C1 A2 200 C2 C4 A3 300 C3 A4 Tabel BC B C 100 C1 200 C2 300 C3 C4 Jika table AB dan table BC digabungkan, hasilnya tidak menghasilkan table awal, sebelum dekomposisi, ini yang disebut dengan Lossy Join Decomposition

143 Tapi bila table awal (table ABC) seperti berikut
200 C2 A B C A1 100 C1 A2 200 C2 A3 300 C3 A4 Jika table ABC seperti diatas maka kedua KF dapat dibenarkan, jika dilakukan dekomposisi maka akan menghasilkan table sebagai berikut: A B A1 100 A2 200 A3 300 A4 Kesimpulaan “Karena itulah, KF pada suatu table harus kita tetapkan berdasarkan pengamatan yang teliti dan asumsi yang dapat dipertanggung jawabkan, agar kelak hasil dekomposisinya dapat dibenarkan” B C 100 C1 200 C2 300 C3

144 Dependency Preservation
Dependency preservation (dapat di Indonesia-kan sebagai Pemeliharaan Ketergantungan) merupakan kriteria yang harus dicapai untuk mendapatkan tabel dan basis data yang baik. Ketika melakukan perubahan data, maka harus dapat dijamin agar perubahan tersebut tidak menghasilkan inkonsistensi data yang mengakibatkan KF yang sudah benar menjadi tidak terpenuhi tetapi dalam upaya untuk memelihara KF yang ada untuk tetap terpenuhi tersebut, prosesnya harus dapat dilakukan dengan efisien. Jika ditinjau pada table universal yang telah digambarkan sebelumnya, sudah jelas sangat rapuh didalam memenuhi kriteria dependency preservation. Kalaupun ingin dipaksakan (agar KF yang ada tetap dapat terjaga pada saat ada perubahan yang terjadi), maka upaya pemeliharaan KF tersebut akan berlangsung tidak efisien Katakanlah ada perubahan data Alamat untuk mahasiswa dengan nim=980001, maka perubahan ini harus juga dijalarkan/dilakukan pada atribut alamat_mhs disemua row yang nilai atribut nim_nya berharga

145 Contoh Katakanlah table Mahasiswa dan table Nilai hasil dekomposisi menghasilkan atribut sebagai berikut: Tabel Nilai Nama_kul, Nim, Nama_mhs, Indeks_nilai Dengan 2 KF yaitu Nama_kul, Nim  Indeks_nilai Nim  Nama_mhs Tabel Mahasiswa Nim, Nama_mhs, Alamat_mhs, Tgl_lahir Jika pada table mahasiswa terjadi perubahan data pada atribut alamat_mhs atau pada atribut tgl_lahir, maka perubahan ini tidak perlu dilakukan/dijalarkan pada table nilai, karena pada table ini atribut-atribut tersebut tidak dilibatkan. Tapi jika perubahan terjadi pada atribut nama_mhs pada table mahasiswa, maka perubahan tersebut harus juga dilakukan/dijalarkan ke table nilai, Karena atribut tersebut dilibatkan pada table nilai

146 Jika penjalaran ini hanya dilakukan pada satu baris (row) pertama pada table nilai dengan nilai nim yang sama, dengan nilai nim di table mahasiswa yang nama_mhs-nya diubah tersebut, maka KF nimnama_mhs tidak terpenuhi lagi. Jika demikian perubahan tersebut harus dijalarkan kesemua baris data dengan nilai nim yang sama/sesuai, masalahnya penjalaran perubahan ini tidak efisien dan seharusnya dihindari. Solusinya agar dependency preservation terpenuhi adalah meniadakan/melepaskan atribut nama_mhs dari table nilai, sehingga table nilai menjadi Nim Nama_kul Indeks_nilai