Model Data Bengkel Mobil

Menjalankan bengkel mobil/mobil adalah bisnis yang sangat kompleks. Anda harus membuat janji saat beberapa pelanggan akan datang dan Anda tidak ingin mereka menunggu berjam-jam. Selain itu, Anda harus mengatur karyawan, melacak perbaikan, material, menagih pelanggan, dll. Anda pasti membutuhkan solusi TI dan, tentu saja, model data di latar belakang. Hari ini kita akan berbicara tentang satu model seperti itu.

Ide

Saya telah menyebutkan bahwa model bisnis ini sangat kompleks. Oleh karena itu, saya tidak akan mencoba untuk menutupi semuanya. Saya sengaja menghilangkan materi pelacakan dan suku cadang dan juga menyederhanakan beberapa bagian model. Alasannya cukup sederhana. Jika saya benar-benar memasukkan semuanya, modelnya akan terlalu besar untuk artikel dengan ukuran yang masuk akal. Jadi, mari kita mulai.

Model Data

Model terdiri dari 5 bidang subjek:

Repair shops & employees
Customers & contacts
Vehicles
Services & offers dan
Visits

Kami akan menjelaskan masing-masing dari 5 bidang subjek ini sesuai urutannya.

Bagian 1:Bengkel &karyawan

Area subjek pertama, kita akan mulai dengan Repair shops & employees bidang studi. Cukup jelas bahwa kami perlu mengetahui apa yang kami miliki sebelum kami dapat memberikan penawaran kepada pelanggan.

city kamus digunakan untuk menyimpan semua kota yang berbeda tempat kami memiliki bengkel atau pelanggan kami berasal. Setiap kota secara unik ditentukan oleh pasangan postal_code – city_name . Kami dapat memutuskan untuk hanya memiliki satu entri per setiap kota, meskipun kota tersebut memiliki beberapa kode pos. Dalam hal ini, kami hanya akan menggunakan kode pos "utama" untuk kota itu. Namun, kami memiliki opsi untuk memiliki beberapa entri untuk kota yang sama dan kode pos yang berbeda – jika kami menginginkannya.

repair_shop meja adalah tempat di mana kami akan menyimpan daftar semua bengkel kami. Kami dapat berharap bahwa kami akan mengoperasikan lebih dari satu di beberapa titik. Setiap toko secara unik ditentukan oleh shop_name its dan id kota miliknya (city_id ). Kami juga akan menyimpan alamat toko dan details tambahan dalam format tekstual jika ada.

position kamus digunakan untuk menyimpan position_names yang unik yang dapat diberikan kepada karyawan kami. Sementara sebagian besar posisi akan terkait dengan bisnis inti kami, kami juga memiliki beberapa yang bukan bagian dari bisnis inti (peran/jabatan teknis) tetapi juga penting (administrasi, penjualan, dll.).

Daftar semua karyawan kami disimpan di employee meja. Untuk setiap karyawan, kami akan menyimpan:

first_name &last_name – Nama depan dan belakang karyawan.
employment_start_date &employment_end_date – Tanggal mulai dan berakhirnya karyawan di perusahaan. Tanggal akhir harus berisi nilai NULL sampai kita dapat menentukannya.
position_id – Referensi ke posisi saat ini di perusahaan.
city_id – Referensi ke kota tempat tinggal karyawan saat ini.
is_active – Bendera yang menunjukkan apakah karyawan tersebut sedang aktif atau tidak.

Tabel terakhir di bidang subjek ini adalah schedule meja. Dalam tabel ini, kami akan menyimpan jadwal yang tepat untuk semua karyawan kami pada tingkat harian. Kami juga memiliki opsi untuk menyimpan beberapa interval untuk karyawan yang sama pada hari yang sama. Untuk mencapai ini, kami akan menggunakan atribut berikut:

repair_shop_id – Referensi ke bengkel terkait.
employee_id – Referensi ke karyawan terkait.
position_id – Referensi ke posisi terkait, yang akan dimiliki karyawan selama periode waktu yang ditentukan. Dalam kebanyakan kasus, ini akan menjadi posisinya saat ini, tetapi kami memiliki fleksibilitas untuk menetapkan beberapa posisi lain di sini.
schedule_date – Tanggal terkait entri ini.
time_from &time_to – Pasangan ini menentukan periode waktu yang terkait dengan entri ini.
plan – Bendera yang menunjukkan jika ini adalah entri yang direncanakan. Entri tidak akan direncanakan hanya jika kita memasukkannya secara ad-hoc.
actual – Bendera ini menunjukkan jika entri ini direalisasikan. Perhatikan bahwa dalam kebanyakan kasus, baik flag, plan dan actual, akan disetel ke True. Ini menunjukkan bahwa kami merencanakan dan benar-benar mewujudkan rencana itu.
insert_ts – Stempel waktu yang menunjukkan saat catatan ini dimasukkan ke dalam tabel.

Kombinasi repair_shop_id - employee_id - schedule_date - time_from membentuk kunci UNIK/alternatif dari tabel ini. Sebelum memasukkan record baru, kita juga harus memeriksa interval baru time_from – time_to tidak tumpang tindih dengan interval yang ada untuk karyawan dan tanggal yang sama.

Bagian 2:Pelanggan &kontak

Sekarang kami siap untuk beralih ke bagian model yang berhubungan dengan pelanggan.

Kami akan menyimpan semua pelanggan, kami bekerja dengan sebelumnya atau kami memiliki kontak dengan, di customer meja. Untuk setiap pelanggan, kami akan menyimpan:

first_name &last_name – Nama depan dan belakang pelanggan, jika pelanggan kami adalah individu pribadi.
company_name – Nama perusahaan, jika pelanggan adalah perusahaan dan bukan individu pribadi.
address – Alamat pelanggan.
mobile – Nomor ponsel pelanggan.
email – Email pelanggan
details – Semua detail pelanggan tambahan, jika ada, dalam format tekstual.
insert_ts – Stempel waktu yang menunjukkan saat catatan ini dimasukkan ke dalam tabel.

Sebagian besar atribut dalam tabel ini nullable karena kita mungkin tidak akan memiliki beberapa atribut tersebut dan beberapa (first_name &last_name vs. company_name ) mengecualikan orang lain.

Kami harus melacak semua kontak yang kami buat dengan setiap pelanggan. Untuk melakukan itu, kami akan menggunakan dua tabel. Yang pertama, contact_type table, adalah kamus sederhana yang hanya berisi type_name UNIK nilai.

Data kontak asli disimpan di contact meja. Kami akan menyimpan referensi ke jenis kontak tersebut (contact_type_id ), pelanggan yang kami hubungi (customer_id ), seorang karyawan yang membuat kontak tersebut (schedule_id ), dan juga menyimpan detail kontak dan waktu saat catatan ini dimasukkan ke dalam tabel (insert_ts ).

Bagian 3:Kendaraan

Setelah mengetahui sumber daya dan pelanggan kami, kami perlu menyimpan kendaraan yang akan kami gunakan. Selain melacak data dan membuat laporan internal, di sebagian besar negara kami juga perlu membuat laporan untuk badan pengatur, perusahaan asuransi, polisi.

Pertama, kami akan menentukan model kendaraan kami. Kami akan menggunakan 3 tabel untuk mencapai itu. Dalam make kamus, kami akan mencantumkan make_names yang unik untuk semua pabrikan/merek mobil/kendaraan. Selain itu, kita perlu mengetahui jenis kendaraan, jadi kita akan menggunakan satu kamus lagi dengan hanya satu atribut nilai unik – type_name . Kamus 3 yang digunakan adalah model kamus. Yang ini akan berisi daftar semua model yang datang melalui pintu kami. Untuk setiap model, kami akan menentukan kombinasi unik model_name – make_id – vechicle_type_id .

