Program Studi Bisnis Digital · FEB UNDIP

Sistem Database

Pertemuan 2: Arsitektur Basis Data dan Komponen DBMS

Mengenal peta besar sebuah sistem basis data — dari yang dilihat pengguna sampai yang tersimpan di cakram, dan siapa saja yang mengelolanya.

RPS minggu 2 · 2x50 menit

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu:

Sub-CPMK 1

3 Lapis

Arsitektur ANSI-SPARC

Menjelaskan tiga level pandangan data: eksternal, konseptual, internal — dan mengapa pemisahan ini penting.

Sub-CPMK 2

6 Komponen

Anatomi DBMS

Mengidentifikasi komponen utama DBMS (query processor, storage manager, dsb.) dan peran masing-masing.

Kita juga akan mengenal peran manusia dalam ekosistem basis data — DBA (Database Administrator), programmer aplikasi, dan pengguna akhir — serta mengaitkannya dengan contoh nyata seperti sistem BBCA mobile banking dan katalog Tokopedia.

Ada dua tujuan besar hari ini, dan keduanya saling menopang. Pertama, Anda akan paham konsep arsitektur tiga lapis — ini fondasi berpikir yang dipakai hampir semua textbook dan hampir semua sistem database komersial, jadi wajib dikuasai sebelum lanjut ke pemodelan ER minggu depan. Kedua, Anda akan tahu apa saja komponen di dalam DBMS itu sendiri, sehingga ketika nanti Anda memakai MySQL atau PostgreSQL, Anda tidak menganggapnya kotak ajaib, melainkan paham ada bagian yang menerima perintah, ada yang mengoptimalkan, ada yang menyimpan. Saya juga akan mengajak Anda mengenal siapa saja manusianya — karena basis data bukan cuma soal mesin, tapi juga soal tata kelola dan tanggung jawab. Nanti kita akan sambungkan dengan aplikasi yang Anda pakai sehari-hari supaya konsepnya tidak terasa abstrak.

Mengapa Basis Data Butuh "Arsitektur"?

Bayangkan aplikasi marketplace seperti Tokopedia. Tim front-end hanya perlu tahu "tampilkan nama produk dan harga" — mereka tidak peduli data itu tersimpan di file apa, di server mana, atau dalam format apa.

Pemisahan ini disebut independensi data (data independence): perubahan cara penyimpanan data di "belakang" tidak boleh memaksa aplikasi di "depan" ikut ditulis ulang.

Tanpa arsitektur berlapis, setiap kali tim infrastruktur mengubah cara penyimpanan (misalnya pindah dari satu disk ke sistem penyimpanan awan), seluruh kode aplikasi harus direvisi. Ini mahal, lambat, dan berisiko tinggi untuk bisnis yang beroperasi 24 jam.

Coba bayangkan Anda adalah pengembang aplikasi di sebuah startup fintech seperti OVO atau Dana. Anda menulis kode yang menampilkan saldo pengguna di layar telepon genggam. Pertanyaannya, apakah Anda perlu tahu persis bagaimana angka saldo itu disimpan secara fisik di cakram server — apakah dalam bentuk file teks, dalam struktur pohon, atau tersebar di banyak mesin? Jawabannya tidak, dan itulah inti dari arsitektur berlapis yang akan kita bahas. Konsep independensi data ini penting sekali karena di dunia nyata, perusahaan sering mengganti teknologi penyimpanan atau melakukan migrasi server tanpa henti melayani pengguna. Kalau aplikasi dan penyimpanan fisik menyatu erat, migrasi semacam itu bisa memakan waktu berbulan-bulan dan berisiko mematikan layanan. Jadi hari ini kita belajar mengapa pemisahan lapisan ini adalah salah satu ide paling berharga dalam sejarah basis data.

Bagian 1 dari 3

Arsitektur Tiga Level (ANSI-SPARC)

Bagaimana satu basis data yang sama bisa "dilihat" berbeda oleh orang yang berbeda.

Apa itu DBMS?

DBMS (Database Management System, sistem manajemen basis data) adalah perangkat lunak yang menjadi perantara antara pengguna/aplikasi dan basis data fisik yang tersimpan di cakram.

Pengguna ↔ DBMS ↔ Basis Data (file fisik)

Contoh DBMS yang umum dipakai industri: MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server. Tanpa DBMS, setiap aplikasi harus menulis sendiri kode rumit untuk membaca-tulis file data — DBMS menyediakan layanan itu secara siap pakai, aman, dan konsisten.

