重要な日付のデータモデル

あなたは何かを忘れていますか？重要な日付を覚えておくのに役立つデータモデル–発生する前に。

お母さんの誕生日や記念日など、重要な日付を忘れたことはありませんか？それともあなたが講義をしているということですか？うん、そのようなことは実生活で起こります。たぶん私たち全員ではなく、私たちの一部（私を含む）にとって、彼らは確かにそうします。このような災害を防ぐために、時間どおりに通知するアプリケーションのバックグラウンドとして使用できるデータモデルを作成します。

がっかりした悲しい顔や、時間どおりに購入されなかった贈り物に別れを告げる時が来ました。 :)

モデルに飛び込みましょう。

データモデル

私たちの目標は、将来のイベントとそれに関連するすべてのアクションを定義できるアプリケーションのデータモデルを作成することです。アプリは、ユーザーが特定の実際のことを行ったときに通知し、完了したときにそのことを完了としてマークする必要があります。一部のタスクが繰り返されています。そのイベントは、定義した時間に将来のイベントをトリガーします。

もちろん、このシステムを本当に便利にするために、Webおよびモバイルアプリケーションも開発する必要があります。しかし今のところ、データモデルに焦点を当てましょう。

モデルは3つのサブジェクトエリアで構成されています：

ユーザーアカウントと日付
イベントとアクション（定義）
イベントとアクション（実際）

これら3つの主題分野のそれぞれについて、記載されている順序で説明します。

セクション1：ユーザーアカウントと日付

私たちのアプリケーションのユーザーは、独自のユーザープロファイルを作成し、選択した重要な日付を保存できます。これをサポートするために、次の表を使用します。

user_account テーブルの構造は多くのデータモデルの記事で説明されているものと似ていますが、もう一度繰り返します。ユーザーごとに、以下を保存します：

first_name およびlast_name –ユーザーの名前と名前。
user_name –ユーザーが選択したユーザー名。
パスワード –ユーザーが選択したパスワードのハッシュ値。
モバイル –ユーザーから提供された携帯電話番号。
メール –登録プロセス中に使用される電子メール。
confirmation_code –登録を完了するためにユーザーに送信される確認コード。
confirmation_time –ユーザーが確認プロセスを完了したとき。
insert_ts -このレコードが挿入されたときのタイムスタンプ。

登録が完了すると、ユーザーは自分の重要な日付を選択できるようになります。このリストはselected_dateテーブルに保存されます。日付について話しているのですが、ユーザーが実際に選択しているのは、日付を示すルールです。最初にこの表のすべての属性について説明し、次にユーザーがそれらの属性を使用してルールを設定する方法について説明します。属性は次のとおりです。

user_account_id –このレコードを挿入したユーザーのID。
date_year 、 date_month 、および date_day -日付部分（年、月、日）を表す整数値。
date_weekday –曜日の序数のテキスト表現。ユーザーがより複雑な値を選択できるため、テキストを使用しています。たとえば、曜日と月の週の両方を定義できます。毎月第2月曜日。

4つの日付部分すべてがNULLになる可能性があることに注意してください。すべてがNULL値のレコードは許可されないため、少なくとも1つの日付部分がNULLでないことをプログラムで確認します。

そして今、いくつかの例：

正確な日付を選択する場合（例： 2018年12月31日、値を date_yearに設定します =2018、 date_month =12、および date_day =31.これは、その単一の日付に1回だけ発生することを定義します。
date_yearの組み合わせを使用する場合 =2019およびdate_month =1、残りの2つの値をNULLのままにして、2019年1月全体で繰り返されるものを定義します。
date_yearの組み合わせ =2019およびdate_day =2は、2019年の毎月2日にイベントをトリガーします。
値を挿入した場合、毎月第2月曜日に発生することを定義しています。

セクション2：イベントとアクション（定義）

漠然とした「何か」について言及してきましたが、それは実際にはイベントです。イベントとアクションが私たちがここにいる理由です。時間領域を、将来発生する実際のイベントやアクションと関連付けたいと思います。このサブジェクトエリアには、すべてのイベントとアクションの定義を保存します。これらの定義は、後で実際のイベントとアクションを作成するために使用されます。

