Model Data Tanggal Penting

Apakah Anda melupakan sesuatu? Model data untuk membantu Anda mengingat tanggal penting – sebelum tanggal itu terjadi.

Pernahkah Anda lupa tanggal penting – ulang tahun ibu atau hari jadi Anda? Atau bahwa Anda sedang memberikan kuliah? Yup, hal seperti itu terjadi di kehidupan nyata. Mungkin tidak bagi kita semua, tetapi bagi sebagian dari kita (termasuk saya), mereka pasti begitu. Untuk mencegah bencana seperti itu, kami akan membuat model data yang dapat Anda gunakan sebagai latar belakang untuk aplikasi yang akan memberi tahu Anda tepat waktu.

Saatnya untuk mengucapkan selamat tinggal kepada semua wajah kecewa dan sedih dan hadiah yang tidak dibeli tepat waktu. :)

Mari selami modelnya.

Model Data

Tujuan kami adalah membuat model data untuk aplikasi yang memungkinkan kami menentukan kejadian di masa mendatang dan semua tindakan yang terkait dengannya. Aplikasi harus memberi tahu pengguna ketika mereka melakukan hal kehidupan nyata tertentu dan menandai hal itu sebagai selesai setelah selesai. Beberapa tugas berulang, mis. peristiwa tersebut memicu peristiwa mendatang pada waktu yang telah kita tentukan.

Tentu saja, kami juga perlu mengembangkan aplikasi web dan seluler agar sistem ini benar-benar berguna. Tapi untuk saat ini, mari kita fokus pada model data.

Model ini terdiri dari tiga bidang subjek:

User accounts & dates
Events & actions (definition)
Events & actions (real)

Kami akan menjelaskan masing-masing dari ketiga bidang subjek ini sesuai urutannya.

Bagian 1:Akun dan Tanggal Pengguna

Pengguna aplikasi kami dapat membuat profil pengguna mereka sendiri dan menyimpan tanggal penting yang mereka pilih. Untuk mendukungnya, kami akan menggunakan tabel berikut.

user_account tabel memiliki struktur yang mirip dengan yang dijelaskan dalam banyak artikel model data, tetapi mari kita ulangi sekali lagi. Untuk setiap pengguna, kami akan menyimpan:

first_name dan last_name – Nama depan dan belakang pengguna.
user_name – Nama pengguna yang dipilih pengguna.
password – Nilai hash dari kata sandi yang dipilih pengguna.
mobile – Nomor ponsel yang diberikan oleh pengguna.
email – Email yang digunakan selama proses pendaftaran.
confirmation_code – Kode konfirmasi yang dikirimkan kepada pengguna untuk menyelesaikan pendaftaran mereka.
confirmation_time – Saat pengguna menyelesaikan proses konfirmasi.
insert_ts - Stempel waktu saat catatan ini dimasukkan.

Setelah pendaftaran selesai, pengguna akan dapat memilih tanggal penting mereka sendiri. Daftar ini disimpan dalam tabel selected_date. Meskipun kita berbicara tentang tanggal, apa yang sebenarnya dipilih pengguna adalah aturan yang akan menunjukkan tanggal. Pertama-tama kami akan menjelaskan semua atribut dalam tabel ini dan kemudian kami akan membahas bagaimana pengguna dapat menetapkan aturan menggunakan atribut tersebut. Atributnya adalah:

user_account_id – ID pengguna yang memasukkan catatan ini.
date_year , date_month , dan date_day - Nilai bilangan bulat yang mewakili bagian tanggal (tahun, bulan, dan hari dalam sebulan).
date_weekday – Representasi tekstual dari nomor urut hari dalam seminggu. Kami menggunakan teks karena memungkinkan pengguna untuk memilih nilai yang lebih kompleks – mereka dapat menentukan hari kerja dan minggu dalam sebulan, mis. Senin kedua setiap bulan.

