Kiếm tiền với Nội dung không sử dụng:Mô hình Dữ liệu Nền kinh tế Chia sẻ

Không có nhiều khả năng bạn đã bỏ lỡ toàn bộ ý tưởng về nền kinh tế chia sẻ - cho dù bạn có muốn hay không. Phổ biến bởi các công ty như Airbnb, Uber, Lyft và nhiều công ty khác, nó cho phép mọi người kiếm một số tiền mặt bằng cách cho thuê những thứ không sử dụng của họ. Hãy xem mô hình dữ liệu đằng sau một ứng dụng như vậy.

Có một phòng trống? Đăng ký với Airbnb và kiếm thêm tiền khi thuê nó. Có một chiếc xe hơi và một số thời gian rảnh rỗi? Trở thành tài xế Uber. Và nó diễn ra - ý tưởng đằng sau những công ty này và nhiều công ty khác gần như giống nhau. Đó là tất cả về việc chia sẻ tài nguyên với (hầu hết) người lạ, với đặc quyền cho cả hai bên. Chủ sở hữu nhận được tiền cho tài sản không sử dụng của họ, trong khi khách hàng thường nhận được một thỏa thuận tốt; đây sẽ là một tình huống đôi bên cùng có lợi.

Tất nhiên, chúng tôi cần một nền tảng để kết nối chủ sở hữu với khách hàng và theo dõi các chi tiết quan trọng. Hôm nay, chúng tôi sẽ trình bày một mô hình dữ liệu có thể quản lý nhiệm vụ. Ngồi xuống ghế và tận hưởng chuyến đi thông qua mô hình dữ liệu nền kinh tế chia sẻ.

Chúng ta cần gì trong Mô hình dữ liệu của mình?

Ý tưởng cho thuê tài sản khi chúng tôi không sử dụng có vẻ rất khôn ngoan. Thứ nhất, tài sản được sử dụng đúng mục đích của nó; thứ hai, việc cho thuê sẽ tạo ra một số loại thu nhập bổ sung. Đó có thể là tiền mặt, nhưng cũng có thể là một cuộc trao đổi (ví dụ:ai đó ở New York đổi căn hộ với ai đó ở Paris trong một tuần).

Các mô hình không dùng tiền mặt thực sự tuyệt vời và chúng thường phụ thuộc vào sự hiểu biết lẫn nhau, thiện chí và trung thực. Tuy nhiên, bài viết này sẽ tập trung vào các mô hình nền kinh tế chia sẻ yêu cầu thanh toán. Nó không lãng mạn như mô hình không dùng tiền mặt, nhưng mô hình thanh toán khá hiệu quả.

Chúng ta cần một cách rất đơn giản để một số lượng lớn các chủ sở hữu bất động sản có thể tiếp cận một lượng lớn khách hàng quan tâm và ngược lại. Đây là yêu cầu đầu tiên đối với mô hình dữ liệu của chúng tôi. Chúng tôi sẽ có tài khoản người dùng và ít nhất hai vai trò riêng biệt - chủ sở hữu và khách hàng.

Điều tiếp theo chúng ta cần là ứng dụng của mình liệt kê tất cả các thuộc tính có sẵn. Đối với Airbnb, đây sẽ là những căn hộ; đối với Uber, đây sẽ là ô tô. Bài viết này sẽ tập trung nhiều hơn vào việc cho thuê căn hộ (mô hình dữ liệu giống như Airbnb) nhưng tôi sẽ giữ cho mô hình đủ chung để có thể dễ dàng chuyển đổi mô hình này sang bất kỳ dịch vụ nền kinh tế chia sẻ nào khác.

Đối với mỗi chủ sở hữu sản phẩm, chúng tôi sẽ cần xác định vị trí nơi họ hoạt động. Đối với căn hộ, điều này là khá rõ ràng (thành phố nơi căn hộ nằm). Đối với dịch vụ vận chuyển, điều này sẽ phụ thuộc vào vị trí hiện tại của ô tô và / hoặc chủ sở hữu của nó.