Analogi: DBMS itu seperti resepsionis bank — nasabah (aplikasi) tidak masuk sendiri ke ruang penyimpanan uang (data fisik), semua permintaan lewat resepsionis yang tahu aturan dan keamanannya.

Mari kita mulai dari definisi paling dasar. DBMS adalah perangkat lunak perantara antara Anda sebagai pengguna atau aplikasi yang Anda tulis, dengan data yang sesungguhnya tersimpan di cakram keras server. Kenapa perlu perantara? Karena data mentah di cakram itu hanyalah deretan bit dan byte yang tidak berarti apa-apa tanpa ada yang menerjemahkannya. Contoh nyata yang mungkin Anda kenal adalah MySQL, yang dipakai banyak aplikasi web di Indonesia, atau PostgreSQL yang makin populer di kalangan startup karena gratis dan tangguh. Analogi resepsionis bank tadi sangat membantu — bayangkan kalau setiap nasabah bebas masuk sendiri ke ruang brankas, itu akan kacau dan berbahaya. DBMS berperan seperti resepsionis yang memvalidasi permintaan, menjaga keamanan, dan memastikan setiap transaksi tercatat dengan benar sebelum diteruskan ke penyimpanan fisik.

Level 1: Eksternal (Pandangan Pengguna)

Level eksternal adalah bagaimana masing-masing pengguna atau aplikasi melihat data — hanya bagian yang relevan bagi mereka, disebut view (pandangan).

Contoh: Kasir Indomaret

View A

Melihat: nama produk, harga, stok kasir. Tidak melihat data gaji karyawan atau margin keuntungan pusat.

Contoh: Manajer Pusat

View B

Melihat: total penjualan semua cabang, tren bulanan, margin. Tidak perlu detail stok per rak.

Kedua view ini berasal dari basis data fisik yang sama — hanya dipotong dan disusun berbeda sesuai kebutuhan tiap pengguna.

Level eksternal ini paling mudah dipahami karena paling dekat dengan pengalaman sehari-hari Anda sebagai pengguna. Bayangkan seorang kasir di gerai Indomaret dekat kampus. Layar kasirnya hanya menampilkan nama barang, harga, dan sisa stok di rak itu saja. Dia tidak pernah melihat data gaji karyawan pusat atau laporan margin keuntungan seluruh Indonesia — itu bukan urusannya dan memang sengaja disembunyikan. Sebaliknya, seorang manajer regional di kantor pusat Indomaret melihat dashboard yang sama sekali berbeda tampilannya, berisi ringkasan penjualan ratusan gerai, tapi dia juga tidak perlu tahu detail stok satu per satu produk di satu gerai. Nah, yang menarik adalah kedua tampilan berbeda ini sebenarnya bersumber dari kumpulan data yang persis sama, hanya disaring dan disusun ulang sesuai kebutuhan masing-masing peran. Inilah yang disebut view, dan ini adalah keajaiban pertama dari arsitektur berlapis.

Level 2: Konseptual (Pandangan Terpadu)

Level konseptual adalah gambaran keseluruhan struktur data milik organisasi — mendeskripsikan semua entitas, atribut, dan hubungan tanpa peduli siapa penggunanya atau bagaimana data disimpan secara fisik.

Yang Dijawab Level Konseptual

Data apa saja yang disimpan organisasi (produk, pelanggan, pesanan)?
Bagaimana data-data itu saling berhubungan (satu pelanggan bisa punya banyak pesanan)?
Aturan bisnis apa yang berlaku (stok tidak boleh negatif)?

Level ini adalah "peta induk" yang menjadi acuan bersama — dibuat oleh perancang basis data, biasanya lewat diagram Entity-Relationship (ER) yang akan kita pelajari mendalam pertemuan berikutnya.

Sekarang kita naik satu tingkat ke level konseptual, yang posisinya ada di tengah, menjembatani pandangan pengguna tadi dengan penyimpanan fisik yang akan kita bahas berikutnya. Level ini menggambarkan seluruh struktur data organisasi secara utuh, tanpa memikirkan siapa yang nanti akan melihatnya atau bagaimana bit-bitnya disimpan di cakram. Kalau kita memakai contoh Tokopedia, level konseptual ini adalah gambaran lengkap bahwa ada entitas produk, ada entitas pelanggan, ada entitas pesanan, dan ada aturan bahwa satu pelanggan bisa membuat banyak pesanan tapi satu pesanan hanya milik satu pelanggan. Level inilah yang nanti kita gambarkan dengan diagram Entity-Relationship, atau ER, yang akan menjadi topik utama pertemuan minggu depan, jadi anggap hari ini sebagai pemanasan konseptual sebelum kita masuk ke teknik menggambarnya secara formal.

