Discussion :

[Limerick]

Bonjour à tous,

Je ne suis absolument pas programmeur, informaticien ou autodidacte surdoué

Cependant, je souhaite créer une petite application que je puisse embarquer sur une clé USB afin de saisir quotidiennement des heures de vol.

En effet, mon but est de créer un Carnet de Vol numérique. En soit, cela est très facile à faire sur Excel, mais ce qui l'est beaucoup moins, c'est de faire toutes une panoplie de requêtes diverses et variées selon un tas de critères qui sont justement dans la base.

Le principe est le suivant :

1. Une table Aircraft comprenant 22 champs (dont certains doivent probablement pouvoir se rassembler)

Cette table permet de stocker les différents aéronefs dont les spécificités seront utilisées pour "ranger" correctement les données saisies dans la table suivante.

1. Une table Flight comprenant 48 champs

Cette table fait appel à un Avion particulier (par son immatriculation), et les données saisies iront dans les champs appropriés de l'avion en question.


Toutes ces données se présentent dans un état ressemblant furieusement à ce que peut être un carnet de vol, même si sa version imprimable serait allégée de la version écran (si c'est possible).
L'idée sous Excel, était d'avoir un onglet par année.

Et enfin, le but final de ce développement, serait d'avoir une interface avec certains critères à cocher/décocher, permettant de sortir les heures de vols de façon très variées. L'évaluation des critères est déjà faite et permet de faire tous les calculs croisés.



Voici donc le principe que j'ai imaginé. Je précise qu'il s'agit là d'un outil à usage personnel, les critères étant liés à un passé aéronautique particulier.

J'ai bien essayé de me former à Access 2007, mais je perds beaucoup de temps pour un résultat pas très probant. J'ai un peu l'impression, malgré les aides que j'ai pu trouver (F1, FAQ, Tutoriaux, etc.), d'avancer dans une pièce noire...

Je suis cependant parvenu à créer ces deux tables (enfin je crois...), les commenter, à faire un début de formulaire pour la table Aircraft, mais sns parvenir à faire une ou deux choses qui doivent pourtant être simples.

Ma question est donc la suivante : y aurait-il quelqu'un qui serait intéressé par ce projet et qui souhaiterait m'aider à avancer plus rapidement que je ne le fais grâce à sa vision d'ensemble d'Access 2007 et à la connaissance de ses possibilités ?

Merci pour votre aide,

Lim.

[Domi2]

Bonjour,

Je ne pense pas que ce soit une bonne idée d'avoir fait déplacer cette discussion dans le sous-forum IHM.

Dans un premier temps, un tutoriel à lire : Access - Les Bases

Avec Access, il est fondamental de réfléchir à la conception de sa base de données.

Dans un deuxième temps, vérifier que ton modèle te permet bien d'afficher (d'extraire) toutes les données souhaitées. Tu peux utiliser uniquement des requêtes. Un tutoriel pour débuter : Créer des requêtes simples

La création de formulaires, d'états, viendra ensuite.

Domi2

[Limerick]

Bonjour Domi2,

Bien sur, avant de venir demander de l'aide, j'ai lu et essayé de m'imprégner des différents tutoriels et films fort bien faits.

C'est grâce à cela que je pense avoir pu faire le tour de ce que doivent comporter les bases. Mais pour ce faire, il a fallu que j'inventorie d'abord toutes les données nécessaires à trier-calculer-extraire.

Ensuite , j'ai créé des tables pour ranger toutes ces données. J'ai même réussi à créer une liaison

Enfin, j'ai cherché à imaginer comment elles seraient saisies en entrée.

Mes problèmes sont de tous ordres.

