Kamera, pintu putar, elevator, sensor suhu, alarm – semua perangkat ini menghasilkan sejumlah besar sinyal yang saling berhubungan yang terkait dengan peristiwa yang terjadi di sekitar kita. Sekarang bayangkan Anda adalah orang yang perlu melacak status, menghasilkan laporan waktu nyata, dan membuat prediksi berdasarkan semua data sinyal ini. Untuk melakukan ini, Anda harus terlebih dahulu menyimpan data itu. Model data yang mendukung pemrosesan sinyal seperti itu adalah topik artikel hari ini.
Cara paling sederhana untuk menyimpan sinyal yang masuk adalah dengan menyimpan representasi tekstualnya dalam satu daftar besar. Pendekatan ini akan memungkinkan kami untuk melakukan penyisipan dengan cepat, tetapi pembaruan akan menjadi masalah. Selain itu, model seperti itu tidak akan dinormalisasi, dan oleh karena itu kami tidak akan menuju ke arah itu.
Kami akan membuat model data yang dinormalisasi yang dapat digunakan untuk menyimpan data yang dihasilkan oleh perangkat yang berbeda dan juga menentukan bagaimana perangkat terkait. Model seperti itu akan secara efisien menyimpan semua yang kita butuhkan dan juga dapat digunakan untuk analisis dan analisis prediktif.
Model Data
Model data pemrosesan sinyal
Model ini terdiri dari tiga bidang subjek:
ComplexesInstallations & DevicesSignals & Events
Kami akan menjelaskan masing-masing bidang subjek ini dalam urutan yang tercantum.
Kompleks
Saat membuat model data ini, saya berasumsi bahwa kami akan menggunakannya untuk melacak apa yang terjadi di kompleks yang lebih besar. Kompleks bervariasi dalam ukuran dari satu kamar ke pusat perbelanjaan. Penting bahwa setiap kompleks memiliki setidaknya satu perangkat/sensor, tetapi mungkin akan memiliki lebih banyak lagi.
Sebelum menjelaskan kompleks, kita perlu mendefinisikan tabel yang menangani negara dan kota. Ini akan memberikan deskripsi yang cukup rinci tentang lokasi setiap kompleks.
Untuk setiap country , kami akan menyimpan country_name UNIK nya; untuk setiap city , kami akan menyimpan kombinasi UNIK dari postal_code , city_name , dan country_id . Saya tidak akan menjelaskan secara rinci di sini, dan kami akan menganggap bahwa setiap kota hanya memiliki satu kode pos. Pada kenyataannya, sebagian besar kota akan memiliki lebih dari satu kode pos; dalam hal ini, kita dapat menggunakan kode utama untuk setiap kota.
Sebuah complex adalah bangunan atau lokasi sebenarnya di mana perangkat penghasil data dipasang. Seperti yang dinyatakan sebelumnya, kompleks dapat bervariasi dari satu ruangan atau stasiun pengukuran ke tempat yang jauh lebih besar seperti tempat parkir, pusat perbelanjaan, bioskop, dll. Mereka adalah subjek analisis kami. Kami ingin dapat melacak apa yang terjadi pada tingkat yang kompleks secara real time dan, kemudian, untuk menghasilkan laporan dan analisis. Untuk setiap kompleks, kami akan mendefinisikan:
complex_code– Pengidentifikasi UNIK untuk setiap kompleks. Meskipun kami memiliki atribut kunci utama yang terpisah (id) untuk tabel ini, kita dapat berharap bahwa kita akan mewarisi kode pengenal lain untuk setiap kompleks dari sistem lain.complex_name– Nama yang digunakan untuk menggambarkan kompleks itu. Dalam kasus pusat perbelanjaan dan bioskop, ini bisa menjadi nama mereka yang sebenarnya dan terkenal; untuk stasiun pengukuran, kita bisa menggunakan nama generik.city_id– Referensi ke kota tempat kompleks itu berada.address– Alamat fisik kompleks itu.position– Posisi kompleks (yaitu koordinat geografis) ditentukan dalam format tekstual.description– Deskripsi tekstual yang lebih dekat menggambarkan kompleks ini.ts_inserted– Stempel waktu saat catatan ini dimasukkan.is_active– Nilai boolean yang menunjukkan apakah kompleks ini masih aktif atau tidak.
Pemasangan dan Perangkat
Sekarang kita bergerak lebih dekat ke jantung model kita. Kami kemungkinan akan memasang sejumlah perangkat di setiap kompleks. Kami juga hampir pasti akan mengelompokkan perangkat ini berdasarkan tujuannya – mis. kita dapat menempatkan kamera, sensor pintu, dan motor yang digunakan untuk membuka dan menutup pintu dalam satu kelompok karena keduanya bekerja bersama.
Dalam model kami, perangkat yang bekerja bersama dalam satu kompleks dikelompokkan dalam instalasi. Ini bisa untuk pintu depan, eskalator, sensor suhu, dll. Untuk setiap pemasangan, kami akan menyimpan detail berikut di installation tabel:
installation_code– Kode UNIK yang digunakan untuk menunjukkan instalasi itu.installation type_id– Referensi keinstallation_typekamus. Kamus ini hanya menyimpantype_nameUNIK atribut yang menjelaskan jenisnya, mis. eskalator, lift.complex_id– Referensi kecomplexmilik instalasi tersebut.position– Koordinat, dalam format tekstual, dari instalasi di dalam kompleks.description– Deskripsi tekstual dari instalasi tersebut.current_status_id– Referensi ke status saat ini (dariinstallation_statustabel) dari instalasi itu.ts_inserted– Stempel waktu saat catatan ini dimasukkan ke dalam sistem kami.
Kami telah menyebutkan status pemasangan. Daftar semua kemungkinan status disimpan di installation_status kamus. Setiap status secara UNIK ditentukan oleh status_name its . Selain itu, kami akan menyimpan tanda yang menunjukkan jika status tersebut, saat digunakan, menyiratkan bahwa instalasi is_broken , is_inactive , is_maintenance , atau is_active . Hanya satu dari tanda ini yang harus disetel pada satu waktu.
Kami telah menetapkan status saat ini untuk penginstalan. Jika kita akan melacak apa yang terjadi dengan perangkat, kita juga perlu menyimpan riwayatnya. Untuk melakukannya, kita akan menggunakan satu tabel lagi, installation_status_history . Untuk setiap catatan di sini, kami akan menyimpan referensi ke penginstalan terkait dan status serta momen (ts_inserted ) saat status itu ditetapkan.
Instalasi adalah bagian dari kompleks kami. Meskipun setiap instalasi adalah satu kesatuan, itu masih bisa terkait dengan instalasi lain. (Misalnya sistem video di pintu masuk depan pusat perbelanjaan jelas terkait dengan pintu depan mal – orang akan dilihat oleh kamera terlebih dahulu dan kemudian pintu akan terbuka.) Jika kita ingin melacak hubungan ini, kita akan menyimpannya di related_installation meja. Harap perhatikan bahwa tabel ini hanya berisi pasangan UNIK dari dua kunci, keduanya merujuk pada installation meja.
Logika yang sama digunakan untuk menyimpan perangkat. Perangkat adalah bagian tunggal dari perangkat keras yang menghasilkan sinyal yang kami minati. Sementara instalasi termasuk kompleks, perangkat termasuk dalam instalasi. Untuk setiap device , kami akan menyimpan:
device_code– Cara UNIK untuk menunjukkan setiap perangkat.device_name– Nama untuk perangkat ini.installation_id– Referensi ke penginstalan perangkat ini.current_status_id– Status perangkat saat ini.ts_inserted– Stempel waktu saat catatan ini dimasukkan.
Status ditangani dengan cara yang sama. Kami akan menggunakan device_status tabel untuk menyimpan daftar semua kemungkinan status perangkat. Tabel ini memiliki struktur yang sama dengan installation_status dan atribut digunakan dengan cara yang sama. Alasan memiliki dua kamus status yang terpisah adalah karena perangkat dan penginstalannya dapat memiliki status yang berbeda – setidaknya dalam nama.
Status saat ini disimpan di device.current_status_id atribut dan riwayat status disimpan di device_status_history meja. Untuk setiap catatan di sini, kami akan menyimpan hubungan ke perangkat dan status serta saat catatan ini dimasukkan.
Tabel terakhir di area subjek ini adalah related_device meja. Meskipun cukup jelas bahwa semua perangkat di dalam instalasi yang sama terkait erat, saya ingin memiliki opsi untuk menghubungkan dua perangkat apa pun yang termasuk dalam instalasi apa pun. Kami akan melakukannya dengan menyimpan dua ID perangkat mereka di tabel ini.
Sinyal dan Peristiwa
Sekarang kita siap untuk inti dari keseluruhan model.
Perangkat menghasilkan sinyal. Semua data sinyal disimpan dalam signal meja. Untuk setiap sinyal, kami akan menyimpan:
device_id– Referensi ke perangkat yang menghasilkan sinyal itu.value– Nilai numerik dari sinyal itu.description– Nilai tekstual yang dapat berisi parameter tambahan apa pun (misalnya jenis sinyal, nilai, unit pengukuran yang digunakan) yang terkait dengan sinyal tunggal tersebut. Data ini disimpan dalam format seperti JSON.ts– Stempel waktu saat sinyal ini dimasukkan ke tabel.
Kita dapat berharap bahwa tabel ini akan mendapatkan penggunaan yang sangat berat, dengan sejumlah besar penyisipan dilakukan per detik. Oleh karena itu, pemeliharaan database harus fokus pada pelacakan ukuran tabel ini.
Hal terakhir yang ingin saya lakukan adalah menambahkan event ke model data kita. Acara dapat secara otomatis dihasilkan oleh sinyal atau dimasukkan secara manual. Satu peristiwa yang dibuat secara otomatis dapat berupa "pintu terbuka selama 5 menit", sedangkan peristiwa yang dimasukkan secara manual dapat berupa "perangkat harus dimatikan karena sinyal ini". Seluruh idenya adalah untuk menyimpan tindakan yang terjadi sebagai akibat dari perilaku perangkat. Kemudian, kita dapat menggunakan peristiwa ini saat melakukan analisis perilaku perangkat.
Acara akan diperinci menurut event_type . Setiap jenis secara UNIK ditentukan oleh type_name-nya .
Semua acara yang dibuat secara otomatis atau dimasukkan secara manual dicatat dalam event meja. Untuk setiap catatan di sini, kami akan menyimpan:
event_type_id– Referensi ke jenis acara terkait.description– Deskripsi tekstual tentang peristiwa itu.signal_id– Referensi ke sinyal, jika ada, yang menyebabkan peristiwa tersebut.inserted_manually– Bendera yang menunjukkan apakah catatan ini dimasukkan secara manual atau tidak.event_tsdants_inserted–Stempel waktu ketika peristiwa ini benar-benar terjadi dan ketika catatan itu dimasukkan. Keduanya bisa berbeda, terutama ketika catatan peristiwa dimasukkan secara manual.
Tabel terakhir dalam model kita adalah event_device meja. Tabel ini digunakan untuk menghubungkan peristiwa dengan semua perangkat yang terlibat. Untuk setiap record, kami akan menyimpan pasangan UNIK event_id – device_id dan stempel waktu saat catatan dimasukkan.
Apa Pendapat Anda Tentang Model Data Pemrosesan Sinyal Kami?
Hari ini, kami telah menganalisis model data sederhana yang dapat kami gunakan untuk melacak sinyal dari sekumpulan perangkat yang dipasang di lokasi berbeda. Model itu sendiri harus cukup untuk menyimpan semua yang kita butuhkan untuk melacak status dan melakukan analitik. Namun, banyak perbaikan yang mungkin dilakukan. Apa yang bisa kami tambahkan? Tolong beri tahu kami di komentar di bawah.