Level 3: Internal (Pandangan Fisik)

Level internal adalah bagaimana data benar-benar disimpan secara fisik — struktur file, indeks untuk mempercepat pencarian, alokasi ruang penyimpanan.

Ditangani Oleh

DBA

Database Administrator

Ahli teknis yang mengatur performa, kompresi, dan lokasi fisik penyimpanan.

Fokus Utama

Performa

Bukan makna data

Bagaimana data diambil secepat mungkin, bukan apa arti bisnisnya.

Mahasiswa pemula sering mengira "basis data = file di cakram". Faktanya, itu hanya level internal — satu dari tiga lapisan yang harus dipahami bersamaan.

Level ketiga dan paling bawah adalah level internal, yaitu bagaimana data itu betul-betul tersimpan secara fisik di perangkat keras. Di sinilah bicara soal struktur file, indeks yang mempercepat pencarian layaknya daftar isi buku, dan alokasi ruang penyimpanan di cakram atau di layanan awan. Yang menangani level ini biasanya seorang DBA, singkatan dari Database Administrator, yaitu seorang profesional teknis yang tugasnya menjaga performa sistem tetap cepat meskipun datanya sudah jutaan baris. Saya ingin menekankan satu miskonsepsi umum di sini: banyak mahasiswa baru mengira basis data itu ya sekadar file yang tersimpan di komputer, padahal itu hanya menggambarkan level internal saja. Padahal basis data sesungguhnya adalah gabungan ketiga level tadi yang bekerja bersama-sama, dan justru kekuatan arsitektur ini ada di pemisahannya, bukan di salah satu levelnya saja.

Independensi Data: Manfaat Nyata Arsitektur Berlapis

Karena tiga level ini terpisah, kita punya dua jenis independensi data (kemampuan mengubah satu level tanpa mengubah level lain):

Independensi Logis

Eksternal ↔ Konseptual

Menambah kolom baru di struktur data (level konseptual) tidak merusak aplikasi lama yang tidak memakai kolom itu.

Independensi Fisik

Konseptual ↔ Internal

Mengganti jenis penyimpanan fisik (mis. pindah ke SSD, tambah indeks) tidak mengubah makna data bagi aplikasi.

Contoh nyata: saat BCA menambah fitur baru di BCA mobile, tim mereka bisa menambah tabel data baru tanpa mematikan layanan transfer yang sudah berjalan bertahun-tahun.

Sekarang kita rangkum manfaat dari tiga lapisan tadi menjadi satu konsep bernama independensi data. Ada dua macam. Yang pertama, independensi logis, yaitu kemampuan mengubah level konseptual, misalnya menambah kolom baru seperti nomor telepon darurat pelanggan, tanpa mengganggu aplikasi lama yang memang tidak memakai kolom itu. Yang kedua, independensi fisik, yaitu kemampuan mengubah cara penyimpanan di level internal, misalnya berpindah dari cakram keras biasa ke SSD yang lebih cepat, atau menambahkan indeks baru untuk mempercepat pencarian, tanpa mengubah sedikit pun makna data di level konseptual maupun eksternal. Bayangkan tim insinyur di BCA yang terus menambah fitur baru di aplikasi BCA mobile setiap beberapa bulan. Mereka bisa melakukan itu justru karena arsitektur berlapis ini memungkinkan perubahan di satu sisi tanpa harus membongkar seluruh sistem transfer uang yang sudah dipercaya jutaan nasabah.

Coba Sendiri: Jelajahi Tiga Level Arsitektur Basis Data

Klik peran kasir atau manajer untuk melihat pandangan level eksternal yang berbeda, lalu amati bagaimana perubahan di level internal tidak mengganggu keduanya.

Bagian 2 dari 3

Komponen Utama DBMS

Membongkar "kotak ajaib" DBMS menjadi bagian-bagian yang bisa Anda pahami satu per satu.

Anatomi DBMS: Diagram Komponen

Perhatikan diagram ini baik-baik karena ini adalah peta yang akan sering Anda ingat sepanjang mata kuliah ini. Alurnya dari atas ke bawah: pengguna mengetik perintah, misalnya lewat SQL atau lewat form aplikasi. Perintah itu pertama ditangkap oleh Query Processor, yang tugasnya menerjemahkan permintaan Anda menjadi langkah-langkah efisien, mirip seperti GPS yang mencari rute tercepat. Bersamaan dengan itu, Transaction Manager memastikan kalau ada banyak orang mengakses data secara bersamaan, semuanya tetap konsisten — bayangkan dua orang mencoba membeli tiket kereta terakhir di aplikasi KAI Access secara bersamaan, transaction manager inilah yang memastikan hanya satu yang berhasil. Security Manager di sebelahnya menjaga siapa boleh mengakses apa. Di lapisan bawahnya ada Storage Manager yang benar-benar membaca dan menulis data ke cakram, Buffer Manager yang menyimpan data yang sering dipakai di memori supaya lebih cepat diakses, dan Data Dictionary yang menyimpan metadata, yaitu data tentang data itu sendiri, seperti nama tabel dan tipe kolom.

