Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Model Data Rumah Pintar

Rumah pintar dulu ketat di masa depan; sekarang mereka menjadi kenyataan. Sebagian besar dari kita telah mendengar tentang mereka, tetapi mereka tidak begitu luas seperti yang akan terjadi dalam waktu dekat. Mengelola rumah Anda dengan cara 'pintar' pasti akan menghasilkan banyak data. Hari ini, kami akan menganalisis model data yang dapat kami gunakan untuk menyimpan data rumah pintar.

Model Data

Ketika Anda memikirkan rumah pintar, Anda mungkin berpikir untuk mengunci dan membuka kunci rumah Anda dari jarak jauh, mengaktifkan alarm, lampu, atau kamera dari ponsel Anda, memiliki termometer yang secara otomatis mengatur pemanasan dan pendinginan Anda, dll. Tetapi rumah pintar dapat melakukan lebih banyak lagi. Anda dapat menghubungkan sejumlah perangkat pintar dan pengontrol untuk mencapai banyak fungsi kompleks. Anda dapat mengirim instruksi ke perangkat atau membaca statusnya dari mana pun Anda berada.

Mari kita lihat model data yang memungkinkan kita untuk mengimplementasikan fungsi tersebut. Selain model data tersebut, kami dapat membangun aplikasi web dan aplikasi seluler yang memungkinkan pengguna terdaftar untuk mengelola akun mereka, mengirim instruksi, dan melacak status.




Model ini terdiri dari tiga bidang subjek:

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

Saya akan menjelaskan masing-masing bidang subjek ini dalam urutan daftarnya. Namun, sebelum hal lain, saya akan menjelaskan user_account tabel.

Tabel Akun_Pengguna

Kita mulai dengan user_account tabel karena digunakan di ketiga bidang studi. Ini menyimpan daftar semua pengguna terdaftar dari aplikasi kita.

user_account tabel berisi semua atribut standar yang Anda harapkan, termasuk:

  • first_name dan last_name – Nama depan dan belakang pengguna.
  • user_name – Nama pengguna UNIK yang dipilih oleh pengguna.
  • password – Nilai hash dari kata sandi pengguna.
  • email – Alamat email yang diberikan oleh pengguna selama proses pendaftaran.
  • confirmation_code – Kode yang dihasilkan selama proses pendaftaran.
  • confirmation_time – Stempel waktu saat pengguna mengonfirmasi akun mereka dan menyelesaikan proses pendaftaran.
  • ts – Stempel waktu saat catatan ini dimasukkan ke dalam database.

Bagian 1:Perkebunan dan Perangkat

Seluruh motivasi di balik pembuatan database ini adalah untuk memantau apa yang terjadi dengan perkebunan kami (yaitu rumah atau properti). Ini bisa berupa perkebunan pribadi, seperti apartemen atau rumah, atau bisa juga properti bisnis, seperti kantor, gudang, dll. Jika kita benar-benar ingin mendorong sistem kita hingga batas maksimal, kita juga bisa menggunakannya untuk kendaraan.

Tabel pusat di area subjek ini adalah real_estate meja. Di sinilah kami akan menyimpan semua perkebunan atau properti berbeda yang terhubung ke aplikasi rumah pintar kami. Untuk setiap perkebunan, kami akan menyimpan:

  • real_estate_name – Nama, yang dipilih oleh pengguna, yang merujuk ke properti tertentu.
  • user_account_id – ID pengguna yang terkait dengan properti ini. Bersama dengan atribut real_estate_name, ini membentuk kunci UNIK (alternatif) dari tabel ini.
  • real_estate_type – Menunjukkan jenis real estat properti ini.
  • address – Alamat sebenarnya dari perkebunan itu. Ini tidak dapat dibatalkan karena kami mungkin menggunakan sistem ini untuk jenis properti lain (yaitu kendaraan).
  • details – Semua detail tambahan dalam format tekstual.

