Mô hình dữ liệu chăm sóc thú cưng

Chăm sóc thú cưng là một ngành công nghiệp khổng lồ. Có mô hình dữ liệu nào có thể giúp chủ sở hữu vật nuôi và các chuyên gia quản lý hoạt động của họ không? Hiện có!

Nhiều người chia sẻ cuộc sống của họ với mèo, chó, chim và các động vật khác. (Tôi đã từng nuôi một con chim bồ câu trong một thời gian, cho đến khi cánh của nó bị hàn lại.) Điều mà nhiều chủ sở hữu vật nuôi không nhận ra là việc chăm sóc thú cưng kinh doanh lớn như thế nào. Tại Hoa Kỳ, chủ sở hữu vật nuôi đã chi 66,75 tỷ đô la - và đó chỉ là vào năm 2016!

Mặc dù hầu hết chúng ta có thể giữ cho chuột lang của mình sống sót mà không cần sử dụng công nghệ phức tạp, nhưng có rất nhiều doanh nghiệp tập trung vào việc chăm sóc thú cưng:cũi cho thú cưng (còn gọi là khách sạn thú cưng hoặc khu nghỉ dưỡng dành cho thú cưng), người bán đồ cho thú cưng, người trông trẻ (người ở trong nhà bạn, với thú cưng, trong khi bạn đi nghỉ), người dắt chó đi dạo, chuyên gia chăm sóc hành vi cho thú cưng, thậm chí cả người xoa bóp và trị liệu cho thú cưng. Những dịch vụ này thường cung cấp các dịch vụ khá phức tạp cho vật nuôi và chủ nhân của chúng, và họ sẽ cần một mô hình dữ liệu để giữ cho chúng có tổ chức. Vì vậy, chúng ta hãy xem xét một.

Điều gì liên quan đến Mô hình Dữ liệu Chăm sóc Thú cưng?

Trước khi bắt đầu mô tả chi tiết của mô hình, hãy thảo luận một số yêu cầu:

1. Ai sẽ cần mô hình dữ liệu này?

   Mặc dù mô hình dữ liệu này nghe có vẻ kỳ lạ, nhưng nó không thực sự bất thường. Chỉ cần tưởng tượng bạn đang điều hành bất kỳ doanh nghiệp nào được đề cập ở trên. Cho dù các mô hình kinh doanh này có khác nhau như thế nào, bạn vẫn cần:

   • Giao tiếp với khách hàng tiềm năng
   • Giải thích các dịch vụ của bạn và nêu giá của chúng
   • Sắp xếp lịch trình của bạn
   • Theo dõi các nhiệm vụ và hoạt động đang thực hiện
   • Tính phí khách hàng cho các dịch vụ được cung cấp

   Vì vậy, có, có khả năng bạn sẽ cần mô hình này cho chính mình hoặc cho khách hàng của mình.

   Bây giờ chúng ta có thể tiếp tục và trả lời một số câu hỏi kỹ thuật.

2. Điều gì nên được đề cập trong mô hình này?

   Nó sẽ đủ chung để bao gồm nhiều tình huống khác nhau. Tôi sẽ giả định rằng chúng ta sẽ có một địa điểm thực tế để chúng ta cung cấp dịch vụ (như khách sạn cho thú cưng) hoặc là điểm khởi đầu để cung cấp dịch vụ (tức là cho chó đi dạo).

   Chúng tôi cũng sẽ cần lưu trữ hồ sơ của từng vật nuôi và chủ sở hữu của chúng, cũng như hồ sơ về các dịch vụ mà chúng tôi cung cấp. Liên quan đến tất cả những điều đó sẽ bao gồm hầu hết các trường hợp chăm sóc thú cưng.

