Model Data Perawatan Hewan Peliharaan

Perawatan hewan peliharaan adalah industri besar. Apakah ada model data yang dapat membantu pemilik hewan peliharaan dan profesional mengelola aktivitas mereka? Sekarang ada!

Banyak orang berbagi kehidupan mereka dengan kucing, anjing, burung, dan hewan lainnya. (Saya pernah memiliki seekor merpati untuk sementara waktu, sampai sayapnya sembuh.) Yang tidak disadari oleh banyak pemilik hewan peliharaan adalah seberapa besar bisnis perawatan hewan peliharaan. Di Amerika Serikat, pemilik hewan peliharaan menghabiskan $66,75 miliar – dan itu baru terjadi pada tahun 2016!

Sementara kebanyakan dari kita dapat menjaga hamster kita tetap hidup tanpa menggunakan teknologi canggih, ada banyak bisnis yang berpusat di sekitar perawatan hewan peliharaan:kandang hewan peliharaan (alias hotel hewan peliharaan atau resor hewan peliharaan), perawatan hewan peliharaan, pengasuh hewan peliharaan (yang tinggal di rumah Anda, dengan Anda hewan peliharaan, saat Anda pergi berlibur), pejalan kaki anjing, ahli perilaku hewan peliharaan, bahkan pemijat dan terapis hewan peliharaan. Ini sering memberikan layanan yang cukup kompleks untuk hewan peliharaan dan pemiliknya, dan mereka akan membutuhkan model data agar tetap teratur. Jadi mari kita lihat salah satunya.

Apa yang Menjadi Model Data Perawatan Hewan Peliharaan?

Sebelum kita mulai menjelaskan detail model, mari kita bahas beberapa persyaratan:

Siapa yang membutuhkan model data ini?

Meskipun model data ini mungkin terdengar eksotis, sebenarnya tidak terlalu aneh. Bayangkan saja Anda menjalankan salah satu bisnis yang disebutkan di atas. Tidak peduli betapa berbedanya model bisnis ini, Anda tetap harus:
- Berkomunikasi dengan calon klien
- Jelaskan layanan Anda dan sebutkan harganya
- Atur jadwal Anda
- Melacak tugas dan aktivitas yang sedang berlangsung
- Tagih klien untuk layanan yang diberikan
Jadi ya, ada kemungkinan Anda akan membutuhkan model ini untuk diri sendiri atau untuk klien Anda.

Sekarang kita dapat melanjutkan dan menjawab beberapa pertanyaan teknis.
Apa yang harus dicakup dalam model ini?

Ini akan cukup umum untuk mencakup banyak situasi yang berbeda. Saya akan pergi dengan asumsi bahwa kami akan memiliki tempat fisik di mana kami akan menyediakan layanan (seperti hotel hewan peliharaan) atau yang berfungsi sebagai titik awal untuk menyediakan layanan (yaitu untuk pejalan kaki anjing).

Kami juga perlu menyimpan catatan untuk masing-masing hewan peliharaan dan pemiliknya, serta catatan layanan yang kami sediakan. Mengaitkan semua itu harus mencakup sebagian besar kasus perawatan hewan peliharaan.
Mengapa model ini penting?

Untuk menjelaskannya, izinkan saya memberi tahu Anda tentang “nubuat” yang menurut saya akan menjadi kenyataan.

Kita semua menyadari bagaimana teknologi mengubah bisnis. Kami melihat artikel tentang pekerjaan yang akan diambil alih otomatisasi dalam 10 atau 20 tahun ke depan. Sebagian besar pekerjaan ini mungkin akan menjadi pekerjaan yang tidak bergantung pada kontak dengan manusia. Misalnya, banyak toko sekarang memiliki jalur pembayaran mandiri di mana satu karyawan manusia dapat memantau 5 atau 10 pembayaran. Sebelumnya, setiap kasir ini akan memiliki kasir. Tetapi menunggu dalam antrean untuk membayar belanjaan Anda mungkin bukan momen terbaik dalam hari Anda. Dan pekerjaan itu juga sangat melelahkan dan dibayar rendah, jadi kasir tidak terlalu senang melihat Anda. Jenis pekerjaan ini dapat dan sedang diotomatisasi.

Kumpulan pekerjaan lain yang akan diotomatisasi secara intelektual lebih menantang tetapi agak berulang – mis. hampir semua layanan keuangan, sebagian besar pemrograman komputer, dan bahkan menulis.

Jadi, "ramalan" saya adalah bahwa pekerjaan yang membutuhkan banyak kontak manusia (atau, dalam hal ini, hewan peliharaan) tidak hanya akan bertahan tetapi juga menjadi "pekerjaan masa depan"; kita berbicara tentang psikolog, penata rambut, penata rambut, dan pengasuh hewan peliharaan, dll. Tetapi mereka memerlukan beberapa teknologi untuk menjalankan bisnis mereka. Dan di situlah model ini masuk.

