Forum d'entraide PHPFrance

Bonjour,

Je cherche des informations pratiques sur base de données relationnelle :
Les avantages et les inconvénients d'avoir une base de données relationnelle?
Est-ce que peut-on avoir une base de données relationnelle avec MySql? Est-ce qu’on peut la monter sous PhpMySql?
Comment peut-on la monter?

Est-ce que vous avez des liens sur cela pour un débutant avec des exemples ?

Je sais que je peux aussi chercher sur Google mais je n'ai pas trouvé un document complet, clair pour un débutant...

Merci votre compréhension à ma question générale...

Wow plutot generale comme question!

Les avantages et les inconvénients d'avoir une base de données relationnelle?

Les avantages ? Stocker beaucoup de donnees, de facon organisees pour pouvoir facilement les recuperer, les relier entre elles, effecturer des calculs etc
Les inconvenients? Je n'en vois pas, sauf si evidemment tu as peu de donneees a stocker, par exemple de la configuration sous forme de cles/valeurs, la ca fait un peu lourd pour rien et un fichier text ou XML ferait aussi bien l'affaire.

Est-ce que peut-on avoir une base de données relationnelle avec MySql?

Oui bien sur MySQL ne sert d'ailleurs qu'a ca.

Est-ce qu’on peut la monter sous PhpMySql?
Comment peut-on la monter?

Le fait que tu attaches PHP et MySQL me perturbe, simple faute de frappe ou tu ne sais pas vraiment qu'est-ce qui est quoi? Du coup je ne comprends pas ta question, tu crees ta base dans MyQL qui est le SGBD, tu l'interroges avec le langage de requetes SQL, requetes que tu peux executer au travers d'un script PHP.

A voir tes questions je pense que tu as besoin d'un peu mieux comprendre ou tu mets les pieds, une bonne base de depart: WIkipedia
Tu trouveras des expllications sur ce que c'est que tout ca:
- http://fr.wikipedia.org/wiki/SGBD
- http://fr.wikipedia.org/wiki/MySQL
- http://fr.wikipedia.org/wiki/SQL

Et tu pourrais aussi nous dire quel est le but de tout ca, on pourra peut-etre t'aider a choisir le bon outil suivant tes besoins

Bonjour ouckileou,

Suite à tes remarques voici un projet fictif :
J'ai un bd qui a 4 tables
table tb_marques contient 2 champs : id et chmps_marques
table tb_moteur contient 2 champs : id et chmps_moteur
table tb_annee contient 2 champs : id et chmps_annee
table tb_note contient 3 champs : id, chmps_id_note et chmps_notes


L’utilisateur affiche un formulaire avec 3 menus déroulants, "marques", "moteurs" et "année" dont les informations viennent de 3 différentes table et un champ de texte pour les notes.

Il sélectionne trois menus et il écrit ses notes dans le champ et valide le formulaire.

Je me demande si j'ai besoin d'un modèle de données relationnelles. Comment je fais la relation entre ces tables ? En fait, j'ai besoin de faire une relation entre les tables pour que j'affiche les résultats qui contient :
les notes, sur la marque, sur son moteur et sur l'année...

Je me demande si j'ai besoin d'un modèle de données relationnelles. Comment je fais la relation entre ces tables ? En fait, j'ai besoin de faire une relation entre les tables pour que j'affiche les résultats qui contient

Tu réponds à ta propre question : tu as besoin d'un modèle relationnel !

1. Un moteur est produit par une marque (et une marque produit plusieurs moteurs).
2. Un moteur est produit pendant une ou plusieurs années. Et chaque année, chaque marque produit un ou plusieurs moteurs.
3. Une note concerne un "modèle" (moteur+année) et chaque "modèle" peut avoir plusieurs notes.