Harap perhatikan bahwa keempat bagian tanggal bisa NULL. Kami tidak akan mengizinkan catatan dengan semua nilai NULL, jadi kami akan memeriksa secara terprogram bahwa setidaknya satu bagian tanggal BUKAN NULL.

Dan sekarang beberapa contoh:

Jika kita ingin memilih tanggal yang tepat, mis. 31.12.2018, kami akan menetapkan nilai ke date_year =2018, date_month =12, dan date_day =31. Ini mendefinisikan sesuatu yang akan terjadi hanya sekali, pada tanggal tersebut.
Jika kita menggunakan kombinasi date_year =2019 dan date_month =1, biarkan dua nilai tersisa NULL, lalu kami mendefinisikan sesuatu yang akan berulang sepanjang Januari 2019.
Kombinasi date_year =2019 dan date_day =2 akan memicu peristiwa pada hari kedua setiap bulan di tahun 2019.
Jika kita memasukkan nilai , kami menentukan sesuatu yang akan terjadi pada hari Senin kedua setiap bulan.

Bagian 2:Peristiwa dan Tindakan (Definisi)

Saya telah menyebutkan "sesuatu" yang tidak jelas, tetapi sesuatu itu sebenarnya adalah sebuah peristiwa. Peristiwa dan tindakan adalah alasan mengapa kami ada di sini. Kami ingin menghubungkan domain waktu dengan peristiwa dan tindakan aktual yang akan terjadi di masa depan. Di area subjek ini, kami akan menyimpan definisi untuk semua peristiwa dan tindakan. Definisi ini nantinya akan digunakan untuk membuat peristiwa dan tindakan yang sebenarnya.

event table jelas merupakan tabel pusat dalam area subjek ini, tetapi sebelum menjelaskannya, saya ingin menjelaskan dua kamus, event_catalog dan recurrence_interval . Keduanya memiliki struktur yang sama, dengan kunci utama yang bertambah secara otomatis (id ) dan atribut nama UNIK.

event_catalog kamus akan menyimpan nilai-nilai seperti "ulang tahun", "libur", "ulang tahun", dan "lainnya". Ini akan membantu kami mengklasifikasikan acara kami.

Di sisi lain, recurrence_interval akan menyimpan nilai seperti "tahun", "bulan", "minggu", dan "hari". Nilai ini menunjukkan unit waktu yang akan berlalu sebelum peristiwa/tindakan yang dirujuk berulang (jika didefinisikan sebagai peristiwa yang berulang). Ketika periode waktu itu berlalu, instance baru dari peristiwa/tindakan yang sama akan dibuat.

Sekarang kita siap untuk masuk ke inti area subjek ini. Dalam event tabel, pengguna mendefinisikan semua peristiwa yang penting bagi mereka. Untuk setiap acara, kami akan menyimpan:

selected_date_id – Merujuk pada definisi tanggal.
event_catalog_id – Menunjukkan jenis acara.
description – Deskripsi tekstual tambahan tentang peristiwa itu.
recurring – Bendera yang menunjukkan jika acara tersebut berulang.
recurrence_interval_id – Menentukan seberapa sering peristiwa tersebut berulang (tahun, bulan, dll). Menggabungkan definisi tanggal dari selected_date dengan interval pengulangan akan memungkinkan kita untuk menentukan titik awal acara dan berapa banyak acara setelah titik awal itu akan dibuat secara otomatis. Dengan cara ini kita dapat mendefinisikan sesuatu seperti:“Mulai dari Senin ke-2 di setiap bulan (selected_date tabel), secara otomatis menjadwalkan rapat harian (event.recurrence_interval atribut)” .
recurring_frequency – Angka yang menunjukkan berapa banyak unit (didefinisikan oleh recurrence_interval_id ) harus dilewati sebelum acara ini berlangsung lagi (jika itu adalah acara yang berulang). Untuk contoh sebelumnya (rapat harian), kami akan mendefinisikan nilai ini sebagai 1.
recurring_times – Jumlah kejadian acara ini. Untuk contoh sebelumnya, ini akan menjadi “5” (rapat harian dari Senin hingga Jumat).