Query Processor: "Penerjemah" Perintah SQL

Query Processor adalah komponen yang menerima perintah SQL Anda (misal: "tampilkan semua pelanggan dari Semarang") dan mengubahnya menjadi langkah teknis paling efisien.

Dua Tugas Utama

Parsing — memeriksa apakah perintah SQL Anda ditulis dengan tata bahasa yang benar.
Optimasi — memilih cara tercepat mengambil data, misalnya memakai indeks daripada memeriksa semua baris satu per satu.

Analogi: seperti sopir taksi online (mis. Gojek) yang menerima tujuan Anda lalu memilih rute tercepat — Anda cukup bilang tujuan, bukan jalan mana yang harus dilewati.

Mari kita perdalam salah satu komponen paling penting, yaitu Query Processor. Ketika Anda menuliskan perintah SQL, misalnya meminta daftar semua pelanggan yang tinggal di Semarang, Anda tidak perlu tahu tabel mana yang harus dibaca duluan atau apakah harus memakai indeks atau tidak — itu semua diurus oleh Query Processor. Ada dua tugas utamanya. Pertama, parsing, yaitu memeriksa apakah kalimat SQL Anda gramatikal dan masuk akal, mirip guru bahasa yang mengoreksi tata bahasa esai Anda. Kedua, optimasi, yaitu memilih strategi tercepat untuk mengeksekusi permintaan itu. Analogi yang saya suka pakai adalah sopir ojek online: Anda cukup memberi tahu tujuan Anda, dan aplikasi atau sopirnya yang memilih rute tercepat berdasarkan kondisi lalu lintas saat itu. Anda sebagai pengguna SQL berperan seperti penumpang, bukan sopir — Anda cukup menyatakan APA yang Anda mau, bukan BAGAIMANA caranya, dan itulah kekuatan bahasa SQL yang akan kita pelajari detail di paruh kedua semester.

Dari Nol: Perjalanan Satu Query di Dalam DBMS

Topik ini tidak berupa angka, jadi kita telusuri tahap demi tahap apa yang terjadi saat Anda menekan Enter pada satu perintah SQL di aplikasi kasir toko buku daring.

Langkah	Apa yang Terjadi	Komponen Terlibat
1	Anda ketik: "tampilkan buku dengan stok kurang dari 5"	Aplikasi / antarmuka pengguna
2	Perintah diperiksa tata bahasanya (parsing) — valid SQL?	Query Processor
3	Dicari cara tercepat: pakai indeks kolom stok, bukan cek semua baris	Query Optimizer (bagian Query Processor)
4	Dicek: apakah Anda punya izin melihat data stok?	Security Manager
5	Data diambil dari memori cache bila sudah pernah dibaca, atau dari cakram bila belum	Buffer Manager + Storage Manager
6	Hasil dikembalikan ke layar Anda dalam bentuk tabel	Aplikasi / antarmuka pengguna

Hasil Akhir

< 1 detik

Enam langkah ini biasanya selesai dalam sepersekian detik berkat optimasi & caching

Sekarang mari kita telusuri perjalanan satu perintah SQL langkah demi langkah, supaya komponen-komponen tadi tidak terasa seperti kotak-kotak terpisah, melainkan satu alur kerja yang mengalir. Bayangkan Anda kasir di toko buku daring dan Anda mengetik perintah untuk menampilkan semua buku dengan stok kurang dari lima. Pertama, perintah itu diperiksa tata bahasanya oleh Query Processor. Kedua, sistem mencari cara tercepat mengeksekusinya, misalnya memakai indeks kolom stok yang sudah disiapkan sebelumnya daripada memeriksa jutaan baris satu per satu. Ketiga, Security Manager memeriksa apakah Anda sebagai kasir memang punya izin melihat data stok itu. Keempat, data sebenarnya diambil, entah dari memori cache yang lebih cepat atau dari cakram kalau belum pernah dibaca sebelumnya. Terakhir, hasilnya dikembalikan ke layar Anda. Yang menakjubkan, seluruh proses ini biasanya rampung dalam sepersekian detik, dan itulah kenapa optimasi di setiap komponen benar-benar berarti bagi pengalaman pengguna sehari-hari.

