AGRÉGATION «ÉCONOMIE ET GESTION»

Transcription

1 AGRÉGATION «ÉCONOMIE ET GESTION» CONCOURS INTERNE SESSION 2002 ÉPREUVE SUR LES TECHNIQUES DE GESTION ET COMPORTANT DES ASPECTS PÉDAGOGIQUES DOMAINE : économie et gestion informatique Durée de préparation : 4 heures Vous disposez d une durée maximale de 30 minutes pour présenter oralement la solution de l étude qui vous est proposée. Au cours de l entretien qui suivra, outre les précisions qui peuvent être demandées sur votre exposé, des questions d ordre pédagogique vous seront posées, en liaison avec le thème étudié et avec votre pratique et votre expérience. AVERTISSEMENT Si le texte du sujet, de ses questions ou de ses annexes, vous conduit à formuler une ou plusieurs hypothèses, il vous est demandé de la (ou les) mentionner explicitement lors de votre exposé.

2 GESTION DE COMPTES BANCAIRES L'idée générale est de réfléchir à la production d'un logiciel permettant de gérer les avoirs bancaires d'un particulier (comptes courants, portefeuille de titres,...). Les candidats dont invités à traiter les questions dans l'ordre. A. Les comptes courants Généralités Un particulier (ou plus généralement un foyer) dispose d'un ou de plusieurs comptes bancaires courants. Ces comptes sont utilisés pour des opérations diverses : - réception d'un virement correspondant au salaire mensuel, - paiement par chèque d'une facture du garagiste, - retrait d'espèces à l'aide d'une carte bancaire,... L'enregistrement de ces opérations par la banque fait l'objet d'un relevé périodique dont voici un exemple : Banque de l'espoir 1, rue haute Lille Mr ou Mme Dupuis 4, rue des fleurs Lille Relevé au compte n Date Libellé Débit Crédit Solde précédent CB CH n CB VIR de AUVERT Solde en votre faveur 2790 Remarques : - La seconde opération correspond à un paiement effectué à l'aide de la carte bancaire n (cette carte appartient à Mme Dupuis). - La troisième opération a été réglée à l'aide du chèque n L'opération du correspond à la réception d'un virement bancaire émis par "AUVERT". Le logiciel doit permettre : - d'enregistrer les opérations au fur et à mesure de leur réalisation (saisie des chèques émis, des retraits d'espèces effectués,...) d'une part, - de rapprocher ces opérations des relevés périodiques émis par la banque d'autre part ("pointage" des opérations constatées d'avance, ajout d'opérations non saisies), - de connaître à tout moment le "solde réel" et le "solde en banque" de chaque compte courant géré.

3 Fonctionnalités diverses > Les opérations doivent être classées en différentes catégories de recettes ou de dépenses, ce qui permettra une analyse du budget de l'utilisateur et un suivi de son évolution dans le temps (part du budget consacré à la nourriture, à l'habillement, à l'automobile,...). > Certaines opérations ont un caractère répétitif : - remboursement mensuel d'un prêt, - paiement d'un loyer trimestriel, - réception mensuelle d'un salaire,... Ces opérations possèdent toujours le même montant (celui-ci pouvant évoluer au cours du temps), et sont réalisées à intervalles fixes. Il serait intéressant de pouvoir les saisir une seule fois. > Il arrive qu'une opération saisie ne figure jamais sur un relevé bancaire. Il peut s'agir d'une erreur commise par l'utilisateur, d'un chèque n'ayant jamais été encaissé, d'une erreur de la banque,... Au bout d'un certain temps, il doit être possible "d'oublier" l'écriture. Celle-ci n'entre alors plus dans le calcul du solde du compte, sans pour autant être supprimée, ce qui permettra de la "restaurer" facilement dans le cas où elle finirait par être régularisée. - Proposez une modélisation des données nécessaires à la réalisation de la partie "gestion des comptes courants" de l'application. B. Solde des comptes Solution adoptée au niveau physique > L'application est développée autour d'un SGBDR. Au niveau physique, on trouve notamment deux tables : - COMPTE, table mémorisant les informations concernant les comptes courants - OPERATION, table mémorisant chaque opération concernant un compte courant > Chaque compte possède deux soldes : - Le solde réel qui prend en considération toutes les opérations saisies par l'utilisateur, qu'elles aient été constatées ou non par la banque. - Le solde en banque qui ne prend en considération que les opérations constatées par la banque, c'est-à-dire ayant fait l'objet d'un "pointage" à partir d'un relevé. > Le calcul de ces deux soldes conduit donc à sommer un grand nombre d'opérations, et ce depuis la mise en service de l'application. Pour éviter ces calculs, il a été décidé de mémoriser les soldes dans la table COMPTE.

