MCD, Clés étrangères & MySQL

[NiCoS]

Hello,

Je suis en train de pondre mon MCD avec DBDesigner pour un projet PHP/MySQL et j'ai qqs questions :

• Quand je lis une table à une autre, cette liaison est-elle forcément une clé étrangère ?
  
• MySQL ne semble gérer les clés étrangères qu'avec les tables InnoDB - est-ce toujours le cas avec MySQL 4.x et quel est l'impact de choisir un type InnoDB plutôt que MyISAM ?
  
• Si je n'utilise pas de clé étrangère mais m'assure seulement d'avoir des liens logiques dans mes tables, hormis un surplus de programmation, qu'est-ce que je risque ? A l'inverse quels sont les impacts d'utiliser des clés étrangères ?
  

Merci d'avance

[Spidetra]

Hello,

Je suis en train de pondre mon MCD avec DBDesigner pour un projet PHP/MySQL et j'ai qqs questions :

Sauf erreur de ma part, DBDesigner ne permet pas de faire des MCD, mais uniquement des MPD.

Le MCd est un niveau d'abstraction plus haut que le MPD

[*]Quand je lis une table à une autre, cette liaison est-elle forcément une clé étrangère ?

Non. Cela dépend du type de cardinalité que tu as des deux côtés de ton association.

Dans cet exemple, un jeu appartient à 0,n catégories ( pour être précis la cardinalité aurait dû être 1,n)

Une catégorie peut avoir entre 0,n jeux.

Dans ce cas tu auras, une table de liason dont la clé primaire est composé des deux clé primaire de la table jeu et de la table catégorie.

Le schéma ci-dessous sera un peu plus clair.

[*]MySQL ne semble gérer les clés étrangères qu'avec les tables InnoDB - est-ce toujours le cas avec MySQL 4.x et quel est l'impact de choisir un type InnoDB plutôt que MyISAM ?

- Tu vas pouvoir gérer des clés étrangères avec quasiment n'importe quel SGBD. Tu peux gérer ça dés mySQL 3 et avec des tables myISAM.

Dans l'exemple ci-dessus, dans la table appartient tu as deux clé étrangères : IDJeu et IDCatégorie.

Généralement tu met des index sur ces champs, afin d'améliorer les performances lorsque tu feras des liaison entre tes tables.

- Lorsque tu parles de clé étrangère, tu fait peut-être référence à la notion d'intégrité référentielle. C'est à dire, si tu supprimme une catégorie, toutes les lignes de la table appartient doivent aussi être supprimmé.

Cette intégrité s'obtient avec des contraintes d'intégrité référentielles, et des triggers.

Cela n'existe effectivement en mySQL4 si tu reste en myIsam

Voici un exemple en mySQL5.0

/*==============================================================*/
/* Nom de SGBD :  MySQL 5.0                                     */
/* Date de création :  25/03/2006 10:35:06                      */
/*==============================================================*/


drop table if exists VILLA;

drop table if exists VILLE;

/*==============================================================*/
/* Table : VILLA                                                */
/*==============================================================*/
create table VILLA
(
   IDVILLA              int not null auto_increment,
   IDVILLE              int not null,
   SUPERFICE            decimal,
   PRIX                 decimal,
   primary key (IDVILLA)
);

/*==============================================================*/
/* Table : VILLE                                                */
/*==============================================================*/
create table VILLE
(
   IDVILLE              int not null auto_increment,
   NOM                  longtext,
   primary key (IDVILLE)
);

alter table VILLA add constraint FK_ASSOCIATION_1 foreign key (IDVILLE)
      references VILLE (IDVILLE) on delete restrict on update restrict;

L'intégrité référentielle entre Villa et Ville est garantie grâce à la contrainte FK_ASSOCIATION_1.

[*]Si je n'utilise pas de clé étrangère mais m'assure seulement d'avoir des liens logiques dans mes tables, hormis un surplus de programmation, qu'est-ce que je risque ? A l'inverse quels sont les impacts d'utiliser des clés étrangères ?

Merci d'avance

<{POST_SNAPBACK}>

Si tu n'utilise pas les contraintes d'intégrité référentielle, ce n'est pas si grave que ça.

L'important est de mettre les bons indexs sur les champs qui te servent de liaison.

Si tu n'a pas de contraintes d'intégrité référentielle ce sera à toi de maintenir cette intégrité dans tes programmes afin de ne pas mettre ta base en vrac.

Les avis sont partagés sur l'utilisation ou non des triggers et des contraintes d'intégrité référentielle. Certains ne jurent que par ça, d'autres n'en veulent pas.

Le nom de contraintes est vraiment bien choisit :

add constraint

ajoute des contraintes sur ta base de donnée. Donc tu perd de la liberté.

C'est parfois enervant en mode dévloppement de vouloir supprimé des enregistrements avec phpMyAdmin, et qu c'est impossible à cause des contraintes référentielle.

Un mix que j'aime bien :

- en phase develop, je n'active pas les contraintes

