Bagian 2 – Cara Mengatur Diagram Basis Data Besar

Di Bagian 1 dari seri ini, kami berhasil mengimpor struktur database SuiteCRM ke alat pemodelan database online kami. Saat itulah kami melihat bahwa model berisi 201 tabel tanpa hubungan di antara mereka. Kami mendapat banyak meja yang terlihat sangat berantakan. Dalam artikel ini, saya akan menunjukkan kepada Anda bagaimana Anda dapat mengatur model sebesar itu.

Tepat setelah mengimpor ke Vertabelo, model database SuiteCRM terlihat sebagai berikut:

Modelnya berhasil – tetapi tidak efisien. Kita perlu memodifikasinya agar benar-benar berguna. Karena kami ingin menganalisis database SuiteCRM setelah tindakan dilakukan pada GUI-nya, kita perlu memahami definisi tabel dan hubungan antar tabel. Mari kita mulai dengan mengelompokkan tabel ke dalam area subjek dan membangun hubungan yang paling penting.

Vertabelo menawarkan tiga alat utama untuk membantu Anda mengatur diagram besar:

• Bidang subjek
• Tabel dan pintasan tampilan
• Pintasan referensi

Saya akan menjelaskannya nanti di artikel ini, tetapi Anda juga dapat mempelajari lebih lanjut dengan menonton video ini.

Langkah 1. Nonaktifkan Pembuatan Kunci Asing Otomatis

Pertama-tama, kami akan menonaktifkan pembuatan kunci asing otomatis. Secara default, Vertabelo menghasilkan atribut kunci asing saat kita menarik relasi dari tabel utama ke tabel yang direferensikan. Ini biasanya hal yang baik, tetapi tidak di sini. Kami sudah memiliki atribut yang mewakili kunci asing. Kekurangan kami adalah hubungan "nyata" antar tabel. Untuk menonaktifkan opsi ini, klik “Akun saya” di menu atas dan temukan “Preferensi pribadi” bagian.

Opsi ini tidak aktif. Sekarang, ketika kita menggambar garis referensi di antara tabel, garis dibuat – tetapi kita harus menentukan atribut mana yang digunakan, baik di sisi primer maupun sisi asing.

Langkah 2. Kelompokkan Tabel Berawalan Dengan Area Subjek

Selanjutnya, mari kita kelompokkan beberapa tabel. Kami akan melakukannya menggunakan Area subjek alat yang memungkinkan untuk mengaitkan tabel berdasarkan kriteria yang dipilih. Dalam kasus kami, kami mencoba mengidentifikasi tabel yang terkait atau bagian dari proses yang sama. Ini akan menghasilkan grup seperti “Telepon”, “Rapat”, dan “Kampanye”.

Kita dapat membuat area subjek dengan mengklik “Tambahkan area baru” ikon di kotak alat:

dan kemudian menggambar persegi panjang pada model kita:

Area subjek dibuat. Kita bisa melihatnya di “Struktur model” panel di sebelah kiri:

Setiap area subjek berisi daftar semua objek yang ada di dalam batasnya; dalam hal ini, ini adalah tabel dan tipe referensi.

Di SuiteCRM, ada banyak tabel yang memiliki awalan yang sama. Jadi, saya mulai mengelompokkan tabel awalan bersama-sama. Lihatlah tabel "acl" sebagai contoh. Di panel “Struktur model”, saya menemukan semua tabel yang namanya dimulai dengan “acl_“:

Kemudian saya membuat area subjek "acl" dalam model dan menyeret semua tabel yang sesuai ke dalamnya. (Untuk visibilitas yang lebih baik, saya menyetel warna latar belakang ke ungu.)

Sekarang, kita sekarang dapat melihat grup “acl”, dengan daftar semua tabel yang ada di dalamnya, di bawah “Area subjek” di “Struktur model” :

Saya mengulangi prosedur yang sama untuk semua tabel awalan yang tersisa.

Langkah 3:Susun Tabel yang Tersisa.

Tabel yang Sama Dua Kali dalam Diagram? Pintasan Tabel!

Ada sekitar 80 tabel awalan. Setelah mengelompokkannya, saya ditinggalkan dengan sekitar 120 meja 'liar'. Ini berarti:mereka menyimpan informasi tentang pengguna, klien, panggilan, rapat, dan hal-hal CRM lainnya. Itu banyak informasi yang harus dirahasiakan, jadi mari kita urutkan tabel ini.

Fitur yang menurut saya paling berguna untuk mengatur tabel ini disebut pintasan tabel . Terkadang Anda ingin menggunakan tabel yang sama lebih dari sekali dalam sebuah model. (Mengapa? Untuk meratakan model dan menghindari tumpang tindih.) Kita dapat melakukannya dengan mudah menggunakan “Copy” dan “Tempel sebagai pintasan” tombol.

Cukup pilih tabel yang ingin Anda buat pintasannya dan klik “Salin” di bilah alat atas (atau tekan Ctrl + C ):

Untuk membuat pintasan, klik “Tempel sebagai pintasan” (atau tekan Ctrl + K ). Setelah itu akan muncul tabel baru dengan garis putus-putus:

Ini bukan salinan tabel, tetapi contoh lain dari tabel asli. Kita dapat menempatkannya di mana saja dalam model kita. Saya menggunakan contoh tabel yang sama di area subjek yang berbeda untuk menghindari referensi yang tumpang tindih. Penting untuk disebutkan bahwa setiap instance tabel memiliki nama area subjek yang ditetapkan (di sebelah namanya) saat berada di dalam area subjek tersebut.

