Discussion :

[rise.shine]

Bonsoir,
je dois faire la création 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, PrénomActeur)

MiseEnScène (NomMS, NomSpectacle)

MetteurEnScène (NomMS, PrénomMS)

Representation (DateRepresentation, NomSpectacle ,Durée)

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

Catégorie(Categorie, coefficient,prixPlace)

Reservation (Email, NumRes, NomSpectateur, Nb_Places, DateReprésentation)


(ceux qui sont souligné sont les clés primaire)

[escartefigue]

Bonjour,

Pour bien répondre à ce genre de questions, il faut savoir ce que représente exactement chaque attribut et quelles sont les règles de gestion.

Quoi qu'il en soit, pour la première table, le nom du gestionnaire et son prénom ne dépendent 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 modélisation 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 catégories de personnel.
À l'inverse, la capacité d'une salle est bien dépendante de la salle, cet attribut a donc toute sa place dans cette table.

Il faut appliquer le même raisonnement pour les autres tables.

Par ailleurs, toutes vos tables ont pour PK une colonne fonctionnelle de type char ou varchar, c'est un très mauvais choix.
La PK doit être stable : sa valeur se propage dans d'autres tables pour permettre les contrôles d'intégrité (contraintes "foreign key").
Si vous choisissez une ou plusieurs colonne(s) ayant un sens fonctionnel comme PK, alors la valeur peut être modifiée à tout moment. Modification qui se propagera dans les tables liées, ce qui peut provoquer des mises à jour en masse préjudiciables aux performances.
Si au contraire vous utilisez un chrono technique, ce genre de mésaventure 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 règle incontournable pour une PK.
Par exemple votre table MetteurEnScène (NomMS, PrénomMS) interdit d'avoir deux metteurs en scènes distincts homonymes, c'est très restrictif !
Enfin, une PK de type char ou varchar pénalise énormément 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 même pas besoin de s'occuper de la valeur, c'est le SGBD qui gère

[rise.shine]

merci de votre réponse , je dois revoir mes tables alors, cependant je vous présente mes règles de gestions:
RG 1 Une salle a un seul gestionnaire, un gestionnaire peut gérer plusieurs salles
RG 2 Une salle est utilisée pour plusieurs spectacle, Un spectacle est joué dans une seule salle
RG 3 Un spectacle a un seul metteur en scène, un metteur en scène peut travailler sur plusieurs spectacles différents
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 représentations/Une représentation est jouée pour un spectacle
RG 7 Un client peut reserver plusieurs représentations/Une représentation peut être reservé par plusieurs clients
RG 8 un spectateur appartient à une seule catégorie pour les réductions (soit prix étudiant, soit prix abonné, soit prix solidarité)
RG9 un client peut faire plusieurs réservation , une reservation est faite par un seul client

, pour le gestionnaire dépend de ma salle car c'est en fait selon la règle 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 réponse: 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 réponse est erronée

Salle(NomSalle, Capacité , NomEquipement)

le type d'entité [salle] est mal modélisé : plusieurs équipements étant possibles dans une même salle, le nom de l'équipement n'a rien à faire dans la salle. il faut créer 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 même 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

Relisez-vous bien, car il y a d'autres erreurs de même 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 créant des tables,faire des requêtes SQL.
Cela permet de voir si la définition des tables est correcte et optimale.
Bref pour faire simple ne pas passer trop d'heures sur la partie conceptuelle...

[escartefigue]

Non : la création des tables n'apportera aucune information quant au respect des formes normales et notamment de la 3NF, c'est bien au niveau du modèle conceptuel qu'il faut réfléchir au positionnement des attributs, positionnement qui doit tenir compte des règles de gestion.

Les tables ne sont qu'une conséquence du modèle conceptuel.

[Paprick]

Bonjour,

pour ajuster tout cela bref la partie conceptuelle je propose de mettre en pratique sous Ms-Access ou Open Office...en créant des tables,faire des requêtes SQL.
Cela permet de voir si la définition 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 données et faire des requêtes SQL pour, ensuite, s'intéresser à la modélisation conceptuelle n'a, pour moi, aucun sens...
La conception, comme son nom l'indique, permet de concevoir le SI... et comment le réaliser si on ne l'a pas préalablement conçu ?
Un bon Modèle Conceptuel de Données (MCD) permettra de formaliser les règles de gestion du SI (dans le respect des formes normales), et le Modèle Logique de Données (MLD) ainsi que les requêtes permettant la création du schéma relationnel (les tables du SGBD) seront automatiquement générées par tout bon outil de modélisation.

[SQLpro]

pour ajuster tout cela bref la partie conceptuelle je propose de mettre en pratique sous Ms-Access ou Open Office...en créant des tables,faire des requêtes SQL.
Cela permet de voir si la définition 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 préoccuper 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 dès le départ...

A +

[Mat.M]

Par analogie édifier un immeuble sans se préoccuper 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 dès le départ...

bah oui on s'en doute bien

[escartefigue]

bah oui on s'en doute bien

En ce cas, il ne fallait pas proposer de brûler les étapes comme ce fut le cas dans votre réponse précédente :

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