Mô hình dữ liệu cửa hàng sửa chữa ô tô

Điều hành một cửa hàng sửa chữa ô tô / ô tô là một công việc kinh doanh thực sự phức tạp. Bạn sẽ cần đặt lịch hẹn trong khi một số khách hàng sẽ lái xe đến và bạn không muốn họ đợi hàng giờ. Ngoài ra, bạn sẽ cần tổ chức nhân viên, theo dõi sửa chữa, vật liệu, tính phí khách hàng, v.v. Bạn chắc chắn sẽ cần một giải pháp CNTT và tất nhiên, một mô hình dữ liệu trong nền. Hôm nay chúng ta sẽ nói về một mô hình như vậy.

Ý tưởng

Tôi đã đề cập rằng mô hình kinh doanh này thực sự phức tạp. Vì vậy, tôi sẽ không cố gắng che đậy mọi thứ. Tôi đã cố ý bỏ qua vật liệu theo dõi và phụ tùng thay thế, đồng thời cũng đơn giản hóa một số bộ phận của mô hình. Lý do cho điều đó là khá đơn giản. Nếu tôi thực sự đã bao gồm tất cả mọi thứ, thì mô hình sẽ đơn giản là quá lớn đối với một bài báo có kích thước hợp lý. Vì vậy, hãy bắt đầu.

Mô hình dữ liệu

Mô hình bao gồm 5 chủ đề:

• Repair shops & employees
• Customers & contacts
• Vehicles
• Services & offers và
• Visits

Chúng tôi sẽ mô tả từng lĩnh vực trong số 5 lĩnh vực chủ đề này theo thứ tự chúng được liệt kê.

Phần 1:Cửa hàng sửa chữa &nhân viên

Chủ đề đầu tiên, chúng ta sẽ bắt đầu với Repair shops & employees môn học. Rõ ràng là chúng ta cần biết những gì chúng ta có trước khi có thể đưa ra đề nghị cho khách hàng.

city từ điển được sử dụng để lưu trữ tất cả các thành phố riêng biệt nơi chúng tôi có cửa hàng sửa chữa hoặc khách hàng của chúng tôi đến từ. Mỗi thành phố được xác định duy nhất bởi cặp postal_code - city_name . Chúng tôi có thể quyết định chỉ có một mục nhập cho mỗi thành phố, ngay cả khi thành phố đó có nhiều mã bưu điện. Trong trường hợp đó, chúng tôi sẽ chỉ sử dụng mã bưu chính "chính" cho thành phố đó. Tuy nhiên, chúng tôi có một tùy chọn để có nhiều mục nhập cho cùng một thành phố và các mã bưu chính khác nhau - trong trường hợp chúng tôi muốn điều đó.

repair_shop bảng là nơi chúng tôi sẽ lưu trữ danh sách tất cả các cửa hàng sửa chữa của chúng tôi. Chúng tôi có thể mong đợi rằng chúng tôi sẽ vận hành nhiều hơn một tại một số điểm. Mỗi cửa hàng được xác định duy nhất bởi shop_name và id của thành phố mà nó thuộc về (city_id ). Chúng tôi cũng sẽ lưu trữ địa chỉ của cửa hàng và các chi tiết details bổ sung ở định dạng văn bản nếu có.

position từ điển được sử dụng để lưu trữ position_names duy nhất có thể được giao cho nhân viên của chúng tôi. Mặc dù hầu hết các vị trí sẽ liên quan đến hoạt động kinh doanh cốt lõi của chúng tôi, nhưng chúng tôi cũng sẽ có một số vị trí không thuộc lĩnh vực kinh doanh cốt lõi (vai trò / vị trí kỹ thuật) nhưng cũng rất cần thiết (quản trị, bán hàng, v.v.).

Danh sách tất cả nhân viên của chúng tôi được lưu trữ trong employee bàn. Đối với mỗi nhân viên, chúng tôi sẽ lưu trữ:

• first_name &last_name - Họ và tên của nhân viên.
• employment_start_date &employment_end_date - Ngày bắt đầu và ngày kết thúc của nhân viên trong công ty. Ngày kết thúc phải chứa giá trị NULL cho đến khi chúng tôi có thể xác định nó.
• position_id - Tham chiếu đến vị trí hiện tại trong công ty.
• city_id - Tham chiếu đến thành phố nơi nhân viên hiện đang sống.
• is_active - Một cờ cho biết nhân viên hiện đang hoạt động hay không.

Bảng cuối cùng trong chủ đề này là schedule bàn. Trong bảng này, chúng tôi sẽ lưu trữ lịch trình chính xác cho tất cả nhân viên của mình ở cấp độ hàng ngày. Chúng tôi cũng sẽ có tùy chọn lưu trữ nhiều khoảng thời gian cho cùng một nhân viên trong cùng một ngày. Để đạt được điều này, chúng tôi sẽ sử dụng các thuộc tính sau:

• repair_shop_id - Một tài liệu tham khảo về cửa hàng sửa chữa liên quan.
• employee_id - Tham chiếu đến nhân viên có liên quan.
• position_id - Một tham chiếu đến vị trí liên quan, nhân viên sẽ có trong khoảng thời gian xác định. Trong hầu hết các trường hợp, đây sẽ là vị trí hiện tại của anh ấy, nhưng chúng tôi có thể linh hoạt bổ nhiệm một số vị trí khác tại đây.
• schedule_date - Ngày mà mục này liên quan đến.
• time_from &time_to - Cặp này xác định khoảng thời gian mà mục nhập này có liên quan.
• plan - Một lá cờ biểu thị nếu đây là mục nhập đã được lên kế hoạch. Mục nhập sẽ không được lên kế hoạch chỉ nếu chúng tôi đưa nó vào bất kỳ thời điểm nào.
• actual - Cờ này biểu thị mục nhập này có được thực hiện hay không. Lưu ý rằng trong hầu hết các trường hợp, cả cờ, kế hoạch và thực tế, sẽ được đặt thành Đúng. Điều này cho thấy rằng chúng tôi đã lên kế hoạch và thực sự hiện thực hóa kế hoạch đó.
• insert_ts - Dấu thời gian biểu thị thời điểm khi bản ghi này được chèn vào bảng.

Sự kết hợp repair_shop_id - employee_id - schedule_date - time_from tạo thành khóa DUY NHẤT / thay thế của bảng này. Trước khi chèn bản ghi mới, chúng ta cũng nên kiểm tra khoảng thời gian mới đó time_from - time_to không trùng lặp với bất kỳ khoảng thời gian hiện có nào cho cùng một nhân viên và ngày tháng đó.

Phần 2:Khách hàng và địa chỉ liên hệ

Bây giờ chúng tôi đã sẵn sàng chuyển sang phần liên quan đến khách hàng của mô hình.

Chúng tôi sẽ lưu trữ tất cả khách hàng, chúng tôi đã làm việc với trước đây hoặc chúng tôi đã liên hệ, trong customer bàn. Đối với mỗi khách hàng, chúng tôi sẽ lưu trữ:

• first_name &last_name - Họ và tên của khách hàng, trong trường hợp khách hàng của chúng tôi là cá nhân.
• company_name - Tên công ty, trong trường hợp khách hàng là một công ty chứ không phải một cá nhân.
• address - Địa chỉ của khách hàng.
• mobile - Số điện thoại di động của khách hàng.
• email - Email của khách hàng
• details - Tất cả các chi tiết bổ sung về khách hàng, nếu có, ở định dạng văn bản.
• insert_ts - Dấu thời gian biểu thị thời điểm khi bản ghi này được chèn vào bảng.