Bagian 3 dari 3

Peran Manusia dan Bahasa dalam Ekosistem Basis Data

Mesin saja tidak cukup — ada manusia dan bahasa standar yang menjaga sistem tetap berjalan.

Siapa Saja yang Berinteraksi dengan Basis Data?

DBA

Penjaga

Database Administrator — mengatur keamanan, performa, backup, dan hak akses seluruh sistem.

Pengembang Aplikasi

Pembangun

Menulis kode yang memanggil basis data lewat SQL untuk menampilkan data di aplikasi.

Pengguna Akhir

Pemakai

Kasir, admin toko, pelanggan yang berinteraksi lewat antarmuka — tanpa perlu tahu SQL sama sekali.

Di perusahaan seperti Bank Mandiri atau Bukalapak, ketiga peran ini biasanya dipegang tim/orang berbeda — bukan satu orang yang mengerjakan semuanya.

Mari kita kenali tiga peran utama yang biasa berinteraksi dengan basis data di perusahaan sungguhan. Yang pertama, DBA atau Database Administrator, adalah sosok penjaga sistem — dialah yang memastikan data selalu ter-backup, performa tetap cepat meski penggunanya jutaan orang, dan hanya orang yang berwenang yang bisa mengakses data sensitif. Yang kedua, pengembang aplikasi, adalah orang yang menulis kode program yang di dalamnya memanggil perintah SQL untuk mengambil atau menyimpan data, lalu menampilkannya dalam bentuk aplikasi yang cantik dan mudah dipakai. Yang ketiga, pengguna akhir, adalah kita semua sebagai pemakai aplikasi — seorang kasir di minimarket atau pelanggan yang belanja di Bukalapak tidak pernah menulis SQL sama sekali, mereka cukup mengetuk tombol di layar. Di perusahaan besar seperti Bank Mandiri, ketiga peran ini dipegang oleh tim yang benar-benar terpisah dengan tanggung jawab dan akses yang berbeda-beda, dan pemisahan ini juga bagian dari prinsip keamanan yang akan kita bahas lebih jauh nanti.

Dua Jenis "Bahasa" yang Dipakai DBMS

DBMS berkomunikasi lewat SQL (Structured Query Language), yang terbagi jadi dua kelompok perintah besar — akan kita praktikkan detail mulai pertemuan 8:

DDL

Data Definition Language

Untuk mendefinisikan struktur — membuat tabel baru, mengubah kolom. Contoh perintah: CREATE, ALTER, DROP.

DML

Data Manipulation Language

Untuk mengolah isi data — menambah, mengubah, menghapus baris. Contoh perintah: INSERT, UPDATE, DELETE, SELECT.

Analogi: DDL itu seperti membangun rak buku (struktur), DML itu seperti menaruh/mengambil buku dari rak (isi).

Sebelum kita tutup pertemuan hari ini, saya ingin memperkenalkan sekilas dua kelompok besar perintah dalam bahasa SQL, supaya Anda punya bayangan ke mana arah mata kuliah ini menuju. Kelompok pertama disebut DDL, singkatan dari Data Definition Language, yang dipakai untuk mendefinisikan struktur basis data, misalnya membuat tabel baru bernama pelanggan dengan kolom nama dan alamat. Kelompok kedua disebut DML, singkatan dari Data Manipulation Language, yang dipakai untuk mengolah isi data yang sudah ada, misalnya menambah satu baris data pelanggan baru atau mengubah alamat pelanggan yang pindah rumah. Analogi rak buku ini semoga membantu: DDL itu seperti tukang kayu yang membangun raknya terlebih dahulu, sedangkan DML itu seperti Anda yang menaruh dan mengambil buku dari rak itu setiap hari. Kita belum akan praktik menulis perintah-perintah ini hari ini — itu baru dimulai serius di pertemuan kedelapan setelah UTS, tapi penting Anda kenal istilahnya dari sekarang.

Dari Nol: Skenario Toko Retail Membuka Cabang Baru

Toko retail nasional (misalnya seperti Alfamart) membuka cabang baru dan butuh sistem data untuk cabang tersebut. Mari telusuri siapa mengerjakan apa, tahap demi tahap:

Tahap	Aktivitas	Peran / Level yang Terlibat
1	Menentukan data apa saja yang perlu dicatat cabang baru (produk, transaksi, karyawan)	Perancang basis data — level konseptual
2	Membuat struktur tabel baru di server (DDL: CREATE TABLE)	DBA
3	Mengatur siapa saja yang boleh mengakses data cabang ini	DBA — Security Manager
4	Membuat aplikasi kasir yang memanggil data lewat SQL (DML)	Pengembang aplikasi
5	Menggunakan aplikasi kasir sehari-hari tanpa perlu tahu SQL	Pengguna akhir — level eksternal

