Devoir 1 corrige - Modélisation Merise

Ce document présente le corrigé du Devoir n°1 d'Organisation du Système d'Informations, destiné spécifiquement aux étudiants de BTS CGO 2A. Il vise à consolider et approfondir leur compréhension des principes de gestion des systèmes d'information en entreprise.

Il couvre les notions suivantes:

L'analyse et l'interprétation de systèmes d'information existants.
L'élaboration de requêtes SQL pour l'exploitation de bases de données.
La modélisation conceptuelle de données et l'extension de schémas.
La conception d'algorithmes pour la gestion des fournisseurs.

Modélisation Merise : Devoir 1 corrige

Télécharger PDF

Organisation du Système d’Informations - Corrigé de Devoir

I - Analyse du système d’information existant

A. Étude du schéma de fourniture des barrières aux clients

1. D'après le schéma, avons-nous plusieurs fournisseurs par composant ?

Non, car "NomFournisseur" est une propriété de l’entité "Composant". Par conséquent, à chaque composant correspond un et un seul nom de fournisseur. Il n’est pas possible d’avoir plusieurs fournisseurs pour un même composant.

2. Les schémas des données permettent-ils d’obtenir les informations suivantes ?

a - La connaissance du nombre de ruptures de stock par composant.

Le nombre de ruptures de stock peut être déterminé d’après l’association « être en rupture ». Cette association est reliée à l’entité "Composant" et permet de connaître la date de chacune des ruptures de stock d'un composant. Il est donc possible de connaître le nombre de ruptures de stock par composant en réalisant une requête.

b - La détermination des retards de fabrication des produits commandés par un client.

Oui, parce que :

Les propriétés nécessaires existent : "DateFinFab" se trouve dans l’entité "OrdreFabrication" et "DateRéalPrévue" est dans l'entité "CommandeCli".
Les entités sont reliées : l'entité "OrdreFabrication" est reliée à l'entité "CommandeCli" par l'association "Déclencher".

Il suffit de comparer la dernière "DateFinFab" de l’entité "OrdreFabrication" avec la "DateRéalPrévue" de l’entité "CommandeCli" pour une commande donnée.

c - La connaissance du prix des composants du produit « barrière LBA12 ».

L'association "Composer" est une association ternaire qui relie "Produit", "CommandeCli" et "Composant". Le produit "Barrière LBA12" peut donc contenir plusieurs composants en fonction du client. Si l'on connaît la commande client, on obtiendra une liste précise des produits et donc des prix.

Le prix des composants est inclus dans la relation Composant. La donnée est donc présente et peut être listée avec les bons critères : la référence du produit et le code du client.

B. Exploitation de la base de données

1. Expliquer la présence dans la relation « OrdreFabrication » :

de « RéfProduit » dans la clé primaire ;
de « NumCdeCli » en clé étrangère.

"RéfProduit" dans la clé primaire : L’entité « OrdreFabrication » est une entité relative (ou entité faible ou entité dépendante) de l’entité « Produit ». Par conséquent, la relation issue de l’entité « OrdreFabrication » hérite en clé primaire de la clé primaire de la relation issue de l’entité « Produit ».

"NumCdeCli" en clé étrangère : L’entité « OrdreFabrication » est en dépendance fonctionnelle avec l’entité « CommandeCli ». Par conséquent, la relation issue de l’entité « OrdreFabrication » hérite en clé étrangère de la clé primaire de la relation issue de l’entité « CommandeCli ».

2. Rédiger les requêtes SQL permettant d’obtenir :

a. la liste des composants et le fournisseur (désignComp, NomFournisseur) pour lesquels la société a connu un retour de livraison durant l’année 2013 ;

SELECT DesignComp, NomFournisseur
FROM COMPOSANT, RETOURNER
WHERE COMPOSANT.RefComp = RETOURNER.RefComp
AND Date BETWEEN #01/01/2013# AND #31/12/2013#;

-- La dernière ligne peut être remplacée par :
-- AND YEAR(DATE) = 2013;

b. le nombre de ruptures de stock par composant pour l’année 2013 (désignComp, NomFournisseur) ;

SELECT DesignComp, NomFournisseur, COUNT([ETRE EN RUPTURE].RefComp)
As NbreDeRuptures
FROM COMPOSANT, [ETRE EN RUPTURE]
WHERE COMPOSANT.RefComp = [ETRE EN RUPTURE].RefComp
AND Date BETWEEN #01/01/2013# AND #12/31/2013#
GROUP BY DesignComp, NomFournisseur;

c. l’ajout du nouveau produit LBA4 dans la base de données : LBA4, barrière pour résidence, 1 700,34 € ;

INSERT INTO PRODUIT (RefProduit, DesigProd, PVHTProd)
VALUES ('LBA4', 'barrière pour résidence', 1700.34);

II – Nouvelle politique d’approvisionnement et système d’information

A. Extension du schéma de données

1. Compléter et mettre à jour le schéma conceptuel de données afin de proposer une spécialisation des fournisseurs et la possibilité d’enregistrer plusieurs fournisseurs pour un même composant.

