DÉVELOPPEMENT D'APPLICATIONS AVEC ...






COURS 7 - EXERCICES DE MODÉLISATION


L'ÉDITEUR







L'éditeur publie des livres. Chaque livre est écrit par un seul auteur. Aussi, chaque livre est évalué et corrigé par un rédacteur ou parfois, par plusieurs rédacteurs qui corrigent chacun une partie du livre. Certains livres sont publiés par une filiale spécialisée.
Chaque livre est identifié par son ISBN et possède un titre, date de publication et prix de vente. On identifie l'auteur par son nom car on n'a jamais 2 auteurs avec le même nom. On garde aussi son adresse et son numéro de téléphone ainsi que sa date de naissance et son sexe car il faut parfois noter ces informations dans la publicité. Le rédacteur, identifié par son nom, a une spécialité dans laquelle il travaille. Pour la filiale on lui donne un code de compagnie et on note le nom de l'entreprise et son adresse ainsi que la catégorie principale de livres qu'elle publie.

Après avoir étudié les notes prises lors de l'entrevue avec le client, on commence la modélisation:

Après avoir dessiné une première ébauche, il faut raffiner le diagramme. Ce processus s'appelle normalisation. Au cours suivants on étudiera la méthode formelle de normalisation mais, disons pour l'instant qu'il s'agit de spécifier les relations entre les entités sous une forme que le logiciel SGBD pourra comprendre. On modifie notre ERD pour montrer les relations sous forme d'entités.

D'abord, on règle la relation Livre --> Auteur; puisque c'est une relation de type 1:M (1 livre est écrit par 1 auteur mais 1 auteur peut écrire plusieurs livres) on inscrit le nom de l'auteur (clé primaire de Auteur) dans l'entité Livre. On doit noter que l'inverse est impossible.

Dans la description des relations entre entités on utilise souvent le terme Parent --> Enfant. En général, un parent peut avoir plusieurs enfants mais, chaque enfant n'a qu'un parent. Dans l'exemple ci-haut, Livre est l'enfant et Auteur est le parent. En insérant le nom du parent dans l'entité enfant, on peu l'identifier facilement.


Pour la relation Livre --> Filiale on utilise la même technique: clé primaire de Filiale dans l'entité Livre.

Pour Livre --> Rédacteur c'est un peu plus compliqué: on ne peut pas mettre le nom du rédacteur dans Livre puisqu'il y en a plusieurs et on ne peut pas mettre l'ISBN du livre dans Rédacteur parce qu'il y en a plusieurs aussi. La solution est de créer une entité de relation entre les deux autres. On ajoute une entité CONTRAT avec les attributs appropriés pour lier rédacteur et livre; la clé primaire de CONTRAT sera un numéro de contrat qu'on assigne (la clé pourrait aussi être une clé combinée de l'ISBN et du nom du rédacteur).

En résumé: pour implanter une relation 1:M, il faut insérer la clé primaire de l'entité parent de la relation dans l'entité enfant. Pour implanter une relation M:M il faut créer une nouvelle entité qui sera en relation 1:M avec chacune des deux autres.

Pour un court résumé des notions de RDBMS allez voir Ashok et regardez le lien "Related primers".


LA GESTION DE PROJETS



La compagnie GEN5 INC. se spécialise dans la consultation en systèmes informatiques auprès de l'industrie. À tout moment il y a plusieurs projets en cours et plusieurs soumissions de projets en train d'être négociées. Chaque projet actif emploie plusieurs employés mais, pas exclusivement - au cours d'une semaine donnée, un employé peut travailler sur 2 ou 3 projets différents. Ceci est important quand il faudra établir les coûts du projet et savoir si on a fait un profit ou une perte sur ce projet. Certains employés affectés à la gestion ne sont assignés à aucun projet.

Quand vient le moment de faire une soumission pour un nouveau projet, il faut regarder le dossier des employés qui pourraient exécuter ce projet. Il faudra avoir l'ancienneté de l'employé (ie. le nombre d'années en Informatique) et l'expérience de l'employé avec chaque langage. Tous les employés maîtrisent au moins un langage de programmation et on garde le nombre d'années d'expérience avec chaque langage.

Notre première ébauche de ER pourrait ressembler à ceci:



Cette fois nous utilisons une notation différente pour la structure: une liste structurée

Projet
   Numéro-projet
   Titre
   Date-début
   Date-fin
   Chef
   Employé *
      Id
      Nom
      Adresse
      Date-embauche
      Salaire
      Telephone
      Nb-heures
      Langage *
         Code-lang
         Nom-Langage
         Cat-Langage
         Experience
   Montant-dépensé




[ PAGE TITRE ]      [ PRÉCÉDENTE ]      [ SUIVANTE ]