Standar Basis Data & Manajemen Data
Informasi Dokumen
| Atribut | Keterangan |
|---|---|
| Kode Dokumen | DTSI-STD-DB-001 |
| Revisi | 1.0 |
| Tanggal Efektif | 13 Februari 2026 |
| Pemilik Dokumen | Departemen Teknologi dan Sistem Informasi (DTSI), Universitas Harapan Bangsa |
| Pemilik Proses | Kepala Departemen Teknologi dan Sistem Informasi (DTSI) |
| Status | DRAFT |
1. Pendahuluan
1.1 Tujuan
Dokumen ini menetapkan aturan baku perancangan, pengelolaan, dan keamanan basis data di lingkungan Departemen Teknologi dan Sistem Informasi (DTSI) Universitas Harapan Bangsa. Dokumen ini merupakan milik DTSI dan mengikat pengelolaan data serta sistem informasi dalam lingkungan universitas. Tujuannya adalah menjamin integritas data, konsistensi struktur, kemudahan pemeliharaan (maintainability), serta keamanan informasi sesuai standar akreditasi, regulasi perlindungan data, dan prinsip pengendalian teknologi dalam ISO/IEC 27001 & ISO/IEC 27002 (serta pemetaan kontrol pada setiap SOP terkait di Daftar SOP Operasional).
1.2 Ruang Lingkup
Standar ini berlaku untuk seluruh pengembangan sistem informasi, aplikasi web (termasuk LMS, Portal Akademik, Riset), dan layanan digital yang dikelola oleh DTSI atau mitra pihak ketiga.
1.3 Kedudukan dalam SPMI DTSI
Bagian dari kerangka Manual SPMI DTSI. Indikator terkait: DAT-01 … DAT-03 pada DTSI-REG-KPI-001. Selaras DTSI-STD-DEV-001 dan prosedur DTSI-SOP-OPS-03.
2. Standar Platform Teknologi
DTSI menetapkan teknologi basis data yang didukung secara resmi untuk menjamin ketersediaan dukungan teknis dan keamanan.
| Jenis Database | Teknologi Standar | Versi Min. | Peruntukan |
|---|---|---|---|
| RDBMS (Utama) | PostgreSQL | 14.x | Sistem Transaksional Utama (SIAKAD, LMS, Keuangan) |
| RDBMS (Sekunder) | MySQL / MariaDB | 8.0 / 10.6 | Aplikasi Legacy atau CMS sederhana |
| NoSQL / Cache | Redis | 6.x | Session storage, caching, background jobs (Sidekiq) |
| Time Series | InfluxDB / Timescale | - | Data sensor IoT (proyek MataParkir/Smart Campus) |
Larangan Penggunaan
Dilarang menggunakan database berbasis file (seperti Microsoft Access atau SQLite) untuk lingkungan Produksi (Production Environment), kecuali untuk keperluan prototyping atau aplikasi mobile lokal.
3. Konvensi Penamaan (Naming Conventions)
Untuk menjaga konsistensi kode (terutama pada framework seperti Ruby on Rails dan Laravel), aturan penamaan berikut wajib diikuti:
3.1 Tabel
- Menggunakan format
snake_case. - Nama tabel harus jamak (plural) dalam Bahasa Inggris (disarankan untuk kompatibilitas framework) atau Bahasa Indonesia yang konsisten.
- Contoh Benar:
users,student_scores,jadwal_kuliah. - Contoh Salah:
User,tabelNilai,DataMahasiswa.
3.2 Kolom (Field)
- Menggunakan format
snake_case. - Hindari singkatan yang ambigu (misal: gunakan
birth_datebukanbday). - Primary Key: Wajib bernama
id(BigInteger/UUID). - Foreign Key: Format
nama_tabel_tunggal_id(contoh:user_id,course_id).
4. Standar Tipe Data
Pemilihan tipe data harus presisi untuk menjaga akurasi informasi dan efisiensi penyimpanan.
4.1 Tanggal dan Waktu
Penggunaan tipe data string (VARCHAR) untuk menyimpan tanggal adalah pelanggaran berat terhadap standar ini.
| Data | Tipe Data (PostgreSQL) | Contoh Format | Keterangan |
|---|---|---|---|
| Tanggal Lahir / Transaksi | DATE |
YYYY-MM-DD |
Wajib ISO 8601 |
| Waktu Log / Audit Trail | TIMESTAMP |
YYYY-MM-DD HH:MM:SS |
Disarankan menyimpan dalam UTC |
| Durasi | INTERVAL |
1 hour 30 mins |
Untuk menghitung selisih waktu |
4.2 Numerik dan Finansial
Peringatan Finansial
Dilarang keras menggunakan tipe data FLOAT atau DOUBLE untuk menyimpan nilai uang (Rupiah/Dollar) karena masalah presisi pembulatan (floating point error).
- Uang/Nilai Transaksi: Wajib menggunakan
DECIMAL(p,s)atauNUMERIC. Contoh:DECIMAL(15, 2)untuk nilai rupiah. - Jumlah Barang/SKS: Gunakan
INTEGERatauSMALLINT.
4.3 Teks dan Boolean
- Boolean: Gunakan tipe
BOOLEAN(TRUE/FALSE). Jangan gunakanTINYINT(1),CHAR(1)('Y'/'N'), atau integer 0/1 untuk kejelasan semantik. - String Pendek: Gunakan
VARCHAR(n)untuk data dengan panjang variabel (Nama, Email). - Teks Panjang: Gunakan
TEXTuntuk deskripsi, artikel, atau logs.
5. Standar Integritas & Desain
5.1 Normalisasi
Basis data transaksional wajib dinormalisasi minimal hingga Bentuk Normal Ketiga (3NF) untuk mencegah redundansi data, kecuali untuk tabel khusus analitik/data warehouse.
5.2 Constraints (Batasan)
Logic validasi data tidak boleh hanya bergantung pada aplikasi (Backend), tetapi harus dijaga di level database:
- NOT NULL: Wajib diterapkan pada kolom kritikal (misal:
email,password_digest). - UNIQUE: Wajib diterapkan pada data unik (misal:
NIM,NIDN,email). - FOREIGN KEY: Wajib didefinisikan secara eksplisit untuk menjaga integritas relasi antar tabel (mencegah orphan data).
6. Manajemen Perubahan (Database Migration)
Dalam semangat Infrastructure as Code:
- Dilarang melakukan perubahan struktur tabel (ALTER, CREATE, DROP) secara manual/langsung di database produksi menggunakan GUI (seperti phpMyAdmin atau DBeaver).
- Semua perubahan skema harus menggunakan File Migrasi (Migration Files) yang tersimpan dalam Version Control System (Git).
- Contoh pada Rails:
bin/rails generate migration AddNikToUsers. - Contoh pada Laravel:
php artisan make:migration.
- Contoh pada Rails:
7. Keamanan & Akses Data
7.1 Enkripsi
- Password: Dilarang menyimpan password dalam bentuk teks terang (plain text). Wajib menggunakan algoritma hashing kuat (Bcrypt, Argon2).
- Data Sensitif: Data NIK, Nomor Rekening, dan Riwayat Kesehatan (sesuai proyek IFLS) disarankan dienkripsi pada level kolom (Column Level Encryption).
7.2 Hak Akses (Privileges)
- Aplikasi harus terhubung ke database menggunakan user khusus dengan hak akses minimal (Least Privilege).
- Aplikasi tidak boleh menggunakan user
rootataupostgres(Superuser).
8. Backup & Pemulihan Bencana
Prosedur backup wajib berjalan otomatis (melalui cron job atau fitur cloud).
- Frekuensi Backup:
- Full Backup: Mingguan (Disimpan di lokasi fisik berbeda/Cloud Storage s3).
- Incremental Backup: Harian (setiap jam 02:00 dini hari).
- Retensi: Data backup disimpan minimal selama 3 bulan terakhir.
- Uji Pemulihan: Wajib dilakukan simulasi restore data minimal 1 kali per semester untuk memastikan file backup tidak korup.
Persetujuan Dokumen
Dokumen ini telah ditinjau dan disetujui untuk diterapkan dalam lingkungan Universitas Harapan Bangsa, sebagai bagian dari standar mutu yang menjadi tanggung jawab DTSI.
Disetujui Oleh:
(Tanda Tangan)
Kepala Departemen Teknologi dan Sistem Informasi (DTSI)