3. Tại sao mô hình này lại quan trọng?

   Để giải thích, hãy để tôi kể cho bạn nghe về một "lời tiên tri" mà tôi nghĩ sẽ trở thành sự thật.

   Tất cả chúng ta đều biết công nghệ đang thay đổi hoạt động kinh doanh như thế nào. Chúng tôi thấy các bài báo về các công việc mà tự động hóa sẽ đảm nhận trong 10 hoặc 20 năm tới. Hầu hết những công việc này có thể sẽ là những công việc không phụ thuộc vào việc tiếp xúc với con người. Ví dụ:nhiều cửa hàng hiện có các làn đường tự thanh toán, nơi một nhân viên có thể giám sát 5 hoặc 10 lượt thanh toán. Trước đây, mỗi thanh toán này sẽ có một nhân viên thu ngân. Nhưng xếp hàng chờ thanh toán hàng tạp hóa có lẽ không phải là khoảnh khắc tuyệt vời nhất trong ngày của bạn. Và công việc đó cũng rất mệt mỏi và lương thấp khiến nhân viên thu ngân không thực sự hào hứng khi gặp bạn. Những loại công việc này có thể và đang được tự động hóa.

   Các công việc khác sẽ được tự động hóa có nhiều thách thức hơn về mặt trí tuệ nhưng hơi lặp đi lặp lại - ví dụ:hầu hết các dịch vụ tài chính, hầu hết các chương trình máy tính và thậm chí cả viết.

   Vì vậy, “lời tiên tri” của tôi là những công việc đòi hỏi nhiều sự tiếp xúc của con người (hoặc trong trường hợp này là thú cưng) sẽ không chỉ tồn tại mà còn trở thành “công việc của tương lai”; chúng ta đang nói về các nhà tâm lý học, nhà tạo mẫu tóc, người chăm sóc chó và người chăm sóc thú cưng, v.v. Nhưng họ sẽ cần một số công nghệ để điều hành doanh nghiệp của mình. Và đó là nơi xuất hiện của mô hình này.

Mô hình dữ liệu

Mô hình dữ liệu này bao gồm bốn lĩnh vực chủ đề:

• Pets
• Facilities & services
• Cases
• Planned & provided

Chúng ta sẽ bắt đầu với Pets vì thú cưng rõ ràng là phần quan trọng nhất của mô hình kinh doanh này. Sau đó, chúng tôi sẽ tiếp tục theo thứ tự như các lĩnh vực chủ đề được liệt kê.

Phần 1:Thú cưng

Tôi sẽ bắt đầu với Pets môn học; sau tất cả, mô hình này là ở đây vì những người bạn nhỏ của chúng tôi mặc áo lông vũ và lông vũ của chúng. Tôi sẽ giữ cho nó đơn giản, mặc dù lĩnh vực chủ đề này có thể được mở rộng. Ví dụ:chúng tôi có thể lưu trữ thêm nhiều thông tin chi tiết mô tả vật nuôi, đặc điểm của chúng và chủ sở hữu vật nuôi (và đặc điểm của chúng 😊).

Bảng quan trọng nhất trong toàn bộ mô hình là pet bàn. Đối với mỗi vật nuôi, chúng tôi sẽ lưu trữ:

• name - Tên mà chủ sở hữu đặt cho thú cưng của họ.
• species_id - Tham khảo species từ điển và biểu thị các loài vật nuôi.
• birth_date - Ngày sinh của thú cưng, nếu có.
• notes - Tất cả các ghi chú bổ sung liên quan đến con vật cưng này, ở định dạng văn bản miễn phí.

Trong owner bảng, chúng tôi sẽ lưu trữ danh sách tất cả các khách hàng trước đây, hiện tại và tiềm năng của chúng tôi. Cá nhân tôi không thích từ “chủ sở hữu”, bởi vì sau khi bạn sống với thú cưng của mình, chúng giống như những thành viên trong gia đình hơn. Nhưng tôi có thể sử dụng nó trong mô hình dữ liệu. Vì vậy, đối với mỗi chủ sở hữu, chúng tôi sẽ lưu trữ first_name của họ và last_name , chi tiết liên hệ (như chúng tôi biết, chúng tôi có thể không biết tất cả) và bất kỳ chi tiết bổ sung nào trong notes thuộc tính.

Chúng tôi sẽ liên hệ với chủ sở hữu và vật nuôi bằng cách sử dụng pet_owner bàn. Một chủ sở hữu có thể có nhiều vật nuôi và một vật nuôi có thể có một vài chủ sở hữu, vì vậy chúng ta sẽ cần chèn mối quan hệ nhiều-nhiều ở đây. Đối với mỗi bản ghi, chúng tôi sẽ lưu trữ một pet_id DUY NHẤT - owner_id cặp.

Bảng thứ ba và bảng cuối cùng trong chủ đề này là species từ điển. Bên cạnh thuộc tính khóa chính id , nó chỉ chứa species_name DUY NHẤT giá trị. Chúng tôi sẽ sử dụng từ điển này để lưu trữ thông tin loài ở cấp độ mà doanh nghiệp yêu cầu. Chúng ta có thể chọn một tập hợp các giá trị đơn giản như “mèo”, “chó”, “ngựa” và “chim”. Hoặc chúng tôi có thể sử dụng nhiều giá trị mô tả hơn như “mèo - Maine Coon”, “mèo - Munchkin”, v.v. Chúng tôi có thể sử dụng một cấu trúc phức tạp hơn - tức là có một bảng cho các loài và một bảng khác cho giống - nhưng tôi không nghĩ cách tiếp cận này sẽ mang lại bất kỳ điều gì mới cho mô hình.