- les tables sont-elles correctement conçues ?
(ex : j'aurai besoin de faire des totaux d'heures sur multimoteur, seulement les avions sont mono, bi, tri ou quadri moteurs. J'ai donc créé un champ dans la table que j'essaye de passer à "oui", dès que un champ bi, tri ou quadri est renseigné. Non seulement je n'y parviens pas, mais je ne suis pas certain que ce soit la meilleure méthode)

- comment additionner des durées ? Quelle type de donnée est-ce ?
J'ai bien vu un tuto la dessus, mais il m'embarque dans des formules que je ne sais même pas où saisir...

J'en ai tout pleins d'autres comme cela d'où mon appel à l'aide.

En résumé, je pense avoir bien fait le tour des données à saisir et à extraire, c'est entre les deux que ça coince.

Lim.

[Domi2]

Re,

Une question par discussion... On est donc loin du compte...

Pour commencer, fais une copie écran de la fenêtre des relations de ta base, en affichant au maximum les informations de tes tables et que tes relations soit bien visibles, et poste là ici. Qu'on voie déjà à quoi ça ressemble...

Domi2

[Limerick]

Re,

Une question par discussion... On est donc loin du compte...

C'est précisément pourquoi je requérais une aide disons... globale

Sinon voici la copie d'écran des relations de ma base.
Il manque juste deux petits trucs en bas : "type of flight" (avec 4 choix possibles) et "flight number" (en texte)

Ça parle un peu mieux ?

EDIT : pièces-jointes mises à jour plus loin.

[f-leb]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

=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…

[Limerick]

Merci f-leb de venir à mon aide. Et à te lire, je vais en avoir besoin. Alors je te réponds au fur et à mesure.

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).

Oui, j'aurais bien voulu faire cela mais ne sachant pas comment passer d'une Case d'option (c'est ce que je trouve de plus pratique) à une valeur dans un champ, j'ai pensé à un champ par motorisation.

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

=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".

Alors c'est là où ça commence à se corser.

Donc je comprends que le code se met dans une zone de texte d'un formulaire. Mais dans le cas présent, je ne souhaite pas voir ce champs dans le formulaire puisqu'il n'est qu'un conséquence des autres. En fait il me sert pour faire des calculs différenciés du Single Engine. Je suppose qu'il y a un moyen plus rationnel de le faire en utilisant le champ NbrMoteurs que tu évoques. Mais ne sachant pas comment faire, c'est pourquoi j'ai imaginé ce truc.

D'autre part, je ne vois pas ce que sont des "boutons radios" et où se trouve l'assistant du contrôle "groupe d'options".
Il y a bien un bouton "Utiliser les Assitants contrôle", mais il ne se passe rien quand je clique dessus (hormis changer de couleur).

Pour les "Cases d'option" qui m'intéressent, je ne vois pas comment faire pour faire en sorte pour les "lier" quand un seul choix est possible (ex : NbrMoteurs).

Même principe avec les champs [Single pilot] et [Multi pilot] dont l’information peut être portée avec un seul champ.

Oui, pareil que ci-dessous.

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 ?

Alors là, c'est pour "ranger" correctement les heures saisies en fonction de type d'avion et de pouvoir plus tard facilement faire les requêtes (sommes en fonction de critères retenus dans un formulaire).

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.

Si je comprends bien, il faut faire une table par modèle d'avion; Mais le problème est que je ne souhaite pas à me replonger dans le programme simplement parce qu'il faut rajouter un nouveau modèle.

Voilou pour l’instant, à suivre…

Oui et ce n'est que le début...

D'ailleurs j'ai une question (qui aurait dû être préliminaire mais qui était peut-être noyée dans mon premier post) : est-il possible d'installer l'application dons son ensemble (interface et BdD) sur une clé USB, sans n'avoir à installer quoi que ce soit sur l'ordinateur d'accueil. Par nature du boulot, je serai souvent sur des ordinateurs de passage.

Je me suis donc dit que peut-être, le même outil accessible par un navigateur internet était plus universel...
C'est pourquoi j'ai demandé l'avis des experts MySQL-PHP.

[pier.antoine]

Bonjour

Attention !

Comme le dit Domi2

Avec Access, il est fondamental de réfléchir à la conception de sa base de données.

Avant de faire l'habillement de la base, les formulaires, les requêtes.... faire en sorte que la base soit propre, bien conçue dès le départ. Après, c'est vraiment galère pour rattraper le coup.

Quand on construit une maison, avant de soucier de la couleur des murs, ou de la position du canapé, on fait d'abord les fondations, et le gros oeuvre. EN général, on ne conçoit pas une maison selon la forme du canapé. On lui trouvera une place. AU besoin, on le change.

Je vous cite :

Donc je comprends que le code se met dans une zone de texte d'un formulaire. Mais dans le cas présent, je ne souhaite pas voir ce champs dans le formulaire puisqu'il n'est qu'un conséquence des autres.