Hầu hết các thuộc tính trong bảng này đều không thể sử dụng được vì chúng tôi có thể sẽ không có một số thuộc tính trong số đó và một số thuộc tính (first_name &last_name so với company_name ) loại trừ những người khác.

Chúng tôi sẽ cần theo dõi tất cả các liên hệ mà chúng tôi đã thực hiện với từng khách hàng. Để làm điều đó, chúng tôi sẽ sử dụng hai bảng. Đầu tiên, contact_type bảng, là một từ điển đơn giản chỉ chứa type_name DUY NHẤT giá trị.

Dữ liệu liên hệ thực được lưu trữ trong contact bàn. Chúng tôi sẽ lưu trữ các tham chiếu đến loại liên hệ đó (contact_type_id ), một khách hàng mà chúng tôi đã liên hệ (customer_id ), một nhân viên đã liên hệ đó (schedule_id ), đồng thời lưu trữ chi tiết liên hệ và thời gian bản ghi này được chèn vào bảng (insert_ts ).

Phần 3:Xe cộ

Sau khi biết các nguồn lực và khách hàng của mình, chúng tôi cần lưu trữ các phương tiện mà chúng tôi sẽ làm việc cùng. Bên cạnh việc theo dõi dữ liệu và tạo báo cáo nội bộ, ở hầu hết các quốc gia, chúng tôi cũng cần tạo báo cáo cho các cơ quan quản lý, công ty bảo hiểm, cảnh sát.

Đầu tiên, chúng tôi sẽ xác định các mẫu xe của chúng tôi. Chúng tôi sẽ sử dụng 3 bảng để đạt được điều đó. Trong make từ điển, chúng tôi sẽ liệt kê các make_names duy nhất cho tất cả các nhà sản xuất / chế tạo ô tô / xe cộ. Bên cạnh đó, chúng tôi sẽ cần biết các loại phương tiện, vì vậy chúng tôi sẽ sử dụng thêm một từ điển chỉ có một thuộc tính giá trị duy nhất - type_name . 3 từ điển được sử dụng là model từ điển. Cái này sẽ chứa danh sách tất cả các mô hình đã đến cửa của chúng tôi. Đối với mỗi mô hình, chúng tôi sẽ xác định kết hợp duy nhất model_name - make_id - vechicle_type_id .

Chúng tôi sẽ kết thúc việc mô tả lĩnh vực chủ đề này với vehicle bàn. Đây là bảng duy nhất trong chủ đề này có chứa dữ liệu "thực". Chúng tôi sẽ sử dụng bảng này để lưu trữ các chi tiết sau:

• vin - Số nhận dạng phương tiện, xác định duy nhất phương tiện này.
• license_plate - Biển số xe hiện tại.
• customer_id - Một tài liệu tham khảo cho khách hàng mà chiếc xe này thuộc về. Trong trường hợp xe thay đổi chủ sở hữu, chúng tôi sẽ ghi vào hồ sơ mới nhưng chúng tôi sẽ biết rằng đây là cùng một chiếc xe dựa trên số sê-ri.
• model_id - Tham chiếu đến từ điển mô hình.
• manufactured_year &manufactured_month - Biểu thị năm và tháng chiếc xe này được sản xuất.
• details - Tất cả các chi tiết bổ sung ở định dạng văn bản.
• insert_ts - Dấu thời gian biểu thị thời điểm khi bản ghi này được chèn vào bảng.

Phần 4:Dịch vụ và ưu đãi

Chúng tôi đã sẵn sàng thực hiện bước quan trọng tiếp theo. Chúng ta cần xác định những gì chúng ta cung cấp cho khách hàng (tiềm năng) của chúng ta. Đây có thể là các nhiệm vụ đơn lẻ hoặc một tập hợp các nhiệm vụ - dịch vụ.