Kesimpulan

5 Tahap, 3 Peran

Satu cabang baru butuh kerja sama perancang, DBA, pengembang, dan pengguna — bukan satu orang saja

Mari kita satukan seluruh materi hari ini lewat satu skenario utuh: sebuah jaringan retail nasional seperti Alfamart membuka cabang baru dan butuh sistem basis data untuk cabang itu. Tahap pertama, seorang perancang basis data menentukan data apa saja yang perlu dicatat — ini murni pekerjaan level konseptual yang kita bahas di awal tadi. Tahap kedua, DBA membuat struktur tabel yang sesungguhnya di server menggunakan perintah DDL seperti CREATE TABLE. Tahap ketiga, DBA yang sama juga mengatur siapa saja yang berwenang mengakses data cabang ini, melibatkan Security Manager yang sudah kita kenal. Tahap keempat, pengembang aplikasi menulis program kasir yang di dalamnya memanggil data lewat perintah DML seperti SELECT dan INSERT. Terakhir, kasir di cabang baru itu tinggal memakai aplikasinya sehari-hari tanpa pernah menyentuh SQL sama sekali. Perhatikan bagaimana lima tahap ini melibatkan tiga peran berbeda yang harus bekerja sama — inilah gambaran nyata bagaimana semua konsep hari ini bertemu dalam satu proyek dunia kerja.

Mengapa Tidak Cukup Pakai File Excel Saja?

Sebelum DBMS populer, data bisnis sering disimpan di file terpisah (mis. Excel per cabang). Pendekatan ini punya banyak kelemahan yang DBMS selesaikan:

Masalah	File Terpisah (mis. Excel)	DBMS
Data ganda	Data pelanggan bisa dicatat ulang di banyak file berbeda	Data tersimpan satu kali, diakses banyak pihak
Konsistensi	Ubah data di satu file, file lain bisa tertinggal	Perubahan langsung berlaku untuk semua pengguna
Akses bersamaan	Sulit dibuka banyak orang sekaligus tanpa bentrok	Dirancang untuk ratusan/ribuan pengguna simultan
Keamanan	Sulit membatasi siapa lihat kolom tertentu	Hak akses bisa diatur sampai level kolom

Sekarang kita bandingkan langsung dengan cara lama yang mungkin masih Anda temui di usaha kecil, yaitu menyimpan data dalam file Excel terpisah per cabang atau per departemen. Masalah pertama adalah data ganda: nama pelanggan yang sama bisa tercatat berulang kali di beberapa file berbeda dengan ejaan yang mungkin tidak konsisten. Masalah kedua adalah konsistensi, di mana kalau Anda mengubah alamat pelanggan di satu file, file lain yang menyimpan data pelanggan yang sama bisa saja tertinggal dan tidak ikut diperbarui. Masalah ketiga adalah akses bersamaan — coba bayangkan sepuluh orang di kantor mencoba membuka file Excel yang sama secara bersamaan, biasanya akan muncul peringatan "file sedang dipakai orang lain" dan itu sangat menghambat pekerjaan. Masalah keempat adalah keamanan, karena sangat sulit membatasi kolom mana yang boleh dilihat siapa dalam sebuah spreadsheet biasa. DBMS dirancang khusus untuk menyelesaikan keempat masalah ini sekaligus, dan itulah mengapa hampir semua perusahaan skala menengah ke atas beralih dari spreadsheet ke sistem basis data yang sesungguhnya.

Data Dictionary: "Kamus" Basis Data

Data Dictionary (kamus data) adalah komponen DBMS yang menyimpan metadata — data tentang data, seperti nama tabel, nama kolom, tipe data, dan aturan (constraint).

Contoh Isi Data Dictionary untuk Tabel "Pelanggan"

Nama tabel: pelanggan
Kolom: id_pelanggan (angka, wajib unik), nama (teks, maks. 100 karakter), kota (teks)
Aturan: id_pelanggan tidak boleh kosong dan tidak boleh sama dengan baris lain

DBMS memakai data dictionary ini setiap kali memproses perintah — untuk memastikan Anda tidak memasukkan teks ke kolom angka, misalnya.

