Comment les données de l’appli sont structurées
La structure de données de RecordsManager est décrite ci-dessous en termes de hiérarchie et de relations entre les composants de données.
Hiérarchie
Vous pouvez personnaliser la structure de données de RecordsManager au sein du cadre suivant :
•Au niveau root de l’appli, vous pouvez créer autant de référentiels que vous le souhaitez. Par exemple, dans la structure affichée dans la capture d’écran ci-dessous, il existe deux référentiels : (i) Contract Database, (ii) Company Database.
•Dans chaque référentiel, vous pouvez ajouter autant de Tables de données de niveau supérieur que vous le souhaitez. Dans notre base de données d’exemple, Contract Database a une table de données de niveau supérieur (Contract), alors que Company Database a deux tables de données de niveau supérieur (Company Group et Company).
•Dans le cadre d’un conteneur de niveau supérieur (ainsi que des conteneurs de niveau inférieur), vous pouvez ajouter plusieurs conteneurs enfant. Vous pouvez continuer à ajouter des tables de données enfant à de multiples niveaux plus bas. Par exemple, la table de données Company a une table de données enfant nommée Department, qui a lui-même une table de données nommée Person.
Les tables de données sont liées ensemble dans des relations, voir ci-dessous.
Relations
Lors de la définition de la structure de base de données, vous construirez des relations entre les tables de données. Ces relations seront importantes dans la hiérarchie et l’organisation de vos données, et doivent donc être soigneusement planifiées
Il existe deux types de relations qui peuvent être établies entre des tables de données :
•Relations parent–enfant
•Liens lâches
Relations parent–enfant
Ces liens entre les tables de données sont considérés être des liens forts puisqu’un enfant est créé depuis un parent et ne peut pas être créé sans le parent. Une table de données parent peut avoir de multiples tables de données enfant. Un enfant, néanmoins, peut uniquement avoir une table de données parent. Les conséquences suivantes des relations parent–enfant doivent être notées :
•Lorsqu’un enregistrement parent est supprimé, tous les enregistrements enfants sont aussi supprimés
•Lors de la conception des formulaires, les champs de toutes les tables de données ancêtre seront disponibles pour y être inclus
•Les interdépendances des champs dans une hiérarchie de liens forts sont gérées automatiquement
•Des enregistrements enfants peuvent être édités dans les formulaires parents
Liens lâches
Un deuxième type de relations est un lien qui est créé entre deux tables de données indépendants. Ces liens lâches permettent de créer des enregistrements indépendamment et sans référence l’un à l’autre. Les liens sont créés manuellement pendant la configuration. Un seul enregistrement peut donc avoir plusieurs liens lâches vers d’autres enregistrements. Si un enregistrement d’une paire liée lâchement est supprimé, l’autre enregistrement n’est pas affecté.
Les liens lâches peuvent être définis des manières suivantes :
•Définir le champ d’une table de données pour être de type Lier à. Ce champ apporte l’ancre du lien dans l’autre table de données.
•Les tables de données enfant peuvent avoir les relations fortes à leurs parents respectifs converties en un lien lâche.
Voir aussi la rubrique suivante, Comment sont stockées les données.