Selanjutnya, kita perlu menghubungkan orang (dikenal oleh pengguna) dengan acara. Daftar semua orang yang disisipkan oleh pengguna kami disimpan di person meja. Untuk setiap orang, pengguna akan menentukan nama lengkap dan detail tambahan apa pun (jika diperlukan).

Sekarang, orang-orang ini dapat dikaitkan dengan acara pengguna. Dalam related_event tabel, kami akan menyimpan referensi ke event dan person serta beberapa details dari sifat hubungan itu. Harap dicatat bahwa orang yang sama dapat ditambahkan beberapa kali untuk acara yang sama. Ini masuk akal jika kita ingin menyimpan lebih dari satu rekaman untuk secara spesifik menunjukkan sesuatu yang istimewa (misalnya, “mengundang Sofia ke pesta”; Sofia adalah tamu pesta dan penyanyi band di pesta itu).

Dua tabel yang tersisa di area subjek ini terkait dengan definisi tindakan.

Tindakan dapat berupa apa saja yang berhubungan dengan peristiwa tersebut. Sebagai contoh, jika kita ingin mengingat ulang tahun ibu, alangkah baiknya jika aplikasi memberi tahu kita:"Mulailah memikirkan hadiah yang ingin kamu berikan kepada ibumu", "Beli hadiah untuk ulang tahun ibu", "Berikan ibu padanya Hadiah B-hari. Dan beberapa ciuman juga” dan akhirnya “Kamu berhasil melakukannya lagi tahun ini. Bravo untuk Anda (dan untuk saya)!”

Oke, mari kita serius lagi. Tindakan adalah kumpulan teks standar yang harus memberi tahu pengguna kapan harus melakukan sesuatu. Kami akan memiliki kamus dengan jenis tindakan yang telah ditentukan sebelumnya seperti "mulai berpikir", "beli hadiah", "temukan musisi", dll. Daftar semua tindakan UNIK tersebut disimpan di action_catalog meja. Saat menentukan peristiwa, pengguna akan memilih satu atau beberapa action s terkait dengan peristiwa itu dan tentukan nilai berikut untuk masing-masing peristiwa tersebut:

event_id – ID acara terkait.
action_catalog_id – Nilai yang dipilih dari action_catalog kamus.
description – Deskripsi opsional dari tindakan itu. Setiap kali tindakan ini dipicu, aplikasi kita akan melihat atribut ini, membaca perintah, dan melakukan tindakan itu.
action_code – Definisi tekstual terstruktur dari tindakan tersebut.
starts_before – Menentukan berapa banyak unit waktu yang dipilih akan berlalu sebelum dimulainya tindakan ini untuk acara yang dipilih (jika ini adalah tindakan berulang). Jika nilai ini tidak ditentukan (yaitu disetel ke NULL), maka tindakan akan dimulai pada saat yang sama saat acara dimulai.
send_message – Bendera yang menunjukkan apakah pesan harus dikirim ke pengguna atau tidak.
recurring – Menunjukkan apakah tindakan ini berulang atau tidak.
recurring_interval_id – Menunjukkan interval/unit untuk pengulangan (jika ini adalah tindakan berulang).
recurring_frequency – Menunjukkan jumlah unit yang dipilih yang harus berlalu antara dua pengulangan dari tindakan yang sama (jika ini adalah tindakan berulang).
recurring_times – Berapa banyak contoh tindakan ini yang akan kita buat?

Pengulangan tindakan mengikuti pola yang sama seperti pengulangan peristiwa. Jika tindakan didefinisikan sebagai berulang, kami akan membuat instance tindakan baru setelah jangka waktu yang ditentukan.