Model Data

Model data ini terdiri dari empat bidang subjek:

Pets
Facilities & services
Cases
Planned & provided

Kita akan mulai dengan Pets karena hewan peliharaan jelas merupakan bagian terpenting dari model bisnis ini. Setelah itu, kami akan melanjutkan dalam urutan yang sama dengan subjek yang terdaftar.

Bagian 1:Hewan Peliharaan

Saya akan mulai dengan Pets bidang studi; lagi pula, model ini ada di sini karena teman-teman kecil kita mengenakan bulu dan bulu mereka. Saya akan membuatnya sederhana, meskipun area subjek ini dapat diperluas. Misalnya, kami dapat menyimpan lebih banyak detail yang menjelaskan hewan peliharaan, karakteristiknya, dan pemilik hewan peliharaannya (dan karakteristiknya 😊 ).

Tabel terpenting dalam keseluruhan model adalah pet meja. Untuk setiap hewan peliharaan, kami akan menyimpan:

name – Nama yang diberikan pemiliknya kepada hewan peliharaannya.
species_id – Merujuk pada species kamus dan menunjukkan spesies hewan peliharaan.
birth_date – Tanggal lahir hewan peliharaan, jika tersedia.
notes – Semua catatan tambahan yang terkait dengan hewan peliharaan ini, dalam format teks bebas.

Di owner tabel, kami akan menyimpan daftar semua klien kami sebelumnya, saat ini, dan potensial. Secara pribadi, saya tidak suka kata "pemilik", karena setelah Anda tinggal dengan hewan peliharaan Anda, mereka lebih seperti anggota keluarga. Tapi saya baik-baik saja untuk menggunakannya dalam model data. Jadi, untuk setiap pemilik, kami akan menyimpan first_name mereka dan last_name , detail kontak (seperti yang kami ketahui, kami mungkin tidak mengetahui semuanya) dan detail tambahan apa pun di notes atribut.

Kami akan menghubungkan pemilik dan hewan peliharaan menggunakan pet_owner meja. Satu pemilik dapat memiliki banyak hewan peliharaan dan satu hewan peliharaan dapat memiliki beberapa pemilik, jadi kita perlu memasukkan relasi banyak-ke-banyak di sini. Untuk setiap record, kami akan menyimpan pet_id UNIK – owner_id pasangan.

Tabel ketiga dan terakhir dalam bidang subjek ini adalah species kamus. Selain atribut kunci utama id , hanya berisi species_name UNIK nilai. Kami akan menggunakan kamus ini untuk menyimpan informasi spesies pada tingkat yang dibutuhkan bisnis. Kita bisa menggunakan serangkaian nilai sederhana seperti "kucing", "anjing", "kuda", dan "burung". Atau kita dapat menggunakan nilai yang lebih deskriptif seperti “kucing – Maine Coon”, “kucing – Munchkin”, dll. Kita dapat menggunakan struktur yang lebih kompleks – yaitu memiliki satu tabel untuk spesies dan satu lagi untuk ras – tetapi menurut saya pendekatan ini tidak akan membawa sesuatu yang baru ke modelnya.

Bagian 2:Fasilitas dan Layanan

Hal terpenting kedua dalam model ini adalah layanan yang akan kami berikan. Kami juga membutuhkan fasilitas, apa pun yang kami tawarkan kepada pemilik hewan peliharaan. Ini bisa berupa satu tempat, seperti hotel hewan peliharaan, atau bisa juga tempat kita mengambil atau menurunkan hewan peliharaan (seperti yang akan digunakan oleh pejalan kaki anjing). Kami akan menyimpan informasi ini di Facilities & services bidang subjek.

Saya akan mulai dengan service meja. Ini adalah kamus yang akan kami gunakan untuk menyimpan daftar semua layanan yang kami tawarkan kepada klien kami. Untuk setiap layanan, kita memerlukan:

service_name – Nama yang secara UNIK mendefinisikan layanan.
has_limit – Nilai yang menunjukkan apakah layanan ini memiliki batas (misalnya jumlah “tempat tidur” di hotel hewan peliharaan).
unit_id – Unit yang akan kami gunakan untuk mengukur layanan itu. Itu tergantung pada jenis layanan yang kami berikan dan apakah itu membutuhkan waktu atau materi (atau keduanya). Dalam kebanyakan kasus, kita akan memperhatikan waktu. Misalnya, jika seekor anjing menginap di hotel hewan peliharaan, maka unit yang digunakan harus berupa "hari". Di sisi lain, jika kita sedang berjalan-jalan dengan seekor anjing, maka satuannya harus berupa "jam" atau "menit". Selain satuan waktu, kita juga dapat menggunakan ukuran lain, mis. jika kita ingin menentukan jumlah camilan yang akan "disediakan" kepada anjing.
cost_per_unit – Biaya per unit saat ini untuk layanan tersebut.