Kami akan menyelesaikan deskripsi area subjek ini dengan vehicle meja. Ini adalah satu-satunya tabel di area subjek ini yang berisi data "nyata". Kami akan menggunakan tabel ini untuk menyimpan detail berikut:

vin – Nomor identifikasi kendaraan, yang secara unik mendefinisikan kendaraan ini.
license_plate – Nomor plat mobil saat ini.
customer_id – Referensi ke pelanggan milik kendaraan ini. Jika kendaraan berganti pemilik, kami akan memasukkannya sebagai catatan baru, tetapi kami akan tahu bahwa ini adalah kendaraan yang sama berdasarkan nomor seri.
model_id – Referensi ke kamus model.
manufactured_year &manufactured_month – Tunjukkan tahun dan bulan saat kendaraan ini diproduksi.
details – Semua detail tambahan dalam format tekstual.
insert_ts – Stempel waktu yang menunjukkan saat catatan ini dimasukkan ke dalam tabel.

Bagian 4:Layanan &penawaran

Kami siap untuk membuat langkah besar berikutnya. Kita perlu mendefinisikan apa yang kita tawarkan kepada (calon) pelanggan kita. Ini bisa berupa tugas tunggal atau serangkaian tugas – layanan.

Daftar semua layanan disimpan di service_catalog kamus. Setiap layanan terdiri dari beberapa tugas dan secara unik ditentukan oleh service_name . Selain nama, kami juga akan menyimpan deskripsi, jika ada, persentase service_discount dan is_active bendera. Diskon layanan akan digunakan untuk semua tugas yang termasuk dalam layanan ini.

Selanjutnya, kita akan mendefinisikan tugas. Tugas adalah bagian dari layanan kami. Mereka adalah tindakan dasar yang dapat dilakukan secara mandiri. Setiap tugas ditentukan oleh nilai-nilai ini di task_catalog tabel:

task_name &service_catalog_id – Nama yang akan kami gunakan untuk menjelaskan tugas ini dan layanan tempatnya. Pasangan atribut ini membentuk kunci unik dari tabel.
description – Deskripsi tekstual tambahan, jika ada, digunakan untuk menjelaskan tugas ini.
ref_interval – Bendera yang menunjukkan jika kita akan mengukur interval untuk tugas ini.
ref_interval_min &ref_interval_max – Batas minimal dan maksimal dari rentang referensi.
describe – Bendera yang menunjukkan jika kita harus menambahkan komentar tekstual untuk tugas ini.
task_price – Harga saat ini, tanpa diskon layanan, untuk tugas ini.
is_active – Bendera yang menunjukkan apakah tugas saat ini aktif (dalam penawaran kami) atau tidak.

Setelah kontak dengan pelanggan, kami akan membuat penawaran kepada mereka. Tawaran itu bisa berupa layanan lengkap, dengan semua tugasnya atau serangkaian tugas. Semua penawaran disimpan di offer meja. Untuk setiap penawaran, kami akan menyimpan:

customer_id – Id pelanggan terkait.
contact_id – Id dari kontak terkait, jika ada. Ini bisa menjadi informasi penting untuk menentukan berapa banyak penawaran yang datang sebagai hasil dari kontak sebelumnya.
offer_description – Deskripsi tekstual tambahan dari penawaran ini.
service_catalog_id – Id dari layanan yang kami tawarkan kepada pelanggan. ID ini dapat berupa NULL jika kami belum menawarkan layanan lengkap kepadanya, tetapi satu atau beberapa tugas yang bukan merupakan bagian dari layanan.
service_discount – Diskon layanan saat penawaran dibuat. Nilai ini harus berisi NULL jika penawaran tidak terkait dengan layanan.
offer_price – Harga akhir dari penawaran itu. Ini dapat dihitung sebagai jumlah semua tugas dikurangi diskon layanan.
insert_ts – Stempel waktu yang menunjukkan saat catatan ini dimasukkan ke dalam tabel.

