# Gnral Dveloppement > ALM > Modlisation > Schma >  Savoir si mes tables sont correctes en 3NF

## rise.shine

Bonsoir,
je dois faire la cration de table dans MySQL, avant cela j'aimerai savoir si les table et les dependences fonctionnelles sont tous bien en 3NF?
merci de votre aide par avance.

Salle (NomSalle, Capacit, NomEquipement, NomGes, PrenomGes) 

Spectacle (NomSpectacle, DateDebut_Program, GenreSpectacle, Prix, DateFin_Program, NomSalle)  

Casting (NomActeur, NomSpectacle)  

Acteur (NomActeur, PrnomActeur) 

MiseEnScne (NomMS, NomSpectacle) 

MetteurEnScne (NomMS, PrnomMS) 

Representation (DateRepresentation,  NomSpectacle ,Dure) 

Spectateur (NomSpectateur, PrenomSpectateur, Email, ge, Tel, Categorie) 

Catgorie(Categorie, coefficient,prixPlace) 

Reservation (Email, NumRes, NomSpectateur, Nb_Places, DateReprsentation) 


(ceux qui sont soulign sont les cls primaire)

----------


## escartefigue

Bonjour,

Pour bien rpondre  ce genre de questions, il faut savoir ce que reprsente exactement chaque attribut et quelles sont les rgles de gestion.

Quoi qu'il en soit, pour la premire table, le nom du gestionnaire et son prnom ne dpendent pas de la salle. Cette table n'est donc pas en 3NF.
Si le gestionnaire est en charge de plusieurs salles, alors, en cas d'erreur sur l'orthographe du nom, il faudra modifier toutes les salles o ce gestionnaire intervient. La bonne modlisation est donc une table des salles et une table du personnel, dans laquelle on trouvera non seulement les gestionnaires de salles, mais galement les autres catgories de personnel. 
 l'inverse, la capacit d'une salle est bien dpendante de la salle, cet attribut a donc toute sa place dans cette table.

Il faut appliquer le mme raisonnement pour les autres tables.

Par ailleurs, toutes vos tables ont pour PK une colonne fonctionnelle de type char ou varchar, c'est un trs mauvais choix.
La PK doit tre stable : sa valeur se propage dans d'autres tables pour permettre les contrles d'intgrit (contraintes "foreign key").
Si vous choisissez une ou plusieurs colonne(s) ayant un sens fonctionnel comme PK, alors la valeur peut tre modifie  tout moment. Modification qui se propagera dans les tables lies, ce qui peut provoquer des mises  jour en masse prjudiciables aux performances.
Si au contraire vous utilisez un chrono technique, ce genre de msaventure n'arrive jamais, car la valeur de ce genre de chrono n'a aucune importance, seule son unicit compte.
En plus, dans certains cas, les choix faits ne garantissent aucunement l'unicit qui est une rgle incontournable pour une PK.
Par exemple votre table MetteurEnScne (NomMS, PrnomMS) interdit d'avoir deux metteurs en scnes distincts homonymes, c'est trs restrictif !
Enfin, une PK de type char ou varchar pnalise normment les performances.
C'est pour toutes ces raisons que le plus souvent, on utilise un chrono technique attribu par le SGBD comme PK : c'est une colonne stable et concise dont on n'a mme pas besoin de s'occuper de la valeur, c'est le SGBD qui gre  ::):

----------


## rise.shine

merci de votre rponse , je dois revoir mes tables alors, cependant je vous prsente mes rgles de gestions:
RG 1	Une salle a un seul gestionnaire, un gestionnaire peut grer plusieurs salles 
RG 2	Une salle est utilise pour plusieurs spectacle, Un spectacle est jou dans une seule salle
RG 3	Un spectacle a un seul metteur en scne, un metteur en scne peut travailler sur plusieurs spectacles diffrents
RG 4	Une salle peut avoir plusieurs quipements, un quipement est dans une seule salle (car chaque salle a son equipement particulier)
RG 5	Un acteur peut jouer dans plusieurs spectacles, un spectacle a plusieurs acteurs 
RG 6	Un spectacle peut avoir plusieurs reprsentations/Une reprsentation est joue pour un spectacle
RG 7	Un client peut reserver plusieurs reprsentations/Une reprsentation peut tre reserv par plusieurs clients
RG 8	un spectateur appartient  une seule catgorie pour les rductions (soit prix tudiant, soit prix abonn, soit prix solidarit) 
RG9	un client peut faire plusieurs rservation , une reservation est faite par un seul client

, pour le gestionnaire dpend de ma salle car c'est en fait selon la rgle de gestion 1 salle-->NomGestionnaire, prenomGestionnaire
avec chaque salle ont pourra dernier le gestionnaire qui se charge de la salle...

----------


## rise.shine

Merci de votre rponse: j'ai modifier mes tables en prenant en compte que la PK soit un decimal et non un varchar

Salle(NomSalle, Capacit , NomEquipement) 