=> Il y a bien des relations entre tes tables.
Pour être plus précis, il faudrait mieux connaître ton modèle fonctionnel (Par exemple, as-tu besoin d'avoir les informations génériques pour un moteur ? Ou tu ne t'intéresseras qu'au couple moteur+année ?)

Bonjour Macgawel,


Je ne sais pas exactement puisque c'est un projet fictif pour comprendre comment ça marche en faisant des exercices.

tb_moteur
+-----------+---------------------+
| id | chmps_moteur |
+-----------+----------------------+
| 1 | V8 |
| 2 | V6 |
| 3 | 4 cyl. |
+-----------+---------------------+
Ce que je pense : une marque peut avoir plusieurs moteurs et un moteur (en fait, c'est V6, V8 et 4cylindres) peut être utilisé par plusieurs marques par contre dans le même année la même marque n'utilise qu'une seule fois le même moteur.

salut,

dans ton cas tu a donc 3 "entités", la marque, le moteur et l'année, qui peuvent être décrit par 3 table (pourquoi pas, il serait plus pertinent, peut être d'avoir une fourchette d'année sur le moteur ? quoi qu'une marque peut utilise plus ou moins longtemps un moteur qu'une autre).

tu aura donc une relation :
- plusieurs à plusieurs entre les moteurs et les marques (plusiers marque et plusieurs moteurs) c'est une relation n:n
- plusieurs à plusieurs entre moteurs et marque.

Pour gérer tous cela il faut une table qui va stocker la chose. Par exemple

table coupleannemarquemoteur (
id int unsigned not null auto_increment, <= ça c'est la clef primaire de la table pas utile dans l'exemple
idmoteur .... ça c'est la clef primaire correspondant au moteur
idmarque ... la clef primaire correspondant à la marque
idannée .... la clef primaire correspondant à l'année
primary key(id)
);

dans cette table les idmoteur, idmarque et idannée correspondent aux clef primaire de trois tables différentes on appelle cela des clefs étrangères.
dans cette on pourra stoker autant que couple année - marque - moteur que l'on souhaite sans avoir a dupliquer l'information.
voila la 'relation' de la chose.

Prenons un autre exemple plus simple (et classique ) une bibliothèque.
qu'est ce que l'on trouve dans une bibliothèque ?
-des documents
ces documents peuvent être des livres de la musique des articles, des histoires etc.
ils peuvent êtres sur des support différents (journal, livre relier, livre de poche, cd / dvd pour de la musique pour des livre numérique etc)

on peux donc définir un document avec
- un code unique (notre clef primaire pour l'identifier)
- un auteur
- un editeur
- support
- un titre
(pourquoi pas une description)

on pourrais avoir une table et tout mettre dedans mais on pourra avoir des doublons sur les auteurs par exemple (moogli c'est pas Moogli ni même MooGli ).
Pour cela on va avoir une table auteur, même principe pour les éditeurs et les supports.

maintenant les relations entre nos 4 tables.
- un document a un ou plusieurs auteurs donc relation 1 à n
- un document a un ou plusieurs editeur (plusieurs édition différentes) 1 à n
- un document a un ou plusieurs support. 1 à n
ça en fait de la relation tous ça

donc une table qui faire la relation entre le document et le ou les auteur(s)
une table qui permet la relation entre le document et le ou les editeur(s)
et une table qui permet la relation entre le document et le ou les support(s)

ce qui fait 7 tables avec des relation entre elle. on a une base de données relationnelles .

je suis pas certain d'avoir était clair, mais si tu demande à google des infos la méthode merise par exemple tu aura beaucoup plus d'info et des exemples

@+

Je ne sais pas si on peut parler de relationnelle proprement dit, techniquement, pour ce genre de choses. Je m'explique : Tu peux tout à faire créer du relationnel avec du xml, ou n'importe quoi. Là où les bases de données relationnelles, et plus généralement, les Systèmes relationnels apportent une valeur ajoutée, c'est effectivement d'une part les requêtes 'simples' qu'ils proprosent, mais aussi tout le fonctionnement derrière que je résumerai en ACID. La grande force est alors de permettre l'atomicité des actions, en étant sûr qu'une chaine d'actions est réalisée entièrement ou pas du tout, la cohérence, qui évite par exemple que lors de la suppression d'un moteur, des voitures se retrouvent avec des moteurs inconnus, l'isolation, qui va éviter lors de la lecture et ou de l'écriture d'avoir des informations fantômes (grossomodo qui ne reflète pas la réalité à un moment crutial, peu après leur obtention), et lié à cela, des écritures concurrentes, et enfin la durabilité, mais ça je considère que même un simple fichier l'est.

En gros, ils permettent un système 'parfait' qui n'est quasiment pas faillible, sauf si bien sûr une coupure de courant se produit exactement au moment où une transaction est au milieu d'enregistrements lors de sa validation. Dans un sens, tout est relationnel, un objet A dont une propriété pointe vers un objet B, c'est du relationnel ... mais c'est surtout ce que cela implique et permet.

Bonsoir devlop78 et moogli,

Merci pour vos explications...

Alors comment je peux faire tout cela dans le pratique?

J'ai fait un essai avec deux tables simple sous PhpMyAdmin dans mon bdd MySql...

Voici ce que j'ai fait :


j'ai créé ma première table, nom, qui contient 2 colonnes :id_nom et prenom

ma requête : ensuite 2e table, ecole, avec 3 colonnes :id_ecole (clé première), nom_prof et nom_etud. Ce derniere est une clé étrangère (foreign key) qui vient du colonne 'id_nom' de table nom

ma requête : PHPmyAdmin crée les tables sans erreur, mais on ne voit pas du tout le concept de foreign key même si dans ma requête, il y avait "REFERENCES nom(id_nom)"

Alors comment je peux créer une table avec foreign key dans PhpMyAdmin ?

Je ne sais pas si on peut parler de relationnelle proprement dit, techniquement, pour ce genre de choses. Je m'explique : Tu peux tout à faire créer du relationnel avec du xml, ou n'importe quoi. Là où les bases de données relationnelles, et plus généralement, les Systèmes relationnels apportent une valeur ajoutée, c'est effectivement d'une part les requêtes 'simples' qu'ils proprosent, mais aussi tout le fonctionnement derrière que je résumerai en ACID. La grande force est alors de permettre l'atomicité des actions, en étant sûr qu'une chaine d'actions est réalisée entièrement ou pas du tout, la cohérence, qui évite par exemple que lors de la suppression d'un moteur, des voitures se retrouvent avec des moteurs inconnus, l'isolation, qui va éviter lors de la lecture et ou de l'écriture d'avoir des informations fantômes (grossomodo qui ne reflète pas la réalité à un moment crutial, peu après leur obtention), et lié à cela, des écritures concurrentes, et enfin la durabilité, mais ça je considère que même un simple fichier l'est.

En gros, ils permettent un système 'parfait' qui n'est quasiment pas faillible, sauf si bien sûr une coupure de courant se produit exactement au moment où une transaction est au milieu d'enregistrements lors de sa validation. Dans un sens, tout est relationnel, un objet A dont une propriété pointe vers un objet B, c'est du relationnel ... mais c'est surtout ce que cela implique et permet.

Beau travail de vulgarisation

Attention, c'est un élève qui appartient à une école, et pas l'inverse. Dans ce que tu as fait, c'est l'inverse. En plus, tu mets "id_nom" dans la deuxième table, sans préciser à quelle table il doit faire référence.

Dans PHPMyAdmin :

- Tu dois créer tes tables sous le moteur InnoDB. Celui-ci est plus lent que MyISAM, mais MyISAM n'est ni relationnel, ni transactionnel.
- Tu dois mettre les FK (Foreign Key) en Index. Je crois que c'est obligatoire pour MySQL, ça l'est en tous cas pour PHPMyAdmin.
- Tu vas dans la structure de la table où est la FK, et tu cliques sur "Gestion des relation"
- Tu lies ta FK (qui devient alors vraiment une FK) avec la PK (Primary Key) de la table voulue. Tu peux sur la droite préciser le comportement souhaité en cas de modification de la PK ou de la suppression de la ligne qu'elle représente. Par défaut, sur MySQL, c'est NO ACTION == RESTRICT mais tu peux choisir CASCADE ou SET NULL. Cascade fera, pour une suppression que si tu supprime la ligne de la PK, la ligne de la FK sera supprimée. SET NULL lors de la suppression de la ligne de la PK, mettra la FK à NULL, si NULL est une valeur autorisée.

Tout ces choix sont fait à la modélisation. Si tu as une voiture, un modèle de moteur, que tu as choisi SET NULL, si tu supprime le moteur, la voiture se retrouve en quelque sorte sans moteur, ou sans moteur connu/défini. Cela peut être intolérable comme tout à fait possible dans ton application. Si tu mets cascade, la suppression du moteur entraine la suppression de ta voiture. Dans une application courante, dans ce contexte, ce n'est vraiment pas souhaitable ...

Mais si on imagine un forum, on pourrait avoir une table SUJETS et une table MESSAGES. On crée un sujet comme le tient, et on y répond comme toi et moi. Si on s'en tient à ces deux seules tables, il serait absurde de supprimer un sujet et de laisser les messages en NULL. On aurait alors des messages qui ne seront par personne, dont personne ne connait l'existence, et qui pollue la table. Par ailleurs, si on le laisse à RESTRICT, on sera dans l'incapacité de supprimer le sujet si il y a des messages. Evidemment, il suffit de supprimer les messages avant de supprimer le sujet, c'est un choix tout à fait raisonnable. On a aussi la possibilité de laisser MySQL gérer ça avec CASCADe, qui entrainera la suppression des messages à la suppression du sujet, et en plus, si je ne m'abuse, de façon atomique.

Par contre, mais c'est valable pour tout script, une bonne solution dans un contexte ne l'est pas dans un autre. Si ton message possède des images sur le disque dur, l'opération CASCADE entrainera des images orphelines et sans aucun référencement. Dans le temps, les images s'accumuleront et il faudra alors développer un script pour faire le nettoyage des orphelines.

Pire encore, si tu as une table utilisateurs et une table pages (pour un site web par exemple), et que tu lis en cascade, la suppression de l'utilisateur entrainera la suppression des pages. Ce n'est pas en général l'effet recherché. Il n'y a pas de solutions miracles à ma connaissance, soit tu passes en SET NULL si tu autorises des pages aux utilisateurs inconnus (et encore, là il a été connu, donc ça peut être interprété comme de la corruption de données), soit tu transmets les pages à un autre utilisateur, mais là c'est pire tu changes toute la véracité de l'information, soit tu crées une option de désactivation de l'utilisateur, qui le laissera propriétaire des pages tout en rendant son propriétaire dans l'incapacité de se connecter à son compte. L'option RESTRICT étant donné la dangereusité potentielle est donc par défaut dans cette situation le choix le plus approprié. Rien n'empêche par la suite d'avoir une sorte de Garbage Collector qui supprimera les utilisateurs qui n'ont plus aucun lien avec rien.

Finalement, c'est comme tout, le sujet est complexe. Le problème est aussi que NULL peut avoir beaucoup de signification, tout comme en PHP, il est impossible de différencier une variable inexistante d'une variable initialisée à null, en MySQL NULL peut vouloir dire "non précisé", mais aussi "non lié", ou "n'est plus lié". Donc, c'est aussi à prendre en compte.

Enfin voilà, dans la théorie technique, c'est assez simple, c'est surtout le choix judicieux, logique et cohérent qui le sera moins ^^

Merci devlop78,

super clair : tes explications au niveau théorique et pratique....

Merci encore et j'arrive ce que j'ai voulu grâce à tes (et vous les autres) explication