- en production, j'essaye d'imposer ( c'est pas tjrs facile ) ,l'activation systématique de l'intégrité référentielle.

Conclusion : le risque de ne pas utilisé des contraintes de clé étrangères, n'est pas si grave que ça, si tu sais être rigoureux dans tes dev et dans ta manipulation de ta base.

Modifié 26 Mars 2006 par anorci

[NiCoS]

C'est vrai que j'en suis peut être plus au MPD qu'au MCD.

En fait, ma question des clés étrangères est arrivé en cherchant à comprendre pourquoi DBDesigner faisait des liens avec des FK

Pour le moment, j'en suis à ce que tu peux voir ci-joint.

Je me pose la question de mentionner aussi les relations "inverses" : par ex, j'ai mentionné pour le moment le lien utilisateur > profil, mais je me demandais si cela m'était utile de définir la relation profil > utilisateur...

[Spidetra]

J'aime bien réfléchir au niveau MCD, c'est bc pplus simple pour voir rapidement les pb de modélisation. Malheureusement, il n'existe pas de bons outils OpenSource de modélisation ( MCD->MPD->Implémentation multiSGBD ).

Sur ton diagrame je vois au moins un pb :

La liason profil : utilisateur.

Pour moi :

Cardinalité côté utilisateur : 1,1 => Un utilisateur a un profil et un seul

Cardinalité côté profil : 0,n => Un profil correspond à 0,n utilisateurs.

=> la clé id_profil doit être dans la table utilisateur. Tu as fait l'inverse.

J'aime bien garder le même nom de champ pour la PK, et pour la FK.

La clé FK ( dans la table utilisateur ) je l'apellerai id_profil, et non pas profil_utilisateur(FK).

Complément : si tu change la cardinalté côté utilisateur. Un utilisateur corrspond à plusieurs profils => création d'une table de liason.

J'ai pas pris le temps de regarder tout le diagrame, il fait beau et je vais aller faire dun roller.

Bon week !

[NiCoS]

Ok c'est corrigé dans ce sens

J'ai un peu avancé depuis hier et si redbus le veut bien c'est consultable ici :

http://www.unelectronlibre.info/perso/Export_Guss.png

http://www.unelectronlibre.info/perso/guss.xml (Format DBDesigner)

Si tu as le temps d'y jeter un oeil, je suis preneur

[MarvinLeRouge]

Salut,

Si un utilisateur a un et un seul profil, et si un profil est associé à un et un seul utilisateur, pourquoi profil est-il une entité indépendante dans ton schema ?

[Spidetra]

Je suis d'accord avec MarvinLeRouge. Une association bijective entre deux entités, en théorie, ce n'est pas faux, mais c'est quand même bizarre.

Je n'en ai jamais vu.

Je t'ai fait un schéma avec 4 possibilité de relation entre profil et utilisateur.

La 1° possibilité correspond à ton MPD.

Je n'ai mis que les clés primaires dans les entités et pas tout les attributs.

C'est quoi pour toi un profil ?

Modifié 27 Mars 2006 par anorci

[NiCoS]

Un profil peut être détenu par 0,n utilisateurs donc mon cas serait ton cas n°2 si je lis bien

[Spidetra]

Donc c'est exactement l'inverse de ton tout premier schéma.

Si tu es sur qu'un utilisateur a un profil et un seul, alors ça donne ça :

[NiCoS]

arf oui en effet :-/

[Spidetra]

J'ai pa pu récupérer le schéma XML ( RedBus fait encore des siennes )

Un conseil simple :

- prend une feuille et un crayon

- essaye de faire un MCD. Inspire toi du schéma que je t'ai fait pour utilisateur/role.

- Met juste les clé primaires dans tes entités, ne perd pas du temps à mettre tout tes attributs.

- Oubli les cardinalités 1:1 des deux côtés de l'association.

- Réfléchis bien aux cardinalités de chaque côté d' une association.

Applique ces règles simple pour générer ton MPD :

- Fait glisser la clé primaire du côté 1:1 ou 0:1 de ton association ( ce que j'ai fait pour la table utilisateur )

- si tu as des cardinalités 0:n ou 1:n des deux côtés de l'association => une table de liason intermédiaire entre tes deux tables ( ce que j'ai fait dans mon schéma plus haut pour jeu/categorie ).

J'ai regardé juste la relation profil/utilisateur, mais il m'a semblé que le reste du schéma aussi comprenait des erreurs.

Tu peux aussi télécharger une version d'essai de powerAMC ( ils en sont à la 12 )

http://www.sybase.com/products/development...ration/poweramc

Tu pourras facilement faire : MCD->MPD->Implémentation en mySQL 4.x ou 5.x

[NiCoS]

Hum ok vais tenter de reprendre cela au calme, je pense

Merci pour vos retours

[Spidetra]

N'hésite pas à reposter tes diagrammes. J'y jetterai un coup d'oeil rapide.

[NiCoS]

OK c'est sympa, en effet pour les profils, j'avais tout faux, je m'étais trompé de sens

Bon sur ce je m'y remets à mon beau schéma

[NiCoS]

Je reviens à l'assaut

- MCD DBDesigner

- MCD (au format png)

J'espère que j'ai bon cette fois-ci

[Spidetra]

Salut,

Je viens juste de me rendre compte que tu avais posté ton schéma.

J'ai jeté un coup d'oeil ( je dois avouer un coup d'oeil rapide ), ça à l'air bc plus correct que la première fois.

Tes noms de clés étrangères sont parfois un peu long à mon goût ( domaine_utilisateur_profil_id_profil ), mais bon c'est pas très grave.

Modifié 20 Avril 2006 par Spidetra