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

Mô hình dữ liệu nhà thông minh

Những ngôi nhà thông minh đã từng là nghiêm ngặt trong tương lai; bây giờ chúng là một thực tế. Hầu hết chúng ta đã nghe nói về chúng, nhưng chúng không phổ biến rộng rãi như chúng sẽ xuất hiện trong tương lai gần. Quản lý ngôi nhà của bạn theo cách ‘thông minh’ chắc chắn sẽ tạo ra rất nhiều dữ liệu. Hôm nay, chúng tôi sẽ phân tích một mô hình dữ liệu mà chúng tôi có thể sử dụng để lưu trữ dữ liệu nhà thông minh.

Mô hình dữ liệu

Khi nghĩ đến nhà thông minh, có lẽ bạn sẽ nghĩ đến việc khóa và mở khóa nhà từ xa, kích hoạt báo thức, đèn hoặc camera từ điện thoại, có nhiệt kế tự động quản lý hệ thống sưởi và làm mát, v.v. Nhưng nhà thông minh còn có thể làm được nhiều hơn thế. Bạn có thể kết nối một số thiết bị thông minh và bộ điều khiển để đạt được nhiều chức năng phức tạp. Bạn có thể gửi hướng dẫn đến các thiết bị hoặc đọc trạng thái của chúng từ mọi lúc mọi nơi.

Hãy cùng xem mô hình dữ liệu cho phép chúng tôi triển khai các chức năng như vậy. Trên mô hình dữ liệu đó, chúng tôi có thể tạo ứng dụng web và ứng dụng di động cho phép người dùng đã đăng ký quản lý tài khoản của họ, gửi hướng dẫn và theo dõi trạng thái.




Mô hình bao gồm ba lĩnh vực chủ đề:

  • Estates & devices
  • Users & profiles
  • Commands & data

Tôi sẽ mô tả từng lĩnh vực chủ đề này theo thứ tự chúng được liệt kê. Tuy nhiên, trước bất kỳ điều gì khác, tôi sẽ mô tả user_account bảng.

Bảng User_Account

Chúng tôi đang bắt đầu với user_account vì nó được sử dụng trong cả ba lĩnh vực chủ đề. Nó lưu trữ danh sách tất cả những người dùng đã đăng ký ứng dụng của chúng tôi.

user_account bảng chứa tất cả các thuộc tính tiêu chuẩn mà bạn mong đợi, bao gồm:

  • first_namelast_name - Họ và tên của người dùng.
  • user_name - Tên người dùng DUY NHẤT do người dùng chọn.
  • password - Giá trị băm của mật khẩu của người dùng.
  • email - Địa chỉ email do người dùng cung cấp trong quá trình đăng ký.
  • confirmation_code - Mã được tạo trong quá trình đăng ký.
  • confirmation_time - Dấu thời gian khi người dùng xác nhận tài khoản của họ và hoàn tất quá trình đăng ký.
  • ts - Dấu thời gian khi bản ghi này được chèn vào cơ sở dữ liệu.

Phần 1:Giá cả và thiết bị

Toàn bộ động lực đằng sau việc tạo cơ sở dữ liệu này là để theo dõi những gì đang xảy ra với các bất động sản của chúng ta (tức là nhà hoặc tài sản). Đây có thể là bất động sản tư nhân, như căn hộ hoặc nhà ở hoặc chúng có thể là tài sản kinh doanh, như văn phòng, nhà kho, v.v. Nếu chúng tôi thực sự muốn đẩy hệ thống của mình đến giới hạn, chúng tôi cũng có thể sử dụng nó cho xe cộ.

Bảng trung tâm trong lĩnh vực chủ đề này là real_estate bàn. Đây là nơi chúng tôi sẽ lưu trữ tất cả các bất động sản hoặc tài sản khác nhau được kết nối với ứng dụng nhà thông minh của chúng tôi. Đối với mỗi bất động sản, chúng tôi sẽ lưu trữ:

  • real_estate_name - Tên do người dùng chọn, đề cập đến một thuộc tính cụ thể.
  • user_account_id - ID của người dùng mà bất động sản này có liên quan. Cùng với thuộc tính real_estate_name, thuộc tính này tạo thành khóa DUY NHẤT (thay thế) của bảng này.
  • real_estate_type - Biểu thị loại bất động sản mà tài sản này là.
  • address - Địa chỉ thực tế của di sản đó. Điều này là vô hiệu vì chúng tôi có thể sử dụng hệ thống này cho các loại tài sản khác (tức là xe cộ).
  • details - Tất cả các chi tiết bổ sung ở định dạng văn bản.