Đối với mỗi thuộc tính hoặc tài nguyên, chúng tôi sẽ cần theo dõi thời gian sử dụng và yêu cầu / đặt chỗ. Điều này sẽ cho phép chúng tôi tìm các tài sản có sẵn khi có yêu cầu mới và tính toán tỷ lệ lấp đầy và giá cả. Chúng tôi cũng sẽ có thể sử dụng các chương trình khác để phân tích dữ liệu này và đưa ra các số liệu thống kê khác.

Mô hình dữ liệu

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

• Quốc gia và thành phố
• Người dùng và vai trò
• Dịch vụ &tài liệu
• Yêu cầu
• Dịch vụ được cung cấp

Chúng tôi sẽ trình bày từng lĩnh vực chủ đề theo thứ tự được liệt kê.

Phần 1:Quốc gia và thành phố

Chúng ta sẽ bắt đầu với Quốc gia và thành phố môn học. Mặc dù không cụ thể cho mô hình dữ liệu này, nhưng các bảng này rất quan trọng. Các dịch vụ liên quan đến tài sản thường được định hướng theo địa lý. Mô hình của chúng tôi có liên quan chặt chẽ đến việc thuê một số loại nhà ở, vì vậy vị trí thực tế là rất quan trọng ở đây. Tất nhiên, vị trí đó thường không thay đổi. Có một số trường hợp rất đặc biệt có thể dẫn đến việc thay đổi vị trí của bất động sản, nhưng tôi sẽ coi việc ở tại vị trí mới đó là một bất động sản hoàn toàn mới.

Đối với các ứng dụng đặt xe và / hoặc tài xế như Uber, vị trí hiện tại của xe và tài xế cũng rất quan trọng. Không giống như cho thuê căn hộ kiểu Airbnb, những vị trí bất động sản này có thể thay đổi thường xuyên.

quốc gia bảng chứa danh sách các tên DUY NHẤT của các quốc gia nơi chúng tôi hoạt động. thành phố bảng chứa danh sách tất cả các thành phố nơi chúng tôi hoạt động. Sự kết hợp DUY NHẤT cho bảng này là sự kết hợp của Postal_code , city_name và country_id thuộc tính.

Cả hai bảng này đều có thể chứa nhiều thuộc tính bổ sung, nhưng tôi đã cố ý bỏ qua chúng vì chúng sẽ không thêm bất kỳ giá trị nào vào mô hình này.

Phần 2:Người dùng và vai trò

Điều tiếp theo chúng ta cần làm là xác định người dùng và hành vi hoặc vai trò của họ trong ứng dụng của chúng ta. Để làm điều này, chúng tôi sẽ sử dụng ba bảng trong Người dùng &vai trò lĩnh vực chủ đề.

Danh sách tất cả người dùng có trong user_account bàn. Đối với mỗi người dùng, chúng tôi sẽ lưu trữ các thông tin chi tiết sau:

• user_name - Tên DUY NHẤT mà người dùng đã chọn để truy cập ứng dụng của chúng tôi.
• mật khẩu - Giá trị băm của mật khẩu do người dùng chọn.
• first_name và last_name - Họ và tên của người dùng.
• city_id - Tham chiếu đến thành phố nơi người dùng thường ở.
• current_city_id - Tham chiếu đến thành phố người dùng hiện đang ở đâu.
• email - Địa chỉ email của người dùng.
• time_inserted - Dấu thời gian khi bản ghi này được chèn vào bảng.
• Confirm_code - Mã được tạo trong quá trình đăng ký để xác nhận địa chỉ email của người dùng.
• time_conf Dead - Dấu thời gian khi địa chỉ email được xác nhận. Thuộc tính này chứa giá trị NULL cho đến khi thông qua xác nhận.

Người dùng sẽ có các quyền khác nhau trong ứng dụng tùy theo vai trò của họ. Cũng có thể một người dùng có thể có nhiều vai trò hoạt động cùng một lúc, ví dụ:họ có thể là chủ sở hữu của một tài sản và khách hàng của tài sản khác. Trong trường hợp đó, người dùng sẽ sử dụng các chi tiết đăng nhập giống nhau và sẽ có tùy chọn để chuyển đổi giữa các vai trò. Mỗi vai trò sẽ có màn hình riêng trong ứng dụng.

