Prepare your sequence data
Last updated
Last updated
Si vos données brutes impliquent une série d'événements dans un seul tableau, vous devez le séparer dans un entity table et un linked table. Suivez les étapes suivantes, pour y parvenir.
A titre d'exemple, le tableau ci-dessous contient une série d'événements (informations et statistiques sur les joueurs de baseball à chaque saison).
Déplacer les données relatives aux événements dans une autre table, en veillant à ce que cette nouvelle table soit connectée à la table d'entité via une clé étrangère correspondant à la clé primaire de la table d'entité. Dans cette configuration, chaque personne ou entité répertoriée dans la table des entités a un identifiant correspondant dans la table des liens.
La disposition de vos données séquentielles est cruciale. Si les données relatives aux événements se trouvent dans les colonnes, vous devez les reformer en lignes, où chaque ligne décrit un événement unique.
Voici quelques exemples d'ensembles de données communs conçus pour une série d'applications:
Les parcours des patients, où un tableau des événements médicaux est lié à des patients individuels.
Différents types de relevés de capteurs où une table d'entités répertorie les capteurs, et le tableau lié enregistre les relevés associés à ces capteurs.
Dans le domaine du commerce électronique, les données synthétiques proviennent souvent d'ensembles de données d'achat où les tables d'entités contiennent des informations sur les clients, et des tables liées stockent les achats effectués par ces clients.
Ces achats sont classés par ordre chronologique, ensembles de données séquentielles, où la séquence et la chronologie des événements fournissent des informations importantes.
Lorsque vous organisez vos ensembles de données en vue d'un traitement ultérieur, respecter ces exigences:
Examinez votre table liée contenant des événements. Si elle contient des informations statiques décrivant l'entité, il devrait être déplacé vers la table des entités. Par exemple, Considérons un scénario de commerce électronique dans lequel chaque événement d'achat appartient à des clients spécifiques. L'adresse électronique du client reste la même pour tous les événements. Il est statique et caractérise le client, et non l'événement. Dans ce cas, les email_address doit être transférée dans la table des entités.
Un autre exemple est celui d'une table de joueurs de base-ball et d'une table indiquant leurs statistiques par saison. Dans ce cas, les joueurs de baseball doivent être considérés comme une table d'entités puisque la table des joueurs de baseball aura une clé primaire (player id), Les lignes seront indépendantes les unes des autres, représenteront un individu unique et contiendront des informations statiques. D'autre part, les, La table des saisons comportera différentes lignes consacrées à un même individu, puisqu'un joueur de base-ball peut disputer plusieurs saisons. De plus, la table des saisons possède un identifiant unique dans la table des entités (foreign key) et contient des informations dynamiques ordonnées dans le temps. Voir l'illustration ci-dessous.
| Tableau des entités | Tableau lié |
|---|---|
Chaque ligne représente un individu unique
Plusieurs lignes peuvent correspondre à la même personne
Doit avoir un identifiant d'entité unique (clé primaire)
Chaque ligne doit être liée à un identifiant unique dans la table des entités (clé étrangère).
Les lignes sont indépendantes les unes des autres
Plusieurs lignes peuvent être reliées entre elles
Ne contient que des informations statiques
Contient uniquement des informations dynamiques ; les séquences doivent être ordonnées dans le temps si possible.