Chúng tôi đã đề cập đến các loại bất động sản. Danh sách đầy đủ các loại có thể được lưu trữ trong real_estate_type từ điển. Nó chỉ chứa một giá trị DUY NHẤT, type_name . Chúng tôi có thể mong đợi các giá trị như "căn hộ", "nhà ở" hoặc "nhà để xe" ở đây.

Một mảnh bất động sản có thể được chia thành nhiều khu vực. Đây có thể là các phòng của một căn hộ hoặc một ngôi nhà; có thể chúng ta muốn nhóm một vài phòng lại với nhau hoặc chúng ta muốn mọi thứ liên quan đến sân hoặc vườn trong một nhóm, v.v. Hoặc có thể chúng ta có một khu công nghiệp hoặc khu phức hợp với nhiều văn phòng; nếu tài sản của chúng tôi thực sự lớn, việc có các khu vực cụ thể có thể rất hữu ích. Để đạt được điều đó, chúng tôi sẽ sử dụng area bàn. Nó chứa cặp DUY NHẤT của real_estate_idarea_name do người dùng chọn.

Hai bảng cuối cùng trong chủ đề này liên quan đến thiết bị.

Trong device_type , chúng tôi sẽ lưu trữ một danh sách đầy đủ về tất cả các loại thiết bị riêng biệt. Đối với mỗi loại, chúng tôi sẽ sử dụng type_name DUY NHẤT và chèn thêm một description Nếu cần thiết. Các loại thiết bị có thể là các cảm biến khác nhau (nhiệt độ, khí), khóa cửa hoặc cửa sổ, đèn, hệ thống điều hòa và sưởi ấm, v.v.

Bây giờ chúng ta đã sẵn sàng cho phần thú vị. Chúng tôi sẽ sử dụng device bảng để lưu trữ danh sách tất cả các thiết bị có trong các ngôi nhà thông minh khác nhau. Những thiết bị này do người dùng thêm vào, theo cách thủ công hoặc tự động nếu thiết bị có tùy chọn đó. Đối với mỗi thiết bị, chúng tôi sẽ cần lưu trữ:

  • real_estate_id - ID của bất động sản nơi thiết bị này được lắp đặt.
  • area_id - Tham chiếu đến area nơi thiết bị này được cài đặt. Đây là giá trị tùy chọn vì bất động sản có thể được chia thành các khu vực, nhưng nó cũng có thể không được phân chia.
  • device_type_id - ID của device_type thiết bị này thuộc về.
  • device_parameters - Chúng tôi sẽ sử dụng thuộc tính này để lưu trữ tất cả các thông số thiết bị có thể có (ví dụ:khoảng thời gian lưu trữ dữ liệu) ở định dạng văn bản có cấu trúc. Những thông số này có thể do người dùng hoặc một phần chức năng thông thường của thiết bị đặt (ví dụ:các số đo khác nhau).
  • current_status - Tình trạng hiện tại của các thông số thiết bị.
  • time_activatedtime_deactivated - Biểu thị khoảng thời gian khi thiết bị này hoạt động. Nếu time_deactivated không được đặt, khi đó thiết bị đang hoạt động và is_active thuộc tính cũng được đặt thành True.

Phần 2:Người dùng và Hồ sơ

Chúng tôi đã đề cập đến user_account bàn. Trong ứng dụng của chúng tôi, người dùng có thể tạo các cấu hình khác nhau và chia sẻ chúng với những người dùng khác nếu họ muốn.

Cấu hình về cơ bản là tập hợp con của các thiết bị được cài đặt trong mọi phần bất động sản do người dùng sở hữu. Mỗi người dùng có thể có một hoặc nhiều hồ sơ. Ý tưởng là cho phép người dùng nhóm các thiết bị nhà thông minh của họ theo cách phù hợp. Mặc dù người dùng có thể có một hồ sơ với tất cả các thiết bị của họ, nhưng họ cũng có thể có một hồ sơ chỉ hiển thị camera phía trước cho tất cả các thuộc tính của họ. Hoặc có thể một hồ sơ chỉ cho các nhiệt kế được lắp đặt trong tất cả các phòng trong căn hộ của họ.

Tất cả các cấu hình do người dùng tạo đều được lưu trữ trong profile bàn. Đối với mỗi bản ghi, chúng tôi sẽ có:

  • profile_name - Tên của hồ sơ, do người dùng chọn.
  • user_account_id - Tham khảo người dùng đã tạo hồ sơ này. Thuộc tính này và profile_name thuộc tính tạo thành khóa DUY NHẤT của bảng.
  • allow_others - Cờ biểu thị nếu hồ sơ này được chia sẻ với những người dùng khác.
  • is_public - Cờ biểu thị nếu hồ sơ này được hiển thị công khai. Mặc dù chúng tôi có thể mong đợi điều này sẽ được đặt thành Sai hầu hết thời gian, nhưng có thể có trường hợp chúng tôi muốn chia sẻ hồ sơ với mọi người.
  • is_active - Một cờ cho biết hồ sơ này có đang hoạt động hay không.
  • ts - Dấu thời gian về thời điểm bản ghi này được chèn.

