Mô hình dữ liệu vận tải tích hợp

Giao thông tổng hợp là thứ mà chúng ta thường nghe trên internet hoặc trên tin tức. Mặc dù đây không phải là điều gì đó mới mẻ, nhưng chắc chắn đó là một quá trình liên tục, với những thay đổi liên tục được thực hiện. Hôm nay, chúng ta sẽ xem xét một mô hình dữ liệu có thể xử lý thông tin về khu vực, hành khách và vé.

Hãy cùng tìm hiểu kỹ về mô hình dữ liệu vận tải tích hợp của chúng tôi, bắt đầu với ý tưởng đằng sau tất cả.

Ý tưởng

Việc tích hợp giao thông vận tải là cần thiết để tối đa hóa hiệu quả của nó và đối với khách hàng, việc sử dụng nó dễ dàng. Tích hợp liên quan đến chi phí mà còn liên quan đến thời gian, khả năng tiếp cận, sự thoải mái và an toàn. Điều này áp dụng cho các thành phố lớn hơn cũng như các thành phố nhỏ hơn. Ý tưởng là sử dụng cơ sở hạ tầng giao thông hiện có và tối ưu hóa nó để có kết quả tốt hơn; điều này có nghĩa là đưa ra lịch trình, thông báo, đường dây hoặc đài mới. Có thể chỉ cần có một số thông tin là đủ để bạn quyết định đợi xe buýt, thuê xe đạp hoặc đơn giản là đi bộ đến điểm đến của bạn.

Hãy giải thích điều này bằng hai ví dụ.

Trong trường hợp ở một thành phố lớn, thường có nhiều phương tiện giao thông khác nhau:xe buýt, taxi, tàu điện, đường sắt, tàu điện ngầm, ... Điều này có thể dẫn đến nhiều công ty tư nhân khác nhau cung cấp các dịch vụ vận tải khác nhau. Việc kết hợp thậm chí một số dịch vụ này chắc chắn sẽ mang lại lợi ích cho hành khách và công ty bằng cách giảm chi phí, nâng cao hiệu quả và cung cấp nhiều dịch vụ hơn cho mỗi vé.

Cũng có những lợi ích tương tự đối với một thành phố nhỏ hơn. Có thể không có cùng một số tùy chọn để kết hợp, nhưng chúng có thể được sắp xếp để đạt được hiệu quả tối đa.

Bài viết này sẽ chủ yếu tập trung vào các hệ thống bán vé giao thông tích hợp. Chúng tôi sẽ không tập trung vào tất cả các khía cạnh của tích hợp và các loại hình vận tải khác nhau; điều đó sẽ quá phức tạp.

Với ý nghĩ này, hãy chuyển sang mô hình của chúng tôi.

Mô hình dữ liệu

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

• Cities & companies
• Tickets

Chúng tôi sẽ mô tả chúng theo thứ tự được liệt kê.

Thành phố và Công ty

Trong chủ đề đầu tiên, chúng tôi sẽ lưu trữ tất cả các bảng cần thiết để thiết lập các khu vực giao thông ở các thành phố.

country bảng chứa danh sách country_name DUY NHẤT các giá trị. Bảng này chỉ được sử dụng làm tài liệu tham khảo trong city bàn. Mặc dù chúng tôi có thể mong đợi rằng mô hình của chúng tôi sẽ chỉ bao gồm giao thông vận tải ở một quốc gia, nhưng chúng tôi muốn có tùy chọn bao gồm nhiều quốc gia. Đối với mỗi thành phố, chúng tôi sẽ lưu trữ kết hợp DUY NHẤT city_name - country_id .

Các thành phố nhỏ hơn có thể sẽ chỉ có một khu vực, trong khi các thành phố lớn hơn sẽ có nhiều khu vực. Danh sách tất cả các khu vực có thể có được lưu trữ trong zone bàn. Đối với mỗi vùng, chúng tôi sẽ lưu trữ zone_name của nó và một tham chiếu đến thành phố có liên quan. Cặp này tạo thành khóa thay thế của bảng này.