(Cette question implique une modification du modèle de données, par exemple l'introduction d'une entité "Spécialisation" liée aux fournisseurs et une table d'association entre "Fournisseur" et "Composant" pour gérer la cardinalité multiple.)

B. Choix de nouveaux fournisseurs

1. Justifier par le calcul la décision du maintien du fournisseur CATERPRO dans la table des fournisseurs.

Calcul : 12/05 – 07/05 = 5 jours. Or, 5 <= 10 + 2 (délai négocié plus marge).

Conclusion : Le fournisseur existant Caterpro est maintenu dans la table des fournisseurs LBA puisque le délai réel de livraison est inférieur ou égal au délai de livraison négocié augmenté d'une tolérance.

2. Indiquer quelle sera la décision (maintien ou suppression) pour THALES. Justifier la réponse.

Calcul : 12/05 – 14/04 = 29 jours. Or, 29 > 15 + 2 (délai négocié plus marge).

Conclusion : Le fournisseur existant Thales est supprimé de la table des fournisseurs LBA puisque le délai réel de livraison est supérieur au délai de livraison négocié augmenté d'une tolérance.

3. Algorithme de choix des fournisseurs.

Déclaration des variables
 NbreFour : entier           -- Nombre de fournisseurs à traiter
 NomFour : chaîne de caractères -- Nom du fournisseur
 SF : chaîne de caractères    -- Spécialisation du Fournisseur
 PA : réel                   -- Prix d’achat d’un composant
 Décision : chaîne de caractères -- « Accepté » ou « Refusé »
 I : entier                  -- (Compteur)

Début
 Saisir NbreFour
 POUR I de 1 à NbreFour
  Saisir NomFour
  Saisir PA
  Saisir SF
  Décision ← « Refusé »
  SI SF = « Tôlerie » ALORS
   SI PA <= 220 ALORS
    Décision ← « Accepté »
   FIN SI
  SINON SI SF = « Mécanique » ALORS
   SI PA <= 360 ALORS
    Décision ← « Accepté »
   FIN SI
  SINON SI SF = « Bras de barrière » ALORS
   SI PA <= 230 ALORS
    Décision ← « Accepté »
   FIN SI
  FIN SI
  Imprimer NomFour, Décision
 FIN POUR
FIN

-- D'autres solutions sont possibles, par exemple :
-- SI SF = « Tôlerie » ET PA <= 220 ALORS
--  Décision ← « Accepté »
-- SINON SI SF = « Mécanique » ET PA <= 360 ALORS
--  Décision ← « Accepté »
-- SINON SI SF = « Bras de barrière » ET PA <= 230 ALORS
--  Décision ← « Accepté »
-- SINON
--  Décision ← « Refusé »
-- FIN SI

Schéma conceptuel de données (extrait tel que présenté dans la source)

0,n
0,n
0,n
Appartenir
1,1
Fournisseur
NumFrs
NomFrs
AdrueFrs
AdvilleFrs
AdrCPFrs
Délai de livraison
Réaliser
1,N
CommandeFournisseur
N°commande
DateCommande
DateLivraisonPrévue
DateLivraisonRéelle
Composants
RefComp
DésignComp
PUHTComp
NomFournisseur
StockSecurite
StockInitial
EtatStock
Famille
Composants
CodeFamComp
NomFamComp
1,n
1,1
Calendrier
Date
Livrer
QtéLivrée
0,n
Retourner
NombreRetournés
0,n
Être en rupture
0,n
Spécialisation
CodeSpé
LibelléSpé
Posséder
Commander
QtéCommandée
1,1 1,N
1,n
1,n
Accepté : association
Posséder avec Famille
Composant

Note sur le schéma : Le schéma conceptuel de données ci-dessus est une transcription du texte original. Il est important de noter que pour répondre à l'exigence de la question II.A.1 (plusieurs fournisseurs par composant et spécialisation), une modélisation plus avancée serait nécessaire. Par exemple, l'attribut "NomFournisseur" ne devrait pas figurer directement dans l'entité "Composants" si plusieurs fournisseurs peuvent fournir un même composant; une entité d'association entre "Fournisseur" et "Composant" serait alors appropriée. La structure textuelle et les répétitions ("Composants" deux fois) peuvent prêter à confusion et nécessiteraient une interprétation ou une refonte graphique pour une clarté totale.

FAQ (Foire Aux Questions)

Qu'est-ce qu'une clé primaire et une clé étrangère dans une base de données ?

Une clé primaire est un attribut ou un ensemble d'attributs qui identifie de manière unique chaque enregistrement dans une table. Elle garantit l'intégrité de l'entité en assurant qu'il n'y a pas de doublons. Une clé étrangère est un ensemble d'attributs dans une table qui fait référence à la clé primaire d'une autre table. Elle établit une relation entre les deux tables, assurant l'intégrité référentielle et permettant de lier des données entre différentes entités.

Pourquoi est-il important d'analyser le système d'information existant ?

L'analyse du système d'information existant est cruciale pour comprendre son fonctionnement actuel, identifier ses forces et ses faiblesses, et déterminer si les besoins des utilisateurs sont satisfaits. Elle permet de détecter les goulots d'étranglement, les redondances ou les lacunes, et sert de base à toute évolution ou refonte, assurant que les modifications apportées améliorent l'efficience et la pertinence du système.

Comment la modélisation des données aide-t-elle à la gestion des fournisseurs ?

La modélisation des données permet de représenter de manière structurée les informations relatives aux fournisseurs et à leurs relations avec les composants et les commandes. En définissant clairement les entités (Fournisseur, Composant, Commande) et les associations (Fournir, Commander), elle assure une gestion cohérente des données. Cela facilite le suivi des délais de livraison, l'évaluation des performances des fournisseurs et la prise de décisions éclairées pour leur sélection ou leur maintien, comme illustré par l'algorithme de choix des fournisseurs.