BAB I: APA ITU BASIS DATA?

1.1 PENDAHULUAN

1. Latar Belakang

Di era informasi dan transformasi digital saat ini, data telah menjadi salah satu aset paling berharga bagi setiap organisasi, perusahaan, institusi pendidikan, maupun pemerintahan. Istilah "Data is the new oil" menggambarkan betapa penting dan bernilainya data ketika dikumpulkan, diorganisasikan, dan diolah dengan tepat untuk mendukung proses pengambilan keputusan strategis.

Setiap aktivitas modern selalu bersinggungan langsung dengan sistem pencatatan dan pengelolaan data dalam volume yang sangat besar, seperti:

• Transaksi finansial dan perbankan digital (transfer dana, pembayaran e-wallet, pencatatan mutasi rekening).
• Transaksi perdagangan elektronik (e-commerce) yang mencakup jutaan katalog produk, histori pesanan, pelacakan pengiriman, dan ulasan pelanggan.
• Sistem layanan kesehatan rumah sakit untuk rekam medis elektronik (electronic health records).
• Sistem informasi akademik perguruan tinggi untuk pengelolaan kartu rencana studi (KRS), presensi, penilaian, dan data kelulusan mahasiswa.
• Media sosial dan platform streaming yang memproses miliaran interaksi pengguna setiap detiknya.

Tanpa adanya mekanisme penyimpanan dan pengelolaan yang terstruktur, data yang berjumlah masif tersebut akan menjadi tumpukan fakta mentah yang tidak teratur, sulit dicari, rentan terhadap kehilangan, dan tidak memberikan manfaat optimal bagi penggunanya.

2. Perkembangan Pengelolaan Data

Secara historis, pengelolaan data mengalami evolusi yang signifikan:

1. Era Pengelolaan Manual (Kertas/Arsip Fisik): Data dicatat di dalam buku besar (ledger), kartu indeks, atau map arsip fisik. Metode ini memiliki banyak kelemahan fatal:

   • Pencarian data membutuhkan waktu yang sangat lama.
   • Risiko kerusakan fisik tinggi akibat kebakaran, banjir, serangga, atau kelembapan.
   • Sulit dilakukan penggandaan dan pembaruan data secara serentak.

2. Era Pemrosesan Berkas Berbasis Komputer (File-Based Systems): Dengan diperkenalkannya komputer digital, data mulai disimpan dalam berkas elektronik terpisah (misalnya file biner, teks datar, atau spreadsheet sederhana). Meskipun lebih cepat daripada sistem manual, pemrosesan berkas menimbulkan masalah baru seperti duplikasi data (redundancy), inkonsistensi data, dan ketergantungan yang kaku antara program aplikasi dan struktur berkas fisik.

3. Era Sistem Basis Data (Database Management System - DBMS): Sebagai jawaban atas keterbatasan pemrosesan berkas, lahirlah konsep Sistem Basis Data. Pada pendekatan ini, data dikelola secara terpusat dan terpadu menggunakan perangkat lunak khusus (DBMS) yang memisahkan definisi data logis dari implementasi penyimpanan fisiknya, menjamin integritas, serta memfasilitasi akses multi-pengguna (multi-user) secara bersamaan dengan aman.

3. Tujuan dan Ruang Lingkup Bab I

Bab ini bertujuan meletakkan fondasi konseptual yang kokoh mengenai apa sebenarnya basis data, mengapa pendekatan basis data menggantikan sistem pemrosesan berkas tradisional, serta bagaimana arsitektur dan komponennya bekerja.

Secara rinci, topik-topik yang dibahas dalam Bab I meliputi:

• 1.1 Pendahuluan: Gambaran umum pentingnya basis data dan latar belakang evolusi pengolahan data.
• 1.2 Konsep Dasar dan Definisi: Membedakan konsep data, basis data, informasi, serta metadata.
• 1.3 Sistem Pengolahan Data dengan Pemrosesan Berkas: Karakteristik dan kelemahan mendasar dari pendekatan berbasis berkas lama.
• 1.4 Karakteristik Pendekatan Basis Data: Konsep abstraksi data (tiga level ANSI/SPARC), model data, bahasa basis data (SQL), dan klasifikasi pengguna/administrator.
• 1.5 Keunggulan yang Didapat dari Penggunaan DBMS: Manfaat sistem relasional, prinsip manajemen transaksi (ACID), struktur mesin DBMS internal, dan ragam arsitektur aplikasi (2-tier, 3-tier, multi-tier).
• 1.6 Sejarah Sistem Basis Data dan Aplikasi Praktis: Kronologi sejarah basis data dari era 1960-an hingga era modern, serta contoh penerapannya di dunia industri.

4. Rangkuman

Basis data bukan sekadar kumpulan tabel atau file komputer, melainkan suatu sistem terorganisir yang dirancang untuk menyimpan, mengelola, memanipulasi, dan menyajikan data secara cepat, akurat, aman, dan konsisten guna mendukung kebutuhan operasional serta pengambilan keputusan organisasi.

BAB I: APA ITU BASIS DATA?

1.2 KONSEP DASAR DAN DEFINISI

Untuk memahami sistem basis data secara komprehensif, perlu dipahami terlebih dahulu beberapa konsep kunci yang menjadi landasan utamanya, yaitu data, basis data, informasi, serta metadata.

1.2.1 Data dan Basis Data

A. Definisi Data

Data berasal dari kata Latin datum yang berarti fakta, keterangan, atau representasi dasar dari suatu objek, entitas, peristiwa, transaksi, atau kondisi di dunia nyata (real world). Data disajikan dalam bentuk simbol, angka, teks, gambar, suara, atau kombinasi di antaranya yang belum memiliki makna signifikan jika berdiri sendiri secara terisolasi.

Karakteristik Data:

1. Bersifat objektif dan mencerminkan fakta empiris apa adanya.
2. Belum memiliki konteks atau keterkaitan fungsional bagi penerimanya.
3. Menjadi bahan mentah (raw material) untuk proses pengolahan lebih lanjut.

Contoh Data:

• 2024001
• Ahmad Fadil
• Teknik Informatika
• 3.85
• 2024-09-15

Jika angka 3.85 dilihat terpisah tanpa konteks, penerima tidak dapat mengetahui apakah angka tersebut adalah Indeks Prestasi Kumulatif (IPK), nilai tukar mata uang, ukuran panjang, atau berat barang.

B. Definisi Basis Data (Database)

Secara etimologi, basis berarti markas, gudang, tempat bersarang, atau tempat berkumpul; sedangkan data adalah representasi fakta dunia nyata.

Secara formal dalam ilmu komputer:

Basis Data (Database) adalah sekumpulan data yang saling berhubungan secara logis (logically related data), terorganisasi dan tersimpan secara terpadu di dalam media penyimpanan komputer, serta dirancang sedemikian rupa agar dapat diakses, dikelola, diperbarui, dan dimanipulasi dengan mudah, cepat, dan aman oleh berbagai program aplikasi maupun pengguna (multi-user).

C. Karakteristik Utama Basis Data

1. Terpadu (Integrated): Basis data mengonsolidasikan data dari berbagai sumber ke dalam satu kesatuan struktur logis, sehingga menghilangkan duplikasi yang tidak diperlukan.
2. Dapat Dipakai Bersama (Shared): Data dapat diakses secara simultan oleh banyak pengguna yang berbeda untuk tujuan yang beragam tanpa saling mengganggu.
3. Kemandirian Data (Data Independence): Struktur data fisik dapat diubah tanpa mengharuskan perubahan pada kode program aplikasi yang menggunakannya.
4. Keamanan & Integritas Terjamin (Security & Integrity): Terdapat aturan validasi (constraints) yang mencegah masuknya data tidak valid, serta pembatasan hak akses (authorization).

+---------------------------------------------------------------+
|                       SISTEM BASIS DATA                       |
|                                                               |
|  [ Pengguna / User ] <---> [ Aplikasi Klien ]                 |
|                                  ^                            |
|                                  | (Query / SQL)              |
|                                  v                            |
|       +-----------------------------------------------+       |
|       |    DBMS (Database Management System)          |       |
|       |  (Katalog Sistem, Parser, Optimizer, Engine)  |       |
|       +-----------------------------------------------+       |
|                                  ^                            |
|                                  | (I/O Fisik)                |
|                                  v                            |
|          +-----------------------------------------+          |
|          |     Basis Data Tersimpan (Storage)      |          |
|          |  - Data Pengguna (Tabel, Rekaman)       |          |
|          |  - Metadata (Kamus Data / Skema)        |          |
|          |  - Indeks                               |          |
|          +-----------------------------------------+          |
+---------------------------------------------------------------+

1.2.2 Data versus Informasi

Meskipun sering kali digunakan secara bergantian dalam percakapan sehari-hari, istilah Data dan Informasi memiliki perbedaan yang sangat mendasar.

A. Definisi Informasi

Informasi adalah data yang telah diproses, diorganisasikan, distrukturkan, dan ditempatkan dalam suatu konteks tertentu sehingga memiliki makna, nilai tambah, dan kegunaan nyata bagi penerima untuk meningkatkan pemahaman atau mendukung pengambilan keputusan (decision making).

B. Tabel Perbandingan Data vs Informasi

C. Siklus Pengolahan Data (Data Processing Cycle)

Transformasi dari data menjadi informasi berlangsung melalui serangkaian tahapan:

graph LR
    A[Input: Data Mentah] --> B[Processing: Pengolahan/DBMS]
    B --> C[Output: Informasi Berguna]
    C --> D[Penerima / Pengambil Keputusan]
    D -.->|Umpan Balik / Feedback| A

1. Input: Data mentah dikumpulkan dan dimasukkan ke dalam sistem.
2. Processing: Data diklasifikasikan, dihitung, diurutkan, difilter, dan diagregasi.
3. Output: Menghasilkan informasi berupa laporan (report), grafik (dashboard), atau ringkasan tabel.
4. Penyimpanan (Storage): Baik data mentah maupun hasil olahan disimpan dalam basis data untuk kebutuhan di masa mendatang.

D. Kriteria Kualitas Informasi

Informasi yang berkualitas harus memenuhi dimensi berikut:

• Akurat (Accurate): Bebas dari kesalahan (error-free) dan mencerminkan keadaan yang sebenarnya.
• Tepat Waktu (Timely): Tersedia pada saat dibutuhkan oleh pengambil keputusan, sebelum kehilangan relevansi.
• Relevan (Relevant): Sesuai dengan konteks kebutuhan penerima informasi.
• Lengkap (Complete): Menyajikan seluruh fakta esensial tanpa ada variabel penting yang tertinggal.

1.2.3 Metadata

A. Definisi Metadata

Metadata secara sederhana sering didefinisikan sebagai:

"Data tentang data" (data about data).

Metadata adalah informasi terstruktur yang mendeskripsikan karakteristik, struktur, definisi, konteks, batasan, dan aturan dari data yang disimpan di dalam basis data.

Dalam sistem basis data, metadata disimpan dan dikelola secara otomatis oleh DBMS di dalam suatu area khusus yang dinamakan Kamus Data (Data Dictionary) atau Katalog Sistem (System Catalog).

B. Jenis dan Komponen Informasi dalam Metadata

Metadata mencakup rincian teknis mengenai:

1. Definisi Objek Skema: Nama-nama tabel, view, indeks, prosedur, dan fungsi.
2. Struktur Kolom (Field Specification):
   • Nama atribut/kolom (misalnya: nim, nama_mhs, tgl_lahir).
   • Tipe data (misalnya: VARCHAR(50), INTEGER, DATE, DECIMAL(4,2)).
   • Ukuran dan panjang maksimum data yang diizinkan.
3. Batasan Integritas (Integrity Constraints):
   • Batasan Kunci Utama (Primary Key).
   • Batasan Kunci Tamu (Foreign Key) dan relasi antar-tabel.
   • Batasan Keunikan (Unique Constraint).
   • Batasan Keharusan Nilai (NOT NULL Constraint).
   • Batasan Nilai (CHECK Constraint, rentang nilai nilai minimal/maksimal).
4. Otoritas dan Hak Akses: Siapa saja pengguna yang berhak membaca (SELECT), menambah (INSERT), mengubah (UPDATE), atau menghapus (DELETE) data tabel tersebut.

C. Contoh Konkret Metadata pada Tabel Basis Data

Perhatikan tabel relasional sederhana berikut:

Tabel Mahasiswa:

Pada contoh di atas:

• Nilai "230101", "Budi Santoso", "3.75" adalah Data.
• Penjelasan bahwa "Kolom NIM bertipe VARCHAR(10), bersifat Primary Key, Not Null, dan kolom IPK bertipe DECIMAL(3,2) dengan nilai antara 0.00 hingga 4.00" adalah Metadata.

D. Mengapa Metadata Sangat Penting?

1. Memungkinkan Kemandirian Data (Data Independence): Karena program aplikasi tidak perlu lagi mencatat format fisik data di dalam baris kodenya, melainkan cukup berkonsultasi dengan metadata melalui DBMS.
2. Penegakan Validitas Otomatis: DBMS langsung menolak transaksi yang melanggar batasan yang tercantum pada metadata.
3. Dokumentasi Terpusat: Pengembang aplikasi lain dapat dengan mudah memahami skema sistem tanpa perlu membaca manual teknis yang terpisah.

Rangkuman

• Data adalah fakta mentah yang belum diolah.
• Informasi adalah data yang telah diolah dan diberi konteks sehingga bermakna bagi pengambil keputusan.
• Basis Data adalah kumpulan data logis yang terorganisasi dan tersimpan terpadu di komputer.
• Metadata adalah deskripsi struktural mengenai data ("data tentang data") yang dikelola oleh DBMS di dalam kamus data.

BAB I: APA ITU BASIS DATA?

1.3 SISTEM PENGOLAHAN DATA DENGAN PEMROSESAN BERKAS

Sebelum munculnya teknologi Sistem Manajemen Basis Data (Database Management System - DBMS), sistem pengolahan informasi dalam dunia bisnis dan komputasi bergantung pada pendekatan Pemrosesan Berkas Tradisional (Traditional File-Processing System).

Pada pendekatan ini, setiap departemen atau unit kerja biasanya membangun dan memelihara aplikasi komputer mereka sendiri beserta berkas (file) datanya masing-masing.

1.3.1 Karakteristik Pemrosesan Berkas

Sistem pemrosesan berkas memiliki beberapa karakteristik mendasar yang membedakannya secara tajam dari sistem basis data modern:

1. Berorientasi pada Program Aplikasi (Program-Oriented)

Struktur berkas fisik, tata letak rekaman (record layout), dan tipe data ditentukan secara langsung di dalam kode program aplikasi (misalnya ditulis menggunakan bahasa COBOL, Pascal, Fortran, C, atau RPG). Jika struktur berkas berubah, seluruh program aplikasi yang membaca berkas tersebut harus diubah kodenya (re-coded) dan dikompilasi ulang.

2. Desentralisasi dan Fragmentasi Data

Setiap departemen memiliki berkas terpisah yang didesain hanya untuk melayani fungsi spesifik departemen tersebut:

• Departemen Penjualan memelihara berkas Pelanggan_Penjualan.dat.
• Departemen Akuntansi memelihara berkas Pelanggan_Keuangan.dat.
• Departemen Pengiriman memelihara berkas Pelanggan_Ekspedisi.dat.

Meskipun objek yang dicatat sama (yaitu data pelanggan), masing-masing pihak membuat berkas sendiri tanpa ada integrasi logis.

3. Organisasi Berkas Konvensional

Data disimpan dalam bentuk file teks datar (flat file) atau file biner pada media penyimpanan sekunder (pita magnetik atau disket), dengan metode pengorganisasian:

• Sekuensial (Sequential): Data dibaca satu per satu dari awal hingga akhir berkas.
• Acak / Langsung (Direct/Random): Menggunakan fungsi matematika (hashing) untuk menghitung alamat penyimpanan rekaman.
• Sekuensial Berindeks (Indexed Sequential): Menggunakan tabel indeks pembantu untuk mempercepat pencarian.

+-------------------------------------------------------------+
|        ARSITEKTUR PEMROSESAN BERKAS TRADISIONAL             |
|                                                             |
|   [ Program Aplikasi 1 ]  ------->  [ Berkas Data 1 ]       |
|    (Bagian Akademik)                 (File Mahasiswa.dat)   |
|                                                             |
|   [ Program Aplikasi 2 ]  ------->  [ Berkas Data 2 ]       |
|    (Bagian Perpustakaan)             (File Anggota.dat)     |
|                                                             |
|   [ Program Aplikasi 3 ]  ------->  [ Berkas Data 3 ]       |
|    (Bagian Keuangan/SPP)             (File Pembayaran.dat)  |
|                                                             |
|   *Data Mahasiswa diduplikasi di 3 file berbeda!            |
+-------------------------------------------------------------+

