Skip to content

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_date bukan bday).
  • 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) atau NUMERIC. Contoh: DECIMAL(15, 2) untuk nilai rupiah.
  • Jumlah Barang/SKS: Gunakan INTEGER atau SMALLINT.

4.3 Teks dan Boolean

  • Boolean: Gunakan tipe BOOLEAN (TRUE/FALSE). Jangan gunakan TINYINT(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 TEXT untuk 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:

  1. Dilarang melakukan perubahan struktur tabel (ALTER, CREATE, DROP) secara manual/langsung di database produksi menggunakan GUI (seperti phpMyAdmin atau DBeaver).
  2. 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.

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 root atau postgres (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)