Prepare your sequence data
Last updated
Last updated
生データが1つのテーブルに一連のイベントを含む場合, に分ける必要があります。 entity table そして linked table.以下の手順に従ってください。, これを達成するために
例えば, 下の表は、一連のイベント（野球選手の情報と毎シーズンの統計）を持っています。
イベントデータを別のテーブルに移す, この新しいテーブルが、エンティティ・テーブルの主キーに対応する外部キーを介してエンティティ・テーブルに接続されていることを確認します。このセットアップでは, エンティティ・テーブルにリストされた各個人またはエンティティは、リンクされたテーブルに対応する ID を持っています。
シーケンシャルデータの配置は非常に重要です。イベント・データが列, 列の形を変える, 各行が固有のイベントを記述している。
さまざまな用途のために設計された一般的なデータセットの例を以下に挙げる。:
医療イベントの表が個々の患者にリンクされているペイシェント・ジャーニー。
エンティティテーブルがセンサーを一覧表示する、さまざまなタイプのセンサー測定値, リンク先のテーブルには、それらのセンサーに関連する測定値が記録されている。
eコマース, 合成データは、エンティティ・テーブルに顧客情報が含まれる購買データセットに由来することが多い。, とリンクされたテーブルは、それらの顧客による購入を保存する。
これらは時系列に並んでいる。, 連続データセット, そこでは、出来事の順序とタイミングが重要な洞察を与えてくれる。
さらなる処理のためにデータセットを整理する場合, これらの要件に従うこと:
各行がユニークな個人を表す
複数の行が同じ個人に対応することもある
一意なエンティティID（プライマリキー）を持つこと。
各行は、エンティティテーブル（外部キー）の一意のIDにリンクする必要があります。
行は互いに独立している
複数の行を相互に関連付けることができる
静的な情報のみを含む
動的な情報のみを含む。シーケンスは可能であれば時間順に並べるべきである。
イベントを含むリンクされたテーブルを調べます。エンティティを記述する静的情報が含まれている場合, これはエンティティ・テーブルに移すべきである。例えば, 各購入イベントが特定の顧客に属するEコマースシナリオを考えてみましょう。顧客のEメールは、様々なイベントで同じままです。これは静的なもので、顧客を特徴づけるものです。, イベントではない。その場合, その email_address カラムはエンティティ・テーブルに転送されるべきである。
別の例として、野球選手のテーブルとシーズンごとの統計情報を示すテーブルがあります。この場合, 野球選手テーブルは主キー(player id), 行は互いに独立し、ユニークな個人を表し、静的な情報を含む。一方, seasonsテーブルは、1人の野球選手が複数のシーズンでプレーできるため、1人の個人に対して異なる行を持つことになります。また、シーズン・テーブルは、エンティティ・テーブル(foreign key)であり、時間順に並んだ動的情報を含んでいる。下の図を参照。
