Bonsoir Limerick,
Il y a beaucoup de choses à dire, je commence par ton schéma des relations.
Principe essentiel : un schéma "normalisé" interdit toute redondance d’informations pouvant mettre en péril la cohérence des données.
En l’occurrence les 5 champs (de type Oui/Non je suppose) single engine, 2 engine, 3 engine, 4 engine et multi engine sont utilisés pour porter la même information, à savoir : le nombre de moteurs.
L’usage recommande donc ici de coder l’information avec un seul champ numérique [NbrMoteurs] avec, par exemple, une condition (Valide si : Entre 1 et 4).
Un avion multi-moteurs est alors simplement caractérisé par la propriété : [NbrMoteurs]>1
Par exemple dans une zone de texte d’un formulaire :
=VraiFaux([NbrMoteurs]>1 ; "multi-moteurs" ; "mono-moteur")
Au niveau de l’interface, remplir le champ [NbrMoteurs] grâce à des boutons radio ne devrait pas être très compliqué avec l’assistant du contrôle "groupe d’options".
Même principe avec les champs [Single pilot] et [Multi pilot] dont l’information peut être portée avec un seul champ.
48 champs dans la table Flight, ça commence aussi à faire beaucoup. Je soupçonne le même genre de problème que précédemment avec les champs sing-pist-xxxxx, sing-turb-xxx, sing-jet-xxx et multi-xxxxxx. Quelle est la signification de chacun de ces champs ?
De plus, il y a un champ [Model] dans la table Aircraft qui semble indiqué le modèle de l’avion immatriculé. Or, sans être spécialiste en aéronautique, il me semble que certaines caractéristiques comme la motorisation dépendent d’abord du modèle de l’avion.
On a donc intérêt ici à décomposer:
ModelAircraft-1--------∞-Aircraft selon les règles de gestion :
Un avion immatriculé est selon un modèle (ex : modèle A380 d’Airbus). Pour un modèle d’avion, il peut y avoir plusieurs avions immatriculés.
Voilou pour l’instant, à suivre…
Partager