Gestion du système d'information

Améliorer la structure d’une base de données. Cas TLM

Je suis assistante de gestion au sein de l’entreprise Transport Local de Marchandises qui est spécialisé dans le transport routier de marchandises. Je vais remplacer Madame GROS qui part prochainement à la retraite. Actuellement, l’entreprise est en train d’élaborer le projet suivant : remplacer les fiches cartonnées de la gestion des tournées par un modèle relationnel. On me demande de continuer la mise en place de ce modèle relationnel.

• Comprendre le contexte

1. Les informations telles que les clients à livrer, le chauffeur désigné, la ville de départ, la ville d’arrivée ainsi que les endroits auxquels les chauffeurs vont s’arrêter, sont des informations nécessaires à la gestion des tournées.
2. Perte de certaines fiches, se mélanger les pinceaux car mme gros est la seule a gerer les fiches, les autrep peuvent avoir des pb de compréhension, personne d’autre qu’elle peut faire la mise a jour de ces fiches si elle est absente.
3. Si on a certaines infos a lui demander sur les fiches qu’elle a déjà faites, qu’on puisse lui demander.

• Votre mission

1. Ca demande trop de clés primaire concaténé.
2. La donnée manquante est la date d’embauche
3. Non elles ne seront pas toutes au même format : numérique texte booléen (masculin/féminin) date. Ex : Boléen : masculin féminin. Numérique :adresse, nb km,… date : date d’embauche. Texte : nom/prénom chauffeur, adresse….

• Lire le modèle relationnel initial

1. Nb de relation : 4 ( chauffeur, tournée, poids lourd, releve)
2. Eléments entre parenthese : une ligne= une relation. Les attributs. L’attribut souligné = clé primaire.. Les attributs se transformeront en données réelles. Deux clés primaire étrangères dans une même relation= clé primaire concaténée.
3. L’élement qui n’apparait pas est l’attribut clé étrangere : attribut #

• Reperer les erreurs du model initial

1. Car c’est grâce au numéros de chauffeur que l’on retrouve directement le chauffeur. Et il permet de faire le lien avec le numéros de tournée (clé primaire concaténée)
2. Pour retrouver simplement et facilement le releve sans avoir besoin de faire une recherche avancée. A développer
3. La relation poid lourd est isolé car elle n’est relié a aucune autre relation. Il faudrait y insérer le [num_ch]

• Corriger et optimiser le modèle

1. L’adresse a été réparti sur trois attributs car la 1ère forme normale contient des attributs atomique c a d non divisible. On peut pas écrire l’adresse en un seul attribut parce qu’il y a plusieurs type d’informations qui la rue le code postale et la ville.
2. La 2eme forme normale n’est pas respecté car la distribution des trois premiers attributs est mauvaise. La clé primaire mois devrait être séparé des clés concaténées num_ch et num_tour. Il faudrait mettre la clé primaire mois au début de la relation, mettre une virgule et souligné ensuite les deux clés concaténées num_ch et num_tour.
3. La troisieme forme n’est pas respecter car l’attribut Num_permisPL n’a rien a faire dans la relation POIDSLOURDS, puisqu’il ne dépend pas de la clé primaire num_immatric contrairement à tout les autres attributs. La clé primaire num_immatric renseigne sur tout les autres attributs. Il faudrait crée une nouvelle relation PERMIS (Num_permiPL en clé primaire, en attribut date_acq,    FAUX

Elle est pas respecter car la clé primaire n’est pas la bonne, tout les attributsd qui ne sont pas souligné ne dépendent pas au num d’immatriculation . Num permis PL n’est pas en relation directe avec la clé primaire. Il faudrait que la clé primaire soit Num_typePL. Et ainsi tout les autres attributs seraient en relation direct avec cette clé primaire.

...