Comment les données de l’appli sont structurées
La structure de données de ContractManager 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 ContractManager selon vos besoins. La structure autorisée est la suivante :
•Au niveau root de l’appli, vous pouvez créer autant de bases de données que vous le souhaitez. Par exemple, dans la structure affichée dans la capture d’écran ci-dessous, il existe deux bases de données : (i) Contract Database, (ii) Company Database.
•Dans chaque base de données, vous pouvez ajouter autant de conteneurs de niveau supérieur que vous le souhaitez. Dans notre base de données d’exemple, Contract Database a un conteneur de niveau supérieur (Contract), alors que Company Database a deux conteneurs 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 d’ajouter des conteneurs enfant sur plusieurs niveaux. Par exemple, le conteneur Company a un conteneur enfant nommé Department, qui a lui-même un conteneur enfant nommé Person.
Les conteneurs sont liés ensemble dans des relations, voir ci-dessous.
Les données de contrat de vos utilisateurs seront stockées en tant que l’enregistrement des conteneurs. Chaque conteneur est défini par un ensemble de champs, dans lesquels les données des enregistrements seront stockés. Voir la rubrique suivante, Comment sont stockées les données, pour plus de détails.
Relations
Lors de la définition de la structure de base de données, vous construirez des relations entre les conteneurs. 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 conteneurs:
•Relations parent–enfant
•Liens lâches
Relations parent–enfant
Ces liens entre les conteneurs 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. Un conteneur parent peut avoir plusieurs enfants conteneurs. Un enfant, néanmoins, peut uniquement avoir un conteneur 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 tous les conteneurs ancêtres 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 second type de relations est un lien qui est créé entre deux conteneurs 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’un conteneur pour être de type Lier à. Ce champ apporte l’ancre du lien dans l’autre conteneur.
•Les conteneurs enfants peuvent voir les relations fortes à leurs parents respectifs converties en un lien lâche.
Voir aussi la rubrique suivante, Comment sont stockées les données.