Phần 2:Cơ sở vật chất và Dịch vụ

Điều quan trọng thứ hai trong mô hình này là các dịch vụ mà chúng tôi sẽ cung cấp. Chúng tôi cũng sẽ cần cơ sở vật chất, bất kể chúng tôi cung cấp những gì cho chủ sở hữu vật nuôi. Đây có thể là một địa điểm, chẳng hạn như khách sạn dành cho thú cưng hoặc có thể là nơi chúng tôi đón hoặc thả thú cưng (chẳng hạn như xe tập đi cho chó). Chúng tôi sẽ lưu trữ thông tin này trong Facilities & services lĩnh vực chủ đề.

Tôi sẽ bắt đầu với service bàn. Đây là từ điển mà chúng tôi sẽ sử dụng để lưu trữ danh sách tất cả các dịch vụ mà chúng tôi cung cấp cho khách hàng của mình. Đối với mỗi dịch vụ, chúng tôi sẽ cần:

• service_name - Một cái tên KHÔNG CẦN THIẾT xác định một dịch vụ.
• has_limit - Giá trị biểu thị nếu dịch vụ này có giới hạn (ví dụ:số lượng "giường" trong khách sạn vật nuôi).
• unit_id - Đơn vị chúng tôi sẽ sử dụng để đo lường dịch vụ đó. Nó phụ thuộc vào loại dịch vụ mà chúng tôi cung cấp và nếu nó yêu cầu thời gian hoặc vật liệu (hoặc cả hai). Trong hầu hết các trường hợp, chúng tôi sẽ quan tâm đến thời gian. Ví dụ:nếu một con chó ở trong khách sạn vật nuôi, thì đơn vị được sử dụng phải là "ngày". Mặt khác, nếu chúng ta đang dắt chó đi dạo, thì đơn vị tính phải là “giờ” hoặc “phút”. Bên cạnh đơn vị thời gian, chúng ta cũng có thể sử dụng các thước đo khác, ví dụ:nếu chúng ta muốn xác định số lượng đồ ăn mà chú chó sẽ được “cung cấp”.
• cost_per_unit - Chi phí hiện tại trên mỗi đơn vị cho dịch vụ đó.

unit từ điển được sử dụng để lưu trữ danh sách unit_name DUY NHẤT các giá trị. Các giá trị từ từ điển này chỉ được tham chiếu trong service nhưng chúng rất quan trọng trong giai đoạn lập kế hoạch và khi chúng tôi tính phí khách hàng cho các dịch vụ được cung cấp.

Đối với mỗi dịch vụ, chúng tôi cũng sẽ cần xác định mọi loài được chấp nhận. Ví dụ:có thể chúng tôi sẽ cung cấp dịch vụ khách sạn thú cưng chỉ dành cho mèo chứ không phải chó. Điều này có thể xảy ra bất kể thực tế là chúng tôi cung cấp dịch vụ dắt chó đi dạo và chải lông. Chúng tôi sẽ lưu trữ tất cả service_id DUY NHẤT - speices_id các cặp trong available_for bảng.

Sau khi chúng tôi đã mô tả tất cả các dịch vụ của mình và thông tin chi tiết của chúng, bây giờ chúng tôi sẽ mô tả các cơ sở (địa điểm) mà chúng tôi sẽ cung cấp các dịch vụ này.

Có một cơ hội tốt là chúng tôi sẽ vận hành nhiều hơn một cơ sở và cung cấp nhiều dịch vụ. Do đó, chúng tôi sẽ cần lưu trữ tất cả các cơ sở của mình và các chi tiết liên quan của chúng. Chúng tôi sẽ sử dụng facility bảng để theo dõi:

• facility_name - Một cái tên mà chúng tôi sẽ sử dụng nội bộ để biểu thị BẤT CỨU CƠ SỞ đó.
• address , phone , email và contact_person - Vị trí và thông tin liên hệ, khá nhiều thứ tự giải thích.