Personnels(NomSalle, NomGes, PrenomGes ) 

Spectacle(IdSpectacle, NomSpectacle, GenreSpectacle, DateDebutProgramm, DateFinProgram, Prix, NomSalle) 

Acteurs(NumActeur, NomActeur, PrenomActeur, IdSpectacle) 

MetteurEnScene (NumMS , NomMS, PrenomMS, IdSpectacle) 

Representation (DateRepresentation , idSpectacle , Duree) 

Spectateur ( NumCl, NomCl, PrenomCl, Email, Age, Tel, Categorie) 

Categorie( NumCl, Categorie, Coefficient,  PrixPlace) 

Reservation(NumRes, NumCl, NbPlace, DateRepresentation)

----------


## escartefigue

Bonjour,

Compte tenu de ceci 




> RG 4	Une salle peut avoir plusieurs quipements, un quipement est dans une seule salle (car chaque salle a son equipement particulier)


Cette rponse est errone




> Salle(NomSalle, Capacit , NomEquipement)


le type d'entit [salle] est mal modlis : plusieurs quipements tant possibles dans une mme salle, le nom de l'quipement n'a rien  faire dans la salle. il faut crer un type d'entit [equipement] ayant pour attributs un identifiant, un nom etc... et qui sera en relation avec le type d'entit [salle]

Il faut appliquer le mme raisonnement aux autres types d'entit

Par ailleurs 


> j'ai modifi** mes tables en prenant en compte que la PK soit un decimal et non un varchar


Un decimal, c'est mieux, mais un integer c'eut t encore mieux, car moins encombrant qu'un decimal  nombre de valeurs distinctes gal et donc plus performant  :;): 
De plus, dans l'entit-type [salle], vous avez conserv le nom comme identifiant  ::aie:: 

Relisez-vous bien, car il y a d'autres erreurs de mme nature  :;):

----------


## Mat.M

> Bavant cela j'aimerai savoir si les table et les dependences fonctionnelles sont tous bien en 3NF?


pour ajuster tout cela bref la partie conceptuelle je propose de mettre en pratique sous Ms-Access ou Open Office...en crant des tables,faire des requtes SQL.
Cela permet de voir si la dfinition des tables est correcte et optimale.
Bref pour faire simple ne pas passer trop d'heures sur la partie conceptuelle...

----------


## escartefigue

Non : la cration des tables n'apportera aucune information quant au respect des formes normales et notamment de la 3NF, c'est bien au niveau du modle conceptuel qu'il faut rflchir au positionnement des attributs, positionnement qui doit tenir compte des rgles de gestion.

Les tables ne sont qu'une consquence du modle conceptuel.

----------


## Paprick

Bonjour,



> pour ajuster tout cela bref la partie conceptuelle je propose de mettre en pratique sous Ms-Access ou Open Office...en crant des tables,faire des requtes SQL.
> Cela permet de voir si la dfinition des tables est correcte et optimale.
> Bref pour faire simple ne pas passer trop d'heures sur la partie conceptuelle...


Mettre en oeuvre la structure de la base de donnes et faire des requtes SQL pour, ensuite, s'intresser  la modlisation conceptuelle n'a, pour moi, aucun sens...
La conception, comme son nom l'indique, permet de concevoir le SI... et comment le raliser si on ne l'a pas pralablement conu ?   ::weird:: 
Un bon Modle Conceptuel de Donnes (MCD) permettra de formaliser les rgles de gestion du SI (dans le respect des formes normales), et le Modle Logique de Donnes (MLD) ainsi que les requtes permettant la cration du schma relationnel (les tables du SGBD) seront automatiquement gnres par tout bon outil de modlisation.

----------


## SQLpro

> pour ajuster tout cela bref la partie conceptuelle je propose de mettre en pratique sous Ms-Access ou Open Office...en crant des tables,faire des requtes SQL.
> Cela permet de voir si la dfinition des tables est correcte et optimale.
> Bref pour faire simple ne pas passer trop d'heures sur la partie conceptuelle...


Votre propos est stupide. Par analogie difier un immeuble sans se proccuper des fondations ou encore, en l'difiant puis en chargeant les tages pour voir si cela tient, coute minemment plus cher que de faire bien ds le dpart...

A +

----------


## Mat.M

> Par analogie difier un immeuble sans se proccuper des fondations ou encore, en l'difiant puis en chargeant les tages pour voir si cela tient, coute minemment plus cher que de faire bien ds le dpart...


bah oui on s'en doute bien

----------


## escartefigue

> bah oui on s'en doute bien


En ce cas, il ne fallait pas proposer de brler les tapes comme ce fut le cas dans votre rponse prcdente :




> pour ajuster tout cela bref la partie conceptuelle je propose de mettre en pratique sous Ms-Access ou Open Office...en crant des tables,faire des requtes SQL.
> Cela permet de voir si la dfinition des tables est correcte et optimale.
> *Bref pour faire simple ne pas passer trop d'heures sur la partie conceptuelle*...

----------

