Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Mô hình Cơ sở dữ liệu cho Hệ thống Đặt chỗ của Trường Lái xe. Phần 1

Tôi cần thiết kế một mô hình dữ liệu cho hệ thống đặt chỗ cho một trường dạy lái xe. Lĩnh vực chủ đề trông khá đơn giản, nhưng sự phức tạp vẫn liên quan. Bạn phải theo dõi tất cả các yêu cầu từ khách hàng và theo dõi các nguồn lực (phương tiện, thời gian và người hướng dẫn) được sử dụng trong các bài học.

Giới thiệu

Tôi muốn sử dụng phương pháp tiếp cận theo hướng miền để thiết kế một mô hình dữ liệu. Nó khiến tôi gạt nỗi ám ảnh về công nghệ sang một bên và tập trung chủ yếu vào việc lập mô hình chủ đề xoay quanh các thực thể liên quan và mối quan hệ giữa chúng.

Yêu cầu trong Tóm tắt

Trước tiên, hãy để tôi đặt ra yêu cầu bằng tiếng Anh đơn giản trước.

Tôi cần mô hình dữ liệu cho trường dạy lái xe để cho phép khách hàng để thực hiện đặt chỗ cho bài học Trực tuyến. Trường dạy lái xe có thể có nhiều người hướng dẫn và nhiều hơn một phương tiện . Người hướng dẫn được chỉ định cho bài học khi đặt trước. Hệ thống sẽ cho phép khách hàng hủy đặt chỗ bất kỳ lúc nào trước ngày đã định. Phương tiện được chỉ định cho bài học cũng nên được ghi lại nếu bài học diễn ra.

Các thực thể và các mối quan hệ có liên quan

Khi tôi nghĩ về chủ đề này, đối tượng xuất hiện đầu tiên trong tâm trí tôi là “Khách hàng” , “Người hướng dẫn” , “Bài học lái xe” , “Yêu cầu đặt chỗ trước” “Phương tiện” . Hãy để tôi bắt đầu với bảng đầu tiên của tôi cho mô hình này và đó là customer . Nó là để lưu trữ dữ liệu chủ cho khách hàng. Tôi có thể cần một bảng khác để lưu trữ thông tin chi tiết về Người hướng dẫn, nhưng thay vì tạo một bảng có tên của người hướng dẫn, tôi sẽ tạo một bảng chung có tên là staff để biết thông tin chi tiết về nhân viên và giữ "Người hướng dẫn" như một chức danh công việc. Nó sẽ làm cho mô hình dữ liệu của tôi có thể mở rộng để phục vụ cho các lĩnh vực dịch vụ khác, như công việc hành chính và pháp lý, của một trường dạy lái xe.

Tôi coi là “khóa học lái xe” là một trong các dịch vụ, do đó tôi tạo một bảng khác có tên service . Một dịch vụ, “khóa học lái xe” trong trường hợp này, có thể có nhiều bài học. Để xử lý yêu cầu này, tôi chắc chắn cần một bảng chính khác, cụ thể là lesson và một bảng quan hệ, cụ thể là service_lesson , để quản lý nhiều mối quan hệ giữa cả hai thực thể chính này, tức là một dịch vụ chắc chắn có thể có nhiều bài học, nhưng mặt khác, một bài học cũng có thể là một phần của nhiều dịch vụ.

Khi một người gửi yêu cầu đặt chỗ, họ sẽ được yêu cầu điền thông tin chi tiết và sở thích sơ bộ của họ như loại dịch vụ mà họ muốn, lựa chọn phương tiện và ngày bắt đầu. Thông tin chi tiết của khách hàng được lưu trữ trong bảng khách hàng. Sau đó, một yêu cầu được tạo trong request bảng và tất cả các tùy chọn được lưu trữ theo yêu cầu trong cùng một bảng. Có một số trạng thái nhất định được liên kết với mỗi yêu cầu, như “gửi”, “đang xử lý”, “hủy” và “hoàn thành”. Tôi sẽ tạo một bảng hỗ trợ cho nó có tên là request_status .

Tại thời điểm gửi yêu cầu, người ta đặt một ưu tiên cho phương tiện, tức là loại phương tiện. Tuy nhiên, chiếc xe thực sự sẽ được giao cho một bài học khi nó diễn ra. Do đó, tôi giữ lại vehicle_type_id là một trong các cột trong request bây giờ.

Khi một yêu cầu được xử lý, việc đặt chỗ được thực hiện cho mỗi bài học của yêu cầu dịch vụ. Ngoài ra, giáo viên hướng dẫn và phương tiện đi lại được chỉ định cho mỗi buổi học dựa trên sự sẵn có của giáo viên hướng dẫn và sở thích của khách hàng đối với phương tiện đi lại. Các bài học được lên lịch cho các ngày trong tương lai với trạng thái “Đang mở”. Tất cả những chi tiết này được ghi lại trong một bảng giao dịch khác được gọi là reservation . Tôi đã đánh dấu tất cả các bảng giao dịch bằng màu khác với tất cả các bảng chính.

