Pertemuan 1 — Introduction to Database Concepts

TL;DR — Basis data bukan sekadar “kumpulan file”. Ia adalah sistem yang menyimpan, mengelola, dan melindungi data agar bisa diandalkan banyak pengguna sekaligus. Pertemuan ini meletakkan fondasi: apa itu data, DBMS, model data, bahasa query, dan kenapa kita butuh semuanya sebelum menyentuh SQL di pertemuan 6.

Tujuan Pembelajaran

Setelah pertemuan ini, mahasiswa mampu:

1. Membedakan data, basis data, dan DBMS.
2. Menjelaskan alasan DBMS menggantikan file system.
3. Mengenali model data yang umum dipakai (relasional, ER, semi-terstruktur).
4. Membedakan DDL, DML, dan bahasa query.
5. Memahami tahapan perancangan basis data.
6. Mengidentifikasi komponen arsitektur sistem basis data.
7. Menerapkan analisis relasional pada studi kasus nyata.

1. Konsep Dasar

1.1 Data, Basis Data, DBMS

Sebelum bicara teknologi, kita perlu sepakati istilahnya dulu. Salah kaprah paling umum: menganggap data, basis data, dan DBMS itu sama. Padahal tiga hal berbeda.

Contoh DBMS yang umum dipakai:

Datum → Data → Informasi:

• Datum: "Budi"
• Data: ("Budi", 25, "Bandung")
• Informasi: “Budi, 25 tahun, dari Bandung”

Satu datum tidak bisa dikaitkan ke siapa pun. Begitu digabung jadi tuple (nama, umur, kota), ia baru bermakna. Ini poin penting: basis data menyimpan data, tapi tujuannya menghasilkan informasi.

Kesalahan umum: menyebut MySQL sebagai “basis data”. MySQL adalah DBMS — software. Basis datanya adalah kumpulan tabel yang dikelola oleh MySQL. Bedakan keduanya.

1.2 Peran Basis Data di Aplikasi Nyata

Hampir semua aplikasi modern yang menyimpan state pakai basis data. Contoh:

Pertanyaan diagnostik: kalau aplikasimu hilang semua datanya, apakah masih berguna? Kalau jawabannya tidak, berarti basis data adalah jantung aplikasi itu.

2. Kenapa DBMS, Bukan File System?

Sebelum era DBMS (1960-an), aplikasi menyimpan data di file biasa — TXT, CSV, Excel. Ini masih umum di proyek kecil dan script sederhana. Tapi begitu aplikasi tumbuh, file system mulai retak.

Contoh nyata: bayangkan dua file — mahasiswa.csv dan nilai.csv. Keduanya menyimpan NIM dan nama_mahasiswa. Kalau Budi ganti nama, kamu harus update di dua file. Kalau salah satu lupa di-update, data jadi inkonsisten — dan tidak ada yang mendeteksi. Di DBMS, ini dicegah oleh normalisasi (nama disimpan sekali) dan foreign key (relasi antar-tabel dijaga).

ACID — Empat Jaminan Transaksi

Ini alasan paling sering orang beralih dari file system: transaksi. Saat transfer uang antar rekening, kamu tidak mau saldo terpotong di satu sisi tapi tidak masuk di sisi lain. DBMS menjamin ini dengan empat properti — singkatan ACID:

Kesalahan umum: menganggap ACID itu otomatis di semua DBMS. Tidak. Banyak operasi bisa dimatikan (mis. SET autocommit=1 di MySQL) atau memang tidak didukung (sebagian NoSQL hanya eventual consistency). Untuk sistem keuangan, ACID wajib.

3. Model Data

Model data = cara menggambarkan struktur data, relasi, dan constraint. Ini abstraksi — bukan implementasi. Bayangkan blueprint arsitek vs bangunan jadi.

Yang dominan saat ini: relasional. Sederhana, matang, dan didukung banyak tools. Tapi bukan berarti yang lain mati — NoSQL tumbuh pesat karena kebutuhan data fleksibel (log, sensor, media sosial).

Kesalahan umum: menganggap NoSQL “lebih modern = lebih baik”. Tidak. NoSQL menang di skenario tertentu (data tidak terstruktur, horizontal scaling). Untuk transaksi keuangan yang butuh ACID ketat, relasional tetap juara.

Model ER dan EER dipelajari detail di Pertemuan 2 dan Pertemuan 3.

4. Bahasa Basis Data

Interaksi dengan basis data relasional pakai SQL, tapi SQL sebenarnya payung untuk beberapa sub-bahasa. Masing-masing punya peran berbeda:

Contoh DDL — bikin tabel:

CREATE TABLE Mahasiswa (
  nim      CHAR(10) PRIMARY KEY,
  nama     VARCHAR(100) NOT NULL,
  angkatan INT
);

Contoh DML/DQL — ambil data:

SELECT nama FROM Mahasiswa WHERE angkatan = 2026;