Contoh bagus tentang cara kerjanya adalah users meja. Itu dapat ditemukan di "Pengguna dan Akun", "Peran", "Dokumen", dan bidang subjek lainnya. Kita akan melihat ini nanti di model.

Saya menggunakan pintasan tabel secara ekstensif saat membuat area subjek dengan hubungan yang mapan antar tabel. Untuk melihat cara kerjanya, lihat area subjek “Peluang” yang dipetakan di bawah ini. Perhatikan bahwa semua tabel dalam area subjek diberi nama mengikuti aturan ini:{nama tabel} :{nama area subjek} .

Saat kami memperluas {subject area name} di panel "Struktur model", kita dapat dengan jelas melihat bahwa itu berisi tabel dan referensi:

Saya melakukan ini untuk bidang subjek berikut:"Panggilan", "Kasus", "Kampanye", "Kontak", "Dokumen", "Rapat dan prospek", "oauth", "Proyek", "Prospek dan pemasaran email", "Peran", dan "Pengguna dan akun". Semua area ini memiliki latar belakang biru muda.

Tabel yang tersisa dikelompokkan berdasarkan nama dan arti yang diperkirakan:“Email”, “Pengguna (tambahan)”, dan “Tabel lainnya”. Grup ini memiliki warna latar belakang yang disetel ke merah muda.

Model yang Diatur

Saya menggunakan opsi yang dijelaskan sebelumnya untuk meratakan model sebanyak mungkin sambil mengelompokkan tabel secara logis. Hasilnya adalah 26 bidang subjek, beberapa di antaranya hanya berisi tabel sementara yang lain memiliki tabel dan relasi. Mari kita lihat ulasan singkat untuk setiap kategori:

Area Subjek yang Berisi Tabel dan Hubungan:

“Panggilan”, “Kampanye”, “Kasus”, “Kontak”, “Dokumen”, “Rapat dan prospek”, “Peluang”, “Proyek”, “Prospek dan pemasaran email”, “Peran”, “Pengguna dan akun”

Semua hubungan ditetapkan sebagai tidak wajib. Ini menyimpan informasi bahwa tabel-tabel ini terkait dan melalui atribut apa.

Area Subjek yang Hanya Berisi Tabel:

“acl”, “am”, “aod”, “aok”, “aop”, “aor”, “aos”, “aow”, “Email”, “fp”, “jwg”, “oauth”, “security_groups ”, “Pengguna ekstra”

Ini tidak berarti bahwa hubungan tidak ada di sini; mereka hanya tidak ditekankan.

Area subjek “Tabel lain” adalah untuk tabel yang tidak benar-benar sesuai dengan grup tertentu.

Seperti Apa Modelnya?

Model yang disusun ulang terlihat seperti ini:

Jelas konvensi penamaan telah digunakan. Berikut ini ikhtisar panduan yang kami ikuti:

1. Nama tabel kebanyakan jamak:users , contracts , folders , roles , tasks . Beberapa nama tabel bersifat tunggal, seperti project .
2. Kunci utama di sebagian besar tabel hanya disebut id dan merupakan tipe char(36).
3. Saat relasi one-to-many terjadi, foreign key biasanya diberi nama parent_id . (Contoh:contacts_audit.parent_id adalah referensi ke contacts.id .)
4. Dalam relasi banyak ke banyak, “parent_id ” tidak dapat digunakan sebagai nama untuk beberapa kolom. Sebagai gantinya, nama tabel tunggal dengan akhiran "_id" digunakan. (Contoh:contacts_bugs.bug_id adalah referensi ke bug.id .)
5. Ada situasi ketika kolom yang sama digunakan sebagai kunci asing untuk beberapa tabel. (Contoh:calls.parent_id direferensikan ke kolom id di setiap tabel berikut:accounts , bugs , cases , contacts , leads , tasks , opportunities and prospects . Saya belum memeriksa nilai dalam database, tetapi dugaan saya adalah tidak ada nilai kunci yang sama dalam tabel ini. Karena semuanya bertipe char(36), mungkin beberapa kombinasi nama tabel dan peningkatan otomatis digunakan. Kami akan memeriksanya di artikel mendatang.)
6. Kami menggunakan nama yang sama untuk kolom yang memiliki arti yang sama di tabel yang berbeda. (Contoh:modified_user_id , created_by dan assigned_user_id dapat ditemukan di banyak tabel dalam model. Semuanya direferensikan ke users.id .)

Apa Selanjutnya?

Dalam artikel yang akan datang, kami akan menggunakan GUI SuiteCRM dan mengawasi perubahan yang disebabkannya dalam database. Dengan informasi itu, kami akan mencoba membuat perubahan pada model, mengatur ulang bidang subjek, dan membangun koneksi jika diperlukan. Selain itu, kami akan mencari aturan khusus SuiteCRM lainnya, seperti cara kunci utama dibuat.

Menangani diagram database yang besar bukanlah pekerjaan yang mudah. Seperti membangun fondasi yang baik untuk sebuah rumah, menghabiskan lebih banyak waktu untuk hal-hal mendasar sekarang akan membawa keuntungan di kemudian hari. Jika kita ingin menganalisis model seperti yang ada di belakang SuiteCRM, menganalisis sebelum kita mengatur struktur model dan hubungan tabel yang ditentukan adalah melakukannya dengan gaya Sisyphus.