no way to compare when less than two revisions

Différences

Ci-dessous, les différences entre deux révisions de la page.

@@ Ligne 1: / Ligne 1: @@
+====== 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