unit kamus digunakan untuk menyimpan daftar unit_name UNIK nilai-nilai. Nilai dari kamus ini hanya direferensikan di service tabel, tetapi mereka sangat penting dalam fase perencanaan dan saat kami menagih klien untuk layanan yang diberikan.

Untuk setiap layanan, kami juga perlu mendefinisikan setiap spesies yang diterima. Misalnya, mungkin kami akan menyediakan layanan hotel hewan peliharaan hanya untuk kucing dan bukan untuk anjing. Ini mungkin terjadi terlepas dari kenyataan bahwa kami menawarkan jalan-jalan dan perawatan anjing. Kami akan menyimpan semua service_id UNIK – species_id pasang di available_for tabel.

Setelah kami menjelaskan semua layanan kami dan detailnya, sekarang kami akan menjelaskan fasilitas (tempat) di mana kami akan menyediakan layanan ini.

Ada kemungkinan besar kami akan mengoperasikan lebih dari satu fasilitas dan menyediakan lebih dari satu layanan. Karena itu, kami harus menyimpan semua fasilitas kami dan detail terkaitnya. Kami akan menggunakan facility tabel untuk melacak:

facility_name – Nama yang akan kami gunakan secara internal untuk secara UNIK menunjukkan fasilitas itu.
address , phone , email dan contact_person – Lokasi dan informasi kontak, yang cukup jelas.

Untuk setiap fasilitas, kami akan menyimpan layanan yang disediakannya. Kami dapat memiliki satu fasilitas untuk kucing saja dan satu lagi untuk anjing saja. Atau kita bisa memiliki teknisi veteriner di satu fasilitas dan tidak di fasilitas lain. Bagaimanapun, kami harus menyimpan semua layanan yang dapat kami sediakan di setiap fasilitas. Dalam provides tabel, kami akan menyimpan facility_id UNIK - service_id pasangan. Jika service .has_limit untuk layanan yang direferensikan benar, kita juga perlu mendefinisikan service_limit untuk fasilitas itu juga currently_used kuantitas. Nilai tersebut harus dihitung ulang setiap kali kami mulai menyediakan layanan tersebut untuk satu hewan peliharaan lagi di fasilitas itu (misalnya satu tempat lagi di hotel hewan peliharaan diambil) atau kami berhenti menyediakannya untuk hewan peliharaan (misalnya jumlah tempat tidur hewan peliharaan yang tersedia di hotel telah meningkat satu).

Bagian 3:Kasus

Cases area subjek adalah tempat kami akan menjelaskan dan menyimpan semua data yang terkait dengan kunjungan atau sesi (yaitu satu kunjungan adalah satu kali menginap di hotel anjing kami, satu perawatan, satu kali jalan-jalan, dll.)

case meja menyimpan hewan peliharaan dan fasilitas yang terkait dengan sesi, panggilan, atau kunjungan. Saya telah memutuskan untuk menggunakan "case" sebagai nama tabel karena kami mungkin tidak hanya menyimpan kunjungan di sini. Mungkin kita ingin menyimpan panggilan atau kontak lainnya. Untuk setiap kasing, kami akan menyimpan:

facility_id – ID fasilitas terkait. Itu bisa berupa tempat tinggal hewan peliharaan (di hotel) atau fasilitas yang menerima panggilan terkait kasus ini.
pet_id – ID hewan peliharaan yang terlibat.
start_time – Stempel waktu sebenarnya saat kasus itu dimulai.
end_time – Stempel waktu sebenarnya saat kasus itu berakhir. Ini akan menjadi NULL sampai kasus ini ditutup.
notes – Catatan tambahan apa pun, dalam format tekstual, yang terkait dengan kasus tersebut.
closed – Jika kasus ini ditutup atau tidak. Ini akan disetel ke “Benar” ketika end_time telah disetel.

Kami akan menggunakan kombinasi facility_id – pet_id – start_time sebagai kunci UNIK tabel ini.

Setiap kasus akan memiliki satu atau lebih status yang ditetapkan padanya. Kita dapat berharap bahwa status pertama yang ditetapkan akan menunjukkan kapan kasus dimulai. Setelah itu, kami akan menetapkan status baru sesuai kebutuhan, hingga kasus tersebut diselesaikan (ditutup).

Kamus pertama di sini adalah status_category kamus. Ini berisi daftar status_category_name UNIK nilai-nilai. Ini adalah status grup berdasarkan jenis, mis. “status fisik”, “nafsu makan”, atau “status umum”.