イベント テーブルは間違いなくこの主題分野の中心的なテーブルですが、説明する前に、 event_catalogという2つの辞書について説明したいと思います。 およびrecurrence_interval 。どちらも同じ構造で、主キー（ id が自動インクリメントされます。）およびUNIQUEname属性。

event_catalog 辞書には、「誕生日」、「祝日」、「記念日」、「その他」などの値が格納されます。これは、イベントを分類するのに役立ちます。

一方、 recurrence_interval 「年」、「月」、「週」、「日」などの値を格納します。この値は、参照されたイベント/アクションが繰り返されるまでに経過する時間の単位を示します（定期的なイベントとして定義されている場合）。その期間が経過すると、同じイベント/アクションの新しいインスタンスが生成されます。

これで、この主題分野の中心に到達する準備が整いました。 イベント テーブルでは、ユーザーは自分にとって重要なすべてのイベントを定義します。イベントごとに、以下を保存します：

selected_date_id –日付の定義を参照します。
event_catalog_id –イベントの種類を示します。
説明 –そのイベントの追加のテキストによる説明。
繰り返し –イベントが繰り返し発生するかどうかを示すフラグ。
recurrence_interval_id –イベントが繰り返される頻度（年、月など）を定義します。 selected_dateの日付定義を組み合わせる 繰り返し間隔を使用すると、イベントの開始点と、その開始点以降に自動的に作成されるイベントの数を定義できます。このようにして、次のように定義できます。「毎月第2月曜日から開始（ selected_date 表）、毎日の会議を自動的にスケジュールします（ event.recurrence_interval 属性）」 。
recurring_frequency –ユニット数を示す数値（ recurrence_interval_id で定義））このイベントが再度発生する前に合格する必要があります（定期的なイベントの場合）。前の例（毎日の会議）では、この値を1と定義します。
recurring_times –このイベントのインスタンスの数。前の例では、これは「5」（月曜日から金曜日までの毎日の会議）になります。

次に、（ユーザーが知っている）人々をイベントに関連付ける必要があります。ユーザーによって挿入されたすべての人のリストは、 personに保存されます テーブル。ユーザーごとに、フルネームと追加の詳細（必要な場合）を定義します。

