Livrable 3.1 pour le projet Productel

Thèmes abordés

Livrable 3.1, projet Productel, base de donnée, traitement des informations de production, Modèle Conceptuel de Données, Modèle Logique de Données

Résumé du document

Le travail demandé dans ce livrable, est la réalisation de la conception de la base de donnée, ainsi que de sa description. Il s'agira du système de traitement des informations de production de Productel.
Pour réaliser ce livrable, nous nous sommes d'abord concerté en groupe pendant environ 2h en développant un Modèle Conceptuel de Données (MCD) directement sur un tableau. Chacun pouvait alors s'exprimer, exposer ses idées, auxquelles suivait une modification du modèle si tous les membres du groupe étaient en accord avec la proposition. Après deux heures de réflexion, nous avions donc établi ce que nous pensions être le Modèle Conceptuel de Données (MCD) adéquat pour le projet Productel.

Extraits

[...] La clé primaire d'un opérateur correspondra à un numéro unique pour chaque opérateur. Il peut y avoir plusieurs opérateurs de même type (ex : 20 opérateurs operateurs 2). Cela dépend des postes qu'il occupe. Pour cela, nous avons ajouté l'attribut libelle. Ensuite pour chaque type d'opérateur, il y a un salaire différent. Personnel Personnel id_personnel nom prénom date_naissance adresse code_postal ville Cette table permet de gérer le personnel de manière général. La clé primaire correspondra à un numéro unique pour chaque personne. [...]

[...] Après deux heures de réflexion, nous avions donc établi ce que nous pensions être le Modèle Conceptuel de Donnée (MCD) adéquat pour le projet Productel. Une fois le modèle réalisé, nous nous sommes réparti le travail, pour les derniers jours précédents le rendu, de la manière suivante ; Marjorie et Rémi se concentrés sur la réalisation du rapport tandis qu'Antoine réalisé le Modèle Logique de Donnée (MLD) en adéquation avec le Modèle Conceptuel de Donnée (MCD) établi. Aurélie et Hugo devait quant à eux vérifier la justesse du MCD notamment sur le plan des formes normales. [...]

[...] Il peut aussi avoir un double statut et être opérateur A et B par exemple. D'où les cardinalités 0,n. Le statut opérateur peut être associé à plusieurs membre du personnel comme à aucun, d'où la cardinalité 0,n. Composant 0,n fournir 1,1 Fournisseur Cette association permet de lier les composants aux fournisseurs. Un composant est fournit par un seul fournisseur, d'où les cardinalités 1,1. Un fournisseur peut quant à lui fournir 0 à n composants, d'où la cardinalité 0,n. Produit 0,n appartenir 1,1 Type_produit Cette association permet de lier les produits et leur type. [...]

[...] Le libelle correspond au nom de la famille du produit. Composant Composant id_composant libelle_composant coût Cette table permet de gérer les composants. Sa clé primaire correspondra à un numéro unique pour chaque composant. Le libelle est une description du composant. Nous avons aussi besoin du coût de chaque composant d'où l'intérêt de l'attribut coût. Fournisseur Fournisseur id_fournisseur nom_fournisseur Cette table permet de gérer les fournisseurs. La clé primaire d'un fournisseur est un numéro unique pour chaque fournisseur. Ensuite nous devons enregistrer le nom du fournisseur. [...]

[...] Il s'agira du système de traitement des informations de production de Productel. Dans un premier temps, nous définirons les entités qui semblent essentielles pour ce projet. Nous définirons et expliquerons les champs de chacune des entités du MCD (Modèle conceptuel de données). Nous détaillerons ensuite les cardinalités des associations reliant les différentes entités. A partir du MCD, nous réaliserons le MLD (Modèle logique de données) correspondant à notre base de données, afin de créer les scripts SQL pour le prochain rendu. [...]