Bagian 3:Peristiwa dan Tindakan (Nyata)

Sejauh ini, kami telah membuat model data yang memungkinkan kami untuk menyisipkan peristiwa dan menentukan tindakan. Sekarang kita akan beralih ke bagian model yang lebih menarik:peristiwa dan tindakan aktual.

event_instance tabel berisi daftar semua peristiwa yang telah dihasilkan secara otomatis atau dimasukkan secara manual. Meskipun pembuatan otomatis cukup jelas – itulah sebabnya kami membuat model ini – penyisipan acara manual juga dimungkinkan. Kami dapat mengharapkan bahwa suatu peristiwa akan dimasukkan secara otomatis pada saat jatuh tempo, jadi kami biasanya hanya memiliki peristiwa aktual dan masa lalu di tabel ini. Namun, itu bisa terjadi bahwa kami telah menangani beberapa acara di masa depan, mis. kami telah mempersiapkan pertemuan yang akan berlangsung bulan depan. Dalam hal ini, kita harus dapat menyisipkan acara mendatang secara manual (waktu acara diusulkan menurut aturan yang ditentukan) dan segala sesuatu yang terkait dengan acara itu ke dalam tabel ini. Di sisi lain, aplikasi kami tidak akan menimpa atau menduplikasi acara itu. Ini akan mengenali peristiwa yang telah kita sisipkan dengan menggunakan event_time nilai. Untuk setiap kejadian, kami akan mendefinisikan:

event_id – Merujuk pada event definisi.
event_time – Waktu acara aktual, dalam format tekstual terstruktur.
insert_ts – Stempel waktu sebenarnya saat acara ini dimasukkan.
event_completed – Nilai Boolean yang menunjukkan apakah event telah selesai atau tidak. Acara secara otomatis diatur ke 'selesai' jika semua tindakan terkait selesai. Itu juga dapat diatur secara manual ke 'selesai' oleh pengguna.

event_id – event_time pair adalah kunci alternatif/UNIQUE dari tabel ini.

Logika serupa digunakan untuk action_instance meja. Tindakan juga akan dibuat secara otomatis saat jatuh tempo. Jika suatu tindakan berulang, kami akan menetapkan lebih dari satu tindakan untuk instance peristiwa yang sama. Untuk setiap tindakan, kami akan menentukan:

action_id – Merujuk action .
event_instance_id – Merujuk pada event_instance .
action_time – Waktu tindakan yang sebenarnya, dalam format tekstual terstruktur.
insert_ts – Stempel waktu aktual saat acara ini dimasukkan.
action_completed – Nilai Boolean yang menunjukkan apakah tindakan telah selesai atau tidak. Tindakan diatur ke 'selesai' secara manual, oleh pengguna. Jika instance tindakan disetel ke 'selesai', instance baru tidak akan dibuat (bahkan jika definisi mengatakan seharusnya demikian).

Dalam tabel ini, kunci alternatif/UNIQUE adalah kombinasi dari action_id – event_instance_id – action_time .

Tabel terakhir dalam model kami adalah message meja. Ini digunakan untuk menyimpan pesan yang dihasilkan oleh tindakan. Pesan-pesan ini dikirim ke pengguna. Untuk setiap pesan, kami akan menyimpan:

action_instance_id – ID action_instance yang membuat pesan ini.
message_title – Judul pesan.
message_text – Teks pesan, yang berisi deskripsi mengapa pesan ini dibuat (yaitu bidang tekstual dari tabel terkait).
insert_ts – Stempel waktu saat pesan ini dibuat.
message_read – Bendera yang menunjukkan jika pesan telah dibaca oleh pengguna.

Bagikan Pendapat Anda tentang Model Data Peristiwa Penting

Saya harap Anda menikmati artikel hari ini. Pernahkah Anda lupa tentang tanggal penting? Apakah menurut Anda model ini dapat membantu Anda? Tolong beri tahu kami di komentar di bawah.