Session mai 2022 – Informatique de gestion S4 GA

Énoncé :

Exercice 1

Citer les constituants d’un modèle conceptuel de données avec détails.
Que devient la relation (1, n) et la relation (n, n) dans le modèle physique de données?
Quelle est la différence entre une entité et une association?
Créer le modèle conceptuel de données du besoin suivant :
1. Le mécanicien répare le véhicule d’un client.
2. Le véhicule peut être une voiture un camion ou autre.
3. Durant la réparation, le mécanicien peut changer des pièces.

Exercice 2

Quels étaient les modules de odoo traités en classe?
Quelles sont les paramètres qu’il faut configurer dans odoo 15 pour automatiser l’approvisionnement d’un article?

Exercice 3

Quelle est la différence entre une base de données classique et la blockchain ? Justifier votre réponse.

Note de réponses:

Exercice 1

Les constituants d’un modèle conceptuel de données (MCD) sont les éléments suivants :
- Entités : Ce sont les objets ou concepts importants du système étudié. Les entités représentent des objets du monde réel qui possèdent des propriétés et des relations avec d’autres objets. Exemple : Client, Produit, Commande.
- Attributs : Ce sont les propriétés ou caractéristiques des entités. Les attributs décrivent les informations que l’on souhaite conserver sur chaque entité. Exemple : nom, prénom, adresse pour l’entité Client.
- Relations : Ce sont les liens entre les entités du système. Les relations décrivent comment les entités sont connectées les unes aux autres et définissent des contraintes sur ces connexions. Exemple : un Client peut passer plusieurs Commandes, et une Commande appartient à un seul Client.
- Cardinalités : Elles décrivent la nature des relations entre les entités en termes de quantité. Les cardinalités indiquent combien d’instances d’une entité sont associées à combien d’instances de l’autre entité. Exemple : (1,1), (0,1), (1,N), (0,N), (M,N).
Dans le modèle physique de données (MPD), les relations (1, N) et (N, N) sont généralement traduites comme suit :
- Relation (1, N) : Une relation un-à-plusieurs (1:N) dans le MCD se traduit généralement par une clé étrangère dans la table représentant l’entité « plusieurs » (N) qui fait référence à la clé primaire de la table représentant l’entité « un » (1). Exemple : une table Commande contenant une clé étrangère client_id faisant référence à la clé primaire id de la table Client.
- Relation (N, N) : Une relation plusieurs-à-plusieurs (N:N) dans le MCD nécessite généralement la création d’une table intermédiaire ou d’association pour représenter la relation. Cette table intermédiaire contient des clés étrangères faisant référence aux clés primaires des deux tables d’entités associées. Exemple : une table intermédiaire Commande_Produit contenant des clés étrangères commande_id et produit_id faisant référence aux clés primaires des tables Commande et Produit, respectivement.
La différence entre une entité et une association réside dans leur rôle et leur représentation dans un modèle conceptuel de données :
- Entité : Une entité est un objet ou un concept du monde réel qui possède des attributs et des relations avec d’autres objets. Les entités sont les principaux éléments de données du modèle et correspondent généralement à des tables dans une base de données.
- Association : Une association est une relation entre deux ou plusieurs entités qui décrit comment elles sont liées les unes aux autres. Les associations sont représentées par des lignes reliant les entités dans un MCD et définissent les contraintes et les cardinalités de ces relations. Dans un modèle physique de données, les associations sont généralement représentées par des clés étrangères ou des tables intermédiaires.

Le modèle conceptuel de données basé sur les besoins fournis :
1. Entités :
  - Mecanicien
  - Client
  - Vehicule
  - TypeVehicule
  - Reparation
  - Piece
2. Attributs :
  - Mecanicien : id_mecanicien, nom, prenom, etc.
  - Client : id_client, nom, prenom, etc.
  - Vehicule : id_vehicule, marque, modele, etc.
  - TypeVehicule: id_type, description, etc.
  - Reparation : id_reparation, date_reparation, description, etc.
  - Piece : id_piece, nom_piece, reference, prix, etc.
