B T S C G O 2 C O R R I G É D U D E V O I R DOSSIER 2 - ORGANISATION DU SYSTÈME D INFORMATION (P10) A. ANALYSE DU SCHEMA DES DONNEES EXISTANT (7 POINTS) a) Commandes non livrées (2 points) Dans le schéma des données fourni en Annexe 7, il est tout à fait possible de trouver les numéros des commandes non livrées au moment prévu (jour et heure), ainsi que le nom du transporteur : - L entité générique <COMMANDE> comporte les propriétés <N commande> et <Etat commande> (pour une commande non livrée, c est-à-dire en-cours, cette propriété prend la valeur E). - Le moment prévu correspond aux propriétés <Jour prévu> et <Heure prévue> figurant dans l entité spécialisée (ou spécifique) <LIVRAISON TRANSPORTEUR> (on peut donc en déduire que la question ne porte pas sur les commandes livrées par la Poste). - L entité <TRANSPORTEUR> comporte la propriété <Nom transporteur>. La contrainte existante entre l entité générique <COMMANDE> et ses entités spécialisées permet de dire qu une commande livrée par un transporteur trouve son complément d informations dans l entité spécialisée <LIVRAISON TRANSPORTEUR> et on peut lier avec certitude, d une part, les propriétés <N commande> et <Etat commande> et, d autre part, les propriétés <Jour prévu> et <Heure prévue>. Selon les cardinalités entre l entité spécialisée <LIVRAISON TRANSPORTEUR> et l association hiérarchique (ou contrainte d intégrité fonctionnelle) <LIVRER>, une livraison est livrée par un et un seul transporteur. Ainsi, il y a une dépendance fonctionnelle entre les valeurs des propriétés <N commande> et <Nom transporteur>. b) Mode de livraison utilisé par une commande (2 points) Il est tout à fait possible de connaître le mode de livraison utilisé par la commande n 675 relative au client Maison de retraite de Trèbes. Selon les cardinalités entre l entité <COMMANDE> et l association hiérarchique (ou contrainte d intégrité fonctionnelle) <CONCERNER>, une commande concerne un et un seul client. Par conséquent, il y a une dépendance fonctionnelle entre les valeurs des propriétés <N commande> et <Nom client>. Une commande utilise deux modes de livraison. Cela est représentée par la contrainte entre l entité générique <COMMANDE> et ses deux entités spécialisés (ou spécifiques) <LIVRAISON POSTE> et <LIVRAISON TRANS- PORTEUR>. Cette contrainte est schématisée par le sigle + (ou XT) qui représente une contrainte de partition. Une commande utilise forcément soit le mode de livraison Poste, soit le mode de livraison transporteur (la contrainte de couverture est donc respectée), mais ne peut pas utiliser les deux (la contrainte de disjonction est donc respectée). 1
c) Impossibilité de retrouver le fournisseur d un produit lors d une réclamation d un client (3 points) - Cause du problème soulevé par M. ALBERT (1 point) L association non hiérarchique (ou contrainte d intégrité multiple) <FOURNIR> est la cause de la difficulté soulevée par M. ALBERT. En effet, les cardinalités 1,N entre cette association et l entité <PRODUIT> signifient qu un produit est fourni par un ou plusieurs fournisseurs. Par conséquent, il est impossible de trouver pour une occurrence de l entité <PRODUIT> le fournisseur concerné. - Objet <PRODUIT> entité faible (2 points) Si l entité <PRODUIT> est une entité faible (ou dépendante ou relative) de l entité forte (ou principale) <FOURNIS- SEUR>, cela serait représenté dans le schéma des données par des cardinalités 1,1 notées entre parenthèses entre l entité <PRODUIT> et l association <FOURNIR>. Ainsi, l entité faible <PRODUIT> possèderait un identifiant relatif par rapport à l identifiant de l entité forte <FOURNISSEUR>, ce qui permettrait d identifier pour chaque produit le fournisseur qui a livré celui-ci. B. EXPLOITATION DE LA BASE DE DONNEES (14 POINTS) 1 ) Réalisation de requêtes SQL (10 points) a) Liste des commandes dont l état de commande est «rejeté» (3 points) La liste des attributs à afficher est indiquée dans l intitulé de la requête. Les attributs à indiquer dans l ordre SELECT (critère de projection) ne pose pas de problème, sauf qu il faut préciser devant l attribut <Code client> le nom de la relation <CLIENT> car cet attribut figure dans les deux relations utilisées par cette requête. Cette requête nécessite d utiliser deux relations, d où un critère de jointure réalisé à partir de l attribut commun <Code client>. Le critère de sélection est à réaliser sur l attribut <Etat commande> à partir de la valeur R (indication fournie en Annexe 7). SELECT CLIENT.Code client, Nom client, N commande, Date commande FROM COMMANDE, CLIENT WHERE CLIENT.Code client = COMMANDE.Code client AND Etat commande = 'R' b) Nombre total de clients par type (4 points) La liste des attributs à afficher est indiquée dans l intitulé de la requête. Les attributs à indiquer dans l ordre SELECT (critère de projection) ne pose pas de problème, sauf qu il faut réaliser un comptage du nombre de clients (opérateur COUNT suivi d un alias précédé de l opérateur AS). Cette requête nécessite d utiliser deux relations, d où un critère de jointure réalisé à partir de l attribut commun <N type>. Pour pouvoir afficher le nombre de clients par type de clients, il faut utiliser l opérateur de regroupement GROUP BY. À l intérieur des parenthèses de l opérateur COUNT, il est possible de remplacer l attribut Code client par le symbole *. SELECT Libelle type, COUNT ( Code client ) AS "Nombre de clients" FROM CLIENT, TYPE CLIENT WHERE TYPE CLIENT.N type = CLIENT.N type GROUP BY Libelle type 2
c) Liste des clients n ayant pas passé commande depuis le 1 er janvier 2010 (3 points) Cette requête nécessite d utiliser des requêtes imbriquées d interrogation : une requête principale et une sous-requête combinée entre elles grâce à l opérateur ensembliste de différence NOT IN utilisant l attribut commun <Code client>. La liste des attributs à afficher dans l ordre SELECT de la requête principale ne pose pas de problème. Cette requête principale nécessite d utiliser uniquement la relation <CLIENT> (pas de jointure). La sous-requête doit s écrire entre parenthèses et nécessite d utiliser deux attributs : <Code client> et <Date commande>, tous les deux attributs de la relation <COMMANDE> (pas de jointure également dans la sous-requête). Le critère de sélection de la sous-requête utilise l attribut <Date commande> dont les valeurs doivent s écrire entre quotes (ou guillemets simples). SELECT Nom client, Prénom client, Ville client FROM CLIENT WHERE Code client NOT IN ( SELECT Code client FROM COMMANDE WHERE Date commande >= '01/01/2010' ) 2 ) Annexe C Algorithme à compléter (4 points) Selon les informations fournies par l Annexe 9, le calcul de la commission sur commandes du mois se fait par tranches. Il y a donc quatre solutions possibles (impliquant dans l algorithme une structure conditionnelle imbriquée) : - Si le nombre de commandes est inférieur à 6, le montant de cette commission est nul (élément figurant déjà en Annexe C). - Si le nombre de commandes est inférieur à 11 (et forcément supérieur à 6 car dans l instruction SINON de la première condition), le montant de cette commission est égal à : (Total Cdes 5 commandes) x 50. - Si le nombre de commandes est inférieur à 16 (et forcément supérieur à 11 car dans l instruction SINON de la deuxième condition), le montant de cette commission est égal à : (5 commandes x 50 ) + (Total Cdes 10 commandes) x 80 ou 250 + (Total Cdes 10 commandes) x 80. - Si le nombre de commandes est supérieur ou égal à 16 (forcément dans l instruction SINON de la troisième condition), le montant de cette commission est égal à : (5 commandes x 50 ) + (5 commandes x 80 ) + (Total Cdes 15 commandes) x 150 ou 650 + (Total Cdes 15 commandes) x 150. Si Total Cdes < 6, Alors Comm. Commandes <= 0 Sinon SI Total Cdes < 11 ALORS Comm. Commandes ( Total Cdes 5 ) x 50 SINON SI Total Cdes < 16 ALORS Comm. Commandes 250 + ( Total Cdes 10 ) x 80 SINON Comm. Commandes 650 + ( Total Cdes 15 ) x 150 FINSI Finsi FINSI 3
C. ÉVOLUTION DE LA BASE DE DONNEES (10 POINTS) Le schéma des données du domaine des contrats de maintenance (Annexe D) à partir des informations fournies par l Annexe 10 est le suivant : - Il faut créer une entité <CONTRAT MAINTENANCE> comprenant trois propriétés : <N contrat> (propriété à souligner car c est l identifiant de cette entité), <DateDébutContrat> et <DateFinContrat> (ces deux dernières propriétés peuvent être respectivement remplacées par <DateSignatureContrat> et <DuréeContrat>). - Il faut ensuite relier cette entité <CONTRAT MAINTENANCE> à l entité <CLIENT> par l association <SOUSCRIRE>. - Entre l entité <CLIENT> et l association <SOUSCRIRE>, les cardinalités sont 0,N car il est indiqué en Annexe 10 que les clients peuvent souscrire des contrats de maintenance, ils ne sont donc pas obligés (d où la cardinalité minimale 0). - Entre l entité <CONTRAT MAINTENANCE> et l association <SOUSCRIRE>, les cardinalités sont à indiquer sont impérativement 1,1 car un contrat de maintenance est souscrit par un et un seul client. On en déduit que l objet <SOUSCRIRE> est une association hiérarchique (ou contrainte d intégrité fonctionnelle). - L entité générique <CONTRAT MAINTENANCE> doit être éclatée en deux entités spécialisées (ou spécifiques) <REEL> et <FOR- FAIT> et indiquer la contrainte entre cette entité générique et ses deux entités spécialisées. Rappel : une contrainte est représentée par une flèche (simple ou double) à destination de l entité générique. - Chaque entité spécialisée comprend une seule propriété <MontantForfait> pour <FORFAIT> et <TarifHoraire> pour <REEL> (Rappel : une entité spécialisée ne comporte jamais d identifiant). - Un contrat de maintenance est forcément soit un contrat forfaitaire, soit un contrat réel (la contrainte de couverture est donc respectée) et ne peut être les deux à la fois (la contrainte de disjonction est donc respectée). Par conséquent, la contrainte à indiquer dans le schéma des données entre l entité <CONTRAT MAINTENANCE> et ses entités spécialisées est une contrainte de partition (notée + ou XT). - L entité spécialisée <REEL> est à relier à l entité PRODUIT (et éventuellement à l entité <CLIENT>) par l association <PORTER SUR>. - Entre l entité <REEL> et l association <PORTER SUR>, les cardinalités sont 1,1 car un contrat réel porte sur un et un seul produit. On en déduit que l objet <PORTER SUR> est une association hiérarchique (ou contrainte d intégrité fonctionnelle). - Entre l entité <PRODUIT> et l association <PORTER SUR>, les cardinalités sont à indiquer sont 0,N car un produit peut faire l objet de zéro ou de plusieurs contrats réels de maintenance. D. ANALYSE DU TRAITEMENT DES COMMANDES DE CONSOMMABLES (9 POINTS) Le schéma de flux du domaine «Gestion des commandes de consommables» (Annexe E) à partir des informations fournies par l Annexe 11 comporte les flux d information suivants (ne pas confondre flux d information et traitement, c est-à-dire action sur les données) : - Le flux d information <1 Bon de commande> est erroné car il ne relie pas l activité <Traitement des commandes clients> du domaine d étude. Il faut donc le corriger en conséquence. - Le flux d information <2 Mise en attente de la commande> est généré par l activité <Traitement des commandes clients> à destination de l acteur externe <Clients>. - Le flux d information <3 Double du bon de livraison> est généré par l activité <Traitement des commandes clients> à destination du domaine connexe <Domaine «Préparation Expédition»>. - Le flux d information <4 Demande de délai supplémentaire> est généré par l activité <Traitement des commandes clients> à destination de l acteur externe <Clients>. - Le flux d information <5 Accord sur délai> est généré par l acteur externe <Clients> à destination de l activité <Traitement des commandes clients>. - Le flux d information <6 Demande d approvisionnement> est généré par l activité <Traitement des commandes clients> à destination de l activité <Lancement des commandes fournisseurs> (flux d information interne au domaine d étude). - Le flux d information <7 Demande de prix et de disponibilité> est généré par l activité <Lancement des commandes fournisseurs> à destination de l acteur externe <Fournisseurs>. - Le flux d information <8 Réponse sur prix et disponibilité> est généré par l acteur externe <Fournisseurs> à destination de l activité <Lancement des commandes fournisseurs>. - Le flux d information <9 Commande auprès du fournisseur retenu> est généré par l activité <Lancement des commandes fournisseurs> à destination de l acteur externe <Fournisseurs>. 4
PRODUIT Code produit 0,N Désignation produit Prix catalogue PORTER SUR 1,1 REEL CONTRAT MAINTENANCE TarifHoraire N Contrat DateDébutContrat DateFinContrat + FORFAIT 1,1 MontantForfait SOUSCRIRE CLIENT Code client 0,N Nom client Prénom client Rue client Ville client CP client 5
Clients Fournisseurs Domaine Domaine des commandes de consommables Traitement des commandes clients 3 «Préparation Expédition» 1 2 4 5 6 Lancement des commandes fournisseurs 7 8 9 Légende des flux : 1 Bon de commande 2 Mise en attente de la commande 3 Double du bon de livraison 4 Demande de délai supplémentaire 5 Accord sur délai 6 Demande d approvisionnement 7 Demande de prix et de disponibilité 8 Réponse sur prix et disponibilité 9 Commande auprès du fournisseur retenu 6