Tabel terakhir di area subjek ini adalah offer_task meja. Untuk setiap penawaran, tidak peduli apakah kami menawarkan layanan lengkap atau tidak, kami akan menyimpan kumpulan semua tugas. Kami perlu menyimpan detail berikut:

offer_id – Id dari penawaran terkait.
task_catalog_id - Sebuah id dari tugas terkait. Bersama dengan offer_id , ini membentuk kunci unik/alternatif tabel ini
task_price – Harga saat ini dari tugas tersebut pada saat catatan ini dimasukkan.
insert_ts - Stempel waktu yang menunjukkan saat catatan ini dimasukkan ke dalam tabel.

Bagian 5:Kunjungan

Area subjek terakhir dalam model kami digunakan untuk menyimpan kunjungan pelanggan yang sebenarnya ke bengkel kami. Meskipun terlihat rumit, kami hanya memiliki 2 tabel baru di sini, visit dan visit_task .

Saat pelanggan menyetujui penawaran kami atau baru saja datang ke toko kami, kami akan menganggapnya sebagai visit . Untuk setiap acara tersebut, kami akan menyimpan detail berikut:

repair_shop_id – Referensi ke bengkel terkait.
customer_id – Referensi ke pelanggan yang terkait dengan kunjungan ini.
vehicle_id – Referensi ke kendaraan yang terkait dengan kunjungan ini.
visit_start_date – Tanggal mulai kunjungan (direncanakan).
visit_start_time – Waktu mulai kunjungan (direncanakan).
visit_end_date – Tanggal mulai kunjungan (aktual). Nilai ini akan ditetapkan saat kunjungan benar-benar berakhir.
visit_end_time – Waktu mulai kunjungan (aktual). Nilai ini akan ditetapkan saat kunjungan benar-benar berakhir.
license_plate – Sebuah nomor plat pada saat kunjungan terjadi. Perhatikan, plat nomor berubah seiring waktu.
offer_id – Id dari penawaran terkait, jika ada.
service_catalog_id – Id dari layanan terkait, jika ada.
service_discount – Jumlah persentase diskon pada saat catatan ini ditambahkan dan jika kami menawarkan layanan lengkap.
visit_price – Harga total yang harus dibayar pelanggan untuk kunjungan tersebut.
invoice_created – Stempel waktu saat faktur dibuat.
invoice_due – Stempel waktu saat faktur jatuh tempo.
invoice_charged – Stempel waktu saat faktur ditagih.
insert_ts – Stempel waktu yang menunjukkan saat catatan ini dimasukkan ke dalam tabel.

Tabel terakhir dalam model kami adalah visit_task meja. Ini adalah tempat untuk menyimpan semua tugas yang sebenarnya merupakan bagian dari kunjungan itu. Untuk setiap record di sini, kami akan menyimpan nilai berikut:

visit_id – Referensi untuk kunjungan itu.
task_catalog_id – Referensi ke tugas terkait
value_measured – Nilai yang diukur selama tugas ini, jika tugas memerlukan pengukuran.
task_description – Deskripsi yang terkait dengan tugas tersebut jika tugas tersebut memerlukan deskripsi.
pass – Bendera yang menunjukkan apakah tugas ini berada dalam interval yang diharapkan atau tidak.
task_price – Harga aktual dari tugas tersebut saat ini dimasukkan ke dalam tabel ini.
insert_ts – Stempel waktu yang menunjukkan saat catatan ini dimasukkan ke dalam tabel.

Meskipun model ini cukup disederhanakan, model ini berisi semua elemen penting yang Anda perlukan untuk membuat model lengkap di sekitarnya. Bagian yang membutuhkan perbaikan pasti bahan yang digunakan dan proses pembayaran. Maukah Anda menambahkan sesuatu yang lebih pada model ini?