Salah satu komponen yang sering diremehkan tapi sebenarnya sangat vital adalah Data Dictionary, atau kamus data. Bayangkan ini seperti buku panduan internal yang dipegang DBMS, berisi daftar lengkap semua tabel yang ada, kolom apa saja di setiap tabel, tipe datanya apa, dan aturan apa yang berlaku. Misalnya untuk tabel pelanggan, kamus data ini mencatat bahwa ada kolom id_pelanggan yang harus berupa angka dan wajib unik, tidak boleh ada dua pelanggan dengan id yang sama, lalu ada kolom nama yang berupa teks dengan batas seratus karakter. Setiap kali Anda mencoba memasukkan data baru, DBMS akan mengecek dulu ke kamus data ini untuk memastikan data yang Anda masukkan sesuai aturan — misalnya sistem akan menolak kalau Anda mencoba memasukkan huruf ke kolom yang seharusnya berisi angka. Data Dictionary inilah yang menjadikan DBMS jauh lebih pintar dan disiplin dibandingkan sekadar menyimpan data mentah tanpa aturan sama sekali.

Latihan: Identifikasi Level dan Komponen

Diskusikan dalam kelompok kecil (3-4 orang), waktu 10 menit. Kasus: aplikasi GoFood.

Pertanyaan Diskusi

Sebutkan satu contoh view (level eksternal) yang dilihat pelanggan GoFood, dan satu contoh view yang dilihat mitra restoran. Apa bedanya?
Siapa yang berperan sebagai DBA di balik sistem GoFood — kira-kira apa saja tugasnya?
Saat Anda mencari "ayam geprek" di aplikasi, komponen DBMS mana yang bekerja lebih dulu: Query Processor atau Storage Manager? Mengapa?

Siapkan satu juru bicara per kelompok untuk memaparkan jawaban ke kelas selama 1-2 menit.

Sekarang saatnya Anda praktik berpikir sendiri. Silakan berkumpul dalam kelompok kecil tiga sampai empat orang, dan saya beri waktu sepuluh menit untuk mendiskusikan kasus aplikasi GoFood yang mungkin sering Anda pakai. Pertanyaan pertama meminta Anda membedakan apa yang dilihat pelanggan yang sedang memesan makanan dibandingkan apa yang dilihat mitra restoran yang menerima pesanan — ingat konsep view dari level eksternal tadi. Pertanyaan kedua mengajak Anda membayangkan siapa di balik layar GoFood yang berperan sebagai DBA dan tugas apa saja yang mungkin mereka kerjakan setiap hari. Pertanyaan ketiga sedikit menantang, meminta Anda menganalisis urutan kerja komponen DBMS saat Anda mengetik kata kunci pencarian makanan. Setelah sepuluh menit, saya akan minta satu perwakilan dari beberapa kelompok untuk memaparkan jawabannya secara singkat di depan kelas, jadi pastikan seluruh anggota kelompok terlibat aktif dalam diskusi ini.

Ringkasan: Tiga Level Arsitektur

Level	Fokus	Contoh
Eksternal	Pandangan tiap pengguna (view)	Layar kasir vs dashboard manajer
Konseptual	Struktur data organisasi secara utuh	Diagram ER seluruh entitas bisnis
Internal	Penyimpanan fisik & performa	File, indeks, alokasi disk

Kunci ingat: level eksternal = "apa yang saya lihat", konseptual = "apa yang organisasi punya", internal = "bagaimana disimpan".

Mari kita rangkum sebelum melangkah ke komponen DBMS lagi secara singkat. Level eksternal adalah tentang apa yang dilihat setiap pengguna secara individual, seperti layar kasir yang berbeda dari dashboard manajer. Level konseptual adalah gambaran utuh struktur data milik organisasi, tidak peduli siapa yang melihatnya, biasanya digambarkan lewat diagram Entity-Relationship yang akan kita pelajari mendalam mulai minggu depan. Level internal adalah soal bagaimana data itu benar-benar disimpan secara fisik, urusan file, indeks, dan performa, yang biasanya menjadi tanggung jawab DBA. Kalimat kunci yang saya sarankan Anda hafalkan adalah ini: eksternal itu "apa yang saya lihat", konseptual itu "apa yang organisasi punya", dan internal itu "bagaimana caranya disimpan". Kalau tiga kalimat pendek ini melekat di kepala Anda, separuh materi ujian tentang arsitektur basis data sudah aman.

Ringkasan: Komponen Kunci DBMS

Komponen	Tugas Singkat
Query Processor	Menerjemahkan & mengoptimalkan perintah SQL Anda
Transaction Manager	Menjaga konsistensi saat banyak orang mengakses bersamaan
Security Manager	Mengecek otentikasi & hak akses pengguna
Storage & Buffer Manager	Membaca/menulis data ke disk & menyimpan cache di memori
Data Dictionary	Menyimpan metadata: nama tabel, kolom, tipe data, aturan