Danh sách tất cả các dịch vụ được lưu trữ trong service_catalog từ điển. Mỗi dịch vụ bao gồm một số tác vụ và được xác định duy nhất bởi service_name của nó . Ngoài tên, chúng tôi cũng sẽ lưu trữ mô tả, nếu có, phần trăm service_discount và is_active lá cờ. Chiết khấu dịch vụ sẽ được sử dụng cho tất cả các nhiệm vụ có trong dịch vụ này.

Tiếp theo, chúng tôi sẽ xác định các nhiệm vụ. Nhiệm vụ là một phần của dịch vụ của chúng tôi. Chúng là hành động cơ bản có thể được thực hiện độc lập. Mỗi tác vụ được xác định bởi các giá trị này trong task_catalog bảng:

• task_name &service_catalog_id - Tên mà chúng tôi sẽ sử dụng để mô tả nhiệm vụ này và dịch vụ của nó. Cặp thuộc tính này tạo thành khóa duy nhất của bảng.
• description - Mô tả văn bản bổ sung, nếu có, được sử dụng để mô tả nhiệm vụ này.
• ref_interval - Một lá cờ biểu thị liệu chúng tôi có đo khoảng thời gian cho nhiệm vụ này hay không.
• ref_interval_min &ref_interval_max - Ranh giới nhỏ nhất và lớn nhất của phạm vi tham chiếu.
• description - Một cờ biểu thị liệu chúng ta có nên thêm nhận xét dạng văn bản cho nhiệm vụ này hay không.
• task_price - Giá hiện tại, không có chiết khấu dịch vụ, cho nhiệm vụ này.
• is_active - Một cờ biểu thị nhiệm vụ hiện đang hoạt động (trong ưu đãi của chúng tôi) hay không.

Sau khi tiếp xúc với khách hàng, chúng tôi sẽ cung cấp cho họ. Phiếu mua hàng có thể là một dịch vụ hoàn chỉnh, với tất cả các nhiệm vụ của nó hoặc một tập hợp các nhiệm vụ. Tất cả phiếu mua hàng được lưu trữ trong offer bàn. Đối với mỗi ưu đãi, chúng tôi sẽ lưu trữ:

• customer_id - Id của khách hàng có liên quan.
• contact_id - Một id của liên hệ liên quan, nếu có. Đây có thể là thông tin quan trọng để xác định số lượng phiếu mua hàng đến từ những lần liên hệ trước.
• offer_description - Mô tả bằng văn bản bổ sung về ưu đãi này.
• service_catalog_id - Một id của dịch vụ chúng tôi đã cung cấp cho khách hàng. Id này có thể là NULL trong trường hợp chúng tôi chưa cung cấp cho anh ấy một dịch vụ hoàn chỉnh, nhưng một hoặc nhiều nhiệm vụ không phải là một phần của dịch vụ.
• service_discount - Giảm giá dịch vụ tại thời điểm ưu đãi đã được tạo. Giá trị này phải chứa NULL trong trường hợp ưu đãi không liên quan đến dịch vụ.
• offer_price - Giá cuối cùng của ưu đãi đó. Nó có thể được tính bằng tổng của tất cả các nhiệm vụ trừ đi chiết khấu dịch vụ.
• insert_ts - Dấu thời gian biểu thị thời điểm khi bản ghi này được chèn vào bảng.

Bảng cuối cùng trong chủ đề này là offer_task bàn. Đối với mỗi ưu đãi, bất kể chúng tôi có cung cấp một dịch vụ hoàn chỉnh hay không, chúng tôi sẽ lưu trữ tập hợp tất cả các nhiệm vụ. Chúng tôi cần lưu trữ các chi tiết sau:

• offer_id - Id của phiếu mua hàng có liên quan.
• task_catalog_id - Một id của nhiệm vụ liên quan. Cùng với offer_id , nó tạo thành khóa duy nhất / thay thế của bảng này
• task_price - Giá hiện tại của nhiệm vụ đó tại thời điểm bản ghi này được chèn.
• insert_ts - Dấu thời gian biểu thị thời điểm khi bản ghi này được chèn vào bảng.