1.3.2 Kekurangan Sistem Pemrosesan Berkas

Pendekatan berbasis berkas tradisional memicu berbagai kelemahan krusial yang menyulitkan pengelolaan data dalam skala besar. Kelemahan-kelemahan utama tersebut antara lain:

1. Redundansi dan Inkonsistensi Data (Data Redundancy and Inconsistency)

• Redundansi: Fakta yang sama dicatat berulang-ulang di beberapa tempat penyimpanan. Contohnya, nama dan alamat mahasiswa tersimpan di berkas akademik, berkas perpustakaan, dan berkas keuangan. Hal ini memboroskan kapasitas media penyimpanan dan waktu input.
• Inkonsistensi: Ketika seorang mahasiswa berpindah alamat tempat tinggal, pembaruan mungkin hanya dilakukan pada berkas akademik, sementara berkas di bagian keuangan belum diperbarui. Akibatnya, sistem memiliki dua alamat berbeda untuk satu orang mahasiswa yang sama, sehingga menurunkan keandalan data.

2. Ketergantungan Data-Program (Data Dependence)

Pada sistem pemrosesan berkas, format dan lokasi fisik penyimpanan data terikat erat dengan kode program aplikasi:

• Jika panjang kolom kode pos diubah dari 5 karakter menjadi 10 karakter, maka semua program yang membaca berkas tersebut harus dirombak kodenya dan dikompilasi ulang.
• Tidak ada lapisan abstraksi antara representasi logika data dan representasi fisik di disk.

3. Kesulitan dalam Mengakses Data (Difficulty in Accessing Data)

Untuk memenuhi permintaan data yang tidak rutin (ad-hoc query), pengguna tidak memiliki sarana mudah untuk langsung menanyakan data tersebut.

• Contoh Kasus: Pimpinan universitas meminta daftar mahasiswa program studi Informatika yang ber-IPK > 3.5 dan belum melunasi biaya SPP.
• Pada pemrosesan berkas, staf IT harus menulis program baru dari awal atau mengekspor berbagai berkas dan memprosesnya secara manual, yang memakan waktu berhari-hari.

4. Isolasi Data (Data Isolation)

Karena data tersebar di berbagai berkas yang mungkin memiliki format rekaman yang berbeda-beda, bahasa pemrograman yang berbeda, atau bahkan sistem operasi yang berlainan, menyatukan data antar-departemen menjadi pekerjaan integrasi yang sangat rumit dan rentan galat.

5. Masalah Integritas Data (Integrity Problems)

Nilai data yang disimpan di dalam basis data harus memenuhi batasan konsistensi tertentu (consistency constraints).

• Contoh: Saldo rekening bank tidak boleh bernilai negatif (< 0), atau nilai IPK harus berada pada rentang 0.00 hingga 4.00.
• Pada sistem pemrosesan berkas, aturan-aturan ini harus dikodekan langsung ke dalam logika setiap program aplikasi. Ketika aturan baru ditambahkan, seluruh program terkait harus diperiksa dan disesuaikan ulang satu per satu.

6. Anomali Akses Bersamaan (Concurrent-Access Anomalies)

Ketika banyak pengguna mencoba membaca dan mengubah berkas yang sama secara bersamaan, sistem pemrosesan berkas tidak memiliki mekanisme penguncian (locking) dan kontrol konkurensi terpadu:

• Dua orang kasir dapat menjual tiket kursi pesawat yang sama secara bersamaan (lost update), karena tidak ada mekanisme transaksi yang mengisolasi eksekusi kedua program tersebut.

7. Masalah Keamanan Data (Security Problems)

Tidak semua pengguna sistem informasi boleh memiliki akses penuh ke seluruh rekaman data:

• Dosen hanya boleh melihat dan memasukkan nilai mahasiswa di kelasnya, staf administrasi boleh melihat data kontak, sedangkan mahasiswa hanya boleh melihat nilainya sendiri.
• Pada sistem pemrosesan berkas, sangat sulit memberikan hak akses selektif hingga tingkat kolom atau baris tertentu. Umumnya, jika berkas dibuka, pengguna dapat melihat seluruh isi file tersebut.

8. Masalah Atomisitas Pembaruan (Atomicity Problems)

Sebuah proses sering kali melibatkan serangkaian langkah pembaruan yang harus berhasil secara keseluruhan atau tidak sama sekali:

• Contoh: Transfer uang dari Rekening A ke Rekening B melibatkan dua langkah:
  1. Kurangi saldo Rekening A sebesar Rp 500.000,-.
  2. Tambahkan saldo Rekening B sebesar Rp 500.000,-.
• Jika listrik padam atau sistem crash di antara langkah 1 dan langkah 2, uang akan hilang dari sistem. Sistem pemrosesan berkas tidak memiliki fitur rollback otomatis untuk mengembalikan kondisi data ke keadaan semula.

Perbandingan: Pemrosesan Berkas vs Pendekatan Basis Data

Rangkuman

Keterbatasan struktural pada sistem pemrosesan berkas konvensional menjadi pendorong utama lahirnya paradigma Sistem Manajemen Basis Data (DBMS), yang menempatkan data sebagai sumber daya bersama yang terlepas dari aplikasi tertentu dan dikendalikan secara tersentralisasi.

BAB I: APA ITU BASIS DATA?

1.4 KARAKTERISTIK PENDEKATAN BASIS DATA

Pendekatan basis data mentransformasi cara sistem informasi menangani data dengan memisahkan definisi dan struktur data dari kode program aplikasi, serta menyediakan mekanisme antarmuka seragam bagi berbagai jenis pengguna.

1.4.1 Cara Pandang Data (Data Abstraction)

Tujuan utama sistem basis data adalah menyediakan cara pandang abstrak mengenai data kepada pengguna, yaitu menyembunyikan kerumitan teknis bagaimana data sebenarnya disimpan dan dikelola pada media fisik.

A. Arsitektur Tiga Tingkat (ANSI/SPARC)

Arsitektur standar sistem basis data dibagi menjadi tiga tingkatan abstraksi:

+-------------------------------------------------------------+
|               TINGKAT VIEW / EKSTERNAL                      |
|   [ View Mahasiswa ]    [ View Dosen ]    [ View Keuangan ] |
+-------------------------------------------------------------+
                              ^
                              | (Logical Data Independence)
                              v
+-------------------------------------------------------------+
|               TINGKAT KONSEPTUAL / LOGIKAL                  |
|     Skema Komunitas: Entitas, Atribut, Relasi, Batasan      |
|     (Tabel Mahasiswa, Tabel KRS, Tabel Mata_Kuliah)         |
+-------------------------------------------------------------+
                              ^
                              | (Physical Data Independence)
                              v
+-------------------------------------------------------------+
|               TINGKAT FISIK / INTERNAL                      |
|     Penyimpanan Disk, Struktur File B-Tree/Hash,            |
|     Alokasi Byte, Kompresi, Pengindeksan Fisik              |
+-------------------------------------------------------------+

1. Tingkat Fisik (Physical / Internal Level):

   • Tingkat abstraksi paling rendah yang menjelaskan bagaimana (how) data sebenarnya disimpan secara fisik di media penyimpanan (hard disk, SSD).
   • Menjelaskan rincian struktur data tingkat rendah, metode pengindeksan (B-Tree, Hashing), representasi blok, alokasi byte, serta algoritma kompresi atau enkripsi.

2. Tingkat Konseptual (Conceptual / Logical Level):

   • Menjelaskan data apa saja (what) yang disimpan di dalam basis data serta hubungan logis antar-data tersebut.
   • Menggambarkan keseluruhan basis data bagi suatu komunitas pengguna tanpa memperhatikan detail fisik penyimpanan.
   • Terdiri dari definisi tabel, atribut, relasi antar-tabel, dan batasan integritas (integrity constraints). Tingkat ini dirancang oleh administrator basis data (DBA).

3. Tingkat Pandangan / Eksternal (View / External Level):

   • Tingkat abstraksi tertinggi yang menggambarkan hanya bagian basis data yang relevan bagi kelompok pengguna tertentu.
   • Menyembunyikan bagian data yang tidak diperlukan atau yang bersifat rahasia.
   • Contoh: Mahasiswa hanya dapat melihat nilai dan KRS miliknya sendiri melalui portal akademik, sedangkan bagian keuangan melihat status pembayaran tagihan tanpa melihat detail transkrip nilai akademik.

B. Kemandirian Data (Data Independence)

Arsitektur tiga tingkat menghasilkan kemampuan penting yang disebut Kemandirian Data:

• Kemandirian Data Fisik (Physical Data Independence): Kemampuan untuk memodifikasi skema fisik (seperti mengubah media penyimpanan dari HDD ke SSD, membuat indeks baru, menyusun ulang blok data) tanpa harus mengubah skema konseptual atau program aplikasi.
• Kemandirian Data Logika (Logical Data Independence): Kemampuan untuk mengubah skema konseptual (seperti menambah atribut baru atau memecah tabel) tanpa harus mengubah skema eksternal atau program aplikasi yang tidak menggunakan perubahan tersebut.

1.4.2 Model Data

Model Data adalah sekumpulan perangkat konseptual (berupa notasi, aturan, dan simbol) yang digunakan untuk mendeskripsikan data, hubungan antar-data, semantik data, serta batasan-batasan konsistensi data.

Model data dikelompokkan ke dalam beberapa kategori utama:

1. Model Berbasis Objek (Object-Based Data Models)

Model ini menggunakan konsep entitas, objek, atribut, dan relasi logis:

• Model Entitas-Relasional (Entity-Relationship Model - ERM): Menggambarkan dunia nyata sebagai kumpulan entitas (objek yang dapat diidentifikasi secara unik) dan relasi antar-entitas tersebut. Model ini sangat populer untuk perancangan basis data konseptual melalui ER-Diagram (ERD).
• Model Berorientasi Objek (Object-Oriented Data Model - OODM): Menggabungkan konsep pemrograman berorientasi objek (kelas, enkapsulasi data, metode/operasi, pewarisan/inheritance) langsung ke dalam basis data.

2. Model Berbasis Rekaman (Record-Based Data Models)

Model yang menstrukturkan data ke dalam format rekaman dengan ukuran tetap:

• Model Relasional (Relational Model): Model paling dominan dalam industri perangkat lunak modern. Diperkenalkan oleh Dr. Edgar F. Codd (IBM) pada tahun 1970. Data direpresentasikan dalam bentuk sekumpulan tabel berdimensi dua (disebut relasi), yang tersusun atas baris (tuple / record) dan kolom (attribute / field).
• Model Jaringan (Network Model): Data direpresentasikan sebagai sekumpulan rekaman, dan relasi antar-rekaman dinyatakan dalam bentuk tautan graf (links/pointers). Mendukung relasi banyak-ke-banyak (many-to-many).
• Model Hierarkis (Hierarchical Model): Data disusun dalam struktur hierarki pohon (tree structure) yang memiliki satu simpul akar (root node), di mana setiap simpul anak hanya boleh memiliki satu simpul induk (parent-child relationship / 1:N).

1.4.3 Bahasa Basis Data (Database Languages)

Untuk berinteraksi dengan DBMS, sistem menyediakan bahasa khusus yang terstandardisasi, umumnya berbasis SQL (Structured Query Language), yang terbagi ke dalam beberapa sub-bahasa fungsional:

1. Data Definition Language (DDL)

Digunakan untuk mendefinisikan, mengubah, dan menghapus struktur skema basis data serta objek-objeknya (tabel, view, index):

• CREATE: Membuat database, tabel, atau view baru.
• ALTER: Mengubah struktur tabel (menambah kolom, mengubah tipe data).
• DROP: Menghapus objek basis data secara permanen.
• TRUNCATE: Mengosongkan seluruh isi data tabel tanpa menghapus strukturnya.

2. Data Manipulation Language (DML)

Digunakan untuk mengakses, memanipulasi, dan memproses data yang tersimpan di dalam tabel:

• DML Deklaratif / Non-Prosedural: Pengguna hanya menspesifikasikan data apa yang diinginkan tanpa perlu memerinci bagaimana langkah algoritma mengambilnya. Contohnya kueri SQL:
  • SELECT: Menampilkan data yang memenuhi kriteria tertentu.
  • INSERT: Menambahkan rekaman data baru ke dalam tabel.
  • UPDATE: Memperbarui nilai data yang sudah ada.
  • DELETE: Menghapus rekaman data tertentu dari tabel.
• DML Prosedural: Mengharuskan pengguna menspesifikasikan urutan instruksi dan alur pengambilan data langkah demi langkah.

3. Data Control Language (DCL)

Digunakan untuk mengatur hak akses (privileges) dan keamanan akun pengguna:

• GRANT: Memberikan izin akses kepada pengguna tertentu.
• REVOKE: Mencabut kembali izin akses yang pernah diberikan.

4. Transaction Control Language (TCL)

Digunakan untuk mengendalikan jalannya transaksi:

• COMMIT: Menyimpan perubahan transaksi secara permanen ke disk.
• ROLLBACK: Membatalkan transaksi dan mengembalikan data ke keadaan sebelum transaksi dimulai.
• SAVEPOINT: Menandai titik tertentu di dalam transaksi yang dapat dijadikan acuan pembatalan parsial.

1.4.4 Pengguna Basis Data dan Administrator

Pengguna sistem basis data diklasifikasikan berdasarkan peran dan cara interaksinya dengan sistem:

1. Database Administrator (DBA)

Orang atau tim yang memegang kendali pusat atas keseluruhan sistem basis data. Tanggung jawab DBA mencakup:

• Perancangan dan modifikasi skema basis data konseptual dan fisik.
• Menetapkan kebijakan otorisasi, hak akses, dan keamanan data.
• Menentukan strategi pencadangan (backup) dan pemulihan (recovery).
• Pemantauan kinerja (performance monitoring) dan penyetelan sistem (query tuning).
• Penanganan reorganisasi penyimpanan dan ketersediaan sistem (high availability).

2. Pengembang Aplikasi (Application Programmers)