Sekarang giliran merangkum komponen-komponen mesin DBMS yang tadi kita bongkar satu per satu lewat diagram. Query Processor bertugas menerjemahkan dan mengoptimalkan perintah SQL Anda menjadi langkah tercepat. Transaction Manager menjaga agar transaksi tetap konsisten meski diakses banyak orang bersamaan, seperti kasus pembelian tiket kereta tadi. Security Manager mengecek siapa Anda dan apa yang boleh Anda akses. Storage Manager dan Buffer Manager bekerja sama menyimpan data secara fisik sekaligus mempercepat akses lewat memori cache. Terakhir, Data Dictionary menyimpan kamus lengkap tentang struktur data itu sendiri. Kelima komponen ini bekerja sebagai tim, bukan sendiri-sendiri, dan pemahaman ini akan sangat membantu Anda ketika nanti kita membahas bagaimana query SQL yang lambat bisa dipercepat lewat indeks pada pertemuan-pertemuan menjelang akhir semester.

Dari Arsitektur ke Pemodelan: Apa Selanjutnya?

Hari ini kita fokus pada level konseptual sebagai "peta induk". Minggu depan, kita belajar alat resmi untuk menggambar peta itu: diagram Entity-Relationship (ER).

Yang Sudah Anda Kuasai

Tiga level arsitektur (eksternal, konseptual, internal)
Enam komponen utama DBMS
Peran DBA, pengembang, pengguna akhir

Yang Akan Dipelajari (P3)

Notasi entitas, atribut, relasi dalam ER
Menggambar diagram ER dari kasus bisnis nyata
Kardinalitas (satu-ke-banyak, banyak-ke-banyak)

Sebelum kita menutup pertemuan hari ini, saya ingin menyambungkan benang merah ke minggu depan supaya Anda paham alur besar mata kuliah ini. Hari ini kita fokus pada level konseptual sebagai peta induk struktur data organisasi, tapi kita belum punya alat formal untuk benar-benar menggambar peta itu di atas kertas. Nah, minggu depan kita akan belajar diagram Entity-Relationship, atau ER, yang merupakan notasi standar industri untuk menggambarkan entitas, atribut, dan hubungan antar data secara visual. Anda akan belajar bagaimana menggambar kotak untuk entitas seperti pelanggan dan produk, garis untuk relasi seperti "memesan", dan simbol kardinalitas yang menunjukkan apakah hubungannya satu-ke-banyak atau banyak-ke-banyak. Semua konsep hari ini — terutama level konseptual — akan menjadi fondasi langsung untuk memahami mengapa diagram ER dirancang seperti itu, jadi pastikan Anda benar-benar menguasai materi hari ini sebelum pertemuan berikutnya.

Tugas & Persiapan Pertemuan 3

Tugas Individu (Kumpul Sebelum P3)

Pilih 1 aplikasi yang Anda pakai sehari-hari (mis. Shopee, MyTelkomsel, KAI Access)
Identifikasi minimal 2 contoh view (level eksternal) berbeda dalam aplikasi itu
Sebutkan 3 komponen DBMS yang menurut Anda paling berperan saat Anda membuka aplikasi itu, beri alasan singkat

Format

1 Halaman

Dikumpulkan via portal e-learning

Tenggat: sebelum pertemuan 3 dimulai. Tulisan bebas, boleh disertai sketsa tangan.

Sampai jumpa minggu depan — siapkan diri Anda untuk mulai menggambar diagram pertama Anda!

Sebagai penutup, saya beri satu tugas individu ringan yang akan menguatkan pemahaman Anda sebelum kita lanjut ke pemodelan ER minggu depan. Silakan pilih satu aplikasi yang Anda pakai sehari-hari, boleh Shopee, boleh aplikasi MyTelkomsel, boleh KAI Access untuk pemesanan tiket kereta, lalu identifikasi minimal dua contoh view berbeda yang mungkin dilihat oleh pengguna berbeda dalam aplikasi itu. Selain itu, sebutkan tiga komponen DBMS yang menurut Anda paling berperan saat Anda membuka aplikasi tersebut, lengkap dengan alasan singkat mengapa Anda memilihnya. Tugas ini cukup ditulis dalam satu halaman saja, boleh disertai sketsa tangan kalau itu membantu Anda menjelaskan, dan dikumpulkan lewat portal e-learning sebelum pertemuan berikutnya dimulai. Terima Kasih atas perhatian Anda hari ini, sampai jumpa minggu depan, dan bersiaplah karena kita akan mulai menggambar diagram pertama Anda sendiri.