3. Relations :
  - Une relation « posséder » entre Client et Véhicule :
    1. – Un client possède un ou plusieurs véhicules
    2. – Un véhicule appartient à un et un seul client
  - Une relation « appartenir » entre véhicule et TypeVehicule:
    1. – Un véhicule peut appartenir à un et un seul type
    2. – Un type peut contenir lors de zéro, un ou plusieurs véhicules
  - Une relation « effectuer » entre Mécanicien et Réparation :
    1. – Un mécanicien effectue une ou plusieurs réparations
    2. – Une réparation est effectuée par un et un seul mécanicien
  - Une relation « concerner » entre Réparation et Véhicule :
    1. Une réparation concerne un et un seul véhicule
    2. Un véhicule peut avoir une ou plusieurs réparations
  - Une relation « rechanger » entre Réparation et Pièce :
    1. – Une réparation peut changer zéro, une ou plusieurs pièces
    2. – Une pièce peut être changée lors de zéro, une ou plusieurs réparations
4. Cardinalités :
  1. posséder(Client, Véhicule) : (0, N) – (1, 1)
  2. effectuer(Mecanicien, Reparation) : (0, N) – (1, 1)
  3. concerner(Reparation, Vehicule) : (1, 1) – (0, N)
  4. rechanger(Reparation, Piece) : (0, N) – (1, N)
  5. appartenir(Vehicule, TypeVehicule) : (1, 1) – (0, N)

Notez que vous pouvez ajuster les attributs des entités en fonction des informations spécifiques dont vous avez besoin pour votre application.

Modèle logique de données textuel (MLD)

(réponse supplémentaire)