Semua kemungkinan status disimpan di status kamus. Untuk setiap status, kami akan menyimpan status_name its , ID kategori status tempatnya, dan is_closing_status nilai. Jika is_closing_status nilainya “True”, artinya ketika kita menetapkan status ini, kasus akan ditandai sebagai ditutup. status_name – status_category_id pair membentuk kunci UNIK tabel ini.

Dalam case_status tabel, kami akan menyimpan semua status yang sebenarnya ditetapkan ke kasus. Untuk setiap record dalam tabel ini, kami akan menyimpan referensi ke case dan status tabel, notes tambahan apa pun , dan insert_time dari status itu. Kita dapat, misalnya, menyimpan kondisi fisik dan nafsu makan hewan peliharaan saat ini sebagai status saat hewan peliharaan tersebut masuk ke fasilitas kita. Status ini akan berubah jika kita melihat perubahan dalam kondisinya. Di sisi lain, kami juga akan menyimpan status terkait setiap kasus (misalnya, “anjing dibawa jalan”); kami akan memberikan detail tambahan terkait status tersebut di notes atribut. Status ini tidak akan menjadi status "penutupan" karena terkait dengan a) status hewan peliharaan saat itu, atau b) tindakan yang diambil selama sesi atau kunjungan. Contoh status "menutup" dapat berupa, "anjing check out" dari hotel hewan peliharaan kami.

Tabel terakhir di bagian ini adalah note meja. Kami akan menggunakan tabel ini untuk menyimpan semua catatan yang terkait dengan kasus ketika tidak perlu menyisipkan status baru. Untuk setiap record, kami akan menyimpan note_text , ID kasus terkait, dan insert_time saat catatan itu dibuat.

Bagian 4:Direncanakan dan Disediakan

Area subjek terakhir adalah Planned & provided bidang studi. Tiga tabel di area subjek ini menyimpan data tentang layanan yang kami rencanakan untuk diberikan, yang sebenarnya disediakan, dan semua faktur yang terkait dengan kasus.

service_planned tabel berisi daftar semua layanan yang telah kami usulkan kepada klien kami atau yang telah mereka pesan. Setiap record akan berisi:

case_id – ID kasus terkait.
service_id – ID layanan terkait.
planned_start_time &planned_end_time – Ketika kami berencana untuk memulai dan mengakhiri layanan ini. Waktu mulai harus ditentukan tetapi waktu berakhirnya bisa NULL.
planned_units – Jumlah unit layanan yang direncanakan, mis. 3 hari di hotel hewan peliharaan.
cost_per_unit – Biaya per unit pada saat itu. Penting untuk menyimpan nilai ini karena nilai disimpan di service .cost_per_unit dapat berubah antara waktu pemesanan dan waktu pelaksanaannya.
planned_price – Harga yang dikutip untuk layanan tersebut. Ini harus sama dengan planned_units * cost_per_unit .
notes – Catatan tambahan apa pun yang terkait dengan layanan yang direncanakan.

service_provided tabel memiliki struktur yang hampir sama dengan service_planned meja. Satu-satunya perbedaan adalah units dan price_charged atribut dapat berisi nilai NULL. Hal ini disebabkan fakta bahwa kami dapat memasukkan catatan dalam tabel ini ketika kami mulai memberikan layanan (misalnya ketika hewan peliharaan memasuki hotel hewan peliharaan) dan kami akan memperbaruinya ketika kami berhenti memberikan layanan (misalnya ketika pemilik mengambil rumah hewan peliharaan).

Tabel terakhir dalam model kami adalah invoice meja. Itu menyimpan daftar semua faktur yang kami buat untuk semua kasus kami. Untuk setiap faktur, kami akan menyimpan:

invoice_code – Nomor UNIK internal yang dibuat untuk setiap faktur.
case_id – ID kasus terkait.
time_generated – Saat faktur dibuat.
invoice_amount – Jumlah asli yang kami bebankan kepada klien. Jumlah ini harus sama dengan jumlah semua nilai di price_charged untuk service_provided .
discount – Diskon yang diberikan kepada klien (misalnya karena kupon, kartu loyalitas, dll. Alasannya tidak terlalu penting.)
time_charged – Ketika klien benar-benar ditagih untuk faktur itu. Atribut ini akan berisi nilai NULL hingga pembayaran dilakukan.
amount_charged – Jumlah sebenarnya yang ditagihkan kepada klien untuk faktur tersebut.
notes – Catatan tambahan apa pun yang terkait dengan faktur tersebut.

Apa yang Akan Anda Tambahkan?

Hari ini kita berbicara tentang model data yang mungkin untuk bisnis perawatan hewan peliharaan. Model ini mencakup fungsionalitas dasar, tetapi ada ruang untuk perbaikan. Silakan bagikan saran Anda dengan kami di bagian komentar. Terima kasih!