lifelong learner — urip iku urup, currently working on accenture.

Firebase data modelling

1
Degananda.com -

Firebase merupakan database yang berjenis nosql. Namun, untuk memodelkan data pada firebase “cukup” berbeda dengan nosql lainnya seperti mongodb. Ulasan ini akan membahas bagaimana memodelkan data / menstrukturkan data pada firebase.

Kasus

Ulasan ini kami buat berdasarkan pengalaman pribadi dan juga referensi terkait. Kami membuat riserf (riserf.com atau riserfapp pada playstorge) yakni aplikasi untuk mengelola jadwal suatu tempat hingga proses penjualannya(selling) yang berbasis android dan website dengan menggunakan firebase.  Oleh karena itu kebanyakan yang kami tuliskan disini bersifat subjektif disamping itu tidak ada guideline yang pasti untuk memodelkan data pada firebase sehingga mohon difahami kondisi tersebut.

Aturan mendasar

Hal yang paling fundamental yang harus difahami sebelum memulai menstrukturkan data pada firebase yakni tidak adannya support untuk melakukan JOIN pada firebase.  Sehingga aturan paling mendasar adalah buatlah data sesuai dengan UI (user interfaces). Jangan memisahnya karena memang firebase tidak mensupport JOIN.  Jika anda keukuh (ngeyel) untuk tetap memisah data layaknya pada sql / nosql pada umumnya maka pilihan yang paling tepat adalah menggunakan 3rd party library seperti Elasticsearch atau memirrorkan data pada firebase ke mongodb.

Sehingga best practice untuk membuat struktur pada firebase adalah “denormalisasi” yang merupakan kebalikan dari normalisasi atau google menyebutnya sebagai flat data / flatten data. Data yang tersimpan dalam firebase adalah JSON (Javascript object notation) yang telah terkenal dengan keringanannya (lightweight). Jumlah nest maksimal yang dapat diakomodasi firebase adalah sebanyak 32 level / child.

Sebelum mendemonstrasikan cara menstrukturkan data pada firebase kita akan definisikan data yang akan digunakan. Pada kasus ini kita akan menggunakan data mengenai aplikasi pengelola note atau catatan. Dengan tiga domain utama yakni : note, user dan attachment. Note memiliki “judul_note” dan “isi_note”. User memiliki username dan email sedangkan attachment memiliki “link_attachment”.

ketiga domain tersebut jika buat pada RDBMS maka akan menghasilkan tabel sebagai berikut ini

Pada RDBMS primary key harus kita tentukan dan dapat kita set auto increment atau tidaknya. Namun id pada firebase dapat “tergenerate” secara otomatis dan firebase mengklaim bahwa id tersebut tidak akan pernah sama. Tabel diatas tentunnya jika direlasikan setiap foreign key akan jatuh ke tabel relasinnya. pada note akan terdapat dua buah foreign key yakni id_user dan id_attachment. Kondisi disini sangat ideal dikarenakan adannya relasi membuat integritas data menjadi sangat bagus.

lalu bagaimana memodelkannya dalam untuk “firebase” ? ingat bahwa best practice dari firebase adalah denormalisasi artinnya data diatas yang merupakan hasil normalisasi harus kita jadikan tidak normal atau firebase menyebutnya sebagai flatten data. Terdapat dua jenis flatten data yaitu flatten data yang salah dan benar. Ingat bahwa data pada firebase bertipe JSON.

Salah

struktur diatas sangat tidak dianjurkan. Meski struktur tersebut telah bersifat tidak normal dtetapi akan sangat mahal biaya operasinnya. Mengapa ? karena data tersebut nested. misalkan kita hanya ingin menampilkan detail dari user tersebut secara otomatis firebase juga akan mengambil atau memberikan kita data mengenai note. Bayangkan jika note tersebut berjumlah 200 Maka pada fungsi menampilkan data user kita juga akan mendapatkan data note. Oleh karena itu hindari melakukan nesting seperti gambar diatas. Sehingga model data diatas belum “flatten”.

Singkatnya ketika kita mengakses endpoint /user/degananda/ maka secara otomatis /user/degananda/note beserta child – child didalamnya akan otomatis terquery / diberikan datannya. Namun berbeda jika kita merequest /user/degananda/note/_id1 maka yang muncul hanyalah child dari endpoint tersebut yakni isi_note dan judul_note.  Itulah mengapa nested harus di hindari saat kita menstrukturkan atau memodelkan data.

Benar

untuk membuat model diatas flatten maka harus kita pisahkan (normalisasi) domain “note” dan “attachment” dari user. Setelah dipisahkan user dan attachment akan menjadi bagian dari “note”. Konsepnya adalah meletakan data yang jumlahnya lebih sedikit kemudian mengembed ke data yang banyak. Banyak dalam artian misalnya data note akan diakses dan ditampilkan secara list. Otomatis data note akan lebih banyak jika dibandingkan dengan data user ataupuna attachment. Sehingga modelnya menjadi seperti ini

dapat anda lihat bahwa setiap user akan masuk pada data note. Hal inilah yang disebut sebagai flatten data. Namun kekurangan model seperti ini adalah terkait dengan isue integritas data. Artinnya perubahan pada “user” akan berpengaruh pada data “user” pada “note”.

Hasil akhir flatten data structure pada firebase

data ditampilkan dalam bentuk JSON untuk kasus “aplikasi manajemen note”.

{
  "note" : {
    "_id1" : {
      "isi_note" : "buku kalkulus halaman 2",
      "judul_note" : "PR matematika",
      "link_attachment" : "http://blabla.com",
      "user" : {
        "dega" : {
          "email" : "degananda.ferdian@gmail.com",
          "nama" : "degananda ferdian"
        }
      }
    },
    "_id2" : {
      "isi_note" : "list nama kingdom",
      "judul_note" : "PR Biologi",
      "link_attachment" : "http://blabla.com",
      "user" : {
        "dega" : {
          "email" : "degananda.ferdian",
          "nama" : "degananda ferdian"
        }
      }
    }
  },
  "user" : {
    "dega" : {
      "email" : "degananda.ferdian@gmail.com",
      "nama" : "degananda ferdian"
    }
  }
}

Integritas data

integritas data menjadi isue yang sangat serius pada firebase karena tidak tersediannya fitur join dan data yang flat mengharuskan kita untuk melakukan update manual pada seluruh data terkait. Contohnya pada data diatas adalah bagaimana jika user mengubah namanya ? berdasarkan best practice dari firebase berikut ini adalah solusinnya.

Bagaimana cara menjaga integritas data pada firebase ? tentu jawabannya adalah membuat model data yang dapat “menjaga integritas data” dan juga memanfaatkan firebase admin SDK untuk mengimplmentasikan model tersebut. Silahkan simak ulasan kedua mengenai integritas data firebase pada blog ini.

  • Muh Alif Al-Gibran

    jadi kalau gk bisa join, otomatis ketika mengupdate data user data pada note gk berubah dong?