Chúng tôi có thể mong đợi rằng hệ thống của chúng tôi sẽ lưu trữ thông tin về nhiều công ty vận tải. Các công ty sẽ phát hành vé của riêng họ, nhưng họ cũng có thể phát hành vé chung với các công ty khác. Đối với mỗi company , chúng tôi sẽ lưu trữ sự kết hợp DUY NHẤT của company_name và city_id nó nằm ở đâu. Mọi thông tin bổ sung cần thiết có thể được lưu trữ trong details dạng văn bản trường.

Điều cuối cùng chúng ta cần xác định là hình thức vận chuyển mà mỗi công ty cung cấp. Một số giá trị mong đợi là “xe buýt”, “xe điện”, “tàu điện ngầm” và “đường sắt”. Đối với mỗi giá trị trong transport_form bảng, chúng tôi sẽ lưu trữ form_name DUY NHẤT.

• zone_id - Tham chiếu đến zone và biểu thị khu vực mà công ty này cung cấp hình thức vận chuyển này.
• company_id - Tham khảo company cung cấp dịch vụ này trong khu vực này.
• transport_form_id - Tham chiếu transport_form và biểu thị loại dịch vụ được cung cấp.
• date_from và date_to - Khoảng thời gian mà công ty này cung cấp dịch vụ này. Lưu ý rằng date_to có thể chứa giá trị NULL nếu dịch vụ này vẫn khả dụng và / hoặc không có ngày hết hạn dự kiến.
• details - Tất cả các chi tiết khác, ở định dạng văn bản phi cấu trúc.
• is_active - Nếu dịch vụ này đang hoạt động (đang diễn ra) hay không. Đây là một nút bật / tắt đơn giản mà chúng tôi có thể sử dụng trong một số trường hợp thay vì date_from - date_to khoảng thời gian hoạt động dịch vụ. Cách sử dụng tốt nhất của thuộc tính này là để đơn giản hóa các truy vấn, tức là bằng cách thử nghiệm giá trị này thay vì thử nghiệm khoảng ngày và "chơi" với giá trị NULL.

Vé

Môn học trước đây chỉ là chuẩn bị cho thứ chính:vé. Và đó là nội dung mà chủ đề này sẽ đề cập.

Chúng tôi đã xác định các công ty, khu vực và hình thức vận chuyển, nhưng chúng tôi không có bất kỳ điều khoản nào cho hành khách và vé - cốt lõi của mô hình này. Chúng tôi sẽ giả định rằng một vé có thể được sử dụng cho một hoặc nhiều khu vực do một hoặc nhiều công ty chi trả.

Do đó, trước tiên chúng ta cần xác định từng ticket_type . Trong bảng này, chúng tôi sẽ liệt kê tất cả các loại vé có thể được bán bởi các công ty trong cơ sở dữ liệu của chúng tôi. Đối với mỗi loại, chúng tôi sẽ lưu trữ các giá trị sau:

• type_name - Một cái tên BẤT NGỜ biểu thị loại này.
• valid_from và valid_to - Khoảng thời gian loại vé này còn hiệu lực (hoặc còn hiệu lực). Cả hai trường đều có giá trị rỗng; giá trị NULL có nghĩa là không có ngày bắt đầu (hoặc kết thúc) cho thời điểm giá trị này hợp lệ.
• details - Mọi chi tiết cần thiết, ở định dạng văn bản phi cấu trúc.
• recurring - Cờ biểu thị loại vé này có lặp lại (ví dụ:hàng năm, hàng tháng) hay không.
• interval_month - Nếu loại vé là định kỳ, thuộc tính này sẽ chứa khoảng thời gian lặp lại, tính bằng tháng (ví dụ:“1” đối với vé tháng, “12” đối với vé năm).

