Est-ce que ce schéma semble correct ?

Version imprimable

Salut,

Avant de démarrer concrètement le développement et sur conseil d'un modérateur, je poste mon schéma en espérant que vous pourrez peut-être proposer des améliorations.

je pense démarrer en Symfony 1.4 avec Doctrine et MySQL :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
CREATE TABLE `Client` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Nom` varchar(150) NOT NULL,
  `Prenom` varchar(150) NOT NULL,
  `Sexe` tinyint(4) NOT NULL,
  `Naissance` date NOT NULL,
  `AdrRue` varchar(150) DEFAULT NULL,
  `AdrNoPost` int(11) DEFAULT NULL,
  `Canton` varchar(150) DEFAULT NULL,
  `TelPriv` varchar(150) DEFAULT NULL,
  `TelProf` varchar(150) DEFAULT NULL,
  `Email` varchar(150) DEFAULT NULL,
  `DetenteurNo` int(11) DEFAULT NULL,
  `DetenteurDate` date DEFAULT NULL,
  `PermisNo` int(11) DEFAULT NULL,
  `PermisDate` date DEFAULT NULL,
  `Commentaire` varchar(150) DEFAULT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;
 
 
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `ClientCours` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Cours_ID` int(11) NOT NULL,
  `Client_ID` int(11) NOT NULL,
  `Reussi` tinyint(1) DEFAULT '0',
  `Modifie` tinyint(1) DEFAULT '0',
  `DateInscription` date DEFAULT NULL,
  PRIMARY KEY (`ID`),
  KEY `fk_ClientCours_1` (`Client_ID`),
  KEY `fk_ClientCours_2` (`Cours_ID`),
  CONSTRAINT `fk_ClientCours_1` FOREIGN KEY (`Client_ID`) REFERENCES `Client` (`ID`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `fk_ClientCours_2` FOREIGN KEY (`Cours_ID`) REFERENCES `Cours` (`ID`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;
 
 
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `Cours` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Moniteur_ID` int(11) DEFAULT NULL,
  `Nom` text NOT NULL,
  `DateDebut` date NOT NULL,
  `DateFin` date NOT NULL,
  `NbMax` int(11) NOT NULL,
  `Prix` decimal(10,0) DEFAULT NULL,
  `Annule` int(11) DEFAULT NULL COMMENT 'Si le cours n''a pas été annulé, valeur NULL (defaut).\n\nSi le cours a été annulé : id de l''utilisateur qui a annulé',
  PRIMARY KEY (`ID`),
  KEY `fk_Cours_1` (`Moniteur_ID`),
  KEY `fk_Cours_2` (`Moniteur_ID`),
  CONSTRAINT `fk_Cours_2` FOREIGN KEY (`Moniteur_ID`) REFERENCES `Utilisateur` (`ID`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT `fk_Cours_1` FOREIGN KEY (`Moniteur_ID`) REFERENCES `Moniteur` (`ID`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;
 
 
DROP TABLE IF EXISTS `Moniteur`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `Moniteur` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Nom` varchar(45) NOT NULL,
  `Prenom` varchar(45) DEFAULT NULL,
  `Telephone` varchar(45) DEFAULT NULL,
  `Mobile` varchar(45) DEFAULT NULL,
  `AdresseRue` varchar(255) DEFAULT NULL,
  `AdresseCP` int(11) DEFAULT NULL,
  `AdresseVille` varchar(45) DEFAULT NULL,
  `AdressePays` varchar(45) DEFAULT NULL,
  `Email` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Table des moniteurs';
/*!40101 SET character_set_client = @saved_cs_client */;
 
 
CREATE TABLE `Session` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Cours_ID` int(11) DEFAULT NULL,
  `Moniteur_ID` int(11) DEFAULT NULL,
  `DateDebut` datetime NOT NULL,
  `DateFin` datetime NOT NULL,
  `Lieu` text NOT NULL,
  PRIMARY KEY (`ID`),
  KEY `fk_Session_1` (`Cours_ID`),
  CONSTRAINT `fk_Session_1` FOREIGN KEY (`Cours_ID`) REFERENCES `Cours` (`ID`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;
 
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `Utilisateur` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Username` varchar(45) NOT NULL,
  `Password` varchar(45) NOT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

Les clients s'inscrivent à des cours.

Les cours sont constitués de sessions. Les cours sont donnés par un moniteur.

Merci d'avance

Un outil d'analyse tel que MySqlWorkbench ne devrait jamais servir à générer définitivement le shema.yml d'une application symfony 1.4. En effet, si fichier permet de générer la base de donnée il permet surtout de créer le modèle objet sous jacent qui sera notre interlocuteur principale. C'est aussi lui qui génèrera les objets form et filter.

La moins mauvaise méthode consiste alors à générer un fichier yaml directement depuis le logiciel et à l'optimiser à la main. Créer la base et en recupérer un shema.yml conduit inéluctablement à des situations difficiles à gérer.

Pour ta base, le fichier shema devrait ressembler à ceci (fait à ma façon).
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 //shema.yml Client: columns: //id créé automatiquement nom: type: string(150) notNull: true prenom: type: string(150) notNull: true sexe: integer(1) naissance: type: date notNull: true adr_rue: string(150) adr_no_post: string(11) // le code postal est une valeur texte, même s'il n'y a que des chiffres canton: string(150) tel_priv: tel_prof: email: string(255) //peut être très long detenteur_no: integer(8) // est-ce bien du numérique ? detenteur_date: date permis_no: integer(8) // est-ce bien du numérique ? permis_date: date commentaire: string(150) //mal toléré par la CNIL dans une fiche individuel ClientCour: //c'est un objet cour_client qui est décrit columns: cour_id: i type: integer primary: true client_id: type: integer primary: true reussi: boolean modifie: boolean date_inscription: date relations: cour: foreignAlias: ClientCours client: foreignAlias: ClientCours Cour: columns: moniteur_id: relations: clients: class: Client refClass: ClientCour foreignAlias: cours moniteur: foreignAlias: cours moniteur: columns: nom: string(150) ...
Ce shéma par de l'appriori qu'un client ne peut être inscrit qu'une fois à un cours. Dans le cas contraire, la structure de la table ClientCour et de ces relations doit être revue.

Tu trouveras de nombreuses interventions de ma part où j'explique le pourquoi des décisions techniques et sémantiques prise dans le schéma, n'hésite pas à poser toutes les questions qui te restent, il est indispensable que ce schéma soit le tiens et que tu en acceptes toutes les implications.

18/04/2011, 19h06
lr

Merci pour ta réponse, mais je ne suis pas sûr de comprendre ce que tu dis. Ce que j'ai fait, c'est générer la base de données avec MySQL Workbench puis générer le schema.yml, les objets métiers et les formulaires avec les commandes symfony. C'est une mauvaise méthode ?
19/04/2011, 09h59
Michel Rotta

Oui.

Tu as fait une analyse de base, tu as généré la base et tu en as récupéré un shema.yml dans symfony.

Le problème est que ce shema est à l'image de ta base. Hors il devrait être à l'image de ton modèle objet, la base générée ne doit être que le résultat du modèle. Pas le contraire.

Tupeux utilise MySqlWorkbench pour l'analyse. Il a un bon module qui permet d'exporter directement en yaml. Là il faut affiner le code généré pour qu'il colle avec les objets que tu souhaites utiliser. Ensuite tu vas générer ta base à partir de ce shema.yml optimisé à la main.

C'est la meilleur solution.
19/04/2011, 13h02
lr

Je pense que ça dépend du point de vue, si on se place du coté des données ou du coté fonctionnel.

J'ai eu l'habitude de commencer par le modèle de données et j'ai considéré que c'est dans ce sens que les outils d'ORM comme doctrine et propel sont conçus (permettre d'abstraire la base de données), tout comme les commandes symfony.

Mais il est vrai que les deux approches me semblent possibles mais je ne vois pas ce qui rend supérieur le fait d'utiliser le schema.yml comme point de départ plutôt que la base de données...
19/04/2011, 14h33
Michel Rotta

Attention, ne pas mal interpréter ce que je dis.

Il est bon de commencer par analyse les données que l'on veut traiter, étant un "ancien" je commence par mon MCD pour arriver à mon MPD.

C'est ensuite que je parts du modèle objet pour générer les objets qui me conviendrons en terme de développement et qui colleront au plus prêt du MPD précédant.

A noter que, de plus en plus, je considère que l'étude des objets du modèle devrait se suffire à elle même et que si elle est correctement faîte, elle ne peut que générer une structure viable.

Reste que ce qui est utilisé en programmation est le modèle, pas le physique. Il convient de prendre cela en compte et d'écrire le modèle le plus intéressant pour qu'il facilite notre travail de développeur.
19/04/2011, 14h37
lr

Je suis d'accord, excepté quand tu dis que l'étude des objets du modèle devrait se suffire à elle même car les contraintes d'intégrité sont définies dans la base, pas dans les objets. Sauf bien sûr si tu parles du schema.yml et pas du diagramme de classes (moi aussi j'ai été formé à Merise mais j'utilise aussi UML ;)).