Ici par exemple il y a confusion : on parle conception, vous répondez visibilité de l'information dans un formulaire.

J'en profite, à la lecture de ce passage pour vous donnez une autre règle importante : ne pas mettre de champs calculés dans une table. LEs champs qui dépendraient de données annexes doivent pouvoir se calculer dans des requêtes.

Comme le dit f-leb, lorsqu'on peut différencier deux éléments de la base selon la valeur différente que peut prendre une même caractéristique, on ne fait qu'un seul champ, qui pourra prendre toutes les valeurs qu'on veut (mais qu'on peut limiter en incluant des conditions de validation).

Plusieurs intérêts à cela : parfois, un élément doit prendre une valeur non prévue au départ. Par exemple, si vous devez indiquer des heures de vol sur un planeur, sans moteur....
D'autre part, pour faire des recherches ou des stats, c'est plus simple.

En ce qui concerne la table Flight, même si les champs ne servent qu'à faire des calculs, il faudrait nous expliquer un peu plus la raison de ces champs, afin de vous aider à optimiser votre base.

Enfin, surtout, ne pas faire une table par modèle. Il faut envisager une table qui permet de caractériser tous les modèles : chaque enregistrement de cette table sera un modèle.

Ce qu'a voulu dire f-leb, c'est que l'immatriculation est en relation avec le modèle. Une immatriculation désigne un appareil qui est d'un certain modèle. Cette immatriculation ne peut pas se trouver sur un autre appareil. Par contre, un même modèle peut avoir plusieurs immatriculations différentes.

En gros, si vous avez deux Pipper Cub, chacun se différencie par leur immatriculation.
Par contre, leurs caractéristiques intrinsèques sont les mêmes.
L'idée est donc de faire 2 tables : la première concerne les modèles (Nom , constructeur, caractéristiques diverses...); la deuxième concerne l'immatriculation (n°, année d'immatriculation, année d'acquisition, carnet d'entretien...)

Ne vous découragez pas, vous êtes sur la bonne voie.


Pierre

[Limerick]

Bonjour Pierre,

Merci pour ces explications et encouragements.

Je comprends bien l'analogie qui est faîte avec la construction d'une maison mais j'irais encore plus loin.

En effet, avant les fondations, il y a les plans. C'est un peu ce qui caractérise la conception de la base et des tables.

Et bien lorsque l'on fait les plans d'une maison, avant de faire une portée de plancher à l'étage, par exemple, il faut avoir une idée de la résistance du béton (ou bien pouvoir comparer avec l'existant). Avant de dessiner l'encadrement des fenêtres, il faut savoir quels sont les standards, à moins de faire du sur mesure, etc.
En résumé, il faut avoir quelques notions générales de ce qu'il est possible de faire.

Et c'est ce qui me manque pour construire mes tables.

Il y a tellement de petites choses que c'est pour cette raison que je souhaitais savoir si un spécialiste serait intéressé pour se plonger complètement avec moi sur ce projet car tout faire en détaillant sur le forum peut-être finalement beaucoup plus fastidieux que ça ne pourrait l'être avec un deux coups de fils, finalement.
Mais j'ai l'impression que dans ce cas, on passe à du développement de type professionnel... avec les tarifs qui vont avec...

Pour revenir au projet, aucun des champs de la table "Flight" n'est un champ calculé. C'est pour cela qu'ils sont si nombreux. Un champs représente la durée du vol effectué sur un appareil dont les caractéristiques renseignées dans la table "Aircraft" permettront de remplir le ou les champs adéquats. Par exemple le Pipper Cub pourra aller dans tout ce qui est "sing pist", à savoir : "day dual", "day pic", "nite dual" et "nite pic".
Un TBM 700 (qui est un mono turboprop), ira dans "sing turb", avec toutes ses déclinaisons. Etc.

Pour moi c'est le moyen le plus simple de faire tous les calculs par la suite grâce aux requêtes.

Pour ce qui concerne "le code dans la zone de texte", c'est pire que cela. C'est que je n'ai manifestement pas compris ce qu'à voulu dire f-leb. C'est un peu, pour moi, comme si je vous disais qu'en station arrière, pour passer du radial 180 au 200, il faut virer à droite. Il y a deux ou trois pré-requis à connaître. Une fois connus, c'est bien moins compliqué qu'Access.