Đối với mỗi cấu hình, chúng tôi sẽ xác định danh sách tất cả các thiết bị có trong đó. Danh sách này được lưu trữ trong profile_device_list bảng và chứa danh sách profile_id DUY NHẤT - device_id cặp. Cặp khóa ngoại này tạo thành khóa chính của bảng của chúng tôi.

Bảng cuối cùng trong chủ đề này cho phép người dùng chia sẻ hồ sơ của họ với những người dùng đã đăng ký khác. Điều này có thể rất hữu ích, ví dụ:nếu một người quản lý mọi thứ và những người dùng đã đăng ký khác (ví dụ:thành viên gia đình) muốn xem hồ sơ do chủ sở hữu tạo. Trong shared_with , chúng tôi sẽ lưu trữ một danh sách tất cả các cặp profile_id DUY NHẤT - user_account_id . Một lần nữa, cặp khóa ngoại này là khóa chính của bảng. Xin lưu ý rằng chia sẻ sẽ chỉ hoạt động nếu profile.allow_others thuộc tính được đặt thành True.

Phần 3:Lệnh và Dữ liệu

Chúng tôi sẽ sử dụng các bảng từ chủ đề cuối cùng này để lưu trữ thông tin liên lạc giữa người dùng và thiết bị. Đây sẽ là một giao tiếp hai chiều. Các thiết bị sẽ tạo ra dữ liệu trong quá trình hoạt động của chúng và cơ sở dữ liệu của chúng tôi sẽ lưu trữ dữ liệu đó cũng như bất kỳ thông báo nào được tạo bởi hệ thống (hoặc các thiết bị). Người dùng sẽ muốn xem những tin nhắn này và dữ liệu được gửi bởi thiết bị của họ. Dựa trên dữ liệu này, người dùng có thể tạo các chương trình cho ngôi nhà thông minh của họ. Các chương trình này là các lệnh được tạo thủ công hoặc tự động hoặc thậm chí là một loạt lệnh sẽ thực hiện chính xác những gì mà mỗi người dùng muốn.

Chúng tôi sẽ bắt đầu với dữ liệu mà thiết bị cung cấp cho chúng tôi. Trong device_data , chúng tôi sẽ lưu trữ mô tả về dữ liệu do thiết bị tạo và (các) vị trí của dữ liệu. Một lần nữa, dữ liệu được tạo tự động bởi các thiết bị. Nó có thể là một loạt các phép đo, trạng thái (dữ liệu dạng văn bản) hoặc dữ liệu nghe nhìn. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ:

  • device_id - ID của thiết bị đã tạo ra dữ liệu này.
  • data_description - Mô tả về dữ liệu được lưu trữ, ví dụ:những gì được lưu trữ, thời điểm dữ liệu được lưu trữ trong hệ thống của chúng tôi và ở định dạng nào.
  • data_location - Đường dẫn đầy đủ đến vị trí lưu trữ dữ liệu này.
  • ts - Dấu thời gian khi bản ghi này được chèn.

Dữ liệu thiết bị sẽ được lưu trữ bất kể thiết bị đang hoạt động bình thường hay dữ liệu nằm ngoài phạm vi mong đợi. Về cơ bản, đây là nhật ký của mọi thứ đã được các thiết bị ghi lại. Chúng tôi có thể mong đợi có một chiến lược để xóa các tệp dữ liệu thiết bị cũ, nhưng điều đó nằm ngoài phạm vi của bài viết này.

Không giống như dữ liệu thiết bị, chúng ta có thể mong đợi rằng tin nhắn sẽ chỉ được tạo khi có điều gì đó không mong muốn xảy ra - ví dụ:nếu phép đo của thiết bị nằm ngoài phạm vi bình thường, nếu cảm biến phát hiện chuyển động, v.v. Trong những trường hợp đó, thiết bị sẽ tạo ra thông báo. Tất cả các thư như vậy được lưu trữ trong auto_message bàn. Trong mỗi bản ghi, chúng tôi sẽ có:

  • device_id - ID của thiết bị tạo ra thông báo này.
  • message_text - Văn bản do thiết bị tạo ra. Đây có thể là văn bản được xác định trước, giá trị nằm ngoài phạm vi mong đợi hoặc kết hợp của cả hai.
  • ts - Dấu thời gian về thời điểm lưu trữ bản ghi này.
  • read - Một cờ biểu thị người dùng đã đọc tin nhắn hay chưa.