Danh sách tất cả các vai trò có thể có được lưu trữ trong role từ điển. Mỗi vai trò được định nghĩa BẤT NGỜ bởi role_name của nó . Vì đơn giản, chúng ta có thể mong đợi chỉ có hai vai trò:“chủ sở hữu tài sản” và “khách hàng”.

Một người dùng có thể có cùng một vai trò được chỉ định nhiều lần trong các khoảng thời gian khác nhau. Một trường hợp như vậy sẽ là nếu người dùng đang thuê căn hộ chưa sử dụng của họ và sau đó quyết định không thuê căn hộ của họ vì họ cần nó. Tuy nhiên, sau một vài tháng, cùng một người sử dụng đã quyết định thuê lại căn hộ của họ. Trong trường hợp này, chúng tôi sẽ hủy kích hoạt vai trò của họ và sau đó kích hoạt lại vai trò đó.

Danh sách tất cả các vai trò đã từng được chỉ định cho người dùng được lưu trữ trong has_role bàn. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ:

• user_account_id - ID của người dùng có liên quan .
• role_id - ID của role có liên quan .
• time_from - Dấu thời gian khi vai trò này được chèn vào hệ thống.
• time_to - Dấu thời gian khi vai trò này bị vô hiệu hóa. Điều này sẽ chứa giá trị NULL miễn là vai trò vẫn hoạt động.
• is_active - Được đặt thành Sai khi vai trò bị vô hiệu hóa vì bất kỳ lý do gì.

Khi chèn một bản ghi mới trong bảng này, chúng ta nên kiểm tra các bản ghi chồng chéo. Điều này cho phép chúng tôi tránh làm cho cùng một vai trò có hiệu lực hai lần trong cùng một khoảng thời gian.

Phần 3:Dịch vụ và Tài liệu

Điều tiếp theo chúng ta cần xác định là các dịch vụ được cung cấp bởi người dùng. Chúng tôi cũng sẽ cần theo dõi mọi tài liệu liên quan. Để làm điều đó, chúng tôi sẽ cần các bảng trong Dịch vụ &tài liệu lĩnh vực chủ đề.

Hãy bắt đầu với thuộc tính bàn. Tài sản là bất kỳ đối tượng nào của dịch vụ của chúng tôi:nhà ở, ô tô, xe đạp, v.v. Chúng tôi có thể mong đợi rằng người dùng sẽ tự chăm sóc tài sản của họ. Đối với mỗi thuộc tính, chúng tôi sẽ cần xác định:

• property_name - Tên màn hình cho thuộc tính đó, do người dùng chọn. Tên này được sử dụng khi hiển thị thuộc tính cho khách hàng tiềm năng trên ứng dụng. Nó phải ngắn gọn, mang tính mô tả và đặt thuộc tính đó ngoài các thuộc tính khác.
• property_description - Văn bản miêu tả bổ sung ở dạng không có cấu trúc. Chúng ta có thể mong đợi một loạt các thông tin chi tiết ở đây - về cơ bản là mọi thứ từ kích thước của căn hộ đến việc liệu khách hàng có nhận được đồ uống chào đón khi họ đến hay không. Đồ uống chào mừng trong các dịch vụ vận chuyển ít xảy ra hơn nhiều.
• active_from và active_to - Khoảng thời gian mà thuộc tính đó hoạt động trong hệ thống của chúng tôi. active_to thuộc tính sẽ chứa giá trị NULL cho đến khi thuộc tính này bị hủy kích hoạt.
• is_available - Một cờ biểu thị liệu thuộc tính này có khả dụng tại một thời điểm cụ thể hay không.
• is_active - Cờ biểu thị nếu thuộc tính đó vẫn còn hoạt động trong hệ thống của chúng tôi. Giá trị của thuộc tính này sẽ được đặt thành Sai tại cùng thời điểm active_to đã được thiết lập.

Bây giờ chúng tôi sẽ chuyển sang dịch vụ từ điển. Đây là nơi chúng tôi sẽ xác định tất cả các loại dịch vụ có thể có, như “thuê dài hạn”, “thuê ngắn hạn”, “vận chuyển”, v.v. Nó chứa tên DUY NHẤT của loại dịch vụ và một mô tả bổ sung , nếu cần.