Si j'ai bien compris, il faut faire une table "Model" qui sera utilisée pour la table "Aircraft". Pourtant, il n'y a que deux champs qui seront utilisés pour différencier les modèles d'avions : "variant" et "type".

Ex : un modèle d'avion, le Boeing 737 possède deux variantes : Classic et NG et la variante Classic comporte les B737-300, 400 et 500, alors que la variante NG comporte les 600, 700, 800 et 900.
Mais il faudra être en mesure, par exemple, de déterminer le nombre total d'heures de nuit en PIC (ce qui signifie Commandant de Bord) sur le B737-500.
Ces heures seront prises en compte si l'on demande le total sur B737 et sur "Classic", mais pas sur NG.
Mais elles seront aussi à ajouter à celles du Pipper Cub si l'on demande les heures en tant que Commandant de Bord de nuit du 1er janvier au 30 juin.
Tandis que celle du Pipper Cub ne seront pas prises en compte pour celles effectuées sur avion de plus de 50 tonnes.
Etc, etc...

Disons que sans me décourager, je pense que c'est un petit peu trop gros pour moi, pour une première approche d'Access.

Et puis surtout, j'ai ma question subsidiaire pour savoir si un tel outil développé sur Access peut-être utilisé directement depuis une clé USB. Il y a beaucoup d'utilitaires qui s'utilisent maintenant depuis des clés USB sans installation de quoi que ce soit sur la machine hôte et je souhaiterais pouvoir en faire autant.
On m'a dit qu'un "runtime" permettait désormais de faire cela. Mais autant dire que ce mot n'évoque pour moi que le "temps qui coure"...

Voili-voilà...

[pier.antoine]

Sincérement, je ne pense pas que votre projet soit si démesuré que cela.

Il me semble tout à fait convenir pour un développement avec Access.

A la réserve près de votre dernière question, pour laquelle je ne peux pas vous donner de réponse.

Je reste persuadé que vous pouvez y arriver.

Par rapport à ce que vous dîtes de la maison, et des plans, et des informations sur le caractéristiques des matériaux..., je mettrais un bémol.
Access permet énormément de choses. Plus ou moins simplement, de façon plus ou moins orthodoxe; mais la lecture du forum depuis un an m'a montré qu'on peut presque tout faire.


Mais il faut commencer par le début.
Le début c'est la conception.
Il faut rédiger un "cahier des charges", et le mettre en forme selon la méthode Merise.

Mais cela, f-leb sera beaucoup plus apte à vous en parler que moi.

Bonne continuation.

Pierre

[Limerick]

Il faut rédiger un "cahier des charges", et le mettre en forme selon la méthode Merise.

...heu c'est ça, Merise ?

...bon, ben je r'viendrai l'année prochaine...

[pier.antoine]

C'est bien cela.

Mais il y a un tuto assez simple ici Petit guide d'analyse des données à l'aide de la méthode MERISE

Courage

Pierre

[Chtulus]

Bonjour Limerick,

Faites un petit tour sur l'article d'SQLpro, cela devrait être plus simple !



[Edit] Grilled [/Edit]

[Limerick]

Bon, j'ai lu Merise.

Alors honnêtement, je ne pense pas être loin de la vérité.

Je souhaite enregistrer tous les vols effectués sur un et un seul aéronef à la fois.

Donc les l'enregistrement des vols font appel à la table aéronef.

Chaque aéronef à une et une seule immatriculation. C'est le moyen de les différencier.
Le modèle, la variante auxquels ils appartiennent, le nombre de moteur, le fait qu'il soit certifié JAR 25 ou pas, etc., ne sont que des attributs qui permettent de le différencier lors des requêtes.

De la même manière que le temps de vol qui est associé à un vol est un attribut "temps" ou "durée".

Ce sont les requêtes qui permettront d'en faire la somme suivant les critères sélectionnés.

Effectivement, l'idée du planeur est judicieuse.
Dans mon esprit, s'il fallait rajouter ce cas plus tard, il conviendrait de créer, en plus de single, 2, 3 ou 4 engine, le cas "glider" (ou 0 engine).