Phần 5:Lượt thăm

Khu vực chủ đề cuối cùng trong mô hình của chúng tôi được sử dụng để lưu trữ các chuyến thăm thực tế của khách hàng đến cửa hàng sửa chữa của chúng tôi. Mặc dù có vẻ phức tạp, chúng tôi chỉ có 2 bảng mới ở đây, visit và visit_task .

Khi khách hàng đồng ý với đề nghị của chúng tôi hoặc chỉ đến cửa hàng của chúng tôi, chúng tôi sẽ coi đó như một visit . Đối với mỗi sự kiện như vậy, chúng tôi sẽ lưu trữ các thông tin chi tiết sau:

• repair_shop_id - Một tài liệu tham khảo về cửa hàng sửa chữa liên quan.
• customer_id - Tham chiếu đến khách hàng mà chuyến thăm này có liên quan đến.
• vehicle_id - Tham chiếu đến chiếc xe mà chuyến thăm này có liên quan.
• visit_start_date - Ngày bắt đầu chuyến thăm (dự kiến).
• visit_start_time - Thời gian bắt đầu chuyến thăm (dự kiến).
• visit_end_date - Ngày bắt đầu chuyến thăm (thực tế). Giá trị này sẽ được đặt khi lượt truy cập thực sự kết thúc.
• visit_end_time - Thời gian bắt đầu chuyến thăm (thực tế). Giá trị này sẽ được đặt khi lượt truy cập thực sự kết thúc.
• license_plate - Một biển số xe tại thời điểm chuyến thăm đã xảy ra. Lưu ý rằng biển số xe sẽ thay đổi theo thời gian.
• offer_id - Id của phiếu mua hàng liên quan, nếu có.
• service_catalog_id - Id của dịch vụ liên quan, nếu có.
• service_discount - Phần trăm chiết khấu tại thời điểm này đã được thêm vào hồ sơ này và trong trường hợp chúng tôi cung cấp một dịch vụ hoàn chỉnh.
• visit_price - Tổng giá mà khách hàng phải trả cho lượt truy cập đó.
• invoice_created - Dấu thời gian khi hóa đơn được tạo.
• invoice_due - Dấu thời gian khi hóa đơn đến hạn thanh toán.
• invoice_charged - Dấu thời gian khi hóa đơn được tính phí.
• insert_ts - Dấu thời gian biểu thị thời điểm khi bản ghi này được chèn vào bảng.

Bảng cuối cùng trong mô hình của chúng tôi là visit_task bàn. Đây là nơi lưu trữ tất cả các nhiệm vụ thực sự là một phần của chuyến thăm đó. Đối với mỗi bản ghi ở đây, chúng tôi sẽ lưu trữ các giá trị sau:

• visit_id - Tham chiếu đến chuyến thăm đó.
• task_catalog_id - Tham chiếu đến nhiệm vụ liên quan
• value_measured - Giá trị được đo trong nhiệm vụ này, nếu nhiệm vụ yêu cầu đo lường.
• task_description - Mô tả liên quan đến nhiệm vụ đó nếu nhiệm vụ yêu cầu mô tả.
• pass - Một cờ cho biết liệu nhiệm vụ này có nằm trong khoảng thời gian dự kiến ​​hay không.
• task_price - Giá thực tế của nhiệm vụ đó tại thời điểm được chèn vào bảng này.
• insert_ts - Dấu thời gian biểu thị thời điểm khi bản ghi này được chèn vào bảng.

Mặc dù mô hình này khá đơn giản nhưng nó chứa tất cả các yếu tố cần thiết mà bạn cần để xây dựng một mô hình hoàn chỉnh xung quanh nó. Các bộ phận yêu cầu cải tiến chắc chắn là vật liệu được sử dụng và xử lý thanh toán. Bạn có thể bổ sung thêm thứ gì đó cho mô hình này không?