Tenaga profesional perangkat lunak yang menulis kode aplikasi (menggunakan Java, PHP, Python, C#, JavaScript, Go) yang berinteraksi dengan DBMS melalui pemanggilan kueri SQL atau API database (ODBC/JDBC/ORM).

3. Pengguna Mahir (Sophisticated Users / Data Analysts)

Pengguna yang berinteraksi langsung dengan sistem basis data tanpa melalui program aplikasi jadi, melainkan menulis kueri SQL analitik tingkat lanjut atau menggunakan perkakas pemrosesan data (seperti perkakas BI, Tableau, Power BI, Python/R) untuk eksplorasi dan analisis data bisnis.

4. Pengguna Awam / Akhir (Naïve / End Users)

Pengguna yang berinteraksi dengan sistem basis data melalui antarmuka grafis (GUI) aplikasi yang telah disediakan, tanpa perlu mengetahui adanya basis data atau bahasa SQL di balik layar. Contohnya: kasir toko kelola minimarket, nasabah di mesin ATM, atau pengguna aplikasi pemesanan tiket online.

Rangkuman

• Sistem basis data menyediakan abstraksi tiga tingkat (Fisik, Konseptual, Eksternal) yang menjamin kemandirian data.
• Model Data (khususnya Model Relasional) menyediakan kerangka matematis dan konseptual untuk menyusun hubungan antar-entitas.
• Interaksi dilakukan melalui bahasa basis data terpadu (DDL, DML, DCL, TCL).
• Berbagai pemangku kepentingan mulai dari DBA, Pengembang, Analis, hingga Pengguna Akhir berkolaborasi dalam ekosistem basis data.

BAB I: APA ITU BASIS DATA?

1.5 KEUNGGULAN YANG DIDAPAT DARI PENGGUNAAN DBMS

Penerapan Database Management System (DBMS) menghadirkan lompatan efisiensi, keandalan, dan keamanan yang sangat besar dibandingkan metode pengolahan berkas konvensional.

1.5.1 Keunggulan Sistem Relasional

Sistem Manajemen Basis Data Relasional (Relational DBMS - RDBMS) merupakan model sistem basis data yang paling luas diadopsi di seluruh dunia. Keunggulan utamanya meliputi:

1. Pengurangan Redundansi Data: Melalui teknik perancangan yang tepat dan proses normalisasi, data disimpan hanya pada satu tempat logis. Pengulangan data yang tidak perlu dapat ditekan hingga tingkat minimal, menghemat kapasitas penyimpanan dan menghilangkan pemborosan sumber daya.

2. Penghindaran Inkonsistensi Data: Dengan minimnya duplikasi, setiap perubahan nilai data (pembaruan alamat, status pembayaran, nomor telepon) cukup dilakukan satu kali dan otomatis terefleksi ke seluruh bagian sistem.

3. Integritas Data Terpelihara (Data Integrity): RDBMS menyediakan mekanisme penegakan batasan (constraints) langsung pada level mesin basis data:

   • Entity Integrity: Setiap baris memiliki kunci utama (Primary Key) unik dan tidak boleh bernilai NULL.
   • Referential Integrity: Relasi antar-tabel dijamin melalui Foreign Key, mencegah adanya data anak (child record) yang merujuk pada data induk yang tidak ada (orphan records).
   • Domain Integrity: Nilai masukan dibatasi sesuai tipe dan rentang nilai yang sah (CHECK constraint).

4. Penggunaan Data Bersama (Data Sharing): Basis data dapat diakses oleh banyak pengguna dan aplikasi secara simultan tanpa terjadi konflik data.

5. Standarisasi dan Penegakan Kebijakan Terpusat: Nama kolom, format tanggal, aturan penomoran, serta format mata uang dikelola secara seragam melalui kamus data terpusat (centralized data dictionary).

6. Keamanan Data yang Tangguh (Data Security): DBMS menyediakan otorisasi berbasis peran (Role-Based Access Control), enkripsi data saat transit dan saat tersimpan (data at rest), serta pencatatan jejak audit (audit trail).

1.5.2 Manajemen Transaksi

Salah satu fitur paling vital dari DBMS perusahaan adalah kemampuannya dalam mengelola Transaksi.

Transaksi adalah kumpulan satu atau lebih instruksi operasi basis data (baca/tulis) yang diperlakukan sebagai satu kesatuan unit kerja logis tunggal (single logical unit of work).

A. Prinsip ACID

Agar keandalan dan konsistensi data tetap terjaga meskipun terjadi kegagalan sistem (crash) atau akses konkuren simultan, DBMS menjamin sifat ACID:

+-----------------------------------------------------------------------+
|                             PRINSIP ACID                              |
+---+---------------+---------------------------------------------------+
| A | Atomicity     | All or Nothing (Berhasil semua atau batal semua)  |
| C | Consistency   | Menjaga aturan & batasan data tetap valid         |
| I | Isolation     | Transaksi yang berjalan bersamaan tidak bentrok   |
| D | Durability    | Hasil commit tersimpan permanen walau mati lampu  |
+---+---------------+---------------------------------------------------+

1. Atomicity (Keutuhan / Atomisitas):

   • Transaksi bersifat "semua atau tidak sama sekali" (all-or-nothing).
   • Jika satu instruksi di dalam rangkaian transaksi gagal dieksekusi, maka seluruh instruksi yang telah dijalankan sebelumnya dalam transaksi tersebut akan dibatalkan (ROLLBACK), sehingga basis data kembali ke keadaan semula.

2. Consistency (Konsistensi):

   • Eksekusi transaksi harus membawa basis data dari satu keadaan konsisten yang valid ke keadaan konsisten valid lainnya.
   • Semua batasan integritas (saldo rekening tidak minus, foreign key valid) tidak boleh dilanggar.

3. Isolation (Keterisolasian):

   • Walaupun banyak transaksi dieksekusi secara konkuren (bersamaan waktu), hasil dari setiap transaksi harus terisolasi seolah-olah transaksi tersebut dieksekusi secara berurutan (serializable).
   • Transaksi yang sedang berjalan tidak boleh melihat data sementara yang belum di-commit oleh transaksi lain (mencegah dirty read).

4. Durability (Ketahanan / Daya Tahan):

   • Setelah suatu transaksi berhasil diselesaikan dan di-commit, segala perubahan yang dihasilkannya bersifat permanen dan tidak akan hilang meskipun sesaat kemudian terjadi kegagalan daya (power failure) atau sistem mati mendadak. DBMS mencatat transaksi di dalam transaction log pada disk.

1.5.3 Struktur Sistem Basis Data

Secara internal, arsitektur perangkat lunak DBMS terbagi menjadi beberapa modul fungsional utama:

                  [ Kueri SQL / Program Aplikasi ]
                                 |
                                 v
+-----------------------------------------------------------------+
|                       QUERY PROCESSOR                           |
|  +----------------------+  +---------------------------------+  |
|  | DDL Interpreter      |  | DML Compiler & Organizer        |  |
|  +----------------------+  +---------------------------------+  |
|  +-----------------------------------------------------------+  |
|  | Query Evaluation Engine                                   |  |
|  +-----------------------------------------------------------+  |
+-----------------------------------------------------------------+
                                 |
                                 v
+-----------------------------------------------------------------+
|                       STORAGE MANAGER                           |
|  +---------------------------------+  +----------------------+  |
|  | Authorization & Integrity Mgr   |  | Transaction Manager  |  |
|  +---------------------------------+  +----------------------+  |
|  +---------------------------------+  +----------------------+  |
|  | Buffer Manager                  |  | File Manager         |  |
|  +---------------------------------+  +----------------------+  |
+-----------------------------------------------------------------+
                                 |
                                 v
+-----------------------------------------------------------------+
|                         DISK STORAGE                            |
|   [ Data Files ]  [ Data Dictionary ]  [ Indices ]  [ Logs ]    |
+-----------------------------------------------------------------+

1. Pemroses Kueri (Query Processor)

• DDL Interpreter: Menerjemahkan pernyataan DDL (seperti CREATE TABLE) dan mencatat definisi objek baru tersebut ke dalam kamus data (data dictionary).
• DML Compiler: Mengubah kueri DML (seperti SELECT ... WHERE) menjadi instruksi tingkat rendah yang dapat dimengerti oleh mesin evaluasi.
• Query Evaluation Engine: Menjalankan instruksi tingkat rendah hasil kompilasi kueri dan memilih rencana eksekusi yang paling optimal (Query Optimization).

2. Manajer Penyimpanan (Storage Manager)

Merupakan modul program yang bertugas menyediakan antarmuka antara data tingkat rendah yang berada di disk dengan kueri aplikasi:

• Authorization and Integrity Manager: Memeriksa apakah pengguna memiliki hak akses yang sah dan menguji apakah data memenuhi batasan integritas.
• Transaction Manager: Menjamin bahwa transaksi berjalan sesuai prinsip ACID tanpa konflik dengan transaksi konkuren lainnya.
• File Manager: Mengatur alokasi ruang penyimpanan pada disk dan struktur data yang digunakan untuk merepresentasikan berkas.
• Buffer Manager: Bertanggung jawab mengambil blok data dari disk ke dalam memori utama (RAM) dan menentukan halaman memori mana yang harus di-cache untuk mempercepat performa I/O.

1.5.4 Arsitektur Aplikasi

Berdasarkan penempatan pemrosesan logika bisnis, antarmuka pengguna, dan basis data, arsitektur aplikasi basis data terbagi menjadi beberapa model:

1. Arsitektur Terpusat (Centralized System / Mainframe)

• Semua proses (antarmuka, pemrosesan logika, dan DBMS) berada pada satu komputer pusat (host/mainframe).
• Pengguna berinteraksi menggunakan terminal pasif (dumb terminal) yang hanya menampilkan teks dan mengirimkan ketukan tombol ke komputer pusat.

2. Arsitektur Klien-Server Dua Lapis (2-Tier Client-Server)

• Lapisan Klien (Client Tier): Menjalankan antarmuka pengguna (User Interface) sekaligus logika aplikasi (business logic). Klien ini sering disebut Fat Client.
• Lapisan Basis Data (Database Server Tier): Menjalankan DBMS yang melayani permintaan kueri SQL dari komputer klien melalui koneksi jaringan (ODBC/JDBC).

[ Klien: GUI + Business Logic ] <==== Network (SQL) ====> [ Database Server ]

3. Arsitektur Tiga Lapis (3-Tier Architecture)

Arsitektur standar bagi aplikasi web dan enterprise modern:

• Lapisan Presentasi (Presentation Tier): Berjalan di perangkat klien (peramban web / aplikasi mobile) yang bertugas menyajikan antarmuka (Thin Client).
• Lapisan Aplikasi / Logika Bisnis (Application / Logic Tier): Server aplikasi (web server / API gateway) yang memproses aturan bisnis, kalkulasi, dan alur kerja sistem.
• Lapisan Data (Data Tier): Server basis data yang bertugas murni mengelola operasi penyimpanan, kueri data, dan integritas transaksi.

[ Web Browser / Mobile App ] (Presentation)
             | (HTTP / REST API)
             v
[ Application Server / Backend ] (Business Logic)
             | (SQL Protocol / Connection Pool)
             v
[ Database Server (DBMS) ] (Data Storage & ACID)

Keuntungan 3-Tier:

• Skalabilitas lebih tinggi (lapisan aplikasi dapat di-scale independen).
• Keamanan lebih baik (klien tidak berhubungan langsung dengan server database).
• Pemeliharaan kode lebih modular dan terstruktur.

Rangkuman

• Penggunaan DBMS menghasilkan efisiensi tinggi melalui pengurangan redundansi, penegakan integritas, dan keamanan terpusat.
• Manajemen Transaksi (ACID) memastikan keandalan operasi finansial dan bisnis dalam kondisi apa pun.
• Arsitektur internal DBMS didukung oleh dua pilar utama: Query Processor dan Storage Manager.
• Pola distribusi sistem berevolusi dari model terpusat menuju arsitektur multi-lapis (3-Tier) yang fleksibel dan skalabel.

BAB I: APA ITU BASIS DATA?

1.6 SEJARAH SISTEM BASIS DATA DAN APLIKASI PRAKTIS

Perkembangan sistem basis data merupakan salah satu pencapaian paling transformatif dalam sejarah ilmu komputer, mengubah cara manusia dan organisasi menyimpan serta memanfaatkan pengetahuan.

1. Sejarah dan Evolusi Sistem Basis Data

Evolusi teknologi basis data terbagi ke dalam beberapa era tonggak sejarah utama:

1960-an            1970-an           1980-an            1990-an             2000-an - Kini
+---------------+  +---------------+ +---------------+  +----------------+  +-------------------+
| Model Berkas, |  | E.F. Codd:    | | Komersialisasi|  | RDBMS Dominan, |  | Big Data, NoSQL,  |
| Hierarkis IMS,|->| Model         |-> RDBMS (Oracle,|->| Web + Database,|->| Cloud Databases,  |
| Jaringan      |  | Relasional &  | | DB2, Informix,|  | MySQL,         |  | NewSQL & Vector   |
| (CODASYL)     |  | Bahasa SQL    | | SQL Server)   |  | PostgreSQL     |  | Databases for AI  |
+---------------+  +---------------+ +---------------+  +----------------+  +-------------------+

A. Era 1960-an: Model Hierarkis dan Jaringan

• Pada awal era komputasi bisnis, pemrosesan berkas konvensional terbukti tidak mampu menangani proyek-proyek besar yang kompleks.
• Proyek Apollo (NASA): IBM mengembangkan IMS (Information Management System) berbasis Model Data Hierarkis untuk melacak jutaan suku cadang pesawat luar angkasa Apollo.
• Di waktu yang bersamaan, Charles Bachman di General Electric merintis sistem IDS (Integrated Data Store) yang mendasari standarisasi Model Jaringan oleh komite CODASYL (Conference on Data Systems Languages).
• Karakteristik: Kueri harus ditulis secara prosedural mengikuti navigasi penunjuk (pointer) fisik. Sangat kaku dan sulit dipelihara jika skema berubah.

B. Era 1970-an: Terobosan Model Relasional

• Pada bulan Juni 1970, Dr. Edgar F. Codd (seorang peneliti di IBM San Jose Research Laboratory) menerbitkan makalah ilmiah monumental:

  "A Relational Model of Data for Large Shared Data Banks" (Communications of the ACM).

• Codd mengusulkan pemisahan total antara representasi logika data (berupa tabel matematis berbasis teori himpunan) dari representasi fisik di disk.
• Sebagai implementasi pembuktian konsep, IBM mengembangkan proyek riset System R, yang melahirkan bahasa kueri deklaratif bernama SEQUEL (Structured English Query Language), yang kemudian disingkat menjadi SQL.
• Di University of California, Berkeley, Michael Stonebraker memimpin proyek riset Ingres, yang juga mengimplementasikan model relasional dan bahasa kueri Quel.

C. Era 1980-an: Komersialisasi RDBMS

• Larry Ellison, Bob Miner, dan Ed Oates mendirikan Software Development Laboratories (yang kemudian menjadi Oracle Corporation) dan meluncurkan produk komersial RDBMS pertama berbasis SQL pada tahun 1979.
• IBM menyusul dengan merilis produk komersial SQL/DS (1981) dan IBM DB2 (1983).
• Perusahaan lain seperti Sybase, Informix, dan Microsoft (MS SQL Server) mulai berkembang pesat.
• ANSI (American National Standards Institute) menetapkan SQL sebagai standar industri resmi pada tahun 1986 (SQL-86).

D. Era 1990-an: Integrasi Web, OODBMS, dan Open Source

• Munculnya bahasa pemrograman berorientasi objek (C++, Java) melahirkan Basis Data Berorientasi Objek (OODBMS) dan Objek-Relasional (ORDBMS).
• Meledaknya jaringan World Wide Web (Internet) menuntut sistem basis data dapat terhubung dengan aplikasi web dinamis.
• Munculnya basis data sumber terbuka (Open Source) yang andal seperti MySQL dan PostgreSQL, yang mendemokratisasi akses basis data bagi pengembang di seluruh dunia (era LAMP Stack).

E. Era 2000-an - Sekarang: Big Data, NoSQL, Cloud, dan AI

• Ledakan volume, variasi, dan kecepatan data (Volume, Variety, Velocity) dari media sosial, perangkat IoT, dan mesin pencari memicu lahirnya gerakan NoSQL (Not Only SQL):
  • Document-based: MongoDB, CouchDB.
  • Key-Value: Redis, DynamoDB.
  • Column-family: Apache Cassandra, HBase.
  • Graph: Neo4j.
• Cloud Database (Database-as-a-Service / DBaaS): AWS RDS, Google Cloud Spanner, Azure Cosmos DB yang menawarkan skalabilitas elastis tanpa batas.
• Vector Database: Basis data modern (seperti Pinecone, Milvus, Qdrant, pgvector) yang dioptimalkan untuk pencarian semantik dan embeddings model kecerdasan buatan (Artificial Intelligence / Large Language Models).

2. Aplikasi Praktis Basis Data dalam Kehidupan Nyata

Sistem basis data menjadi infrastruktur tak terlihat (invisible backbone) yang menopang hampir setiap sektor industri modern:

1. Perbankan dan Layanan Keuangan (Banking & Finance)

• Operasional Core Banking: Pencatatan jutaan rekening nasabah, saldo simpanan, pinjaman, dan transaksi kartu debit/kredit.
• ATM dan Internet/Mobile Banking: Pemrosesan transfer dana secara real-time yang menuntut pemenuhan prinsip ACID mutlak untuk mencegah selisih kas.
• Deteksi Penipuan (Fraud Detection): Menganalisis pola transaksi mencurigakan dalam hitungan milidetik.

2. E-Commerce dan Ritel (Retail & Online Shopping)

• Manajemen Katalog dan Inventaris: Menampilkan ketersediaan stok jutaan barang di gudang secara akurat.
• Keranjang Belanja (Shopping Cart) & Checkout: Mengunci barang pesanan dan memproses pembayaran pelanggan.
• Sistem Rekomendasi: Menyajikan saran produk yang dipersonalisasi berdasarkan histori pencarian dan pembelian sebelumnya.

3. Pendidikan dan Akademik (Higher Education)

• Sistem Informasi Akademik (SIAKAD): Pendaftaran mahasiswa baru, pengelolaan kurikulum, kartu rencana studi (KRS), presensi, penilaian (KHS), dan pencatatan ijazah/transkrip nilai resmi.
• Perpustakaan Digital: Peminjaman buku, katalog digital (OPAC), dan penagihan denda keterlambatan.

4. Kesehatan dan Rumah Sakit (Healthcare)

• Rekam Medis Elektronik (Electronic Medical Records - EMR): Menyimpan riwayat diagnosis pasien, riwayat alergi obat, hasil laboratorium, dan rontgen/CT-scan.
• Sistem Penjadwalan & Farmasi: Penjadwalan konsultasi dokter, ketersediaan ruang rawat inap, dan kontrol stok obat-obatan di apotek.

5. Transportasi dan Perjalanan (Travel & Airlines)

• Sistem Reservasi Global (GDS): Pemesanan tiket pesawat, kereta api, hotel, dan kapal laut di mana ketersediaan kursi harus terkoordinasi antar-agen secara global.
• Aplikasi Transportasi Daring (Ride-Hailing): Pencocokan posisi pengemudi dan penumpang menggunakan kueri data geospasial (spatial database).

6. Telekomunikasi dan Media Sosial

• Telekomunikasi: Pencatatan jutaan detail panggilan (Call Detail Records - CDR), paket data, dan penagihan pulsa secara instan.
• Media Sosial: Jejaring pertemanan, linimasa berita, pesan langsung (direct messages), dan pelacakan interaksi likes/comments.

Rangkuman Bab I: Apa Itu Basis Data?

1. Definisi: Basis data adalah kumpulan data yang saling berhubungan logis, terpadu, dan terorganisir yang dikelola oleh DBMS untuk melayani berbagai kebutuhan aplikasi dan pengguna.
2. Keterbatasan Berkas Tradisional: Pendekatan berbasis berkas lama memiliki kelemahan mendasar seperti redundansi data, inkonsistensi, ketergantungan program-data, sulitnya akses kueri ad-hoc, dan minimnya keamanan serta atomisitas transaksi.
3. Karakteristik DBMS: Menyediakan kemandirian data melalui tiga tingkatan abstraksi (Fisik, Konseptual, Eksternal), menggunakan model data relasional, dan diakses menggunakan bahasa standar SQL (DDL, DML, DCL, TCL).
4. Keunggulan DBMS: Penegakan integritas data, sifat ACID pada transaksi, pengoptimalan kueri terpadu, serta arsitektur modern multi-tier yang sangat skalabel.
5. Relevansi: Basis data telah berevolusi dari era hierarkis 1960-an hingga era cloud dan AI saat ini, menjadi pilar utama sistem informasi di seluruh sektor kehidupan manusia.

BAB II: TAHAPAN PENGEMBANGAN SISTEM BASIS DATA

2.1 PENDAHULUAN

1. Latar Belakang

Pengembangan sistem basis data bukanlah sekadar aktivitas teknis mengetik perintah SQL untuk membuat tabel (CREATE TABLE) atau memasukkan data. Di dalam organisasi berskala menengah hingga besar, sistem basis data merupakan komponen inti (core component) dari sistem informasi perusahaan (Enterprise Information System).

Ketiadaan metode dan tahapan perancangan yang sistematis akan menimbulkan berbagai masalah fatal, seperti:

• Struktur tabel yang tidak mencerminkan kebutuhan proses bisnis yang sebenarnya.
• Munculnya redundansi tak terkontrol yang menyebabkan anomali pembaruan data (update anomalies).
• Kinerja sistem yang lambat saat menangani volume data dan transaksi tinggi.
• Kesulitan dalam pengembangan lanjutan (scalability) dan pemeliharaan (maintenance).
• Tingginya biaya perbaikan (re-work) ketika kesalahan desain baru disadari pada tahap akhir produksi.

Oleh karena itu, diperlukan suatu metodologi terstruktur yang menguraikan siklus hidup pengembangan sistem basis data dari tahap perencanaan strategis hingga pemeliharaan operasional.

2. Posisi Basis Data dalam Siklus Hidup Sistem

Basis data tidak berdiri sendiri secara terisolasi. Basis data berkembang berdampingan dengan proses bisnis dan perangkat lunak aplikasi yang menggunakannya:

graph TD
    A[Kebutuhan Strategis Bisnis] --> B[Sistem Informasi Keseluruhan]
    B --> C[Perancangan Proses & Aplikasi]
    B --> D[Perancangan Basis Data]
    C --> E[Integrasi Sistem & Operasional]
    D --> E

Pendekatan rekayasa modern menuntut agar perancangan data (data-driven design) dilakukan secara simultan dan terintegrasi dengan perancangan proses (process-driven design). Struktur data yang kokoh akan menjamin bahwa logika bisnis aplikasi apa pun di masa depan dapat dibangun dan dikembangkan dengan stabil.

3. Ruang Lingkup Pembahasan Bab II

Bab ini mengupas tuntas tahapan pengembangan sistem basis data yang komprehensif, mencakup:

• 2.1 Pendahuluan: Urgensi metodologi terstruktur dalam perancangan basis data.
• 2.2 Pengembangan Basis Data dalam Pengembangan Sistem Informasi Keseluruhan: Menyelaraskan arsitektur sistem informasi, rekayasa informasi (Information Engineering), dan perencanaan sistem informasi (Information Systems Planning).
• 2.3 Proses Pengembangan Basis Data: Menelusuri fase-fase Siklus Hidup Pengembangan Sistem (SDLC), pemodelan organisasi, perancangan konseptual, perancangan logika, perancangan fisik, implementasi, pemeliharaan, serta metode alternatif (Prototyping, Agile, RAD).
• 2.4 Mengelola Manusia yang Terlibat pada Proses Pengembangan Basis Data: Peran dan kolaborasi pemangku kepentingan (DBA, System Analyst, Data Modeler, Programmer, End-User, Project Manager).
• 2.5 Tiga Skema Pengembangan Basis Data: Pemahaman mendalam skema konseptual, skema eksternal, dan skema internal dalam siklus pengembangan.

4. Rangkuman

Perancangan basis data yang berhasil memerlukan pemahaman holistik terhadap tujuan organisasi, metodologi bertahap yang disiplin, serta manajemen koordinasi tim yang solid antara perancang sistem dan para pemangku kepentingan bisnis.

BAB II: TAHAPAN PENGEMBANGAN SISTEM BASIS DATA

2.2 PENGEMBANGAN BASIS DATA DALAM PENGEMBANGAN SISTEM INFORMASI KESELURUHAN

Pengembangan basis data tidak dapat dipisahkan dari konteks pembangunan sistem informasi organisasi secara menyeluruh. Basis data bertindak sebagai fondasi tempat bertumpunya seluruh transaksi, pelaporan, dan analitik bisnis.

2.2.1 Arsitektur Sistem Informasi

Arsitektur Sistem Informasi (Information Systems Architecture - ISA) adalah cetak biru konseptual (conceptual blueprint) yang menggambarkan bagaimana komponen-komponen teknologi, data, proses bisnis, dan sumber daya manusia saling terhubung dan terkoordinasi untuk mendukung tujuan strategis perusahaan.

A. Komponen Utama Arsitektur Sistem Informasi

1. Arsitektur Data (Data Architecture): Mendefinisikan entitas data utama organisasi, aturan bisnis data, hubungan keterkaitan data, serta standar model data yang berlaku di seluruh divisi (misalnya melalui model data enterprise).
2. Arsitektur Aplikasi (Application Architecture): Mendefinisikan portofolio sistem aplikasi yang digunakan (misal: sistem ERP, CRM, SCM, SIAKAD) serta pola interaksi dan pertukaran data antar-aplikasi.
3. Arsitektur Teknologi (Technology Architecture): Mencakup infrastruktur perangkat keras (server, storage area network / SAN), jaringan komputer (LAN/WAN, cloud), dan platform perangkat lunak sistem (sistem operasi, DBMS).
4. Arsitektur Proses Bisnis (Business Process Architecture): Mendefinisikan fungsi bisnis, rantai nilai (value chain), dan alur operasional kerja yang mengonsumsi serta menghasilkan data.

+-------------------------------------------------------------------+
|               ARSITEKTUR SISTEM INFORMASI (ISA)                   |
+-------------------------------------------------------------------+
| 1. Arsitektur Bisnis    : Visi, Misi, Strategi, Proses Bisnis     |
| 2. Arsitektur Data      : Model Data Enterprise, Kamus Data, DBMS |
| 3. Arsitektur Aplikasi  : ERP, CRM, Portofolio Aplikasi Web/App   |
| 4. Arsitektur Teknologi : Server, Cloud, Jaringan, Penyimpanan    |
+-------------------------------------------------------------------+

2.2.2 Rekayasa Informasi (Information Engineering)

Rekayasa Informasi (Information Engineering - IE) adalah pendekatan formal dan disiplin rekayasa perangkat lunak yang berorientasi pada data (data-centric methodology) untuk merencanakan, menganalisis, merancang, dan membangun sistem informasi di seluruh enterprise.

Dipelopori oleh konsultan rekayasa perangkat lunak ternama James Martin, premis dasar Rekayasa Informasi menyatakan bahwa:

"Data di dalam organisasi jauh lebih stabil dibandingkan proses bisnisnya. Proses bisnis, bentuk laporan, dan struktur organisasi dapat berubah seiring waktu, tetapi tipe data dasar (seperti pelanggan, barang, rekening) cenderung tetap konstan."

Oleh karena itu, Rekayasa Informasi menempatkan pemodelan data sebagai langkah pertama yang paling fundamental sebelum mendesain proses atau antarmuka aplikasi.

Tahapan Utama dalam Rekayasa Informasi (Piramida IE):

1. Perencanaan Strategis Informasi (Information Strategy Planning - ISP): Mengidentifikasi tujuan bisnis jangka panjang dan mendefinisikan arsitektur data serta aplikasi tingkat tinggi.
2. Analisis Area Bisnis (Business Area Analysis - BAA): Menganalisis secara detail proses bisnis dalam domain tertentu, menghasilkan Model Hubungan Entitas (ERD) detail dan matriks keterkaitan proses-entitas (CRUD Matrix).
3. Perancangan Sistem (System Design): Merancang struktur basis data spesifik, transaksi, algoritma logika, dan tata letak layar pengguna.
4. Konstruksi dan Implementasi (Construction): Membangun skema tabel pada DBMS, mengodekan program aplikasi, melakukan pengujian, dan men-deploy ke lingkungan produksi.

                  /\
                 /  \     Tahap 4: Konstruksi
                /----\
               /      \    Tahap 3: Perancangan Sistem
              /--------\
             /          \   Tahap 2: Analisis Area Bisnis (BAA)
            /------------\
           /              \  Tahap 1: Perencanaan Strategis (ISP)
          +----------------+

2.2.3 Perencanaan Sistem Informasi (Information Systems Planning)

Perencanaan Sistem Informasi (Information Systems Planning - ISP) adalah proses terstruktur untuk menyelaraskan (aligning) investasi dan pengembangan teknologi informasi dengan strategi bisnis organisasi.

A. Tujuan Utama Perencanaan Sistem Informasi

• Memastikan bahwa setiap proyek pengembangan basis data memiliki kontribusi langsung terhadap pencapaian target bisnis perusahaan.
• Menetapkan skala prioritas proyek basis data yang paling bernilai tinggi dan berisiko rendah.
• Mencegah pembangunan sistem basis data yang terisolasi (siloed systems) antar-departemen.
• Mengalokasikan sumber daya (anggaran, infrastruktur perangkat keras, dan personil) secara optimal.

B. Langkah-Langkah Kunci dalam Perencanaan Sistem Informasi

1. Identifikasi Rencana Strategis Perusahaan: Menganalisis visi, misi, sasaran, tujuan strategis, dan faktor penentu keberhasilan (Critical Success Factors - CSF).
2. Identifikasi Fungsi Bisnis Enterprise: Membagi operasional organisasi ke dalam area fungsi utama (misal: Pemasaran, Produksi, Keuangan, SDM).
3. Identifikasi Entitas Data Enterprise: Menginventarisasi objek-objek data penting yang dibutuhkan oleh setiap fungsi bisnis.
4. Penyusunan Matriks Perencanaan (Matriks CRUD): Menyusun matriks yang memetakan fungsi bisnis terhadap entitas data, untuk melihat di mana data Diciptakan (Create), Dibaca (Read), Diperbarui (Update), dan Dihapus (Delete).

Contoh Matriks CRUD (Fungsi Bisnis vs Entitas Data):
+----------------------+------------+----------+------------+
| Fungsi Bisnis        | Pelanggan  | Produk   | Transaksi  |
+----------------------+------------+----------+------------+
| Registrasi Member    |    C, R    |    -     |     -      |
| Manajemen Katalog    |     -      | C, R, U  |     -      |
| Pemesanan / Kasir    |    R, U    |    R     |  C, R, U   |
| Laporan Penjualan    |     R      |    R     |     R      |
+----------------------+------------+----------+------------+

Matriks ini menjadi pedoman utama dalam menentukan batasan (scope) dan integrasi sistem basis data yang akan dibangun.

Rangkuman

• Pengembangan basis data bertindak sebagai pilar data dalam Arsitektur Sistem Informasi (ISA).
• Metodologi Rekayasa Informasi (IE) memprioritaskan kestabilan struktur data di atas proses yang dinamis.
• Melalui Perencanaan Sistem Informasi (ISP) dan Matriks CRUD, organisasi dapat merancang basis data yang selaras secara strategis dengan kebutuhan operasional seluruh fungsi bisnis.

BAB II: TAHAPAN PENGEMBANGAN SISTEM BASIS DATA

2.3 PROSES PENGEMBANGAN BASIS DATA

Proses pengembangan basis data merupakan rangkaian aktivitas terstruktur yang mengubah kebutuhan informasi pengguna di dunia nyata menjadi sekumpulan skema basis data operasional yang dapat dieksekusi oleh mesin DBMS.

2.3.1 Siklus Hidup Pengembangan Sistem (Database Life Cycle - DBLC)

Siklus Hidup Pengembangan Sistem Basis Data (Database Life Cycle) berjalan beriringan dengan Siklus Hidup Pengembangan Perangkat Lunak (Software Development Life Cycle - SDLC). DBLC terdiri dari tahapan terurut:

graph TD
    A[1. Perencanaan & Pemodelan Enterprise] --> B[2. Analisis Kebutuhan & Pemodelan Konseptual]
    B --> C[3. Perancangan Logika / Logical Design]
    C --> D[4. Perancangan Fisik / Physical Design]
    D --> E[5. Implementasi Basis Data & Loading Data]
    E --> F[6. Pengujian & Konversi Sistem]
    F --> G[7. Pengoperasian & Pemeliharaan / Maintenance]
    G -.->|Evaluasi Kinerja & Pertumbuhan| A

Masing-masing tahapan menghasilkan luaran (deliverables) yang menjadi masukan bagi tahapan berikutnya.

2.3.2 Pemodelan Organisasi/Perusahaan (Enterprise Modeling)

Tahap awal ini berfokus pada pemahaman konteks bisnis tempat basis data akan beroperasi:

• Tujuan: Mengetahui fungsi, sasaran, batasan, dan aliran informasi organisasi secara garis besar.
• Aktivitas:
  • Melakukan wawancara dengan manajemen puncak (executive interview).
  • Meninjau dokumen prosedur operasional standar (SOP), bagan organisasi, dan formulir bisnis.
  • Memetakan proses bisnis utama ke dalam diagram alur (business process diagram).
• Luaran: Model Data Enterprise tingkat tinggi (High-Level Enterprise Data Model) yang berisi entitas-entitas bisnis utama tanpa atribut detail (misal: Pelanggan, Faktur, Gudang, Pemasok).

2.3.3 Pemodelan Konseptual Data (Conceptual Data Modeling)

Tahap ini merupakan fase paling kritis di mana perancang basis data menerjemahkan kebutuhan pengguna ke dalam representasi semantik formal yang independen terhadap perangkat lunak DBMS maupun perangkat keras apa pun.

• Aktivitas Utama:
  • Mengidentifikasi entitas (objek penting dalam bisnis).
  • Mengidentifikasi atribut masing-masing entitas beserta tipe dan domain nilainya.
  • Mengidentifikasi identifier atau calon kunci utama (candidate key).
  • Mengidentifikasi relasi dan derajat asosiasi antar-entitas.
  • Menentukan batasan kardinalitas (cardinality ratio: 1:1, 1:N, M:N) dan modalitas/partisipasi (mandatory vs optional).
• Notasi yang Digunakan: Entity-Relationship Diagram (ERD) standar Chen atau Crow's Foot notation, serta Enhanced ERD (EERD).
• Karakteristik: Bersifat murni konseptual; belum berbicara tentang tabel, kolom SQL, indeks, atau tipe data spesifik mesin seperti VARCHAR atau INT.

2.3.4 Perancangan Basis Data secara Logika (Logical Database Design)

Pada tahap ini, model konseptual (ERD) dipetakan (mapped) ke dalam model data target, yang paling umum adalah Model Relasional.

• Aktivitas Utama:
  1. Transformasi ERD ke Skema Relasi:
     • Mengubah entitas kuat menjadi tabel relasional.
     • Memetakan relasi 1:N dengan menyematkan Foreign Key pada tabel sisi "Many".
     • Memetakan relasi M:N menjadi tabel perantara (associative table / junction table).
     • Menangani entitas lemah (weak entity) dan relasi supertipe-subtipe (specialization/generalization).
  2. Proses Normalisasi (1NF, 2NF, 3NF, hingga BCNF):
     • Menguji setiap tabel terhadap kebergantungan fungsional (functional dependencies).
     • Menghilangkan redundansi data dan anomali penyisipan (insertion), penghapusan (deletion), serta pembaruan (update).
  3. Validasi Batasan Integritas:
     • Menetapkan aturan integritas entitas (Primary Key).
     • Menetapkan aturan integritas referensial (Foreign Key beserta opsi ON DELETE CASCADE / SET NULL).
• Luaran: Skema Relasi Terstandarisasi (Relational Schema) yang bebas anomali dan independen dari spesifikasi mesin penyimpanan fisik.

2.3.5 Perancangan Basis Data secara Fisik (Physical Database Design)

Tahap ini menyesuaikan skema logis ke dalam lingkungan perangkat lunak DBMS spesifik (misalnya MySQL, PostgreSQL, Oracle, atau SQL Server) dan media penyimpanan fisik.

• Fokus Utama: Performa kueri, efisiensi penyimpanan, integritas, dan keamanan.
• Aktivitas Utama:
  1. Pemilihan Tipe Data Spesifik: Memilih tipe data konkret (misal: VARCHAR(100), BIGINT, TIMESTAMP, BOOLEAN).
  2. Perancangan Indeks (Indexing Design): Menentukan kolom yang memerlukan indeks sekunder (indeks B-Tree atau Hash) guna mempercepat pencarian data kueri yang sering dipanggil.
  3. Organisasi Berkas & Partisi: Mengatur penempatan berkas tabel pada ruang tabel (tablespace), pembagian partisi horizontal atau vertikal untuk tabel raksasa.
  4. Denormalisasi Terkendali (Controlled Denormalization): Dalam situasi tertentu di mana performa kueri baca (read performance) sangat diutamakan (seperti pada data warehouse atau pelaporan cepat), tabel dapat sengaja didenormalisasi secara terkendali.
  5. Perancangan Pengendalian Integritas dan Keamanan Fisik: Skrip pemicu (triggers), prosedur tersimpan (stored procedures), dan pembagian peran pengguna.

2.3.6 Implementasi Basis Data (Database Implementation)

Tahap di mana rancangan fisik dituangkan ke dalam bentuk basis data operasional yang berjalan di server:

• Aktivitas Utama:
  • Penulisan dan pengeksekusian skrip DDL (Data Definition Language) SQL untuk membentuk database, tabel, indeks, view, dan constraints.
  • Pembuatan prosedur tersimpan (stored procedure), fungsi (functions), dan pemicu (triggers).
  • Migrasi dan Pemuatan Data (Data Loading / Population): Memindahkan data lama (legacy data) dari sistem berkas atau sistem lama ke dalam basis data baru melalui proses ETL (Extract, Transform, Load).
  • Pengujian integritas dan pengujian beban performa (load testing / stress testing).

2.3.7 Pemeliharaan Basis Data (Database Maintenance)

Basis data yang telah beroperasi di lingkungan produksi (live environment) harus terus dipelihara dan dipantau kinerjanya sepanjang masa pakai sistem:

• Pencadangan dan Pemulihan (Backup and Recovery): Menjadwalkan backup rutin (penuh/diferensial/transaksional) untuk mengantisipasi bencana atau kegagalan perangkat keras.
• Penyetelan Performa (Performance Tuning): Menganalisis kueri lambat (slow queries), mereorganisasi indeks yang terfragmentasi, dan mengoptimalkan memori buffer cache.
• Manajemen Keamanan dan Audit: Meninjau hak akses secara berkala, melakukan patching perangkat lunak DBMS, dan memeriksa catatan jejak log audit.
• Pemeliharaan Adaptif & Sempurna: Menyesuaikan skema tabel jika terdapat aturan bisnis atau regulasi perundang-undangan baru.

2.3.8 Alternatif Lain dari Pengembangan Sistem Informasi

Selain model sekuensial air terjun (Waterfall SDLC), terdapat pendekatan alternatif yang sering diterapkan sesuai dengan karakteristik proyek:

1. Pendekatan Prototyping

• Perancang membangun purwarupa basis data dan antarmuka sederhana secara cepat (rapid mock-up).
• Pengguna langsung menguji purwarupa dan memberikan umpan balik (feedback).
• Sangat efektif ketika pengguna belum memahami secara pasti kebutuhan informasinya di awal proyek.

2. Metodologi Agile & Scrum

• Basis data dikembangkan secara iteratif dan inkremental dalam siklus pendek (sprints 2-4 minggu).
• Skema basis data berevolusi bersamaan dengan fitur aplikasi menggunakan perkakas migrasi basis data (misal: Flyway, Liquibase, atau migrasi framework seperti Laravel/Django).

3. Rapid Application Development (RAD)

• Menggunakan perkakas visual berbantuan komputer (Computer-Aided Software Engineering / CASE tools) dan pembuat kueri visual untuk mempercepat siklus dari desain hingga kode yang siap dijalankan.

4. Paket Aplikasi Jadi (Commercial Off-The-Shelf - COTS)

• Mengadopsi paket perangkat lunak enterprise yang sudah memiliki skema basis data siap pakai (misal: SAP, Oracle ERP). Tim teknis hanya melakukan kustomisasi skema tanpa merancang dari nol.

Rangkuman

Pengembangan basis data melalui tahapan yang berjenjang dan disiplin:

1. Pemodelan Organisasi: Memahami konteks bisnis.
2. Pemodelan Konseptual: Menghasilkan ERD bebas DBMS.
3. Perancangan Logika: Menghasilkan skema relasi ternormalisasi.
4. Perancangan Fisik: Menentukan indeks, tipe data mesin, dan struktur file.
5. Implementasi & Pemeliharaan: Pengeksekusian DDL, pengisian data, tuning performa, dan backup rutin. Metodologi modern juga dapat memadukan pendekatan alternatif seperti Prototyping atau Agile untuk fleksibilitas yang lebih tinggi.

BAB II: TAHAPAN PENGEMBANGAN SISTEM BASIS DATA

2.4 MENGELOLA MANUSIA YANG TERLIBAT PADA PROSES PENGEMBANGAN BASIS DATA

Keberhasilan sebuah proyek pengembangan sistem basis data tidak semata-mata ditentukan oleh kecanggihan perangkat keras atau perangkat lunak DBMS yang digunakan, melainkan sangat bergantung pada faktor manusia (human factors), koordinasi tim, dan komunikasi antar-pemangku kepentingan (stakeholders).

1. Peran dan Pemangku Kepentingan dalam Tim Basis Data

Proses pengembangan basis data melibatkan berbagai pihak dengan keahlian, sudut pandang, dan kepentingan yang berbeda:

                      +-----------------------------+
                      |       PROJECT MANAGER       |
                      +-----------------------------+
                                     |
         +---------------------------+---------------------------+
         |                           |                           |
         v                           v                           v
+-----------------+         +-----------------+         +-----------------+
| SYSTEM ANALYSTS |         | DATA MODELERS / |         |    DATABASE     |
| (Kebutuhan &    | <=====> | DESIGNERS       | <=====> | ADMINISTRATOR   |
| Proses Bisnis)  |         | (ERD & Relasi)  |         | (DBA - Fisik)   |
+-----------------+         +-----------------+         +-----------------+
         ^                           ^                           ^
         |                           |                           |
         v                           v                           v
+-----------------+         +-----------------+         +-----------------+
|   END USERS /   |         |   APPLICATION   |         | QUALITY / TEST  |
| BUSINESS OWNERS |         |   DEVELOPERS    |         |    ENGINEERS    |
+-----------------+         +-----------------+         +-----------------+

A. Database Administrator (DBA)

• Tanggung Jawab: Bertanggung jawab atas pengelolaan fisik, kinerja mesin DBMS, keamanan akun, hak akses otorisasi, pencadangan (backup), pemulihan (disaster recovery), dan integritas data secara global.
• Keahlian Teknis: Mendalam dalam administrasi server DBMS (tuning memori cache, indeks, replikasi, partisi, sistem operasi, jaringan).

B. Perancang Basis Data (Database Designer / Data Modeler)

• Perancang Konseptual & Logika: Bertanggung jawab mewawancarai pengguna, memahami entitas bisnis, aturan integritas, memodelkan ERD/EERD, dan melakukan normalisasi tabel.
• Perancang Fisik: Memetakan skema logika ke dalam struktur fisik tabel pada DBMS spesifik, menentukan tipe data kolom, dan strategi pengindeksan bersama DBA.

C. Analis Sistem (System Analyst)

• Menjembatani kesenjangan pemahaman antara pengguna bisnis awam dengan tim teknis TI.
• Mengidentifikasi proses bisnis, batasan fungsional, dan kebutuhan informasi yang harus diakomodasi oleh sistem basis data dan aplikasi pendukung.

D. Pengembang Aplikasi (Application Programmers / Software Engineers)

• Menulis kode perangkat lunak (antarmuka web/mobile, logika backend, REST API) yang berinteraksi dengan basis data melalui kueri SQL atau ORM (Object-Relational Mapping).
• Memastikan pemanggilan kueri dilakukan secara efisien tanpa menimbulkan pemborosan koneksi (connection leak).

E. Pengguna Akhir (End Users) dan Pemilik Bisnis (Business Owners)

• Peran Kunci: Sebagai narasumber utama dalam mendefinisikan kebutuhan sistem dan aturan bisnis (business rules).
• Keberhasilan sistem diukur dari sejauh mana basis data mampu menjawab kebutuhan operasional harian dan pelaporan manajerial mereka.

F. Manajer Proyek (Project Manager)

• Bertanggung jawab memonitor jadwal, alokasi anggaran, manajemen risiko, serta memastikan setiap fase dalam siklus pengembangan data (DBLC) selesai sesuai target waktu.

2. Tantangan dan Strategi Pengelolaan Tim Basis Data

A. Menjembatani Jurang Komunikasi (Communication Gap)

• Tantangan: Pengguna bisnis sering kali menggunakan terminologi operasional non-formal, sedangkan perancang basis data cenderung berpikir dalam istilah teknis formal (seperti entitas, tabel, primary key, join).
• Solusi: Gunakan teknik wawancara terstruktur, kuesioner, studi formulir bisnis, dan verifikasi rancangan menggunakan notasi visual yang intuitif (seperti diagram ERD konseptual atau antarmuka purwarupa/prototipe).

B. Manajemen Perubahan (Change Management) dan Resistensi Pengguna

• Tantangan: Peralihan dari sistem berbasis berkas lama atau pencatatan manual ke sistem basis data terpusat sering kali menimbulkan kekhawatiran dan penolakan dari staf operasional karena takut akan transparansi data atau kesulitan mempelajari antarmuka baru.
• Solusi:
  • Melibatkan perwakilan pengguna kunci sejak tahap analisis kebutuhan awal.
  • Menyelenggarakan program pelatihan (training) yang memadai dan berkesinambungan.
  • Menyusun panduan pengguna (user manual) dan Standar Operasional Prosedur (SOP) yang jelas.

C. Tata Kelola Data (Data Governance) dan Hak Kepemilikan Data

• Menetapkan dengan tegas siapa yang menjadi "pemilik data" (data owner) dari setiap tabel/entitas, siapa yang bertindak sebagai pemelihara (data steward), dan siapa saja yang hanya memiliki hak baca (read-only).
• Menghindari pertikaian antar-departemen mengenai hak kontrol data.

Rangkuman

Mengelola faktor manusia dalam proyek basis data sama pentingnya dengan merancang struktur tabel. Kolaborasi harmonis antara DBA, Perancang Basis Data, Analis Sistem, Pengembang Perangkat Lunak, dan Pengguna Akhir merupakan prasyarat mutlak untuk menghasilkan sistem basis data yang andal dan diterima oleh seluruh organisasi.

BAB II: TAHAPAN PENGEMBANGAN SISTEM BASIS DATA

2.5 TIGA SKEMA PENGEMBANGAN BASIS DATA

Dalam metodologi rekayasa basis data modern, pemisahan antara kebutuhan pengguna, struktur logis terpadu, dan detail implementasi fisik direalisasikan melalui Arsitektur Tiga Skema (Three-Schema Architecture), yang dirumuskan oleh komite standar ANSI/X3/SPARC (American National Standards Committee on Computers and Information Processing).

Pemahaman terhadap tiga skema ini sangat mendasar karena setiap tahapan pengembangan basis data secara langsung berkorespondensi dengan salah satu dari skema-skema tersebut.

1. Definisi Tiga Skema

+---------------------------------------------------------------+
|                      SKEMA EKSTERNAL                          |
|   (Kebutuhan Pengguna / User Views pada Tahap Analisis)       |
|                                                               |
|  [ View Mahasiswa ]       [ View Dosen ]       [ View Keuangan]
+---------------------------------------------------------------+
                               ^
                               | Pemetaan Eksternal-ke-Konseptual
                               v
+---------------------------------------------------------------+
|                      SKEMA KONSEPTUAL                         |
|   (Struktur Terpadu Organisasi pada Tahap Desain Logika)      |
|                                                               |
|   Entitas, Hubungan, Batasan Bisnis, Tabel Ternormalisasi     |
+---------------------------------------------------------------+
                               ^
                               | Pemetaan Konseptual-ke-Internal
                               v
+---------------------------------------------------------------+
|                      SKEMA INTERNAL / FISIK                   |
|   (Penyimpanan & Akses Fisik pada Tahap Desain Fisik)         |
|                                                               |
|   Struktur Blok Disk, Alokasi Byte, B-Tree Indeks, Kompresi   |
+---------------------------------------------------------------+

A. Skema Eksternal (External Schema / Subschemas)

• Definisi: Menggambarkan bagaimana data dilihat oleh kelompok pengguna tertentu atau aplikasi individual. Suatu basis data dapat memiliki banyak skema eksternal (multiple views).
• Karakteristik:
  • Hanya menyajikan informasi yang relevan dan diperlukan oleh peran pengguna terkait.
  • Menyembunyikan data sensitif yang tidak berhak diakses (misal: gaji dosen atau riwayat catatan disipliner mahasiswa disembunyikan dari staf biasa).
  • Mengizinkan representasi format yang berbeda sesuai kebutuhan tampilan pengguna (misal: format tanggal DD/MM/YYYY untuk pengguna lokal dan YYYY-MM-DD untuk ekspor sistem lain).
• Kaitan dengan Siklus Pengembangan: Dihasilkan dari wawancara kebutuhan pengguna pada tahap awal analisis sistem.

B. Skema Konseptual (Conceptual Schema)

• Definisi: Menggambarkan struktur logis global dari keseluruhan basis data bagi seluruh organisasi. Hanya terdapat satu skema konseptual untuk satu sistem basis data.
• Karakteristik:
  • Memuat semua entitas, atribut, relasi antar-entitas, batasan integritas data (constraints), dan aturan bisnis.
  • Bebas dari rincian teknologi penyimpanan fisik di disk (seperti ukuran blok byte atau algoritma partisi).
  • Menyediakan tampilan terintegrasi yang menyatukan seluruh skema eksternal tanpa duplikasi data yang tidak perlu.
• Kaitan dengan Siklus Pengembangan: Dirancang pada fase pemodelan konseptual (ERD) dan disempurnakan pada fase perancangan logika melalui teknik normalisasi.

C. Skema Internal / Fisik (Internal Schema)

• Definisi: Menggambarkan struktur penyimpanan fisik basis data di dalam media penyimpanan sekunder (disk/SSD). Hanya terdapat satu skema internal untuk satu sistem basis data.
• Karakteristik:
  • Menggunakan model data fisik untuk memerinci tata letak rekaman (record layout), penentuan ukuran alokasi blok, pengelompokan berkas (clustering), struktur penunjuk (pointers), dan struktur pengindeksan (B-Tree/Hash indexing).
  • Menjelaskan mekanisme kompresi dan enkripsi data fisik di disk.
• Kaitan dengan Siklus Pengembangan: Dihasilkan pada fase perancangan basis data secara fisik (Physical Database Design) dan dieksekusi saat implementasi DDL pada DBMS target.

2. Pemetaan Antar-Skema (Schema Mapping)

Agar data dapat ditransformasikan dengan lancar di antara ketiga level tersebut, DBMS menyediakan dua tingkat proses penerjemahan atau pemetaan (mapping):

A. Pemetaan Eksternal-ke-Konseptual (External-to-Conceptual Mapping)

• Mendefinisikan keterkaitan antara suatu pandangan eksternal tertentu dengan skema konseptual global.
• Menentukan bagaimana nama-nama kolom atau tabel virtual (view) pada layar pengguna dipetakan ke tabel-tabel ril di skema konseptual.
• Manfaat: Menjamin Kemandirian Data Logika (Logical Data Independence). Jika skema konseptual diubah (misalnya menambahkan tabel baru atau menambahkan kolom baru), pemetaan pada skema eksternal yang tidak terkait dapat dipertahankan sehingga kode program aplikasi lama tidak rusak.

B. Pemetaan Konseptual-ke-Internal (Conceptual-to-Internal Mapping)

• Menjelaskan bagaimana entitas dan atribut konseptual dipetakan ke dalam struktur berkas dan indeks fisik di disk.
• Manfaat: Menjamin Kemandirian Data Fisik (Physical Data Independence). Jika administrator basis data (DBA) memutuskan untuk memindahkan letak file basis data ke disk yang lebih cepat, mengubah struktur indeks, atau melakukan reorganisasi blok data fisik, skema konseptual dan aplikasi pengguna sama sekali tidak perlu diubah.

3. Manfaat Penerapan Tiga Skema dalam Siklus Proyek

Rangkuman

Penerapan Arsitektur Tiga Skema merupakan landasan esensial dalam tahapan pengembangan basis data:

1. Analisis kebutuhan berfokus pada perumusan Skema Eksternal.
2. Perancangan konseptual dan logika mewujudkan Skema Konseptual.
3. Perancangan fisik dan implementasi menghasilkan Skema Internal. Dengan adanya mekanisme pemetaan (mapping), arsitektur ini memberikan fleksibilitas, keamanan, dan kemandirian data maksimal bagi kelangsungan sistem informasi jangka panjang.

BAB III: MODEL KONSEPTUAL BASIS DATA ENTITAS-RELASIONAL

3.1 PENDAHULUAN

1. Latar Belakang

Tahap paling fundamental dalam perancangan basis data adalah pemodelan data secara konseptual. Sebelum menyusun tabel pada DBMS tertentu (seperti MySQL, PostgreSQL, atau Oracle), seorang perancang basis data (database designer) harus terlebih dahulu memahami secara mendalam dunia nyata (real-world domain) dari sistem yang akan dibangun.

Komunikasi antara perancang sistem dengan pengguna bisnis (business users) sering kali menghadapi kendala karena perbedaan istilah. Pengguna bisnis berbicara dalam bahasa operasional harian (seperti pelanggan membeli produk, dosen mengajar mata kuliah, mahasiswa mengambil kelas), sedangkan sistem komputer memerlukan instruksi biner dan struktur data yang kaku.

Untuk menjembatani jurang komunikasi tersebut, diperlukan suatu perangkat pemodelan grafis tingkat tinggi yang bersifat ekspresif, intuitif, dan bebas dari keterikatan teknologi (DBMS-independent). Model tersebut adalah Model Entitas-Relasional (Entity-Relationship Model - ER Model).

2. Posisi Model Konseptual dalam Perancangan Basis Data

Pemodelan konseptual menempati posisi sentral dalam siklus hidup pengembangan sistem basis data:

graph TD
    A[Kebutuhan Pengguna & Proses Bisnis] --> B[Pemodelan Konseptual: ERD / EERD]
    B --> C[Perancangan Logika: Skema Relasional & Normalisasi]
    C --> D[Perancangan Fisik: Tabel DBMS, Indeks, Storage]

Kelebihan utama pemodelan konseptual menggunakan Model E-R:

1. Representasi Alami: Memodelkan objek dan keterkaitan di dunia nyata secara natural tanpa memusingkan detail teknis memori atau disk.
2. Sarana Verifikasi: Menjadi dokumen komunikasi resmi antara analis sistem dan pemilik bisnis untuk memvalidasi apakah semua aturan bisnis telah terakomodasi.
3. Kemudahan Transformasi: Diagram E-R dapat dipetakan secara matematis dan sistematis ke dalam tabel-tabel basis data relasional.

3. Ruang Lingkup Pembahasan Bab III

Bab III membahas secara mendalam dan komprehensif mengenai konsep serta teknik perancangan konseptual:

• 3.1 Pendahuluan: Urgensi dan peranan pemodelan konseptual dalam rekayasa basis data.
• 3.2 Konsep Dasar: Tiga pilar utama model E-R yaitu Entitas, Atribut, Relasi, serta Kunci (Key).
• 3.3 Model E-R: Definisi formal, notasi grafis (Chen vs Crow's Foot), dan prinsip perancangan diagram.
• 3.4 Entitas dan Atribut: Tipe entitas, instansiasi entitas, entitas kuat (strong entity), entitas lemah (weak entity), entitas asosiatif, serta variasi tipe atribut (sederhana, komposit, bernilai tunggal, bernilai banyak, turunan).
• 3.5 Relasi: Derajat relasi (unary, binary, ternary), batasan kardinalitas (1:1, 1:N, M:N), modalitas partisipasi (mandatory/optional), relasi ganda, pemodelan data bergantung waktu (time stamped), dan agregasi.
• 3.6 Enhanced Entity Relationship Diagram (EERD): Konsep perluasan E-R mencakup spesialisasi, generalisasi, supertipe/subtipe, pewarisan atribut, batasan kelengkapan (total/partial), dan batasan disjoin (disjoint/overlapping).
• 3.7 Aturan Bisnis: Paradigma aturan bisnis, klasifikasi batasan struktural dan operasional, serta cara menerjemahkannya ke dalam model konseptual.

4. Rangkuman

Model Konseptual Entitas-Relasional adalah fondasi utama perancangan basis data yang menjamin struktur data yang dibangun benar-benar merefleksikan kebutuhan informasi dan aturan bisnis organisasi secara akurat, utuh, dan konsisten.

BAB III: MODEL KONSEPTUAL BASIS DATA ENTITAS-RELASIONAL

3.2 KONSEP DASAR

Model Entitas-Relasional didasarkan pada persepsi bahwa dunia nyata terdiri atas sekumpulan objek dasar yang dinamakan entitas, karakteristik penjelas yang disebut atribut, serta hubungan keterkaitan timbal balik antar-entitas yang disebut relasi. Untuk mengidentifikasi setiap rekaman data secara unik, digunakan konsep kunci (key).

3.2.1 Entitas dan Atribut

A. Konsep Entitas (Entity)

Entitas adalah suatu objek, orang, tempat, peristiwa, konsep, atau benda di dunia nyata yang dapat dibedakan secara tegas dari objek lainnya, serta informasi tentangnya perlu dicatat dan disimpan oleh organisasi.

Entitas dapat dikelompokkan menjadi:

1. Entitas Konkret / Fisik (Tangible Entities): Objek yang memiliki wujud fisik nyata.
   • Contoh: Mahasiswa, Dosen, Buku, Mobil, Pasien, Komputer.
2. Entitas Konseptual / Abstrak (Intangible Entities): Objek yang berupa konsep, hak, peristiwa, atau transaksi bisnis yang tidak memiliki wujud fisik tetapi ada dan penting bagi organisasi.
   • Contoh: Mata Kuliah, Akun Rekening, Transaksi Penjualan, Peminjaman, Proyek.

B. Konsep Atribut (Attribute)

Atribut adalah sifat, karakteristik, atau properti deskriptif yang melekat pada suatu entitas yang mendefinisikan informasi detail dari entitas tersebut.

Contoh Kasus: Untuk entitas Mahasiswa, atribut-atribut yang relevan meliputi:

• NIM (Nomor Induk Mahasiswa)
• Nama_Lengkap
• Alamat
• Tanggal_Lahir
• Program_Studi
• Nomor_Telepon

Setiap entitas memiliki domain nilai (value domain), yaitu sekumpulan nilai yang valid dan diizinkan untuk diisikan ke dalam atribut tersebut (misal: domain untuk atribut IPK adalah angka riil antara 0.00 hingga 4.00).

3.2.2 Relasi (Relationship)

Relasi (Relationship) adalah hubungan keterkaitan asosiatif yang bermakna secara bisnis di antara dua atau lebih entitas yang berbeda.

Di dalam dunia nyata, entitas tidak berdiri sendiri secara terpisah, melainkan saling berinteraksi:

• Seorang Mahasiswa mengambil Mata Kuliah.
• Seorang Dosen membimbing Mahasiswa.
• Seorang Pelanggan melakukan Pemesanan.
• Sebuah Departemen mempekerjakan Karyawan.

[ Mahasiswa ] <==== ( Mengambil ) ====> [ Mata Kuliah ]

Relasi dapat memiliki atribut tersendiri yang disebut atribut relasi (misalnya: atribut Nilai_Akhir yang baru memiliki makna ketika entitas Mahasiswa dihubungkan dengan entitas Mata Kuliah yang diambilnya).

3.2.3 Kunci (Key)

Di dalam sistem basis data, sangat penting untuk dapat membedakan satu instansiasi entitas dari instansiasi lainnya tanpa menimbulkan kerancuan. Untuk tujuan ini, digunakan konsep Kunci (Key).

1. Super Key

Sekumpulan satu atau lebih atribut yang secara bersama-sama dapat digunakan untuk mengidentifikasi sebuah baris/rekaman entitas secara unik dalam sebuah himpunan entitas.

• Contoh: Pada entitas Mahasiswa, pasangan atribut {NIM, Nama} atau {NIM, Email} atau hanya {NIM} adalah Super Key.

2. Calon Kunci (Candidate Key)

Sebuah Super Key yang berukuran minimal (minimal super key), artinya jika ada satu saja atribut yang dihilangkan dari himpunan tersebut, ia tidak lagi dapat menjamin keunikan identitas.

• Contoh: Jika pada entitas Mahasiswa, NIM, NIK (Nomor Induk Kependudukan), dan Email masing-masing bersifat unik, maka ketiga atribut tersebut merupakan Candidate Key.

3. Kunci Utama (Primary Key - PK)

Satu Candidate Key yang dipilih secara resmi oleh perancang basis data sebagai pembeda utama dan standar untuk mengidentifikasi setiap rekaman entitas secara tunggal.

• Kriteria Pemilihan Primary Key:
  • Bersifat unik mutlak (unique).
  • Tidak boleh bernilai kosong atau tidak diketahui (NOT NULL).
  • Nilainya stabil dan jarang atau tidak pernah berubah sepanjang waktu (immutable).
  • Berukuran seringkas mungkin (lebih disukai tipe data numerik atau kode singkat).

4. Kunci Tamu (Foreign Key - FK)

Satu atau sekumpulan atribut di dalam suatu entitas/tabel yang nilainya merujuk (referencing) ke Primary Key pada entitas/tabel lain. Kunci tamu berfungsi membentuk jalur relasi logis antar-tabel serta menegakkan aturan Integritas Referensial (Referential Integrity).

5. Kunci Alternatif (Alternate Key)

Semua Candidate Key yang tidak terpilih menjadi Primary Key.

6. Kunci Pengganti (Surrogate Key)

Kunci buatan (artificial key) yang dibuat secara otomatis oleh sistem (misalnya nomor urut ID AUTO_INCREMENT atau UUID) untuk dijadikan Primary Key, ketika atribut alami dunia nyata (natural key) berukuran terlalu panjang atau rentan berubah.

Perbandingan Jenis-Jenis Kunci

Rangkuman

• Entitas merepresentasikan objek di dunia nyata (konkret maupun abstrak).
• Atribut mendeskripsikan karakteristik atau sifat-sifat entitas.
• Relasi menghubungkan entitas-entitas yang saling berinteraksi dalam proses bisnis.
• Kunci (terutama Primary Key dan Foreign Key) menjamin integritas, keunikan, dan jalinan referensi antar-tabel dalam basis data.

BAB III: MODEL KONSEPTUAL BASIS DATA ENTITAS-RELASIONAL

3.3 MODEL E-R (ENTITY-RELATIONSHIP MODEL)

Model Entitas-Relasional (Entity-Relationship Model / ER Model) pertama kali diperkenalkan oleh ilmuwan komputer Dr. Peter Pin-Shan Chen pada tahun 1976 melalui makalah klasiknya berjudul:

"The Entity-Relationship Model: Toward a Unified View of Data" (ACM Transactions on Database Systems).

Peter Chen merancang model ini sebagai sarana unifikasi konseptual untuk menjembatani berbagai pandangan data yang saat itu terfragmentasi (model hierarkis, model jaringan, dan model relasional).

1. Tujuan dan Manfaat Model E-R

1. Abstraksi Tingkat Tinggi: Memudahkan visualisasi struktur basis data tanpa dibebani rincian implementasi perangkat keras atau DBMS tertentu.
2. Media Komunikasi Standar: Menjadi bahasa komunikasi visual yang dipahami dengan mudah oleh analis sistem, perancang basis data, pemrogram aplikasi, dan pengguna bisnis (end-users).
3. Dokumentasi Sistem Terpadu: Berfungsi sebagai cetak biru (blueprint) desain sistem informasi yang dapat dirujuk kapan saja untuk pemeliharaan dan ekspansi di masa depan.
4. Dasar Otomasi Desain: Model E-R yang dibuat menggunakan perangkat lunak berbantuan komputer (CASE Tools) dapat dikonversi secara otomatis menjadi skrip DDL SQL untuk membuat tabel-tabel di basis data.

2. Notasi Grafis Diagram E-R

Dalam literatur dan industri rekayasa perangkat lunak, terdapat dua gaya notasi grafis utama yang paling populer:

A. Notasi Klasik Peter Chen (Chen Notation)

Sering digunakan di lingkungan akademik karena penekanannya yang kuat pada konsep semantik:

• Persegi Panjang (Rectangle): Merepresentasikan Entitas.
• Belah Ketupat (Diamond): Merepresentasikan Relasi.
• Elips (Oval / Ellipse): Merepresentasikan Atribut.
• Garis (Line): Menghubungkan entitas dengan relasi atau atribut dengan entitas.
• Garis Bawah (Underline pada teks elips): Menandakan Kunci Utama (Primary Key).

    (NIM)---[ Mahasiswa ]---< Mengambil >---[ Mata_Kuliah ]---(Kode_MK)

B. Notasi Crow's Foot (Notasi Kaki Gagak / James Martin / Information Engineering)

Banyak digunakan di industri profesional dan perkakas CASE modern (seperti MySQL Workbench, ERDPlus, dbdiagram.io) karena lebih ringkas dan mudah dibaca:

• Entitas digambarkan sebagai kotak persegi dengan judul di bagian atas dan daftar atribut di dalamnya.
• Kunci utama diberi simbol kunci (PK) atau berada di kompartemen paling atas.
• Relasi digambarkan langsung sebagai garis penghubung antar-kotak tanpa simbol belah ketupat, dengan simbol ujung garis menyerupai kaki gagak (crow's foot) untuk menandakan kardinalitas "banyak" (many).

3. Perbandingan Notasi Chen vs Notasi Crow's Foot

4. Tahapan Sistematis Membangun Diagram E-R

Untuk menyusun Diagram E-R yang akurat dari deskripsi kebutuhan bisnis, ikuti lima langkah terstruktur berikut:

[ Langkah 1 ] Identifikasi Himpunan Entitas (Kata Benda)
      |
      v
[ Langkah 2 ] Identifikasi Relasi Antar-Entitas (Kata Kerja)
      |
      v
[ Langkah 3 ] Identifikasi Atribut dan Kunci Utama (PK)
      |
      v
[ Langkah 4 ] Tentukan Batasan Kardinalitas dan Modalitas (1:1, 1:N, M:N)
      |
      v
[ Langkah 5 ] Verifikasi dan Penyempurnaan Diagram Bersama Pengguna

5. Contoh Penerapan Model E-R (Kasus Akademik)

Deskripsi Kasus: "Sebuah perguruan tinggi memiliki banyak mahasiswa dan dosen. Setiap mahasiswa dibimbing oleh satu orang dosen pembimbing akademik, sedangkan satu orang dosen dapat membimbing banyak mahasiswa. Setiap mahasiswa dapat mengambil banyak mata kuliah, dan satu mata kuliah dapat diambil oleh banyak mahasiswa. Pada saat mahasiswa mengambil mata kuliah, tercatat nilai akhir hurufnya."

Representasi Diagram E-R (Konseptual):

erDiagram
    DOSEN ||--o{ MAHASISWA : "membimbing (1:N)"
    MAHASISWA }|--|{ MATA_KULIAH : "mengambil (M:N)"

    DOSEN {
        string NIDN PK
        string Nama_Dosen
        string Gelar
    }
    MAHASISWA {
        string NIM PK
        string Nama_Mhs
        string Jurusan
    }
    MATA_KULIAH {
        string Kode_MK PK
        string Nama_MK
        int SKS
    }

Pada relasi banyak-ke-banyak (M:N) antara MAHASISWA dan MATA_KULIAH, terdapat atribut relasi Nilai_Akhir yang nantinya saat perancangan logika akan dipetakan menjadi tabel perantara (KRS / Transkrip).

Rangkuman

Model E-R menyediakan sarana formal tingkat tinggi untuk memvisualisasikan semantik data dan relasinya di dunia nyata. Dengan memahami notasi standar (Chen maupun Crow's Foot), perancang basis data dapat memodelkan kebutuhan sistem secara presisi sebelum melangkah ke tahap pengkodean basis data fisik.

BAB III: MODEL KONSEPTUAL BASIS DATA ENTITAS-RELASIONAL

3.4 ENTITAS DAN ATRIBUT

Pemahaman mendalam mengenai taksonomi entitas dan karakteristik atribut merupakan syarat mutlak dalam menyusun diagram konseptual yang kokoh dan bebas dari kerancuan data.

3.4.1 Tipe Entitas dan Instansiasi Entitas

Sangat penting untuk membedakan antara konsep abstrak dari suatu entitas dengan data nyata yang mewakilinya:

A. Tipe Entitas (Entity Type)

Koleksi atau kumpulan dari objek-objek sejenis yang berbagi sekumpulan properti atau atribut yang sama. Tipe entitas bertindak sebagai cetak biru (blueprint) atau definisi skema.

• Contoh: Tipe Entitas MAHASISWA, KURSUS, FAKTUR.

B. Himpunan Entitas (Entity Set)

Kumpulan semua instansiasi dari suatu tipe entitas tertentu yang ada di dalam basis data pada suatu titik waktu tertentu.

• Contoh: Himpunan seluruh mahasiswa yang terdaftar aktif pada semester ganjil tahun 2026.

C. Instansiasi Entitas (Entity Instance / Occurrence)

Satu kemunculan objek tunggal tertentu dari suatu tipe entitas yang memiliki nilai-nilai data konkret untuk setiap atributnya.

• Contoh: Seorang mahasiswa bernama Rudi Hermawan dengan NIM 2026001 dan Jurusan Informatika.

Tipe Entitas: MAHASISWA (NIM, Nama, Jurusan)
     |
     +---> Instansiasi 1: ("2026001", "Rudi Hermawan", "Informatika")
     +---> Instansiasi 2: ("2026002", "Dewi Lestari", "Sistem Informasi")
     +---> Instansiasi 3: ("2026003", "Budi Santoso", "Teknik Elektro")

3.4.2 Entitas Kuat dan Entitas Lemah

Berdasarkan kemandirian eksistensinya, entitas dibedakan menjadi:

A. Entitas Kuat (Strong Entity / Regular Entity)

• Definisi: Entitas yang keberadaannya (existence) di dalam sistem tidak bergantung pada keberadaan entitas lainnya.
• Karakteristik: Memiliki atribut pengenal unik tersendiri yang dapat langsung berfungsi sebagai Primary Key.
• Notasi Chen: Digambarkan dengan kotak persegi tunggal.
• Contoh: KARYAWAN (memiliki PK unik ID_Karyawan), MAHASISWA (memiliki PK unik NIM).

B. Entitas Lemah (Weak Entity)

• Definisi: Entitas yang keberadaannya sangat bergantung pada keberadaan entitas lain (yang disebut sebagai identifying owner entity). Jika entitas pemiliknya dihapus, entitas lemah tersebut otomatis tidak memiliki arti lagi dan harus dihapus.
• Karakteristik: Tidak memiliki atribut yang cukup untuk membentuk Primary Key sendiri secara independen. Entitas lemah hanya memiliki Kunci Sebagian (Partial Key / Discriminator), yaitu atribut yang membedakan instansiasi entitas lemah dalam lingkup satu entitas pemilik yang sama.
• Notasi Chen: Digambarkan dengan kotak persegi ganda (double rectangle), dihubungkan ke entitas pemilik melalui relasi identifikasi berupa belah ketupat ganda (identifying relationship - double diamond), dan kunci sebagian digarisbawahi putus-putus (dashed underline).
• Contoh Kasus: Entitas TANGGUNGAN (anak/istri karyawan) yang bergantung pada entitas KARYAWAN.
  • Jika seorang karyawan mengundurkan diri, seluruh data tanggungannya di bagian asuransi perusahaan ikut terhapus.
  • Atribut Nama_Anak bertindak sebagai kunci sebagian (partial key). Kunci utama komposit TANGGUNGAN dibentuk dari gabungan (ID_Karyawan, Nama_Anak).

[ KARYAWAN ] <==== double diamond: < Memiliki > ====> [[ TANGGUNGAN ]]
  (ID_Karyawan)                                         (-Nama_Tanggungan-)

3.4.3 Entitas Asosiatif (Associative Entity)

Entitas Asosiatif adalah suatu entitas yang terbentuk dari hasil perombakan sebuah relasi banyak-ke-banyak (M:N) yang diasosiasikan sebagai entitas mandiri karena memiliki atribut-atribut tambahan tersendiri yang penting untuk dicatat.

Dalam notasi Chen, entitas asosiatif digambarkan sebagai sebuah belah ketupat relasi yang diletakkan di dalam kotak persegi panjang.

Kapan sebuah relasi diubah menjadi Entitas Asosiatif?

1. Terdapat relasi berderajat banyak-ke-banyak (M:N) antar entitas.
2. Relasi tersebut memiliki atribut deskriptif sendiri (misal: tanggal transaksi, jumlah kuantitas, nilai ujian).
3. Entitas asosiatif memiliki makna bisnis independen bagi pengguna (misal: relasi MEMESAN antara PELANGGAN dan PRODUK bermutasi menjadi entitas asosiatif DETAIL_PESANAN atau FAKTUR).
4. Entitas hasil relasi tersebut perlu berpartisipasi dalam hubungan relasi lain di masa mendatang.

3.4.4 Atribut dan Klasifikasinya

Atribut diklasifikasikan ke dalam beberapa dimensi berdasarkan struktur, jumlah nilai, dan metode perolehan nilainya:

1. Atribut Sederhana vs Atribut Komposit

• Atribut Sederhana (Simple / Atomic Attribute): Atribut yang tidak dapat dipecah lagi menjadi bagian-bagian yang lebih kecil.
  • Contoh: Jenis_Kelamin (L/P), Gaji_Pokok, IPK.
• Atribut Komposit (Composite Attribute): Atribut yang dapat didekomposisi atau dipecah menjadi beberapa sub-atribut komponen yang lebih mendasar.
  • Contoh: Atribut Nama_Lengkap dapat dipecah menjadi Nama_Depan, Nama_Tengah, dan Nama_Belakang. Atribut Alamat dapat dipecah menjadi Nama_Jalan, Nomor_Rumah, Kota, dan Kode_Pos.

2. Atribut Bernilai Tunggal vs Bernilai Banyak

• Atribut Bernilai Tunggal (Single-Valued Attribute): Atribut yang hanya memiliki tepat satu nilai untuk setiap instansiasi entitas.
  • Contoh: Tanggal_Lahir, Nomor_KTP, NIM.
• Atribut Bernilai Banyak (Multi-Valued Attribute): Atribut yang dapat memiliki lebih dari satu nilai untuk satu instansiasi entitas yang sama.
  • Contoh: Nomor_HP (seorang mahasiswa bisa memiliki 2 atau 3 nomor HP aktif), Gelar_Akademik, Keahlian (seorang pelamar bisa menguasai Java, Python, dan SQL).
  • Notasi Chen: Digambarkan dengan elips ganda (double ellipse). Pada tahap perancangan logika, atribut bernilai banyak harus dipisahkan ke dalam tabel baru agar memenuhi aturan 1NF.

3. Atribut Tersimpan vs Atribut Turunan

• Atribut Tersimpan (Stored Attribute): Atribut yang nilainya diinput dan disimpan secara permanen di dalam media penyimpanan.
  • Contoh: Tanggal_Lahir, Jam_Masuk.
• Atribut Turunan (Derived Attribute): Atribut yang nilainya tidak disimpan secara fisik di disk, melainkan dihitung atau diturunkan dari nilai atribut tersimpan lainnya atau dari fungsi waktu sistem saat kueri dijalankan.
  • Contoh: Atribut Umur (diturunkan dari rumus: Tahun_Sekarang - Tahun_Lahir), atribut Total_Harga (diturunkan dari: Harga_Satuan * Jumlah_Beli).
  • Notasi Chen: Digambarkan dengan elips garis putus-putus (dashed ellipse).

+---------------------------------------------------------------+
|                      TAKSONOMI ATRIBUT                        |
+----------------------+--------------------+-------------------+
| Kategori             | Jenis Pertama      | Jenis Kedua       |
+----------------------+--------------------+-------------------+
| Struktur Pemecahan   | Sederhana (Atomik) | Komposit          |
| Banyaknya Nilai      | Bernilai Tunggal   | Bernilai Banyak   |
| Sumber Perolehan     | Tersimpan (Stored) | Turunan (Derived) |
+----------------------+--------------------+-------------------+

Rangkuman

• Pembedaan tipe entitas (skema) dan instansiasi (data konkret) memperjelas batasan rancangan.
• Entitas Kuat memiliki eksistensi mandiri, sedangkan Entitas Lemah bergantung pada entitas pemilik dengan bantuan partial key.
• Entitas Asosiatif memfasilitasi relasi banyak-ke-banyak yang memiliki atribut tersendiri.
• Karakteristik atribut (komposit, multi-valued, derived) menentukan langkah transformasi pada tahap perancangan logika tabel relasional.

BAB III: MODEL KONSEPTUAL BASIS DATA ENTITAS-RELASIONAL

3.5 RELASI

Relasi merepresentasikan ikatan asosiatif dinamis antar-entitas yang mencerminkan peristiwa, transaksi, atau keterhubungan dalam proses bisnis organisasi.

3.5.1 Konsep Dasar dan Definisi untuk Relasi

Tipe Relasi (Relationship Type) adalah asosiasi yang bermakna secara bisnis di antara beberapa tipe entitas yang berpartisipasi.

Himpunan relasi (relationship set) adalah kumpulan dari instansiasi relasi yang sejenis.

• Contoh: Pernyataan "Mahasiswa bernama Rudi Hermawan mengambil mata kuliah Basis Data" adalah satu instansiasi relasi yang menghubungkan instansiasi MAHASISWA dengan instansiasi MATA_KULIAH.

3.5.2 Atribut Relasi (Descriptive Attributes)

Relasi tidak hanya menghubungkan dua entitas, tetapi dapat memiliki atribut deskriptif sendiri. Atribut ini tidak dapat ditempatkan secara logis pada salah satu entitas secara sepihak, melainkan hanya eksis ketika kedua entitas tersebut saling berinteraksi.

Contoh Kasus:

• Entitas KARYAWAN bekerja pada entitas PROYEK.
• Atribut Jumlah_Jam_Kerja atau Peran (misal: Lead Developer) hanya memiliki makna ketika seorang karyawan tertentu dihubungkan dengan proyek tertentu.
• Pada notasi Chen, atribut relasi digambarkan sebagai elips yang terhubung langsung ke belah ketupat relasi.

3.5.3 Entitas Asosiatif (Associative Entity)

Ketika sebuah relasi berderajat banyak-ke-banyak (M:N) memiliki atribut deskriptif yang kompleks, relasi tersebut sering kali diangkat kedudukannya (promoted) menjadi Entitas Asosiatif.

• Mengubah relasi konseptual murni menjadi entitas baru yang dapat memiliki atribut sendiri, menjadi induk dari relasi lain, dan memudahkan pemetaan ke tabel perantara (junction table) saat tahap perancangan logika.
• Contoh: Relasi MEMESAN antara PELANGGAN dan PRODUK bermutasi menjadi entitas asosiatif FAKTUR atau ITEM_PESANAN.

3.5.4 Derajat Relasi (Degree of Relationship)

Derajat relasi menunjukkan jumlah tipe entitas yang berpartisipasi dalam relasi tersebut:

1. Relasi Berderajat Satu / Unary (Recursive Relationship)

Hanya melibatkan satu tipe entitas yang berelasi dengan dirinya sendiri.

• Contoh 1: Entitas KARYAWAN dalam relasi Memimpin / Mensupervisi. Seorang karyawan (manajer) mensupervisi karyawan lainnya.
• Contoh 2: Entitas MATA_KULIAH dalam relasi Prasyarat. Suatu mata kuliah menjadi prasyarat bagi mata kuliah lainnya.

2. Relasi Berderajat Dua / Binary

Melibatkan dua tipe entitas yang berbeda. Ini adalah derajat relasi yang paling umum ditemui dalam pemodelan data.

• Contoh: DOSEN mengajar KELAS, PELANGGAN melakukan PEMESANAN.

3. Relasi Berderajat Tiga / Ternary

Melibatkan tiga tipe entitas berbeda secara simultan dalam satu jalinan relasi tunggal.

• Contoh: Relasi MEMASOK yang menghubungkan secara bersamaan: PEMASOK memasok KOMPONEN untuk PROYEK tertentu.
• Ketiga entitas tersebut harus hadir bersama-sama agar transaksi pengiriman memiliki makna utuh.

4. Relasi Berderajat Tinggi / N-ary

Melibatkan $N$ tipe entitas yang berbeda. Dalam praktiknya, relasi dengan derajat lebih dari tiga ($N > 3$) sangat dianjurkan untuk dipecah (decomposed) menjadi kumpulan relasi biner agar kompleksitasnya dapat dikendalikan.

+-------------------------------------------------------------+
|                      DERAJAT RELASI                         |
+-------------------+--------------------+--------------------+
| Unary (Derajat 1) | Binary (Derajat 2) | Ternary (Derajat 3)|
+-------------------+--------------------+--------------------+
|  [ Karyawan ]     |  [ Dosen ]         |    [ Pemasok ]     |
|    |      ^       |     |              |         |          |
|    +--<Supervisi> |     v              |         v          |
|                   |  < Mengajar >      |    < Memasok >     |
|                   |     ^              |      /     \       |
|                   |     |              |     v       v      |
|                   |  [ Kelas ]         | [Komponen] [Proyek]|
+-------------------+--------------------+--------------------+

3.5.5 Batasan Kardinalitas dan Batasan Partisipasi

Batasan pada relasi menentukan konfigurasi dan kuantitas instansiasi entitas yang diizinkan untuk saling terhubung.

A. Rasio Kardinalitas (Cardinality Ratio)

Menyatakan jumlah maksimum instansiasi entitas yang dapat berelasi dengan satu instansiasi entitas lainnya:

1. Satu-ke-Satu (1:1): Satu entitas A berelasi dengan maksimal satu entitas B, dan sebaliknya.
   • Contoh: Satu DOSEN mengepalai tepat satu JURUSAN.
2. Satu-ke-Banyak (1:N): Satu entitas A dapat berelasi dengan banyak entitas B, tetapi satu entitas B hanya berelasi dengan maksimal satu entitas A.
   • Contoh: Satu JURUSAN menaungi banyak MAHASISWA.
3. Banyak-ke-Banyak (M:N): Satu entitas A dapat berelasi dengan banyak entitas B, dan satu entitas B dapat berelasi dengan banyak entitas A.
   • Contoh: Banyak MAHASISWA mengambil banyak MATA_KULIAH.

B. Batasan Partisipasi / Modalitas (Participation Constraint)

Menyatakan jumlah minimum instansiasi entitas yang harus berpartisipasi dalam relasi:

1. Partisipasi Total / Wajib (Total / Mandatory Participation):
   • Setiap instansiasi entitas harus berpartisipasi dalam relasi tersebut (kardinalitas minimum = 1).
   • Digambarkan dengan garis ganda (double line) pada notasi Chen.
   • Contoh: Setiap PASIEN_RAWAT_INAP harus ditempatkan di sebuah KAMAR.
2. Partisipasi Parsial / Opsional (Partial / Optional Participation):
   • Tidak semua instansiasi entitas harus berpartisipasi dalam relasi tersebut (kardinalitas minimum = 0).
   • Digambarkan dengan garis tunggal pada notasi Chen.
   • Contoh: Tidak semua DOSEN harus menjabat sebagai kepala jurusan.

3.5.6 Pemodelan Data Bergantung Waktu (Time-Stamped / Historical Data)

Dalam proses bisnis nyata, relasi sering kali berubah seiring berjalannya waktu:

• Contoh: Harga produk naik setiap tahun, status kepegawaian berganti dari staf menjadi manajer, atau tarif sewa kamar berubah saat musim liburan.
• Jika basis data hanya mencatat kondisi terkini (current state), maka riwayat transaksi masa lalu akan rusak atau tidak akurat saat diaudit.
• Solusi Pemodelan Bergantung Waktu: Menyertakan atribut dimensi waktu, seperti Tanggal_Mulai (Effective_Date) dan Tanggal_Selesai (End_Date), atau mencatat cap waktu (Timestamp) pada relasi/entitas asosiatif guna merekam seluruh rekam jejak historis.

3.5.7 Relasi Ganda (Multiple Relationships)

Dua tipe entitas yang sama dapat dihubungkan oleh lebih dari satu relasi yang berbeda secara simultan, karena masing-masing relasi mewakili proses bisnis yang berlainan.

Contoh Kasus: Hubungan antara entitas DOSEN dan JURUSAN:

1. Relasi 1: DOSEN Bekerja_Di JURUSAN (Kardinalitas N:1, banyak dosen bekerja di satu jurusan).
2. Relasi 2: DOSEN Menjabat_Kajur_Di JURUSAN (Kardinalitas 1:1, hanya satu dosen yang menjabat sebagai kepala jurusan).

Kedua relasi ini harus digambarkan secara terpisah dalam ERD karena memiliki aturan bisnis, kardinalitas, dan implikasi implementasi yang berbeda.

3.5.8 Agregasi (Aggregation)

Agregasi adalah abstraksi pemodelan di mana suatu relasi antar-entitas diperlakukan sebagai suatu entitas tingkat tinggi (higher-level entity), sehingga relasi tersebut dapat dihubungkan lagi dengan entitas lain melalui relasi lanjutan.

Kapan Agregasi Digunakan? Ketika kita ingin menyatakan relasi antara suatu entitas dengan suatu relasi yang sudah ada sebelumnya.

Contoh Kasus:

• KARYAWAN bekerja pada PROYEK.
• Untuk proyek tersebut, tim membutuhkan PERALATAN_KHUSUS.
• Relasi Menggunakan_Peralatan tidak menghubungkan karyawan secara pribadi, melainkan menghubungkan ikatan kerja antara karyawan pada proyek tertentu dengan peralatan yang dipakai.
• Solusi: Relasi (KARYAWAN - Bekerja_Pada - PROYEK) dibungkus di dalam kotak agregasi, kemudian dari kotak agregasi ditarik garis relasi baru ke entitas PERALATAN.

Rangkuman

• Relasi menghubungkan entitas dengan variasi derajat: Unary, Binary, hingga Ternary.
• Integritas data dijaga melalui pengaturan rasio kardinalitas (1:1, 1:N, M:N) dan partisipasi (Mandatory vs Optional).
• Kebutuhan bisnis yang kompleks diakomodasi melalui Entitas Asosiatif, Pemodelan Data Bergantung Waktu, Relasi Ganda, dan Agregasi.

BAB III: MODEL KONSEPTUAL BASIS DATA ENTITAS-RELASIONAL

3.6 ENHANCED ENTITY RELATIONSHIP DIAGRAM (EERD)

Seiring berkembangnya kompleksitas aplikasi basis data modern (seperti sistem CAD/CAM, rekayasa geospasial/GIS, dan sistem enterprise terintegrasi), model E-R tradisional dirasa kurang memadai untuk menangkap konsep pewarisan (inheritance) dan pengelompokan hierarkis objek.

Oleh karena itu, dikembangkanlah Model E-R yang Ditingkatkan (Enhanced Entity-Relationship Model / EERD), yang mengintegrasikan konsep-konsep berorientasi objek seperti Supertipe, Subtipe, Pewarisan Atribut, Spesialisasi, dan Generalisasi.

3.6.1 Notasi dan Konsep Dasar

A. Konsep Supertipe dan Subtipe

• Supertipe Entitas (Entity Supertype): Tipe entitas generik yang memuat sekumpulan atribut dan relasi bersama yang dimiliki oleh seluruh subkelompok di bawahnya.
• Subtipe Entitas (Entity Subtype): Pengelompokan spesifik dari suatu entitas supertipe yang memiliki atribut unik tersendiri atau berpartisipasi dalam relasi khusus yang tidak berlaku untuk subtipe lainnya.

B. Konsep Pewarisan Atribut (Attribute Inheritance)

Prinsip paling penting dalam EERD adalah Pewarisan (Inheritance):

Setiap instansiasi entitas subtipe secara otomatis mewarisi seluruh atribut dan seluruh relasi yang didefinisikan pada entitas supertipenya, sekaligus memiliki atribut unik khusus miliknya sendiri.

Contoh Kasus:

• Supertipe: KARYAWAN
  • Atribut bersama: ID_Karyawan (PK), Nama, Alamat, Tanggal_Masuk.
• Subtipe 1: KARYAWAN_TETAP
  • Atribut unik: Gaji_Bulanan, Tunjangan_Kesehatan.
• Subtipe 2: KARYAWAN_KONTRAK
  • Atribut unik: Tarif_Per_Jam, Tanggal_Berakhir_Kontrak.

Instansiasi KARYAWAN_TETAP secara otomatis memiliki atribut: ID_Karyawan, Nama, Alamat, Tanggal_Masuk, Gaji_Bulanan, dan Tunjangan_Kesehatan.

                  +-----------------------------------+
                  |        KARYAWAN (Supertipe)       |
                  | (ID_Karyawan, Nama, Tgl_Masuk)    |
                  +-----------------------------------+
                                    |
                                  ( d ) Disjoint
                                  /   \
          +----------------------+     +----------------------+
          |                                                   |
          v                                                   v
+-------------------------+                 +-------------------------+
| KARYAWAN_TETAP          |                 | KARYAWAN_KONTRAK        |
| (Gaji_Bulanan,          |                 | (Tarif_Per_Jam,         |
|  Tunjangan_Kesehatan)   |                 |  Tgl_Akhir_Kontrak)     |
+-------------------------+                 +-------------------------+

3.6.2 Spesialisasi dan Generalisasi

Dua proses utama yang digunakan dalam menyusun hierarki supertipe-subtipe:

A. Spesialisasi (Specialization - Top-Down Approach)

• Proses mendefinisikan satu atau lebih subtipe dari suatu supertipe entitas yang sudah ada, berdasarkan karakteristik khusus atau pembeda tertentu.
• Pendekatan berpikir dari atas ke bawah (top-down): dimulai dari konsep umum, lalu dipecah ke dalam kategori-kategori yang lebih spesifik.
• Contoh: Dari entitas umum KENDARAAN, dispesialisasikan menjadi MOBIL, TRUK, dan SEPEDA_MOTOR.

B. Generalisasi (Generalization - Bottom-Up Approach)

• Proses menyatukan beberapa tipe entitas yang memiliki karakteristik umum yang sama ke dalam sebuah supertipe tunggal tingkat tinggi.
• Pendekatan berpikir dari bawah ke atas (bottom-up): meminimalkan redundansi dengan mengabstraksikan persamaan atribut ke supertipe.
• Contoh: Dari entitas awal TABUNGAN, DEPOSITO, dan GIRO, diidentifikasi memiliki persamaan (nomor rekening, saldo, tanggal buka), sehingga digeneralisasikan ke dalam supertipe REKENING.

3.6.3 Batasan dalam Menspesifikasi Hubungan Generalisasi-Spesialisasi

Untuk memastikan ketepatan logika data, perancang harus menetapkan dua jenis aturan batasan:

1. Batasan Disjoin (Disjointness Constraint)

Menentukan apakah suatu instansiasi supertipe boleh menjadi anggota dari lebih dari satu subtipe pada saat yang sama:

• Disjoin (Disjoint Rule - Disimbolkan huruf 'd'):
  • Satu instansiasi supertipe hanya boleh menjadi anggota dari tepat satu subtipe.
  • Subtipe-subtipe bersifat saling lepas (mutually exclusive).
  • Contoh: Pasien rumah sakit hanya bisa berupa PASIEN_RAWAT_INAP ATAU PASIEN_RAWAT_JALAN, tidak bisa keduanya sekaligus.
• Tumpang Tindih (Overlapping Rule - Disimbolkan huruf 'o'):
  • Satu instansiasi supertipe boleh menjadi anggota dari lebih dari satu subtipe secara simultan.
  • Contoh: Di lingkungan kampus, seseorang dengan supertipe CIVITAS_AKADEMIKA dapat sekaligus menjadi MAHASISWA dan ASISTEN_DOSEN atau KARYAWAN.

2. Batasan Kelengkapan (Completeness Constraint)

Menentukan apakah setiap instansiasi supertipe wajib menjadi anggota dari salah satu subtipe yang tersedia:

• Spesialisasi Total (Total Specialization - Garis Ganda):
  • Setiap instansiasi supertipe wajib merupakan salah satu dari subtipe yang ada. Tidak boleh ada instansiasi supertipe yang berdiri sendiri tanpa subtipe.
  • Contoh: Setiap PASIEN wajib terdaftar sebagai PASIEN_RAWAT_INAP atau PASIEN_RAWAT_JALAN.
• Spesialisasi Parsial (Partial Specialization - Garis Tunggal):
  • Suatu instansiasi supertipe tidak harus menjadi salah satu dari subtipe yang didefinisikan. Ada instansiasi supertipe yang bukan merupakan subtipe mana pun.
  • Contoh: Pada supertipe KENDARAAN, subtipe yang didefinisikan adalah MOBIL dan TRUK. Jika perusahaan membeli SEPEDA_MOTOR, ia tetap sah menjadi KENDARAAN tanpa harus masuk ke subtipe yang ada.

+---------------------------------------------------------------+
|             MATRIKS KOMBINASI BATASAN EERD                    |
+--------------------------+------------------------------------+
| Disjoint & Total (d, = ) | Setiap baris masuk ke tepat 1      |
|                          | subtipe, wajib punya subtipe.      |
+--------------------------+------------------------------------+
| Disjoint & Partial (d, -)| Masuk ke max 1 subtipe, boleh tidak|
|                          | masuk subtipe mana pun.            |
+--------------------------+------------------------------------+
| Overlap & Total (o, = )  | Boleh masuk > 1 subtipe, wajib     |
|                          | memiliki minimal 1 subtipe.        |
+--------------------------+------------------------------------+
| Overlap & Partial (o, -) | Boleh masuk > 1 subtipe, dan boleh |
|                          | tidak masuk subtipe mana pun.      |
+--------------------------+------------------------------------+

Rangkuman

• EERD memperluas model E-R dengan kapabilitas abstraksi tingkat tinggi: Supertipe, Subtipe, dan Pewarisan Atribut.
• Spesialisasi (top-down) memecah entitas umum menjadi khusus, sedangkan Generalisasi (bottom-up) mengabstraksikan kesamaan entitas menjadi supertipe.
• Batasan penataan hierarki dikontrol ketat melalui Disjoint vs Overlapping serta Total vs Partial Specialization.

BAB III: MODEL KONSEPTUAL BASIS DATA ENTITAS-RELASIONAL

3.7 ATURAN BISNIS (BUSINESS RULES)

Basis data bukanlah sekadar tempat penampungan data pasif, melainkan cerminan dari kebijakan, regulasi, dan prosedur operasional organisasi. Pernyataan formal yang mendefinisikan atau membatasi aspek-aspek bisnis tersebut dikenal sebagai Aturan Bisnis (Business Rules).

3.7.1 Paradigma Aturan Bisnis

Aturan Bisnis adalah pernyataan singkat, deklaratif, dan tegas yang mendefinisikan atau membatasi beberapa aspek bisnis, kebijakan perusahaan, atau operasi organisasi. Aturan bisnis menetapkan struktur data atau mengendalikan perilaku (behavior) dari proses bisnis.

Karakteristik Aturan Bisnis yang Baik:

1. Deklaratif (Declarative): Menyatakan apa aturan yang berlaku, bukan bagaimana prosedur teknis algoritma implementasinya.
2. Tegas dan Tidak Ambigu (Precise & Unambiguous): Menggunakan istilah baku yang hanya memiliki satu interpretasi logis.
3. Dapat Dinyatakan dalam Bahasa Alami: Ditulis dalam bahasa bisnis yang dipahami oleh pengguna awam dan analis.
4. Dapat Ditegakkan (Enforceable): Dapat diverifikasi dan ditegakkan secara sistematis oleh DBMS (melalui batasan/skema) atau program aplikasi.

Contoh Pernyataan Aturan Bisnis:

• "Seorang mahasiswa hanya dapat mengambil maksimal 24 SKS dalam satu semester."
• "Setiap faktur pesanan harus terkait dengan tepat satu pelanggan terdaftar."
• "Diskon loyalitas 10% hanya diberikan kepada anggota yang telah bergabung lebih dari 1 tahun dan memiliki total belanja di atas Rp 1.000.000,-."

3.7.2 Klasifikasi Aturan Bisnis

Aturan bisnis secara umum diklasifikasikan ke dalam dua kategori besar:

                     +---------------------------------------+
                     |            ATURAN BISNIS              |
                     +---------------------------------------+
                                         |
                 +-----------------------+-----------------------+
                 |                                               |
                 v                                               v
+---------------------------------+             +---------------------------------+
|   BATASAN STRUKTURAL            |             |   ATURAN OPERASIONAL            |
|   (Structural Assertions)       |             |   (Action / Operational Rules)  |
|   - Karakteristik data & relasi |             |   - Alur kerja, kalkulasi,      |
|   - Dimodelkan langsung di ERD  |             |     kondisi pemicu (IF-THEN)    |
|   - Ditegakkan skema DBMS (DDL) |             |   - Ditegakkan Trigger / App    |
+---------------------------------+             +---------------------------------+

1. Batasan Struktural (Structural Assertions / Constraints): Aturan yang berkaitan dengan keberadaan, klasifikasi, komposisi, serta hubungan statis antar-entitas dan atribut. Aturan ini diekspresikan secara langsung di dalam Diagram E-R.
2. Aturan Operasional (Action / Operational Assertions): Aturan yang berkaitan dengan dinamika operasional, peristiwa (events), kalkulasi kondisional, dan batasan alur kerja (workflow constraints).

3.7.3 Mendefinisikan Batasan Struktural

Batasan struktural adalah aturan yang dapat langsung dipetakan ke dalam elemen-elemen model konseptual E-R dan dieksekusi secara otomatis oleh mesin DBMS menggunakan sintaks DDL:

1. Batasan Tipe dan Keberadaan (Type and Existence Constraints)

• Menentukan apakah suatu entitas wajib memiliki atribut tertentu.
• Implementasi SQL: Batasan NOT NULL.
• Contoh: "Setiap pelanggan wajib mencantumkan Nomor Induk Kependudukan (NIK) dan nama lengkap."

2. Batasan Keunikan (Uniqueness Constraints)

• Memastikan tidak ada duplikasi nilai identitas dalam kumpulan entitas.
• Implementasi SQL: Batasan PRIMARY KEY dan UNIQUE.
• Contoh: "Setiap alamat email pengguna harus bersifat unik di seluruh sistem."

3. Batasan Domain Nilai (Domain Constraints)

• Membatasi rentang atau daftar nilai legal yang boleh diinputkan ke dalam atribut.
• Implementasi SQL: Batasan CHECK atau tipe data ENUM.
• Contoh: "Nilai IPK harus berada di antara 0.00 hingga 4.00", atau "Status perkawinan hanya boleh bernilai: Lajang, Menikah, atau Cerai."

4. Batasan Hubungan dan Kardinalitas (Relationship & Multiplicity Constraints)

• Mengatur relasi antar-entitas, derajat partisipasi (apakah wajib atau opsional), serta rasio kardinalitas (1:1, 1:N, M:N).
• Implementasi SQL: Batasan FOREIGN KEY dengan opsi ON DELETE RESTRICT / CASCADE.
• Contoh: "Satu departemen dapat memiliki banyak karyawan, tetapi setiap karyawan hanya boleh terdaftar pada tepat satu departemen."

3.7.4 Mendefinisikan Aturan Operasional

Aturan operasional adalah aturan dinamis yang melibatkan kondisi logika bisnis (condition), peristiwa pemicu (event), dan tindakan lanjutan (action):

Pola Standar: Event-Condition-Action (ECA)

ON (Event: Peristiwa Terjadi)
IF (Condition: Syarat Terpenuhi)
THEN (Action: Jalankan Tindakan / Batalkan Transaksi)

Contoh Penerapan Aturan Operasional:

1. Aturan Validasi Transaksi:
   • Pernyataan: "Saldo rekening sumber tidak boleh kurang dari jumlah uang yang akan ditransfer ditambah biaya admin transfer."
   • Penegakan: Logika program backend atau Stored Procedure di DBMS.
2. Aturan Pemicu Otomatis (Database Trigger):
   • Pernyataan: "Jika stok barang di gudang turun hingga di bawah batas minimum (<= 5 unit), sistem harus secara otomatis mencatat pengajuan pesanan ulang (reorder) ke pemasok terkait."
   • Penegakan: Pemicu SQL (AFTER UPDATE TRIGGER).
3. Aturan Kalkulasi Bisnis:
   • Pernyataan: "Bunga pinjaman dihitung sebesar 1.5% per bulan dari sisa pokok pinjaman jika pembayaran dilakukan tepat waktu, dan dikenakan denda 0.5% per hari jika terlambat."
   • Penegakan: Logika fungsi aplikasi atau fungsi tersimpan (User-Defined Function / UDF).

Hubungan antara Aturan Bisnis dan Diagram E-R

Rangkuman

• Aturan Bisnis adalah jembatan antara kebijakan manajemen organisasi dengan arsitektur sistem perangkat lunak.
• Batasan Struktural dimodelkan langsung ke dalam Diagram E-R dan ditegakkan secara permanen oleh skema DBMS.
• Aturan Operasional mengendalikan perilaku dinamis dan alur kerja yang ditegakkan melalui pemicu (triggers), prosedur tersimpan (stored procedures), atau kode logika aplikasi.