jeediagclasses [WIKI SIO : DEPUIS 2017]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Diagramme de classes et Modèle Logique des Données ======

Le diagramme de classes qui est un des 11 schémas UML est le schéma de base, essentiel au développement de la partie modèle d'une application JEE.
Vous trouverez ci-dessous un extrait du diagramme de classes du projet Equida, avec ses règles de gestion et sa transcription en base de données.

===== 
Modèle Général
 =====


===== Relation 1 à n = Relation Many-To-One / One-To-Many =====


  *  Schéma 
{{:jeemanytoone.jpg?150|}}


  *  Règles de gestion 
__Many-To-One :__ Un cheval est caractérisé par une et une seule race (yearling, trotteur, pure-sang, etc...).

__One-To-Many :__ A une race de cheval correspond plusieurs chevaux.


  *  Modèle Logique de Données 

RACE_CHEVAL (id, libelle, description)

clé primaire : id



CHEVAL (id,nom, sexe, sire, dateNaissance, **idRace**)

clé primaire : id

clé étrangère : idRace en référence à id de RACE_CHEVAL



===== L'héritage : Client / Vendeur / Acheteur =====

  * Schéma 

{{:jeeheritage.jpg?400|}}

  *  Règles de gestion 
Il existe deux categories de clients ayant des propriétés communes : les acheteurs et les vendeurs


  *  Modèle Logique de Données 
Il y a 3 solutions pour implémenter un héritage en base de données.

__Solution n°1 :__ **1** classe seulement sera conservée pour la transformation et on créera une nouvelle table permettant de définir le type de client (acheteur ou vendeur) :

TYPE_ACHETEUR (code, libelle)
clé primaire : code

La table client conservent les mêmes propriétés auxquelles on ajoutera une clé étrangère faisant référence à la clé primaire de la table ci-dessus :

CLIENT (id, titre, nom, prénom, .., idTypeAcheteur, **codeTypeAcheteur**)
clé primaire : id
**clé étrangère :  codeTypeAcheteur en référence à code de la table TYPE_ACHETEUR**

__Solution 2 :__ on conserve les **2** classes pour la transformation, chacune, "héritant" des propriétés de la classe mère. la notion de CLIENT disparait alors :
ACHETEUR (id, titre, nom, prénom,..., adresseMessagerie)
clé primaire : id

VENDEUR (id, titre, nom, prénom,..., adresseMessagerie)
clé primaire : id


__Solution 3 :__  les **3** classes seront conservées pour la transformation :

CLIENT (id, titre, nom, prénom,..., adresseMessagerie)
clé primaire : id

ACHETEUR (idAcheteur)
clé primaire : idAcheteur
clé étrangère : idAcheteur en référence à id de la table CLIENT

VENDEUR(idVendeur)
clé primaire : idVendeur
clé étrangère : idVendeur en référence à id de la table CLIENT

Les sous-classes, conservent leurs propres propriétés (lorsqu'il y en a) auxquelles on ajoute une clé primaire qui sera également clé étrangère en référence à la clé primaire de la classe mère.



===== La classe association  =====


  *  Schéma 

  *  Règles de gestion
Un cheval participe à plusieurs courses.
A une course participent plusieurs chevaux.
Pour chaque course, on souhaite conserver la place à laquelle est arrivée le cheval.



  *  Modèle Logique de Données
CHEVAL (id,nom, sexe, sire, dateNaissance, ....)
clé primaire : id

COURSE (id, nom, lieu, date)
clé primaire : id

COURSE_CHEVAL (idcheval, idCourse)
clé primaire : idCheval, idCourse
clé étrangère : idCheval en référence à id de la table CHEVAL
clé étrangère : idCourse  en référence à id de la table COURSE