Đối với mỗi cơ sở, chúng tôi sẽ lưu trữ những dịch vụ mà cơ sở đó cung cấp. Chúng tôi có thể có một cơ sở chỉ dành cho mèo và một cơ sở khác chỉ dành cho chó. Hoặc chúng ta có thể có một kỹ thuật viên thú y ở một cơ sở này và không có ở cơ sở kia. Trong mọi trường hợp, chúng tôi sẽ cần lưu trữ tất cả các dịch vụ mà chúng tôi có thể cung cấp ở mỗi cơ sở. Trong provides bảng, chúng tôi sẽ lưu trữ một facility_id DUY NHẤT - service_id đôi. Trong trường hợp service đó . has_limit vì dịch vụ được tham chiếu là đúng, chúng tôi cũng sẽ cần xác định service_limit cho cơ sở đó cũng như currently_used số lượng. Giá trị đó nên được tính toán lại mỗi khi chúng tôi bắt đầu cung cấp dịch vụ đó cho một vật nuôi khác trong cơ sở đó (ví dụ:thêm một chỗ trong khách sạn dành cho vật nuôi) hoặc chúng tôi ngừng cung cấp cho vật nuôi (ví dụ:số lượng giường vật nuôi có sẵn trong khách sạn đã tăng lên một).

Phần 3:Các trường hợp

Cases lĩnh vực chủ đề là nơi chúng tôi sẽ mô tả và lưu trữ tất cả dữ liệu liên quan đến các lượt truy cập hoặc phiên hoạt động (tức là một lần ghé thăm là một lần ở khách sạn dành cho chó của chúng tôi, một lần chải lông, một lần đi dạo. v.v.)

case bảng lưu trữ vật nuôi và các cơ sở liên quan đến phiên, cuộc gọi hoặc lượt truy cập. Tôi đã quyết định sử dụng "trường hợp" làm tên của bảng vì chúng tôi có thể không chỉ lưu trữ các lượt truy cập ở đây. Có thể chúng ta muốn lưu trữ các cuộc gọi hoặc các số liên lạc khác. Đối với mỗi trường hợp, chúng tôi sẽ lưu trữ:

• facility_id - ID của cơ sở liên quan. Đó có thể là nơi thú cưng ở (trong khách sạn) hoặc cơ sở nhận cuộc gọi liên quan đến trường hợp này.
• pet_id - ID của vật nuôi có liên quan.
• start_time - Dấu thời gian thực khi trường hợp đó bắt đầu.
• end_time - Dấu thời gian thực tế khi trường hợp đó kết thúc. Nó sẽ là NULL cho đến khi vụ án được đóng lại.
• notes - Bất kỳ ghi chú bổ sung nào, ở định dạng văn bản, liên quan đến trường hợp đó.
• closed - Nếu trường hợp này có đóng lại hay không. Nó sẽ được đặt thành “True” khi end_time đã được thiết lập.

Chúng tôi sẽ sử dụng kết hợp facility_id - pet_id - start_time là khóa DUY NHẤT của bảng này.

Mỗi trường hợp sẽ có một hoặc nhiều trạng thái được gán cho nó. Chúng tôi có thể mong đợi rằng trạng thái đầu tiên được chỉ định sẽ cho biết khi trường hợp bắt đầu. Sau đó, chúng tôi sẽ chỉ định các trạng thái mới nếu cần, cho đến khi vụ việc được giải quyết (đã đóng).

Từ điển đầu tiên ở đây là status_category từ điển. Nó chứa danh sách status_category_name DUY NHẤT các giá trị. Đây là trạng thái nhóm theo loại, ví dụ:"Trạng thái thể chất", "cảm giác thèm ăn" hoặc "trạng thái chung".

Tất cả các trạng thái có thể được lưu trữ trong status từ điển. Đối với mỗi trạng thái, chúng tôi sẽ lưu trữ status_name của nó , ID của danh mục trạng thái mà nó thuộc về và is_closing_status giá trị. Nếu is_closing_status giá trị là “True”, có nghĩa là khi chúng tôi chỉ định trạng thái này, trường hợp sẽ được đánh dấu là đã đóng. status_name - status_category_id cặp tạo thành khóa DUY NHẤT của bảng này.

Trong case_status bảng, chúng tôi sẽ lưu trữ tất cả các trạng thái đã thực sự được chỉ định cho các trường hợp. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ các tham chiếu đến case và status bảng, mọi notes bổ sung và insert_time của trạng thái đó. Ví dụ:chúng tôi có thể lưu trữ tình trạng thể chất hiện tại và sự thèm ăn của vật nuôi dưới dạng trạng thái khi vật nuôi đến cơ sở của chúng tôi. Các trạng thái này sẽ được thay đổi nếu chúng tôi nhận thấy sự thay đổi trong tình trạng của chúng. Mặt khác, chúng tôi cũng sẽ lưu trữ các trạng thái liên quan đến từng trường hợp (ví dụ:“chó bị dắt đi”); chúng tôi sẽ đưa bất kỳ chi tiết bổ sung nào liên quan đến trạng thái đó trong notes thuộc tính. Các trạng thái này sẽ không phải là trạng thái “đóng cửa” vì chúng liên quan đến a) trạng thái hiện tại của thú cưng tại thời điểm đó hoặc b) đến các hành động được thực hiện trong phiên hoặc chuyến thăm. Ví dụ về trạng thái “đóng cửa” có thể là “chó đã trả phòng” khỏi khách sạn thú cưng của chúng tôi.