4 Dès lors se pose le problème de la cohérence entre les opérations et le solde des comptes. La solution adoptée est le recours à un ensemble de procédures stockées et de déclencheurs (triggers) destinés à maintenir à jour les soldes dans la table COMPTE. Schéma partiel de la base de données COMPTE (Cid, Cnumero, CsoldeReel, CsoldeBanque,... ) OPERATION (Oid, Odate, Omontant, Osens, Oreleve#, Ocompte#,... ) RELEVE(Rid, Rdate,... ) Remarques : - CsoldeReel et CsoldeBanque représentent respectivement le "solde réel" et le "solde en banque" du compte. - Osens est un caractère mémorisant la nature de l'opération ('d' pour débit, opération diminuant le solde du compte ; 'c' pour crédit, opération augmentant le solde du compte). - Oreleve contient le numéro du relevé (Rid) ayant permis de pointer l'opération. Cet attribut contient la valeur NULL si l'opération n'a pas encore été pointée. Extrait de la documentation du SGBD utilisé > Création d'une procédure stockée create procedure <nom_procédure> parameters <nom_paramètre> : <type_paramètre> // n fois variables <nom_variable> : <type_variable> // n fois begin <liste d'instructions> end > Création d'un déclencheur create trigger <nom_trigger> on (insert update delete ) for <nom_table> variables <nom_variable> : <type_variable> // n fois begin <liste d'instructions> end > Syntaxe du langage Le langage permet l'utilisation de tous les types de données courants pour la déclaration des paramètres et des variables. Les instructions "classiques" sont présentes : affectation, conditionnelle, boucle, appel de procédure,... > Intégration de SQL Le langage supporte l'utilisation de requêtes SQL selon la norme d'intégration de SQL dans un langage hôte (variables hôtes notamment).

5 > Accès au n-uplet concerné par un trigger Lors de l'écriture d'un trigger, il est possible d'accéder aux valeurs des attributs du n-uplet concerné par l'opération. Le tableau ci-dessous résume les possibilités. Opération Syntaxe Signification INSERT NEW.<attribut> Valeur de l'attribut indiquée dans l'instruction INSERT UPDATE OLD.<attribut> Valeur de l'attribut avant l'instruction UPDATE UPDATE NEW.<attribut> Nouvelle valeur (indiquée dans l'instruction UPDATE) DELETE OLD.<attribut> Valeur de l'attribut avant la suppression du n-uplet - Rédigez l'ensemble des procédures stockées et des déclencheurs nécessaires à la gestion des informations calculées CsoldeReel et CsoldeBanque. - Discutez de l'intérêt de cette solution. C. Portefeuille de titres Structure des données utilisées En ce qui concerne la gestion d'un portefeuille de titres, l'application utilise entre autres les données suivantes : TITRE (id, libelle) ACHAT (id, titre#, date, quantite, prix) VENTE (id, titre#, date, quantite, prix) UTILISER (idvente#, idachat#, quantite) A chaque insertion d'une vente, le logiciel doit déterminer et mémoriser dans la table UTILISER les achats "consommés" (au moins en partie) par cette vente. Ce calcul est fait en appliquant le mécanisme "premier entré premier sorti" (FIFO). Il n'y a jamais deux achats ou deux ventes effectués à la même date et sur un même titre. La table UTILISER permettra par la suite de calculer la plus-value ou la moins-value réalisée pour chaque vente. Par exemple, pour le titre "t05", les achats sont les suivants : id titre date quantité prix 15 t05 02/01/ t05 03/01/ t05 10/01/ t05 11/01/ t05 20/01/ t05 10/02/ Les ventes du même titre sont présentées dans le tableau ci-dessous : id titre date quantité prix 40 t05 15/01/ t05 22/01/ t05 03/02/

6 > La vente 40 donne lieu à la création des n-uplets suivants dans la table UTILISER : idvente idachat quantité > La vente 48 donne lieu à la création des n-uplets suivants dans la table UTILISER : idvente idachat quantité > La vente 60 donne lieu à la création des n-uplets suivants dans la table UTILISER : idvente idachat quantité Proposez une représentation des données utilisées pour la gestion des titres au niveau conceptuel. - Décrivez le principe d'un programme permettant, à partir des tables présentées, de fournir une liste des ventes indiquant pour chacune d'elles la plus-value ou la moins-value réalisée. - Etudiez la possibilité de programmer une épuration périodique des données concernant les achats et les ventes (suppression des achats et des ventes chaque fin d'année civile, après archivage).. Mettez en évidence les problèmes posés par cette épuration.. Présentez de manière schématique une solution algorithmique. D. Téléchargement des relevés Tous les établissements bancaires permettent le téléchargement des relevés de compte périodiques. Il serait donc possible d'éviter certaines saisies d'opérations. Il doit être possible : - De saisir une opération dès qu'elle est effectuée, sans attendre son apparition sur un relevé. - De ne pas saisir une opération, sa création étant alors assurée de manière automatique lors du traitement du relevé qui la contient. - Présentez une solution permettant de prendre en charge cette nouvelle possibilité en décrivant sous la forme de votre choix le traitement automatique d'un relevé téléchargé depuis l'établissement bancaire. L'interaction avec les données décrites au point A doit être mise en évidence. Remarque : la structure du relevé importe peu, il contient au minimum le numéro du compte, les dates des soldes précédent et à nouveau, la description de chaque opération (date, libellé, montant débité, montant crédité).