Dua perintah ini kelihatan mirip, tapi beda peran: DDL mengubah struktur, DML/DQL mengubah atau membaca isi. DDL jarang dijalankan runtime; DML/DQL dipanggil terus-menerus oleh aplikasi.

Kesalahan umum: menganggap SELECT itu DML. Secara teknis ia DQL (Data Query Language) — meski banyak buku menggabungkannya ke DML karena keduanya bekerja di level data, bukan skema.

Detail lengkap DDL, DML, DCL, TCL akan dibahas di Pertemuan 6–10.

5. Perancangan Basis Data

Basis data yang baik tidak muncul begitu saja dari kepala. Ada tahapan formal:

1. Requirement analysis — pahami kebutuhan pengguna.
2. Conceptual design — model ER: entitas, atribut, relasi.
3. Logical design — konversi ER ke skema relasional (tabel, PK, FK).
4. Schema refinement — normalisasi untuk kurangi redundansi.
5. Physical design — index, storage, tuning.

Normalisasi memisahkan data ke tabel sesuai entitasnya. Tujuan:

• Menghindari duplikasi.
• Mencegah anomali insert/update/delete.

Contoh sederhana: data penerbangan dan data penumpang dipisah — bukan digabung jadi satu tabel besar. Alasannya di section 10.3.

Kesalahan umum: melompat langsung ke “bikin tabel di MySQL” tanpa modeling. Akibatnya: kolom duplikat, constraint berantakan, dan mengubah skema setelah produksi jadi mimpi buruk.

6. Arsitektur Sistem Basis Data

6.1 Tiga Level Abstraksi

DBMS menyembunyikan kompleksitas dari pengguna lewat tiga level abstraksi:

Ini disebut data abstraction. Kamu sebagai developer tidak perlu tahu bagaimana DBMS menyimpan baris di disk. Cukup pakai SQL, sisanya DBMS urus.

Kesalahan umum: mengira “physical” = “hardware”. Bukan. Physical design adalah struktur file internal DBMS — page size, B-tree index, tablespace. Ini ranah DBA, bukan developer biasa.

6.2 Application Architecture

Bagaimana aplikasi terhubung ke DBMS? Ada tiga pola umum:

Aplikasi web modern umumnya three-tier: frontend (React/Vue) di browser, backend (Node/Python/Go) di server, dan DBMS (PostgreSQL/MySQL) di belakang. Frontend tidak pernah bicara langsung ke DBMS — selalu lewat API backend. Ini penting untuk keamanan dan validasi.

6.3 Database Architecture

Dari sisi deployment DBMS:

Untuk skala kecil–menengah, client-server sudah cukup. Distributed baru relevan ketika data harus ada di beberapa region geografis (mis. e-commerce multi-negara).

7. Sejarah Singkat DBMS

Kenapa belajar sejarah? Supaya tahu kenapa DBMS hari ini seperti ini — bukan sekadar aturan yang dihafal.

Poin pentingnya: model relasional bukan yang pertama, tapi menang karena sederhana dan formal. NoSQL muncul di 2010-an bukan untuk menggantikan relasional, tapi melengkapi untuk kasus yang tidak cocok (data tidak terstruktur, skala horizontal).

8. Peran Karir Terkait

Belajar basis data membuka banyak jalur karier:

Skill dasarnya sama: memodelkan data, menulis query, dan memahami trade-off. Sisanya spesialisasi.

9. Studi Kasus 1 — Facebook Status

Modul memberikan screenshot status Facebook. Kita analisis jadi tabel relasional. Ini latihan pertama melihat dunia nyata sebagai tabel yang saling terhubung.

9.1 Identifikasi Entitas

1. User — pembuat status & komentar.
2. Status — postingan utama.
3. Comment — komentar atas status.
4. Reply — balasan atas komentar.

9.2 Tabel Status

Id = Primary Key. Setiap baris punya Id unik.

9.3 Tabel Comments

• Id_Status = Foreign Key ke tabel Status.
• Id_Comment = Primary Key.

Perhatikan: Id_Status semua bernilai 1. Artinya semua komentar ini menempel ke status yang sama.

9.4 Tabel Reply Comments

• Id_Comment = Foreign Key ke tabel Comments.
• Dua baris pertama punya Id_Comment = 2 — artinya keduanya membalas komentar yang sama (komentar Pramudya).

9.5 Tabel User

Catatan penting: password di sistem nyata tidak pernah disimpan plaintext. Sistem pakai hash (bcrypt, argon2, scrypt). Kolom •••••• di sini hanya placeholder. Modul meminta “use dummy data except the user name” — jadi kolom selain User_name boleh diisi apa saja.

9.6 Diagram Relasi

User ──< Status ──< Comment ──< Reply

Tanda ──< artinya one-to-many:

• 1 user punya banyak status.
• 1 status punya banyak komentar.
• 1 komentar punya banyak balasan.