Một bảng chính, reservation_status , được tạo ra để lưu trữ tất cả các giá trị có thể có cho các trạng thái đặt chỗ như “mở”, “đang xử lý”, “hủy” và “hoàn tất”.

Mô hình này cho phép khách hàng hủy một bài học cá nhân cũng như toàn bộ yêu cầu dịch vụ. Nếu khách hàng hủy yêu cầu dịch vụ, thì tất cả các bài học còn lại, đã được lên lịch cho khách hàng, sẽ bị hủy trong bảng đặt chỗ.

Vui lòng tham khảo mô hình dữ liệu do tôi tạo bằng Vertabelo để biết chi tiết mức cột của tất cả các bảng này. Một số điểm liên quan đến việc tạo cột:

  • Cột cờ có tên is_active được thêm vào tất cả các bảng chính để cho phép xóa mềm các bản ghi. Vì vậy, ví dụ:nếu bất kỳ giảng viên nào rời trường, chúng tôi sẽ lật cờ sang “N” để khiến hồ sơ của họ không hoạt động.
  • Một số cột nhất định như created_date , created_by , last_modified_datelast_modified_by được thêm vào trong tất cả các bảng giao dịch để cho phép kiểm tra theo dõi các thay đổi trong hồ sơ. Các bảng giao dịch được đánh dấu bằng màu xanh lam trong mô hình dữ liệu được tạo trong Vertabelo.
  • Bạn có thể thắc mắc address_id là gì trong cột staff bảng dành cho. Tôi đã cố tình đặt cột này trong staff để tôi có thể mở rộng mô hình dữ liệu của mình để hỗ trợ quy trình tự động để chỉ định người hướng dẫn cho một yêu cầu dựa trên vị trí của họ. Ví dụ:giả sử ở Thành phố New York, có yêu cầu từ White Plains. Hệ thống của tôi trước tiên nên tìm kiếm một người hướng dẫn có sẵn trong cùng hoặc vùng lân cận gần nhất. Hệ thống của tôi sẽ không bao giờ chỉ định một người hướng dẫn ở Manhattan, nơi cách nơi ở của người yêu cầu gần 50 dặm.

Các tính năng nổi bật của mô hình này

  • Mô hình này cho phép khách hàng đưa ra các yêu cầu đặt chỗ theo sở thích của họ về ngày bắt đầu và chuyến xe.
  • Nó cho phép họ hủy một hoặc nhiều bài học trong khóa học của họ hoặc toàn bộ khóa học.
  • Mô hình này ghi lại thông tin chi tiết về người hướng dẫn và phương tiện cho mỗi bài học.
  • Mô hình này có thể mở rộng để xử lý tất cả các dịch vụ có thể có do trường dạy lái xe cung cấp.
  • Nó cho phép chúng tôi thiết kế các khóa đào tạo và lên kế hoạch cho các bài học một cách hiệu quả.

Mô hình cơ sở dữ liệu

Đây là thiết kế cơ sở dữ liệu cho hệ thống đặt phòng của chúng tôi. Mô hình được tạo trong Vertabelo cho cơ sở dữ liệu Oracle nhưng thiết kế tương tự có thể được triển khai cho các công cụ cơ sở dữ liệu khác mà không có thay đổi đáng kể.




Kết luận

Có một số lĩnh vực chủ đề nhất định mà chúng tôi không đề cập trong bài viết này, chẳng hạn như:

  • Chúng ta có thể xây dựng một phương pháp tiếp cận tự động để phân bổ phương tiện và người hướng dẫn cho các bài học không?
  • Làm thế nào về việc lập hóa đơn cho khách hàng? Điều gì sẽ xảy ra nếu một khách hàng không muốn trả tiền cho toàn bộ khóa học nhưng cho một vài bài học của nó? Chúng ta có thể cung cấp những bài học này cho anh ấy không?

Mô hình hiện tại của chúng tôi có hỗ trợ các tính năng như vậy không? Câu trả lời là không. Tôi có thể sẽ đề cập đến các lĩnh vực chủ đề này trong bài viết tiếp theo của tôi.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Di chuyển dữ liệu

  2. Mô hình Cơ sở dữ liệu cho Khảo sát Trực tuyến. Phần 4

  3. Sửa đổi dữ liệu trong phần Cách ly ảnh chụp nhanh đã cam kết đọc

  4. Di chuyển dữ liệu bằng Network_link

  5. SAP Lumira và Cầu JDBC-ODBC