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

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)

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

TERMINOLOGI SISTEM BASIS DATA

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.

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.

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.

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.

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.

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

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)

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

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

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.

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

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.

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

PROSES DESIGN SISTEM BASIS DATA

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

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

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

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

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.

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

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

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

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)

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.

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.

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

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

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

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

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

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.

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

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

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

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

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

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

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

Database Design and Implementation

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

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.

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

Komponen ERD Entitas Atribut Relasi

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

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

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

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.

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

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)

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

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.

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

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

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 :

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

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

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

Kardinalitas

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

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 )

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

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

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

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

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

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

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

AGREGASI ……2 Mengambil MHS Mt. Kuliah Mengikuti Praktikum

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

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.

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

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

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

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

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.

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)

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.

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

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

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

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.

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

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

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

Studi kasus Perancangan Database Perancangan Sistem Informasi Studi kasus Perancangan Database

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

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

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

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

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

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

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

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

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.

ERD Lengkap Penjualan Obat

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

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

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

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

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

Implementasi rancangan ke Teknologi DBMS SQL Server SQL

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

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')

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)

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)

Teknik Normalisasi 114 114

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.

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

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.

Dependency Fungsional Fungsional penuh Transitif Total

 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

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

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

 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

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

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.

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

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

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

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

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 )

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

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

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

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

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

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.

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.

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

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.

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

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.

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

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

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

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 980001

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

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