Kesalahan umum saat analisis:

• Menjadikan “Reply” sebagai kolom di tabel Comments (padahal relasi satu-ke-banyak — butuh tabel sendiri).
• Lupa FK di tabel Comment ke Status.
• Menggabung semua jadi satu tabel besar (jadi tidak ternormalisasi).

10. Studi Kasus 2 — Flight Data

Modul meminta konversi data penerbangan (Figure 2) jadi 2 tabel. Ini latihan kedua: normalisasi konkret.

10.1 Tabel Flight

Flight_ID = Primary Key. Satu baris = satu penerbangan.

10.2 Tabel Flight Details

• Flight_ID = Foreign Key ke tabel Flight.
• (Flight_ID, Passenger_ID) = composite Primary Key.

Composite PK dipakai karena satu penumpang bisa ikut banyak penerbangan — yang unik adalah pasangan (penerbangan, penumpang).

10.3 Kenapa Dipisah?

Kalau digabung jadi satu tabel:

Masalahnya:

• Kolom Airline, Origin, Destination, Departure diulang tiap baris penumpang — redundansi.
• Kalau jadwal berubah (mis. departure jadi 08:45), harus update semua baris. Kalau ada satu terlewat → inkonsisten.
• Tidak ada tempat menyimpan penerbangan tanpa penumpang — setiap baris butuh penumpang.

Dengan dipecah 2 tabel:

• Data penerbangan disimpan sekali di tabel Flight.
• Update jadwal = update 1 baris.
• Penerbangan kosong bisa disimpan (belum ada yang beli tiket).

Inilah normalisasi: memisahkan data ke tabel sesuai entitas, menghilangkan duplikasi.

Kesalahan umum: menyimpan data penerbangan dan penumpang di satu tabel karena “kelihatannya lebih gampang di-query”. Ini jebakan jangka pendek — jangka panjang rusak karena inkonsistensi.

11. Task 3 — Analisis Software Pilihan

Pilih software / aplikasi lain yang menggunakan basis data. Tidak boleh sama dengan teman sekelas — ini memaksa kamu berpikir sendiri, bukan copy-paste.

Langkah:

1. Pilih software + satu fitur utama. Contoh: Gojek → Pesan GoFood.
2. Tanya: “Objek apa saja yang terlibat?” → Restoran, Menu, Pelanggan, Pesanan, Kurir.
3. Tentukan atribut tiap objek.
4. Tentukan PK & FK.

Isi di sini:

1. Nama software:
2. Fitur utama:
3. Screenshot fitur:
4. Tabel yang terlibat:

Contoh (GoFood):

Kesalahan umum:

• Menjadikan atribut (mis. “Alamat”) sebagai tabel. Alamat adalah kolom di Restoran, bukan entitas sendiri.
• Lupa PK di salah satu tabel.
• Menggabung semua jadi satu tabel besar — melanggar normalisasi.
• Menyalin contoh GoFood — pilih software lain yang kamu benar-benar paham.

12. Ringkasan

13. Tugas Teori — Resume Video

Format pengumpulan (.txt atau .pdf):

Nama :
NIM :
Kelas :
Kode Dosen :
Link Video :

Upload ke Pengumpulan Tugas Teori Pertemuan 1 di e-learning.

14. Tugas Praktikum — Analisis Software

Kerjakan sesuai instruksi di Modul Praktikum Pertemuan 1.

Isi laporan:

1. Software & fitur yang dipilih (berbeda dari teman sekelas).
2. Daftar entitas yang terlibat.
3. Atribut tiap entitas (minimal PK).
4. Sketsa tabel & relasi (boleh diagram sederhana).

Presensi praktikum divalidasi bagi mahasiswa yang sudah mengumpulkan.

15. Checklist Sebelum Kumpul

• Video resume sudah direkam (durasi ≤ 90 detik).
• Komentar video tidak dimatikan.
• File .txt atau .pdf memuat Nama, NIM, Kelas, Kode Dosen, Link Video.
• Task 3 sudah dipilih (software & fitur, bukan GoFood).
• Entitas sudah teridentifikasi (minimal 3).
• Setiap tabel punya PK.
• FK sudah dicatat di tabel yang tepat.
• Sketsa relasi sudah digambar.
• File laporan dinamai P1_NIM_Kelas.pdf.

16. Referensi

• Silberschatz, Korth, Sudarshan. Database System Concepts (6th ed.). McGraw-Hill. Bab 1: Introduction.
• Connolly & Begg. Database Systems (6th ed.). Pearson, 2015. Bab 1–2.
• Elmasri & Navathe. Fundamentals of Database Systems (7th ed.). Pearson. Bab 1.
• Yanto, R. Manajemen Basis Data Menggunakan MySQL. Deepublish, 2016.
• Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM.
• Slide RPL106 Pertemuan 1 — Ahmadi Irmansyah Lubis.