Bảng cuối cùng trong phần này là note bàn. Chúng tôi sẽ sử dụng bảng này để lưu trữ tất cả các ghi chú liên quan đến các trường hợp khi không cần chèn trạng thái mới. Đối với mỗi bản ghi, chúng tôi sẽ lưu trữ note_text , một ID của trường hợp liên quan và insert_time khi ghi chú đó được tạo.

Phần 4:Lập kế hoạch và Cung cấp

Chủ đề cuối cùng là Planned & provided môn học. Ba bảng trong chủ đề này lưu trữ dữ liệu về các dịch vụ mà chúng tôi dự định cung cấp, những dịch vụ đã thực sự cung cấp và tất cả các hóa đơn liên quan đến các vụ việc.

service_planned bảng chứa danh sách tất cả các dịch vụ mà chúng tôi đã đề xuất cho khách hàng của mình hoặc họ đã đặt trước. Mỗi bản ghi sẽ chứa:

• case_id - ID của trường hợp liên quan.
• service_id - ID của dịch vụ liên quan.
• planned_start_time &planned_end_time - Khi chúng tôi dự định bắt đầu và kết thúc dịch vụ này. Thời gian bắt đầu phải được xác định nhưng thời gian kết thúc có thể là NULL.
• planned_units - Số lượng các đơn vị dịch vụ được lên kế hoạch, ví dụ:3 ngày ở khách sạn dành cho thú cưng.
• cost_per_unit - Giá thành trên một đơn vị tại thời điểm đó. Điều quan trọng là phải lưu trữ giá trị này vì giá trị được lưu trữ trong service . cost_per_unit có thể thay đổi giữa thời gian đặt trước và thời gian thực hiện.
• planned_price - Giá niêm yết của dịch vụ đó. Giá trị này phải bằng planned_units * cost_per_unit .
• notes - Bất kỳ ghi chú bổ sung nào liên quan đến dịch vụ đã lên kế hoạch.

service_provided bảng có cấu trúc gần như giống với service_planned bàn. Sự khác biệt duy nhất là units và price_charged các thuộc tính có thể chứa giá trị NULL. Điều này là do chúng tôi có thể chèn một bản ghi vào bảng này khi chúng tôi bắt đầu cung cấp dịch vụ (ví dụ:khi vật nuôi vào khách sạn vật nuôi) và chúng tôi sẽ cập nhật chúng khi chúng tôi ngừng cung cấp dịch vụ (ví dụ:khi chủ sở hữu đưa nhà vật nuôi).

Bảng cuối cùng trong mô hình của chúng tôi là invoice bàn. Nó lưu giữ một danh sách tất cả các hóa đơn mà chúng tôi đã tạo cho tất cả các trường hợp của chúng tôi. Đối với mỗi hóa đơn, chúng tôi sẽ lưu trữ:

• invoice_code - Số DUY NHẤT nội bộ được tạo cho mỗi hóa đơn.
• case_id - ID của trường hợp liên quan.
• time_generated - Khi hóa đơn được tạo.
• invoice_amount - Số tiền ban đầu chúng tôi đang tính cho khách hàng. Số tiền này phải bằng tổng của tất cả các giá trị trong price_charged cho service_provided .
• discount - Giảm giá cho khách hàng (ví dụ:vì phiếu giảm giá, thẻ khách hàng thân thiết, v.v. Lý do không thực sự quan trọng.)
• time_charged - Khi khách hàng thực sự bị tính phí cho hóa đơn đó. Thuộc tính này sẽ chứa giá trị NULL cho đến khi thanh toán được thực hiện.
• amount_charged - Số tiền thực tế đã được tính cho khách hàng cho hóa đơn đó.
• notes - Bất kỳ ghi chú bổ sung nào liên quan đến hóa đơn đó.

Bạn sẽ thêm gì?

Hôm nay chúng ta đã nói về một mô hình dữ liệu khả thi cho một doanh nghiệp chăm sóc thú cưng. Mô hình này bao gồm các chức năng cơ bản, nhưng vẫn còn chỗ để cải thiện. Hãy chia sẻ đề xuất của bạn với chúng tôi trong phần bình luận. Cảm ơn!