Kami telah menyebutkan jenis real estat. Daftar lengkap kemungkinan jenis disimpan di real_estate_type kamus. Ini hanya berisi satu nilai UNIK, type_name . Kita dapat mengharapkan nilai seperti “apartemen”, “rumah”, atau “garasi” di sini.

Satu bagian dari real estat dapat dibagi menjadi beberapa area. Ini bisa berupa kamar apartemen atau rumah; mungkin kita ingin mengelompokkan beberapa ruangan menjadi satu atau kita ingin segala sesuatu yang berhubungan dengan pekarangan atau taman dalam satu kelompok, dll. Atau mungkin kita memiliki kawasan industri atau kompleks dengan beberapa kantor; jika properti kita sangat besar, memiliki area tertentu bisa sangat berguna. Untuk mencapainya, kita akan menggunakan area meja. Ini berisi pasangan UNIK dari real_estate_id dan area_name dipilih oleh pengguna.

Dua tabel terakhir di area subjek ini terkait dengan perangkat.

Di device_type tabel, kami akan menyimpan daftar lengkap semua jenis perangkat yang berbeda. Untuk setiap jenis, kami akan menggunakan type_name UNIK dan masukkan description tambahan jika diperlukan. Jenis perangkat dapat berupa sensor yang berbeda (suhu, gas), kunci pintu atau jendela, lampu, AC dan sistem pemanas, dll.

Sekarang kita siap untuk bagian yang menyenangkan. Kami akan menggunakan device tabel untuk menyimpan daftar semua perangkat yang termasuk dalam berbagai rumah pintar. Perangkat ini ditambahkan oleh pengguna, baik secara manual atau otomatis jika perangkat memiliki opsi itu. Untuk setiap perangkat, kita perlu menyimpan:

  • real_estate_id – ID real estat tempat perangkat ini dipasang.
  • area_id – Merujuk area tempat perangkat ini dipasang. Ini adalah nilai opsional karena perkebunan bisa dibagi menjadi beberapa area, tetapi juga tidak dapat dibagi.
  • device_type_id – ID device_type milik perangkat ini.
  • device_parameters – Kami akan menggunakan atribut ini untuk menyimpan semua kemungkinan parameter perangkat (misalnya interval untuk menyimpan data) dalam format tekstual terstruktur. Parameter ini dapat disetel oleh pengguna atau bagian dari fungsi reguler perangkat (misalnya ukuran yang berbeda).
  • current_status – Status parameter perangkat saat ini.
  • time_activated dan time_deactivated – Menunjukkan interval saat perangkat ini aktif. Jika time_deactivated tidak disetel, maka perangkat aktif dan is_active atribut juga disetel ke True.

Bagian 2:Pengguna dan Profil

Kami telah menyebutkan user_account meja. Dalam aplikasi kami, pengguna harus dapat membuat profil yang berbeda dan membaginya dengan pengguna lain jika mereka mau.

Profil pada dasarnya adalah bagian dari perangkat yang dipasang di setiap bagian real estat yang dimiliki oleh pengguna. Setiap pengguna dapat memiliki satu atau lebih profil. Idenya adalah untuk memungkinkan pengguna mengelompokkan perangkat rumah pintar mereka dengan cara yang sesuai. Meskipun pengguna dapat memiliki satu profil dengan semua perangkat mereka, mereka juga dapat memiliki satu profil yang hanya menampilkan kamera pintu depan untuk semua properti mereka. Atau mungkin satu profil hanya untuk termometer yang dipasang di semua ruangan apartemen mereka.

Semua profil yang dibuat oleh pengguna disimpan di profile meja. Untuk setiap record, kita akan memiliki:

  • profile_name – Nama profil, dipilih oleh pengguna.
  • user_account_id – Referensi pengguna yang membuat profil ini. Atribut ini dan profile_name atribut membentuk kunci UNIK tabel.
  • allow_others – Bendera yang menunjukkan jika profil ini dibagikan dengan pengguna lain.
  • is_public – Bendera yang menunjukkan jika profil ini dapat dilihat oleh publik. Meskipun kami dapat berharap ini akan disetel ke False sebagian besar waktu, mungkin ada kasus ketika kami ingin berbagi profil dengan semua orang.
  • is_active – Bendera yang menunjukkan apakah profil ini aktif atau tidak.
  • ts – Stempel waktu saat catatan ini dimasukkan.