Ba bảng còn lại được sử dụng để lưu trữ các lệnh của người dùng. Các lệnh cho phép người dùng kiểm soát các thiết bị có thể điều khiển của họ và thiết lập giao tiếp hai chiều với ngôi nhà thông minh của họ.

Đầu tiên, chúng tôi sẽ xác định danh sách tất cả các loại lệnh có thể có. Đây có thể là các giá trị như “bật / tắt”, “tăng / giảm nhiệt độ”, v.v. Chúng ta cũng có thể có các lệnh có điều kiện, tức là. các lệnh chỉ được thực hiện nếu một điều kiện cụ thể là đúng. Danh sách tất cả các loại lệnh riêng biệt được lưu trữ trong command_type từ điển. Đối với mỗi loại, chúng tôi sẽ lưu trữ một type_name DUY NHẤT . Chúng tôi cũng sẽ lưu trữ danh sách tất cả các tham số sẽ được xác định cho loại lệnh đó. Điều này sẽ ở định dạng văn bản có cấu trúc với các giá trị mặc định được chèn. Người dùng sẽ đặt các giá trị này khi chèn các lệnh mới của họ.

Người dùng cũng có thể xác định tất cả recurring_commands lên phía trước. Có thể chúng ta muốn có nước nóng mỗi ngày vào lúc 7 giờ sáng hoặc để kích hoạt hệ thống sưởi / làm mát mỗi ngày lúc 4 giờ chiều. Tập hợp các quy tắc và tất cả các thuộc tính cần thiết để thực hiện các lệnh lặp lại được lưu trữ trong bảng này. Chúng tôi sẽ có:

  • user_account_id - ID của người dùng đã chèn lệnh lặp lại này.
  • device_id - ID của thiết bị liên quan đến lệnh lặp lại này.
  • command_type_id - Tham chiếu đến command_type từ điển.
  • parameters - Tất cả các tham số cần được xác định cho loại lệnh đó, cùng với các giá trị mong muốn của chúng.
  • interval_definition - Khoảng thời gian giữa hai lần lặp lại lệnh này. Đối với các tham số lệnh, đây sẽ là một trường văn bản có cấu trúc.
  • active_fromactive_to - Khoảng thời gian mà lệnh này nên được lặp lại. active_to thuộc tính có thể là NULL nếu chúng ta muốn lệnh đó lặp lại mãi mãi (hoặc cho đến khi chúng ta xác định active_to ngày).
  • ts - Dấu thời gian khi bản ghi này được chèn.

Bảng cuối cùng trong mô hình của chúng tôi chứa một danh sách các lệnh đơn lẻ. Những lệnh này có thể được người dùng chèn theo cách thủ công hoặc được tạo tự động (tức là như một phần của các lệnh lặp lại). Đối với mỗi lệnh, chúng tôi sẽ lưu trữ:

  • recurring_command_id - ID của lệnh lặp lại kích hoạt lệnh này, nếu có.
  • user_account_id - ID của người dùng đã chèn lệnh này.
  • device_id - ID của thiết bị có liên quan.
  • command_type_id - Tham chiếu đến command_type từ điển.
  • parameters - Tất cả các tham số liên quan đến lệnh này.
  • executed - Một cờ biểu thị nếu lệnh này đã được thực thi.
  • ts - Dấu thời gian khi bản ghi này được chèn.

Bạn nghĩ gì về Mô hình dữ liệu nhà thông minh?

Trong bài viết này, chúng tôi đã cố gắng đề cập đến các khía cạnh quan trọng nhất của việc quản lý một ngôi nhà thông minh. Một trong số đó chắc chắn là giao tiếp hai chiều giữa người dùng và hệ thống. Hầu hết các hành động "thực" được lưu trữ dưới dạng tham số văn bản và các giá trị này phải được phân tích cú pháp khi thực hiện các hành động cụ thể. Điều này đã được thực hiện để chúng tôi có thể có đủ tính linh hoạt để làm việc với nhiều loại thiết bị khác nhau.

Bạn có gợi ý nào để bổ sung vào mô hình nhà thông minh của chúng tôi không? Bạn sẽ thay đổi hoặc loại bỏ những gì? Vui lòng cho chúng tôi biết trong phần bình luận bên dướ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. Mối quan hệ một-một trong cơ sở dữ liệu là gì?

  2. Đôi khi bạn CÓ THỂ tăng kích thước một cột tại chỗ

  3. Các nguyên tắc cơ bản về biểu thức bảng, Phần 11 - Quan điểm, Cân nhắc sửa đổi

  4. Quản lý bản sao MS SQL của bạn

  5. Biện minh cho Mac Pro mới