Mecanicien = (id INT AUTO_INCREMENT, nom VARCHAR(50), prenom VARCHAR(50));
Client = (id INT AUTO_INCREMENT, nom VARCHAR(50), prenom VARCHAR(50));
Piece = (id INT AUTO_INCREMENT, nom_piece VARCHAR(50), reference VARCHAR(50), prix DECIMAL(19,4));
TypeVehicule = (id INT AUTO_INCREMENT, description VARCHAR(50));
Vehicule = (id INT AUTO_INCREMENT, immatriculation VARCHAR(50), marque VARCHAR(50), modele VARCHAR(50), #id_TypeVehicule, #id_Client);
Reparation = (id INT AUTO_INCREMENT, date_reparation DATE, description VARCHAR(50), #id_Mecanicien, #id_Vehicule);
rechanger = (#id_Reparation, #id_Piece);

Code SQL

(réponse supplémentaire)

CREATE TABLE Mecanicien(
   id INT AUTO_INCREMENT,
   nom VARCHAR(50),
   prenom VARCHAR(50),
   PRIMARY KEY(id)
);

CREATE TABLE Client(
   id INT AUTO_INCREMENT,
   nom VARCHAR(50),
   prenom VARCHAR(50),
   PRIMARY KEY(id)
);

CREATE TABLE Piece(
   id INT AUTO_INCREMENT,
   nom_piece VARCHAR(50),
   reference VARCHAR(50),
   prix DECIMAL(19,4),
   PRIMARY KEY(id)
);

CREATE TABLE TypeVehicule(
   id INT AUTO_INCREMENT,
   description VARCHAR(50),
   PRIMARY KEY(id)
);

CREATE TABLE Vehicule(
   id INT AUTO_INCREMENT,
   immatriculation VARCHAR(50),
   marque VARCHAR(50),
   modele VARCHAR(50),
   id_TypeVehicule INT NOT NULL,
   id_Client INT NOT NULL,
   PRIMARY KEY(id),
   FOREIGN KEY(id_TypeVehicule) REFERENCES TypeVehicule(id),
   FOREIGN KEY(id_Client) REFERENCES Client(id)
);

CREATE TABLE Reparation(
   id INT AUTO_INCREMENT,
   date_reparation DATE,
   description VARCHAR(50),
   id_Mecanicien INT NOT NULL,
   id_Vehicule INT NOT NULL,
   PRIMARY KEY(id),
   FOREIGN KEY(id_Mecanicien) REFERENCES Mecanicien(id),
   FOREIGN KEY(id_Vehicule) REFERENCES Vehicule(id)
);

CREATE TABLE rechanger(
   id_Reparation INT,
   id_Piece INT,
   PRIMARY KEY(id_Reparation, id_Piece),
   FOREIGN KEY(id_Reparation) REFERENCES Reparation(id),
   FOREIGN KEY(id_Piece) REFERENCES Piece(id)
);

Exercice 2

Seuls les présents peuvent répondre à cette question.
Pour automatiser l’approvisionnement d’un article dans Odoo 15, nous devons configurer les paramètres suivants :
1. Route d’approvisionnement : Activer la route d’approvisionnement appropriée pour automatiser l’approvisionnement de l’article. Les routes d’approvisionnement courantes sont « Acheter » et « Fabriquer ». Pour activer la route d’approvisionnement, aller dans l’onglet « Inventaire » de la fiche produit et sélectionner la route appropriée.
2. Fournisseurs : Ajouter et configurer les fournisseurs pour l’article. On doit définir le(s) fournisseur(s) ainsi que les prix d’achat, les délais de livraison et les conditions d’achat pour chaque fournisseur. Pour configurer les fournisseurs, aller dans l’onglet « Achat » de la fiche produit et ajouter les informations nécessaires.
3. Règles de réapprovisionnement : Configurer les règles de réapprovisionnement pour déterminer comment et quand l’article doit être réapprovisionné. Pour cela, on doit définir la quantité minimale et maximale en stock et la quantité à commander. Aller dans l’onglet « Logistique » de la fiche produit et ajuster les valeurs « Quantité minimale » et « Quantité maximale ».
4. Emplacement de stockage : Indiquer l’emplacement où l’article doit être stocké dans votre entrepôt. On peut configurer cela dans l’onglet « Inventaire » de la fiche produit en sélectionnant l’emplacement de stockage approprié.
5. Unité de mesure : S’assurer que l’unité de mesure utilisée pour l’article est correctement configurée. Cela peut être ajusté dans l’onglet « Général » de la fiche produit.

En configurant ces paramètres, Odoo 15 automatisera le processus d’approvisionnement pour l’article en fonction des conditions définies. Lorsque le stock d’un article atteint la quantité minimale définie, Odoo générera automatiquement une demande de réapprovisionnement pour commander la quantité requise auprès du fournisseur approprié.

Exercice 3

La différence entre une base de données classique et la blockchain réside principalement dans leur structure, leur mode de fonctionnement, leur sécurité et leur gouvernance. Voici quelques points de différenciation :

Structure :
- Base de données classique : Une base de données classique est généralement centralisée et structurée autour de tables et de schémas prédéfinis. Elle peut être relationnelle (comme MySQL, PostgreSQL) ou non relationnelle (comme MongoDB, Cassandra).
- Blockchain : La blockchain est une base de données décentralisée, distribuée et immuable, constituée de blocs liés cryptographiquement. Chaque bloc contient un ensemble de transactions et un lien vers le bloc précédent, formant ainsi une chaîne.
Mode de fonctionnement :
- Base de données classique : Les opérations sur une base de données classique sont effectuées par des administrateurs ou des utilisateurs autorisés, et les modifications sont gérées par un système centralisé.
- Blockchain : Les transactions et les modifications dans une blockchain sont gérées de manière décentralisée par un réseau de nœuds participants, qui vérifient et valident les transactions selon un protocole de consensus.
Sécurité :
- Base de données classique : La sécurité des bases de données classiques repose sur des mécanismes d’authentification et d’autorisation. Cependant, elles sont souvent vulnérables aux attaques, en particulier si le point central de contrôle est compromis.
- Blockchain : La sécurité de la blockchain est assurée par la cryptographie et le consensus décentralisé. Les données sont immuables et pratiquement impossibles à modifier rétroactivement, rendant les blockchains résistantes aux attaques et aux manipulations.
Gouvernance :
- Base de données classique : La gouvernance d’une base de données classique est généralement centralisée et contrôlée par une organisation ou une entité spécifique.
- Blockchain : La gouvernance de la blockchain est décentralisée et basée sur un réseau de participants qui collaborent et prennent des décisions consensuelles.

Conclusion:

La blockchain et les bases de données classiques diffèrent par leur structure, leur mode de fonctionnement, leur niveau de sécurité et leur modèle de gouvernance. La blockchain est décentralisée, sécurisée par la cryptographie et le consensus, et offre une meilleure résistance aux attaques et manipulations. Les bases de données classiques sont centralisées, reposent sur des mécanismes d’authentification et d’autorisation pour la sécurité et sont contrôlées par une organisation ou une entité spécifique.