Untuk setiap profil, kami akan menentukan daftar semua perangkat yang disertakan di dalamnya. Daftar ini disimpan di profile_device_list tabel dan berisi daftar profile_id UNIK – device_id berpasangan. Pasangan kunci asing ini membentuk kunci utama dari tabel kita.

Tabel terakhir dalam subjek ini memungkinkan pengguna untuk berbagi profil mereka dengan pengguna terdaftar lainnya. Ini bisa sangat berguna, mis. jika satu orang mengelola semuanya dan pengguna terdaftar lainnya (misalnya anggota keluarga) ingin melihat profil yang dibuat oleh pemiliknya. Di shared_with tabel, kami akan menyimpan daftar semua pasangan UNIK profile_iduser_account_id . Sekali lagi, pasangan kunci asing ini adalah kunci utama tabel. Harap diperhatikan bahwa berbagi hanya akan berfungsi jika profile.allow_others atribut disetel ke True.

Bagian 3:Perintah dan Data

Kami akan menggunakan tabel dari area subjek terakhir ini untuk menyimpan komunikasi antara pengguna dan perangkat. Ini akan menjadi komunikasi dua arah. Perangkat akan menghasilkan data selama operasinya dan database kami akan menyimpannya serta semua pesan yang dihasilkan oleh sistem (atau perangkat). Pengguna akan ingin melihat pesan-pesan ini dan data yang dikirim oleh perangkat mereka. Berdasarkan data ini, pengguna dapat membuat program untuk rumah pintar mereka. Program-program ini adalah perintah yang dibuat secara manual atau otomatis atau bahkan serangkaian perintah yang akan melakukan persis apa yang diinginkan setiap pengguna.

Kami akan mulai dengan perangkat data yang diberikan kepada kami. Di device_data tabel, kami akan menyimpan deskripsi data yang dihasilkan perangkat dan lokasi data tersebut. Sekali lagi, data secara otomatis dihasilkan oleh perangkat. Itu bisa berupa serangkaian pengukuran, status (data tekstual), atau data audio-visual. Untuk setiap record dalam tabel ini, kita akan menyimpan:

  • device_id – ID perangkat yang menghasilkan data ini.
  • data_description – Deskripsi data yang disimpan, mis. apa yang disimpan, kapan data disimpan di sistem kami, dan dalam format apa.
  • data_location – Jalur lengkap ke lokasi penyimpanan data ini.
  • ts – Stempel waktu saat catatan ini dimasukkan.

Data perangkat akan disimpan terlepas dari apakah perangkat berfungsi dengan baik atau jika data berada di luar rentang yang diharapkan. Ini pada dasarnya adalah log dari semua yang direkam oleh perangkat. Kami dapat berharap memiliki strategi untuk menghapus file data perangkat lama, tetapi itu di luar cakupan artikel ini.

Tidak seperti data perangkat, kita dapat mengharapkan bahwa pesan hanya akan dihasilkan ketika sesuatu yang tidak terduga terjadi – mis. jika pengukuran perangkat berada di luar kisaran normal, jika sensor mendeteksi gerakan, dll. Dalam kasus tersebut, perangkat menghasilkan pesan. Semua pesan tersebut disimpan di auto_message meja. Di setiap record, kita akan memiliki:

  • device_id – ID perangkat yang membuat pesan ini.
  • message_text – Teks yang dihasilkan oleh perangkat. Ini bisa berupa teks standar, nilai yang berada di luar rentang yang diharapkan, atau kombinasi keduanya.
  • ts – Stempel waktu saat catatan ini disimpan.
  • read – Bendera yang menunjukkan jika pesan telah dibaca oleh pengguna.