これで、これらの人物をユーザーのイベントに関連付けることができます。 related_event テーブルには、イベントへの参照が保存されます およびperson いくつかの詳細と同様にその関係の性質の。同じイベントに同じ人物が複数回追加される可能性があることに注意してください。これは、特別なことを具体的に示すために複数のレコードを保持したい場合に意味があります（たとえば、「ソフィアをパーティーに招待する」。ソフィアはパーティーのゲストであり、パーティーのバンドの歌手でもあります）。

 
 このサブジェクト領域の残りの2つのテーブルは、アクション定義に関連しています。
 
 アクションは、イベントに関連するものであれば何でもかまいません。たとえば、お母さんの誕生日を思い出したい場合は、アプリケーションで「お母さんに贈りたいギフトについて考え始めてください」、「お母さんの誕生日のギフトを購入してください」、「お母さんにプレゼントしてください」と表示されたら便利です。 B-dayギフト。そして、いくつかのキスも」そして最後に「今年も成功しました。あなたのために（そして私のために）ブラボー！」 
 
 さて、もう一度真剣になりましょう。アクションは、何かを行うときにユーザーに通知する必要がある事前定義されたテキストのセットです。 「考え始める」、「ギフトを購入する」、「ミュージシャンを探す」など、事前定義されたアクションタイプの辞書があります。このようなすべての一意のアクションのリストは、 action_catalog  テーブル。イベントを定義するとき、ユーザーは1つ以上のアクションを選択します  sそのイベントに関連し、それぞれに次の値を定義します。
    event_id  –関連するイベントのID。
   action_catalog_id  –   action_catalogから選択された値  辞書。
 説明 –そのアクションのオプションの説明。このアクションがトリガーされるたびに、アプリケーションはこの属性を確認し、コマンドを読み取り、そのアクションを実行します。
   action_code  –そのアクションの構造化されたテキスト定義。
   startups_before  –選択したイベントに対してこのアクションを開始する前に、選択した時間単位がいくつ経過するかを定義します（これが定期的なアクションの場合）。この値が定義されていない場合（つまり、NULLに設定されている場合）、アクションはイベントの開始と同時に開始されます。
   send_message  –メッセージをユーザーに送信する必要があるかどうかを示すフラグ。
 繰り返し –このアクションが繰り返し発生するかどうかを示します。
   recurring_interval_id  –繰り返しの間隔/単位を示します（これが繰り返しのアクションである場合）。
   recurring_frequency  –同じアクションの2回の繰り返しの間に経過する必要がある選択されたユニットの数を示します（これが繰り返しアクションの場合）。
   recurring_times  –このアクションのインスタンスをいくつ作成しますか？
 
 
 アクションの繰り返しは、イベントの繰り返しと同じパターンに従います。アクションが繰り返しとして定義されている場合は、定義された期間の後に新しいアクションインスタンスを生成します。
 セクション3：イベントとアクション（実際）
 
 これまでに、イベントの挿入とアクションの定義を可能にするデータモデルを作成してきました。次に、モデルのより興味深い部分である実際のイベントとアクションに移ります。
   
 
   event_instance   テーブルには、自動生成または手動で挿入されたすべてのイベントのリストが含まれています。自動生成は非常に明白ですが（これがこのモデルを作成した理由です）、手動のイベント挿入も可能です。イベントは期日までに自動的に挿入されることが期待できるため、通常、このテーブルには実際のイベントと過去のイベントのみが含まれます。それでも、将来のイベントをすでに処理している可能性があります。来月開催される会議の準備をしました。その場合、将来のイベント（定義されたルールに従って提案されるイベント時間）とそのイベントに関連するすべてのものをこのテーブルに手動で挿入できるはずです。一方、アプリケーションはそのイベントを上書きまたは複製しません。  event_time を使用して、すでに挿入されているイベントを認識します 価値。イベントインスタンスごとに、以下を定義します：
    event_id  –イベントを参照します  定義。
   event_time  –構造化されたテキスト形式の実際のイベント時間。
   insert_ts  –このイベントが挿入されたときの実際のタイムスタンプ。
   event_completed  –イベントが完了したかどうかを示すブール値。関連するすべてのアクションが完了すると、イベントは自動的に「完了」に設定されます。ユーザーが手動で「完了」に設定することもできます。
 
 
  event_id  –  event_time  ペアは、このテーブルの代替/一意キーです。
 
   action_instanceにも同様のロジックが使用されます  テーブル。アクションは、期限が来ると自動的に生成されます。アクションが繰り返し発生する場合は、同じイベントインスタンスに対して複数のアクションが定義されます。アクションごとに、以下を定義します：
    action_id  –関連するアクションを参照します  。
   event_instance_id  –関連する  event_instanceを参照します  。
   action_time  –構造化されたテキスト形式でのアクションの実際の時間。
   insert_ts  –このイベントが挿入されたときの実際のタイムスタンプ。
   action_completed  –アクションが完了したかどうかを示すブール値。アクションは、ユーザーによって手動で「完了」に設定されます。アクションインスタンスが「完了」に設定されている場合、新しいインスタンスは生成されません（定義で「完了」と指定されている場合でも）。
 
 
 この表では、alternate/UNIQUEキーはaction_idの組み合わせです。 –  event_instance_id  –  action_time  。
 
 モデルの最後のテーブルはメッセージです  テーブル。アクションによって生成されたメッセージを保存するために使用されます。これらのメッセージはユーザーに送信されます。メッセージごとに、以下を保存します：
    action_instance_id  –   action_instanceのID  このメッセージを生成しました。
   message_title  –メッセージのタイトル。
   message_text  –メッセージテキスト。このメッセージが生成された理由の説明が含まれています（つまり、関連するテーブルのテキストフィールド）。
   insert_ts  –このメッセージが生成されたときのタイムスタンプ。
   message_read  –メッセージがユーザーによって読み取られたかどうかを示すフラグ。
 
 重要なイベントのデータモデルについての考えを共有する
 
 今日の記事を楽しんでいただけたでしょうか。重要な日付を忘れたことはありますか？このモデルがあなたを助けることができると思いますか？以下のコメントで教えてください。