Puis dans la table Flight, de créer le champs "glider day pic", "glider night pic" (même si c'est pas fréquent....), "glider day dual" et "glider nite dual". Rien ne serait "cassé".

Alors il y a probablement des champs dans mes tables qui peuvent être regroupés en un seul, mais pour cela, il faut savoir comment peuvent être enregistrées les données, puis comment elles peuvent être différenciées lors des requêtes.

Et c'est là où une méconnaissance d'Access (ou plus généralement de la gestion des bases de données), limite mon analyse.

[niclalex]

Bonjour,
Je me permets de m'insérer dans la conversation.
Tu vas donc avoir une table Aéronef avec les caractéristiques de tes avions (Immatriculation, marque, type,...)
Tu veux différencier tes vols suivant le type d'Aéronef (mono, bi quatri, sans,...).
Pour moi cela veut dire que tu dois faire une table Type_Aeronef dans laquelle tu va lister l'ensemble des types possibles, et dans ta table Aeronef ytu vas utiliser un champ de référence à cette table.

Ceci va te permettre si un jour tu souhaites ajouter un type d'Aeronef de na pas avoir à "casser" tes tables, requetes....
Ensuite tu peux avoir une table pilote avec les données concernant les pilotes que tu veux suivre (Nom, ...)
Et une table Vol qui comprend:
Numéro
Date
Heure debut
Heure fin
Num Avion
Num Pilote

Ton champ num avion fait référence à ta table avion et te permet donc d'identifier le type d'avion et de moteurs
ton champ pilote permet de conaitre le pilote et d'identifier ses heures de vol.

Il faut donc que tu pousses ton raisonement afin de construire tes tables et les champs qu'elles contiennent avant de penser à l'interface.

Pour répondre à ton autre question, si le Run_time Accès est installé sur les postes tu pourras san pb promener ta base sur une clef USB.

Cordialement

[Limerick]

Bonjour niclalex,

Je me permets de m'insérer dans la conversation.

Pas de problème, même si ça risque à la fin de devenir peut-être plus difficilement compréhensible pour celui qui tombera sur ce sujet. A moins que ce ne soit le contraire

Tu vas donc avoir une table Aéronef avec les caractéristiques de tes avions (Immatriculation, marque, type,...)

Tu veux différencier tes vols suivant le type d'Aéronef (mono, bi quatri, sans,...).

Non, le type c'est : Boeing 737-400, Airbus A320, Piper Cub, etc.


Par exemple, le Boeing 737-400 il appartient au :

- Model : Boeing 737
- Variant : Classic
- NbrMoteurs : 2 (d'où également Multi Engine)
- Jet : oui
- Masse : supérieur ou égale à 50 tonnes
- JAR 25 : oui
- Fonction à bord par défaut : Co-pilot

et pour le Piper Cub :

- Model : Piper Cub
- Variant : (sans)
- NbrMoteurs : 1
- Piston : oui
- Masse : (n'est pas supérieur ou égal à 5,7 tonnes)
- JAR 25 : non
- Fonction à bord par défaut : PIC

et ainsi de suite pour tous les aéronefs (exceptés pour les planeurs pour lesquels il est vrai je n'ai pas créé de champs particuliers, mais je ne suis pas vélivole... )

Ensuite, les heures de vol en Dual, Copi ou PIC, de jour ou de nuit, iront automatiquement enrichir les champs correspondants à ces aéronefs dans la table "Flight".

Ensuite tu peux avoir une table pilote avec les données concernant les pilotes que tu veux suivre (Nom, ...)

Un carnet de vol n'appartient qu'à une seule personne.

Il faut donc que tu pousses ton raisonement afin de construire tes tables et les champs qu'elles contiennent avant de penser à l'interface.

Mais mis à part la disposition des données dans les champs, je pense avoir fait le tour de tout ce qui pourra être demandé dans les requêtes

Pour répondre à ton autre question, si le Run_time Accès est installé sur les postes tu pourras san pb promener ta base sur une clef USB.

Alors c'est là que coince mon système, puisque le but est de pouvoir mettre à jour le carnet de vol avec la clé USB, depuis n'importe quel PC ou portable (qui est sur Windows, quand même) : celui de l'hôtel de Tombouctou, celui du collègue qui a pris son portable, celui des Opérations du terrain de Reykjavik, etc...

C'est pourquoi je me suis demandé si un système basé sur un navigateur n'était pas plus universel.

[f-leb]

Bonjour à tous,

En ce qui concerne la portabilité de ton application sur une clé USB (et sans installation sur le poste), il me semble qu’il existe une version portable d’Open Office qui permette cela. Open Office comprend un SGBD avec un environnement qui s’apparente à celui d’Access.

Peut-être il y a-t-il une meilleure solution même avec Access mais je ne la connais pas. On va attendre le passage d’un spécialiste ().
Quant au couple MySQL+PHP que tu as évoqué, c’est une autre paire de manches surtout si tu débutes…

Néanmoins, quels que soient l’architecture et le SGBD retenu, rien n’empêche de construire et tester le modèle de données sous Access pour te faire les crocs.

…Par exemple le Pipper Cub pourra aller dans tout ce qui est "sing pist", à savoir : "day dual", "day pic", "nite dual" et "nite pic".
Un TBM 700 (qui est un mono turboprop), ira dans "sing turb", avec toutes ses déclinaisons. Etc…
…Puis dans la table Flight, de créer le champs "glider day pic", "glider night pic" (même si c'est pas fréquent....), "glider day dual" et "glider nite dual"…
…Ensuite, les heures de vol en Dual, Copi ou PIC, de jour ou de nuit, iront automatiquement enrichir les champs correspondants à ces aéronefs dans la table "Flight"…

Allô, la tour de contrôle ?!!….

Pour autant que je comprenne, sing pist, sing turbo, sing jet, multi pist… sont des types d’avions (ou plutôt des types de motorisation).

Si l’avion du vol considéré est un sing pist, alors seuls les 4 champs sing pist xxx seront renseignés alors que tous les autres resteront vides. C’est bien ça ?
Pourtant pour un vol donné, le type d’avion est déjà renseigné quelque part dans un champ/table TypeAvion,ModeleAvion (je ne sais plus)…Afin d’éviter toute redondance de données, il ne devrait donc rester que ces heures en Dual, Copi,… à saisir donc seulement 5,6 champs par vol.

Si tu recherches un cumul d’heures avec des critères particuliers, il faudra alors nécessairement passer par une requête multi-tables.

Mais pour avancer davantage pourrait-on avoir un petit jeu de données avec les quelques explications qui vont avec sur ces champs sing pist,etc…?

Pour les "Cases d'option" qui m'intéressent, je ne vois pas comment faire pour faire en sorte pour les "lier" quand un seul choix est possible (ex : NbrMoteurs).

Sous Access 2007, il y a bien un contrôle de formulaire "Groupe d’options"qui permet de faire ça très facilement grâce à l’assistant. Regarder éventuellement dans l’aide Access F1.

[Limerick]

En ce qui concerne la portabilité de ton application sur une clé USB (et sans installation sur le poste), il me semble qu’il existe une version portable d’Open Office qui permette cela. Open Office comprend un SGBD avec un environnement qui s’apparente à celui d’Access.

Oui c'est une idée, mais le but ce serait d'avoir un exécutable assez simple et pas trop lourd. S'il faut avoir tout Open Office sur la clé, c'est pas super optimisé... Mais bon, à défaut...

Peut-être il y a-t-il une meilleure solution même avec Access mais je ne la connais pas. On va attendre le passage d’un spécialiste ().

Ben comme dirait la célèbre Grenouille à Grande Bouche, "il doit pas y en avoir beaucoup par ici"
...heu... désolé...

Quant au couple MySQL+PHP que tu as évoqué, c’est une autre paire de manches surtout si tu débutes…

Néanmoins, quels que soient l’architecture et le SGBD retenu, rien n’empêche de construire et tester le modèle de données sous Access pour te faire les crocs.

Tout à fait.

Allô, la tour de contrôle ?!!….

Y'avait un truc, comme ça, autrefois, qui a fait fantasmer quelques petits n'enfants :

“Allô tour de contrôle, demande un passage bas et rapide…”
“Negatif Ghostrider, y’a du monde dans la boucle…”

Mais bon c'est pas le sujet.

Pour autant que je comprenne, sing pist, sing turbo, sing jet, multi pist… sont des types d’avions (ou plutôt des types de motorisation).

Oui, il faut faire attention, le type d'avion, c'est un autre champ qui existe déjà.

Si l’avion du vol considéré est un sing pist, alors seuls les 4 champs sing pist xxx seront renseignés alors que tous les autres resteront vides. C’est bien ça ?

Oui, c'est exactement ça. En fait un champ minimum est renseigné et cela peut aller à tous les champs sing pist xxx si on fait un seul enregistrement pour toute une série de vols faîtes sur le même avion et qu'il n'est pas important d'en saisir le détail.

Pourtant pour un vol donné, le type d’avion est déjà renseigné quelque part dans un champ/table TypeAvion,ModeleAvion (je ne sais plus)…Afin d’éviter toute redondance de données, il ne devrait donc rester que ces heures en Dual, Copi,… à saisir donc seulement 5,6 champs par vol.

Et bien justement, la table Aircraft sert à répertorier tous les avions sur lesquels des vols sont ou ont été effectués. Dans cette table, il n'y a aucune heure de saisie mais il y a toutes les caractéristiques des avions.

Ensuite, lorsque l'on saisit un vol, en sélectionnant l'avion pré-enregistré, lorsque l'on saisira par exemple 2h00 de jour, et que l'on confirmera la fonction (pré-définie grâce toujours à la table Aircraft), et bien ces deux heures iront se ranger dans le champs correspondant au type de motorisation, comme tu dis.

Si tu recherches un cumul d’heures avec des critères particuliers, il faudra alors nécessairement passer par une requête multi-tables.

J'irai voir ce tuto, mais d'après ce que je comprends du titre, non, je ne devrais pas voir besoin de faire de requêtes multi-tables. En effet, toutes les données qui me sont nécessaires pour toutes les requêtes se trouvent uniquement dans la table Flight.

Mais pour avancer davantage pourrait-on avoir un petit jeu de données avec les quelques explications qui vont avec sur ces champs sing pist,etc…?

En pièce jointe, voici déjà le mini cahier des charges que je m'étais fait quand j'ai voulu essayer de faire quelque chose sous Excel.

Sous Access 2007, il y a bien un contrôle de formulaire "Groupe d’options"qui permet de faire ça très facilement grâce à l’assistant. Regarder éventuellement dans l’aide Access F1.

Bon je vais chercher.

Merci en tout cas pour ton coup de main.

EDIT à l'attention des Administrateurs-Modérateurs du forum : Si les .xls sont acceptés comme pièces jointes, y a-t-il une raison pour laquelle les .xlsx ne le sont pas ?

[f-leb]

OK, je vois mieux…

Citation:
Si l’avion du vol considéré est un sing pist, alors seuls les 4 champs sing pist xxx seront renseignés alors que tous les autres resteront vides. C’est bien ça ?

Oui, c'est exactement ça. En fait un champ minimum est renseigné et cela peut aller à tous les champs sing pist xxx si on fait un seul enregistrement pour toute une série de vols faîtes sur le même avion et qu'il n'est pas important d'en saisir le détail.

Sauf que les 25 à 29 champs vides sur 30 vont consommer beaucoup d’espace mémoire inutilement (table "gruyère").

Voici ce que je peux te recommander dans un premier temps:
AirCraft(registration, …,Type…)-1------∞-Flight(ID, #registration, …, DayDual, DayPic, NightDual, NightPic, DayCopi, NightCopi)

Par exemple, pour avoir les durées sing pist xxx:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT Flight.ID, DayDual as [sing pist Day Dual], DayPic as [sing pist Day Pic],
 NightDual as [sing pist Night Dual], NightPic as [sing pist Night Pic] 
FROM AirCraf INNER JOIN Flight ON AirCraft.registration=Flight.registration 
WHERE AirCraft.Type=’sing pist’

Requête sur les deux tables jointes AirCraft et Flight que tu peux construire avec les assistants.

Pour une présentation tabulaire façon Excel avec les 30 colonnes visibles, on peut également s’en tirer avec une requête UNION (un peu long à écrire).

Le pire, c’est que malgré tout on peut encore mieux faire :
Flight-1-----∞-DetailFlight-∞------1-TypeDuree-∞-------1-TypeAirCraft

TypeDuree(idTypeDuree, LibelleTypeDuree={sing pist day dual, sing pist night dual,…, multi pist day copi,….} , #idTypeAirCraft)
DetailFlight(#idFlight,#idTypeDuree, Duree)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
DetailFlight:
idFlight    idTypeDuree        Duree
104    ‘sing pist day dual’    2h00 
104    ‘sing pist night dual’  2h30

Pour le vol référencé 104, 2h00 en ‘sing pist day dual’ puis 2h30 en ‘sing pist night dual’.

Etc… Même si je reconnais que dans ce cas là les traitements/requêtes s’avèrent (un peu) plus délicats.

Voilà… en résumé.

[Limerick]

OK, je vois mieux…

...heu pour être franc, moi c'est beaucoup moins bien

Sauf que les 25 à 29 champs vides sur 30 vont consommer beaucoup d’espace mémoire inutilement (table "gruyère").

Je n'aurais pas pensé qu'une table dont les champs sont vides puissent prendre de la place, mais enfin bon...

Voici ce que je peux te recommander dans un premier temps:
AirCraft(registration, …,Type…)-1------∞-Flight(ID, #registration, …, DayDual, DayPic, NightDual, NightPic, DayCopi, NightCopi)

Je ne suis pas sur d'avoir bien compris car j'ai l'impression que tu reprends exactement ce que je décris.
Ou alors c'est que tu penses créer une table qui n'a que des champs qui pourront potentiellement être renseignés.
Dans ce cas, il faut créer une table Flight par type de motorisation. Pourquoi pas mais tu auras quand même des trous de gruyères pour chaque vol (tu ne peux pas avoir toutes les fonctions à chaque vol.
Sinon, tu es bien obligé d'avoir tous les types de motorisation dans ta table Flight au sein de laquelle les champs ad-hoc seront renseignés.

Par exemple, pour avoir les durées sing pist xxx:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT Flight.ID, DayDual as [sing pist Day Dual], DayPic as [sing pist Day Pic],
 NightDual as [sing pist Night Dual], NightPic as [sing pist Night Pic] 
FROM AirCraf INNER JOIN Flight ON AirCraft.registration=Flight.registration 
WHERE AirCraft.Type=’sing pist’

Requête sur les deux tables jointes AirCraft et Flight que tu peux construire avec les assistants.

Alors là, je patauge... Je vois bien tous les échanges de codes sur le forum, mais je n'ai pas encore pu déterminer où cela s'insère...

Pour une présentation tabulaire façon Excel avec les 30 colonnes visibles, on peut également s’en tirer avec une requête UNION (un peu long à écrire).

Oui, la présentation d'un état, qu'il soit sur écran ou sur papier, doit reprendre tous les champs. Il y en a d'ailleurs plus sur l'écran que sur le papier.

Le pire, c’est que malgré tout on peut encore mieux faire :
Flight-1-----∞-DetailFlight-∞------1-TypeDuree-∞-------1-TypeAirCraft

TypeDuree(idTypeDuree, LibelleTypeDuree={sing pist day dual, sing pist night dual,…, multi pist day copi,….} , #idTypeAirCraft)
DetailFlight(#idFlight,#idTypeDuree, Duree)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
DetailFlight:
idFlight    idTypeDuree        Duree
104    ‘sing pist day dual’    2h00 
104    ‘sing pist night dual’  2h30

Pour le vol référencé 104, 2h00 en ‘sing pist day dual’ puis 2h30 en ‘sing pist night dual’.

Etc… Même si je reconnais que dans ce cas là les traitements/requêtes s’avèrent (un peu) plus délicats.

Ici encore, mon problème est plutôt d'ordre linguistique... Je ne parle pas le serbo-croate et il va falloir que je déchiffre la signification de cette tirade (je parle des 2 premières "phrases" ).

Voilà… en résumé.

Quelque part, je suis rassuré à l'idée que quelqu'un soit parvenu à saisir ce que je souhaite faire, ou en tout cas essaye de le faire.

Merci f-leb.

Quant à savoir s'il existe un moyen de faire une application totalement portable à partir d'Access 2007, personne ne semble avoir la réponse...