[Merise:>Modéle de données] Comment savoir ?
Résolu/Fermé
P@
Messages postés
1709
Date d'inscription
vendredi 7 juillet 2000
Statut
Membre
Dernière intervention
24 mars 2009
-
25 janv. 2007 à 16:13
P@ Messages postés 1709 Date d'inscription vendredi 7 juillet 2000 Statut Membre Dernière intervention 24 mars 2009 - 6 févr. 2007 à 14:43
P@ Messages postés 1709 Date d'inscription vendredi 7 juillet 2000 Statut Membre Dernière intervention 24 mars 2009 - 6 févr. 2007 à 14:43
A voir également:
- [Merise:>Modéle de données] Comment savoir ?
- Logiciel merise gratuit - Télécharger - Bases de données
- Merise cours et exercices pdf ✓ - Forum Programmation
- Merise mcd exercices corrigés pdf ✓ - Forum Programmation
- Comparaison entre merise et uml pdf - Forum Programmation
- Recherche exos corrigés sur Merise ✓ - Forum Programmation
5 réponses
kij_82
Messages postés
4089
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
26 janv. 2007 à 10:31
26 janv. 2007 à 10:31
Non, mysql ne gère pas les clés étrangères il me semble, ou peut etre dans une des dernières versions, je ne suis plus trop au courant de ca.
Le fait que mysql ne gère pas les clés étrangères signifie qu'il te faut créer des tables intermédiaire pour lier les objets.
Ex :
Tu as une table voiture :
et une table couleur :
Tu veux attribuer une couleur à une voiture, tu créé la table intermédiaire (qui s'appelle une association en MERISE et non une ENTITE) :
Voilà la présentation de la base de donnée.
Du coup, il te faut faire les controles au niveau du code, dans tes requete SQL, par exemple tu souhaite lister toutes les voitures de couleur verte :
Comme tu le vois dans l'exemple, c'est à toi dans le code de lier les tables par rapport aux identifiants.
Le fait que mysql ne gère pas les clés étrangères signifie qu'il te faut créer des tables intermédiaire pour lier les objets.
Ex :
Tu as une table voiture :
Voiture { id_voiture immatriculation }
et une table couleur :
Couleur { id_couleur libelle }
Tu veux attribuer une couleur à une voiture, tu créé la table intermédiaire (qui s'appelle une association en MERISE et non une ENTITE) :
Voiture_Couleur { id_voiture id_couleur }
Voilà la présentation de la base de donnée.
Du coup, il te faut faire les controles au niveau du code, dans tes requete SQL, par exemple tu souhaite lister toutes les voitures de couleur verte :
$request = "SELECT v.immatriculation FROM Voiture c, Couleur c, Voiture_Couleur vc WHERE vc.id_voiture = v.id_voiture AND vc.id_couleur = c.id_couleur AND c.libelle = 'vert'";
Comme tu le vois dans l'exemple, c'est à toi dans le code de lier les tables par rapport aux identifiants.
kij_82
Messages postés
4089
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
25 janv. 2007 à 16:45
25 janv. 2007 à 16:45
Tu t'es bien exprimé, en tout cas j'ai compris (ca veut tout dire :D)
En fait ce genre de litiges, on ne peut le résoudre qu'en se posant la question suivante :
"Qu'est ce que je veux représenter exactement via mon modèle de donnée ?"
et dans ton cas présent :
"status" et "type" sont elle des informations primordiales ?
Ce que je veux dire par là, c'est que tu as certainement défini tes besoins (cahier des charges) avant de modèliser ton MCD. Donc tu devra savoir si à l'avenir tu aura par exemple besoin de connaitre les différents status ou type (par exemple pour en dresser les listes dans des éléments de type 'select' en html/php), ou autre chose... ou simplement étendre ton MCD en ajoutant un module qui a besoin d'une entité 'type' par exemple.
En fait ce genre de litiges, on ne peut le résoudre qu'en se posant la question suivante :
"Qu'est ce que je veux représenter exactement via mon modèle de donnée ?"
et dans ton cas présent :
"status" et "type" sont elle des informations primordiales ?
Ce que je veux dire par là, c'est que tu as certainement défini tes besoins (cahier des charges) avant de modèliser ton MCD. Donc tu devra savoir si à l'avenir tu aura par exemple besoin de connaitre les différents status ou type (par exemple pour en dresser les listes dans des éléments de type 'select' en html/php), ou autre chose... ou simplement étendre ton MCD en ajoutant un module qui a besoin d'une entité 'type' par exemple.
P@
Messages postés
1709
Date d'inscription
vendredi 7 juillet 2000
Statut
Membre
Dernière intervention
24 mars 2009
185
25 janv. 2007 à 16:54
25 janv. 2007 à 16:54
Mon entité statut est là pour marquer si le contact est actif ou non.
Mon entité type est là pour montrer si le contact est interne, externe ou autre.
Il est sur que je ferait des requêtes pour sortir les contacts actif et interne ou seulement contacts actif ou seulement interne.
Il y aura trés peu de requête demandant de lister (en select) le contenu de statut ou type
Y a t il un des points négatif a mettre beaucoup de table ??
Car je viens de décomposer la table contacts ...
Mon entité type est là pour montrer si le contact est interne, externe ou autre.
Il est sur que je ferait des requêtes pour sortir les contacts actif et interne ou seulement contacts actif ou seulement interne.
Il y aura trés peu de requête demandant de lister (en select) le contenu de statut ou type
Y a t il un des points négatif a mettre beaucoup de table ??
Car je viens de décomposer la table contacts ...
kij_82
Messages postés
4089
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
25 janv. 2007 à 17:19
25 janv. 2007 à 17:19
Eléments négatifs ? Non je ne peuse pas.
Toujours est-il qu'il faut bien gérer le lien (clés étrangères) entre les tables pour pouvoir utiliser correctement la base de données plus tard et ne pas la corrompre avec des données qui ne sont rattachées à rien du tout.
Plus ta base est décomposées plus elle te permet d'etre maléable et adaptable par la suite si tu veux ajouter des modules à tes programmes et qui demandent certaines fonctionnalités en plus que celles existante.
Mais le but n'est pas non plus de fragmenter le plus possible sa base de données (donc le MCD) parce que cela implique qu'elle devient plus complexe à gérér, et point de vue code, plus complexe sera l'application qui utilise la base de données, plus complexe seront les requêtes SQL générée, et parfois même, le temps d'acces aux données en sera plus long.
C'est pour cela qu'il faut réfléchir à l'avance aux fonctionnalités de l'application qui repose sur la base de données, afin d'avoir une base la plus adaptables et la plus rapide à la fois.
Dans ton cas, si tu laisse par exemple 'status' en tant que propriété, tu aura de la redondance dans tes tables, mais vu que tu ne t'en servira que pour effectuer des requêtes de sélection pour connaitre les connectés et les non connectés, il faut que tu laisse cela en tems que propriété.
Si tu en fais une table, tu n'aura que deux valeurs dedans, qui ne te serviront pas à grands choses au final et compliquera tes requetes sur la base.
Pour ce qui est du 'type' par contre... à voir selon les fonctionnalités de ton application.
Toujours est-il qu'il faut bien gérer le lien (clés étrangères) entre les tables pour pouvoir utiliser correctement la base de données plus tard et ne pas la corrompre avec des données qui ne sont rattachées à rien du tout.
Plus ta base est décomposées plus elle te permet d'etre maléable et adaptable par la suite si tu veux ajouter des modules à tes programmes et qui demandent certaines fonctionnalités en plus que celles existante.
Mais le but n'est pas non plus de fragmenter le plus possible sa base de données (donc le MCD) parce que cela implique qu'elle devient plus complexe à gérér, et point de vue code, plus complexe sera l'application qui utilise la base de données, plus complexe seront les requêtes SQL générée, et parfois même, le temps d'acces aux données en sera plus long.
C'est pour cela qu'il faut réfléchir à l'avance aux fonctionnalités de l'application qui repose sur la base de données, afin d'avoir une base la plus adaptables et la plus rapide à la fois.
Dans ton cas, si tu laisse par exemple 'status' en tant que propriété, tu aura de la redondance dans tes tables, mais vu que tu ne t'en servira que pour effectuer des requêtes de sélection pour connaitre les connectés et les non connectés, il faut que tu laisse cela en tems que propriété.
Si tu en fais une table, tu n'aura que deux valeurs dedans, qui ne te serviront pas à grands choses au final et compliquera tes requetes sur la base.
Pour ce qui est du 'type' par contre... à voir selon les fonctionnalités de ton application.
P@
Messages postés
1709
Date d'inscription
vendredi 7 juillet 2000
Statut
Membre
Dernière intervention
24 mars 2009
185
26 janv. 2007 à 10:14
26 janv. 2007 à 10:14
Ok, merci :D
autre question, suite à Toujours est-il qu'il faut bien gérer le lien (clés étrangères) entre les tables pour pouvoir utiliser correctement la base de données plus tard et ne pas la corrompre avec des données qui ne sont rattachées à rien du tout.
J'utilise une base mysql, peut on gérer "directement" sur la base les clés étrangére pour contrôle la cohérence ou faut il tout contrôler par le code que je vais écrire.
Bien entendu, le code controlera. Mais je voudrais savoir si il y a un contrôle en plus coté mysql ?
autre question, suite à Toujours est-il qu'il faut bien gérer le lien (clés étrangères) entre les tables pour pouvoir utiliser correctement la base de données plus tard et ne pas la corrompre avec des données qui ne sont rattachées à rien du tout.
J'utilise une base mysql, peut on gérer "directement" sur la base les clés étrangére pour contrôle la cohérence ou faut il tout contrôler par le code que je vais écrire.
Bien entendu, le code controlera. Mais je voudrais savoir si il y a un contrôle en plus coté mysql ?
P@
Messages postés
1709
Date d'inscription
vendredi 7 juillet 2000
Statut
Membre
Dernière intervention
24 mars 2009
185
26 janv. 2007 à 11:04
26 janv. 2007 à 11:04
ok, merci.
je comprend.
Donc mon mcd est presque fini
je le finalise, puis je créer mes table et je concoit mes class ??
enfait, je commence la POO en php (j'ai jamais fait de POO).
Et je voudrais savoir si, mes entité peuvent ressemebler plus ou moins a mes class dans lesquelles j'ajouterais les méthodes me permettant de faire toutes les actions concernant les contacts par exemple.
c'est ca ou bien ??
j'ai un peu du mal a concevoir les class avant de les écrire :D
je comprend.
Donc mon mcd est presque fini
je le finalise, puis je créer mes table et je concoit mes class ??
enfait, je commence la POO en php (j'ai jamais fait de POO).
Et je voudrais savoir si, mes entité peuvent ressemebler plus ou moins a mes class dans lesquelles j'ajouterais les méthodes me permettant de faire toutes les actions concernant les contacts par exemple.
c'est ca ou bien ??
j'ai un peu du mal a concevoir les class avant de les écrire :D
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
kij_82
Messages postés
4089
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
26 janv. 2007 à 11:13
26 janv. 2007 à 11:13
Oui tu peux créer tes classes objet PHP à l'image de tes tables SQL, au niveau des propriétés.
Ainsi, tu pourra loader toutes tes informations de la bases dans des objets PHP, et à l'aide des méthodes des classes, mettre à jour dans la bases les données, etc...
C'est tres utile pour ce qui est de construire graphiquement un inventaire de personnage par exemple, avec les cases, les équipements placés à tel et tel endroit, etc.. (c'est un exemple).
C'est utile pour laoder des informations depuis des fichiers XML et ensuite effectuer des traitements de vérification dessus avant de mettre à jour ces infos dans la base de donnée.
Ainsi, tu pourra loader toutes tes informations de la bases dans des objets PHP, et à l'aide des méthodes des classes, mettre à jour dans la bases les données, etc...
C'est tres utile pour ce qui est de construire graphiquement un inventaire de personnage par exemple, avec les cases, les équipements placés à tel et tel endroit, etc.. (c'est un exemple).
C'est utile pour laoder des informations depuis des fichiers XML et ensuite effectuer des traitements de vérification dessus avant de mettre à jour ces infos dans la base de donnée.
5 févr. 2007 à 16:03
je bug sur la requete d'insertion.
Comment peut on faire pour un insert avec une valeur en auto_increment qui doit servir de foregin key dans une autre table.
Voila.
J'ai une table
et une table
au moment d'inserer une voiture, il faut aussi que j'insérer dans la table usine une ligne avec l'id_voiture qui lui est auto_incrementer dans la table vioture.
Comment fait on ??
doit faire plusieurs requete
type un insert suivi d'un select (dernier element insérer) pour trouver l'id puis a nouveau un insert dans la 2nd table ?? Cette technique est certes réalisable, mais elle me semble trés peu sur
qu'en pensez vous ??
que me conseillez vous ??
dois je utiliser quelque chose comme on duplicate key ou quelque chose du genre ??
Merci d'avance pour votre aide
5 févr. 2007 à 17:37
La tu parle donc niveau PHP.
Une solution est, en PHP donc, d'effectuer ta requete d'insertion via
Puis, toute suite derriere tu récupère le nouvel identifiant ainsi créé via l'instruction :
Puis, tu effectuant ta seconde requète pour liée avec la valeur récupérée :)
Récapitulatif :
Bon courage pour la suite :)
6 févr. 2007 à 10:02
mais pourquoi mets tu @ avant mysql_query ??
6 févr. 2007 à 13:39
Ca ne gène pas de ne pas les mettre.
6 févr. 2007 à 14:43