Tiga tabel yang tersisa digunakan untuk menyimpan perintah pengguna. Perintah memungkinkan pengguna untuk mengontrol perangkat mereka yang dapat dikontrol dan menjalin komunikasi dua arah dengan rumah pintar mereka.

Pertama, kami akan mendefinisikan daftar semua jenis perintah yang mungkin. Ini bisa berupa nilai seperti "menghidupkan/mematikan", "menaikkan/menurunkan suhu", dll. Kita juga bisa memiliki perintah bersyarat, mis. perintah yang hanya dipenuhi jika kondisi tertentu benar. Daftar semua jenis perintah yang berbeda disimpan di command_type kamus. Untuk setiap jenis, kami akan menyimpan type_name UNIK . Kami juga akan menyimpan daftar semua parameter yang harus ditentukan untuk jenis perintah tersebut. Ini akan berada dalam format teks terstruktur dengan nilai default yang disisipkan. Pengguna akan menyetel nilai ini saat memasukkan perintah baru mereka.

Seorang pengguna juga dapat menentukan semua recurring_commands di muka. Mungkin kita ingin air panas setiap hari pada jam 7 pagi atau untuk mengaktifkan sistem pemanas/pendingin setiap hari pada jam 4 sore. Kumpulan aturan dan semua atribut yang diperlukan untuk membuat perintah berulang disimpan dalam tabel ini. Kami akan memiliki:

  • user_account_id – ID pengguna yang memasukkan perintah berulang ini.
  • device_id – ID perangkat yang relevan dengan perintah berulang ini.
  • command_type_id – Referensi ke command_type kamus.
  • parameters – Semua parameter yang harus ditentukan untuk jenis perintah tersebut, bersama dengan nilai yang diinginkan.
  • interval_definition – Interval antara dua pengulangan perintah ini. Seperti halnya parameter perintah, ini akan menjadi bidang teks terstruktur.
  • active_from dan active_to – Interval di mana perintah ini harus diulang. active_to atribut bisa NULL jika kita ingin perintah itu diulang selamanya (atau sampai kita mendefinisikan active_to tanggal).
  • ts – Stempel waktu saat catatan ini dimasukkan.

Tabel terakhir dalam model kami berisi daftar perintah tunggal. Perintah-perintah ini dapat dimasukkan secara manual oleh pengguna atau dibuat secara otomatis (yaitu sebagai bagian dari perintah berulang). Untuk setiap perintah, kami akan menyimpan:

  • recurring_command_id – ID perintah berulang yang memicu perintah ini, jika ada.
  • user_account_id – ID pengguna yang memasukkan perintah ini.
  • device_id – ID perangkat yang relevan.
  • command_type_id – Merujuk pada command_type kamus.
  • parameters – Semua parameter yang relevan dengan perintah ini.
  • executed – Bendera yang menunjukkan jika perintah ini telah dijalankan.
  • ts – Stempel waktu saat catatan ini dimasukkan.

Apa Pendapat Anda tentang Model Data Rumah Pintar?

Dalam artikel ini, kami mencoba membahas aspek terpenting dalam mengelola rumah pintar. Salah satunya pasti komunikasi dua arah antara pengguna dan sistem. Sebagian besar tindakan "nyata" disimpan sebagai parameter tekstual, dan nilai-nilai ini harus diuraikan saat melakukan tindakan tertentu. Ini dilakukan agar kami memiliki fleksibilitas yang cukup untuk bekerja dengan banyak jenis perangkat yang berbeda.

Apakah Anda memiliki saran untuk ditambahkan ke model rumah pintar kami? Apa yang akan Anda ubah atau hapus? Tolong beri tahu kami di komentar di bawah.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Statistik Penantian Lutut :PAGEIOLATCH_SH

  2. Apa itu AWS RDS

  3. Ketuk dan Parkir:Model Data Aplikasi Parkir

  4. 50 Shades of NULL – Arti Berbeda dari NULL dalam SQL

  5. Meningkatkan Solusi Median Penomoran Baris