Bây giờ chúng tôi đã sẵn sàng để xác định các khu vực được bao phủ bởi từng loại vé. Trong service_included bảng, chúng tôi sẽ chỉ lưu trữ cặp DUY NHẤT ticket_type_id - service_available_id . Sau đó cũng sẽ cho biết công ty và khu vực có thể sử dụng vé này. Bảng này cho phép chúng tôi xác định nhiều khu vực trên mỗi vé; các khu vực có thể thuộc về các công ty khác nhau. Vì đây là những loại vé được xác định trước nên mỗi loại vé sẽ có các khu vực được xác định ở đây (không dành cho từng hành khách).

Chúng tôi sẽ không lưu trữ quá nhiều thông tin chi tiết về hành khách trong mô hình này. Đối với mỗi passenger , chúng tôi sẽ chỉ lưu trữ first_name của họ , last_name , address , và một tham chiếu đến thành phố nơi họ sống. Tất cả dữ liệu này sẽ được hiển thị trên vé.

Bảng cuối cùng trong mô hình của chúng tôi là ticket bàn. Chúng tôi sẽ không tập trung vào vé sử dụng một lần ở đây; thay vào đó, chúng tôi sẽ xử lý các vé đăng ký và trả trước. Những vé này sẽ có số dư, ngày hiệu lực hoặc cả hai. Điều này có thể khác biệt đáng kể, dựa trên công ty và các quy tắc của nó. Nếu một số công ty quyết định phát hành vé, chúng tôi có thể hỗ trợ điều đó trong bảng này - chúng tôi sẽ biết tất cả các chi tiết quan trọng. Đối với mỗi vé, chúng tôi sẽ lưu trữ:

• serial_number - Chỉ định DUY NHẤT cho mỗi vé. Đây có thể là sự kết hợp của số và chữ cái.
• ticket_type_id - Tham khảo loại vé đó.
• passenger_id - Giới thiệu hành khách, nếu có, ai sở hữu vé đó. Trong trường hợp vé trả trước, không thể có chủ sở hữu.
• valid_from và valid_to - Biểu thị khoảng thời gian vé này có giá trị. Giá trị NULL biểu thị không có ranh giới dưới hoặc ranh giới trên.
• credits - Các khoản tín dụng (dưới dạng giá trị số) hiện có trên vé đó. Nếu đó là vé trả trước, chúng tôi có thể giả định rằng hành khách sẽ mua thêm tín dụng trên vé. Nếu vé có giá trị trong cả tháng (hoặc một số khoảng thời gian khác) mà không có bất kỳ giới hạn sử dụng nào, giá trị này có thể là NULL.

Các cải tiến đối với Mô hình Dữ liệu Vận tải Tích hợp

Bạn có thể nhận thấy rằng mô hình này đã được đơn giản hóa rất nhiều. Đó là bởi vì vận tải tích hợp đơn giản là quá lớn để có thể được đề cập trong một bài báo. Có một số điều mà tôi nghĩ có thể được thay đổi trong mô hình này:

• Các vùng quá đơn giản hóa; chúng ta sẽ có thể xác định chúng linh hoạt hơn.
• Chúng tôi không bao gồm các tuyến (ví dụ:tuyến xe buýt). Điều gì sẽ xảy ra nếu họ đi từ khu vực này sang khu vực khác, v.v.?
• Chúng tôi không lưu trữ lịch sử sử dụng vé.
• Không có đăng ký cho các công ty và hành khách.

Tất cả những điều này sẽ dẫn đến thực tế là chúng tôi thiếu dữ liệu quan trọng và không thể thực hiện bất kỳ phân tích sâu hơn nào. Vậy bạn nghĩ như thế nào? Mô hình này cần những gì? Bạn sẽ thêm hoặc bớt những gì? Chia sẻ ý tưởng của bạn trong phần bình luận.