je vous préviens amicalement, je suis une vraie quiche et vous risquez de
m'avoir avec vous pour quelques temps :-)
Je suis en train de tenter de créer une toute petite appli php/sql.
J'ai assimilé le principe de création, mise à jour et suppression de tables
et de données.
Soit deux tables, une nommée 'terrains', l'autre 'batiments'.
Je souhaite qu'à chaque fois que je créé (avec un formulaire) une nouvelle
entrée dans 'batiments', celle-ci soit liée à la table 'terrains'.
Les champs dans terrains sont id_terrain et designation_terrain
Les champs dans batiments sont id_batiment et designation_batiment
L'idéal serait de lier les deux champs designation_terrain et
designation_batiment.
Le but final serait que lorsque j'interroge 'terrains', il me donne les
bâtiments installés dessus.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred Brouard - SQLpro
jaunit a écrit :
bonjour
je vous préviens amicalement, je suis une vraie quiche et vous risquez de m'avoir avec vous pour quelques temps :-)
Je suis en train de tenter de créer une toute petite appli php/sql.
J'ai assimilé le principe de création, mise à jour et suppression de tables et de données.
Soit deux tables, une nommée 'terrains', l'autre 'batiments'.
Je souhaite qu'à chaque fois que je créé (avec un formulaire) une nouvelle entrée dans 'batiments', celle-ci soit liée à la table 'terrains'.
Les champs dans terrains sont id_terrain et designation_terrain Les champs dans batiments sont id_batiment et designation_batiment
L'idéal serait de lier les deux champs designation_terrain et designation_batiment. Le but final serait que lorsque j'interroge 'terrains', il me donne les bâtiments installés dessus.
J'éspère être un minimum compréhensible...
Tout dépend si votre "liaison" est 1:1 (un a un), 1:n (un à plusieurs) ou n:m (plusieurs à plusieurs). Et cette "cardinalité" (car c'est son nom) dépend de la nature du "lien" (en fait on parle d'association).
En effet dans le cas 1:1 vous pouvez fusionner les tables en une seule. Exemple si l'association est terrain (situé en dessous du) batiment => 1:1 donc tout dans la même table.
Dans le cas du 1:n il faut reporter la clef de la table coté n dans celle côté 1. Exemple : batiment (est construit sur) terrain on peut avoir plusieurs batiment sur le même terrain. Donc les cardinalité sont : batiment [1:1] (est construit sur) [0:n] terrain ce qui se lit : sur un terrain on peut construire au moins 0 batiment et au plus n batiments (c'est à dire un nombre quelconque) un batiment est construit au moins sur 1 terrain et au plus sur un terrain Dans ce cas il faudra ajouter à la table batiment la clef de la table terrain. Ce sera donc un "clef étrangère" de la table terrain dans la table batiment. Il est bon dans ce cas de mettre en oeuvre une intégrité référentielle. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7
Enfin pour l'association n:m il faut ajouter une table de jointure qui possède les deux clefs des table.
Tout ceci s'apelle de la modélisation de données et vous pouvez lire les quelques pages que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/modelisation/merise/
A +
merci beaucoup
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
jaunit a écrit :
bonjour
je vous préviens amicalement, je suis une vraie quiche et vous risquez de
m'avoir avec vous pour quelques temps :-)
Je suis en train de tenter de créer une toute petite appli php/sql.
J'ai assimilé le principe de création, mise à jour et suppression de tables
et de données.
Soit deux tables, une nommée 'terrains', l'autre 'batiments'.
Je souhaite qu'à chaque fois que je créé (avec un formulaire) une nouvelle
entrée dans 'batiments', celle-ci soit liée à la table 'terrains'.
Les champs dans terrains sont id_terrain et designation_terrain
Les champs dans batiments sont id_batiment et designation_batiment
L'idéal serait de lier les deux champs designation_terrain et
designation_batiment.
Le but final serait que lorsque j'interroge 'terrains', il me donne les
bâtiments installés dessus.
J'éspère être un minimum compréhensible...
Tout dépend si votre "liaison" est 1:1 (un a un), 1:n (un à plusieurs)
ou n:m (plusieurs à plusieurs).
Et cette "cardinalité" (car c'est son nom) dépend de la nature du "lien"
(en fait on parle d'association).
En effet dans le cas 1:1 vous pouvez fusionner les tables en une seule.
Exemple si l'association est terrain (situé en dessous du) batiment =>
1:1 donc tout dans la même table.
Dans le cas du 1:n il faut reporter la clef de la table coté n dans
celle côté 1.
Exemple : batiment (est construit sur) terrain
on peut avoir plusieurs batiment sur le même terrain.
Donc les cardinalité sont :
batiment [1:1] (est construit sur) [0:n] terrain
ce qui se lit :
sur un terrain on peut construire au moins 0 batiment et au plus n
batiments (c'est à dire un nombre quelconque)
un batiment est construit au moins sur 1 terrain et au plus sur un terrain
Dans ce cas il faudra ajouter à la table batiment la clef de la table
terrain. Ce sera donc un "clef étrangère" de la table terrain dans la
table batiment. Il est bon dans ce cas de mettre en oeuvre une intégrité
référentielle.
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7
Enfin pour l'association n:m il faut ajouter une table de jointure qui
possède les deux clefs des table.
Tout ceci s'apelle de la modélisation de données et vous pouvez lire les
quelques pages que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/modelisation/merise/
A +
merci beaucoup
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
je vous préviens amicalement, je suis une vraie quiche et vous risquez de m'avoir avec vous pour quelques temps :-)
Je suis en train de tenter de créer une toute petite appli php/sql.
J'ai assimilé le principe de création, mise à jour et suppression de tables et de données.
Soit deux tables, une nommée 'terrains', l'autre 'batiments'.
Je souhaite qu'à chaque fois que je créé (avec un formulaire) une nouvelle entrée dans 'batiments', celle-ci soit liée à la table 'terrains'.
Les champs dans terrains sont id_terrain et designation_terrain Les champs dans batiments sont id_batiment et designation_batiment
L'idéal serait de lier les deux champs designation_terrain et designation_batiment. Le but final serait que lorsque j'interroge 'terrains', il me donne les bâtiments installés dessus.
J'éspère être un minimum compréhensible...
Tout dépend si votre "liaison" est 1:1 (un a un), 1:n (un à plusieurs) ou n:m (plusieurs à plusieurs). Et cette "cardinalité" (car c'est son nom) dépend de la nature du "lien" (en fait on parle d'association).
En effet dans le cas 1:1 vous pouvez fusionner les tables en une seule. Exemple si l'association est terrain (situé en dessous du) batiment => 1:1 donc tout dans la même table.
Dans le cas du 1:n il faut reporter la clef de la table coté n dans celle côté 1. Exemple : batiment (est construit sur) terrain on peut avoir plusieurs batiment sur le même terrain. Donc les cardinalité sont : batiment [1:1] (est construit sur) [0:n] terrain ce qui se lit : sur un terrain on peut construire au moins 0 batiment et au plus n batiments (c'est à dire un nombre quelconque) un batiment est construit au moins sur 1 terrain et au plus sur un terrain Dans ce cas il faudra ajouter à la table batiment la clef de la table terrain. Ce sera donc un "clef étrangère" de la table terrain dans la table batiment. Il est bon dans ce cas de mettre en oeuvre une intégrité référentielle. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7
Enfin pour l'association n:m il faut ajouter une table de jointure qui possède les deux clefs des table.
Tout ceci s'apelle de la modélisation de données et vous pouvez lire les quelques pages que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/modelisation/merise/
A +
merci beaucoup
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
jaunit
Fred Brouard - SQLpro sur fr.comp.applications.sgbd le mercredi 07 février 2007 11:30
J'éspère être un minimum compréhensible...
Tout dépend si votre "liaison" est 1:1 (un a un), 1:n (un à plusieurs) ou n:m (plusieurs à plusieurs). Et cette "cardinalité" (car c'est son nom) dépend de la nature du "lien" (en fait on parle d'association).
En effet dans le cas 1:1 vous pouvez fusionner les tables en une seule. Exemple si l'association est terrain (situé en dessous du) batiment => 1:1 donc tout dans la même table.
Dans le cas du 1:n il faut reporter la clef de la table coté n dans celle côté 1. Exemple : batiment (est construit sur) terrain on peut avoir plusieurs batiment sur le même terrain. Donc les cardinalité sont : batiment [1:1] (est construit sur) [0:n] terrain ce qui se lit : sur un terrain on peut construire au moins 0 batiment et au plus n batiments (c'est à dire un nombre quelconque) un batiment est construit au moins sur 1 terrain et au plus sur un terrain Dans ce cas il faudra ajouter à la table batiment la clef de la table terrain. Ce sera donc un "clef étrangère" de la table terrain dans la table batiment. Il est bon dans ce cas de mettre en oeuvre une intégrité référentielle. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7
Enfin pour l'association n:m il faut ajouter une table de jointure qui possède les deux clefs des table.
Tout ceci s'apelle de la modélisation de données et vous pouvez lire les quelques pages que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/modelisation/merise/
Merci pour l'explication, j'ai bien compris le principe. Et vos documents me semblent parfaits, ça imprime :)
À bientôt Romain
Fred Brouard - SQLpro sur fr.comp.applications.sgbd le mercredi 07 février
2007 11:30
J'éspère être un minimum compréhensible...
Tout dépend si votre "liaison" est 1:1 (un a un), 1:n (un à plusieurs)
ou n:m (plusieurs à plusieurs).
Et cette "cardinalité" (car c'est son nom) dépend de la nature du "lien"
(en fait on parle d'association).
En effet dans le cas 1:1 vous pouvez fusionner les tables en une seule.
Exemple si l'association est terrain (situé en dessous du) batiment =>
1:1 donc tout dans la même table.
Dans le cas du 1:n il faut reporter la clef de la table coté n dans
celle côté 1.
Exemple : batiment (est construit sur) terrain
on peut avoir plusieurs batiment sur le même terrain.
Donc les cardinalité sont :
batiment [1:1] (est construit sur) [0:n] terrain
ce qui se lit :
sur un terrain on peut construire au moins 0 batiment et au plus n
batiments (c'est à dire un nombre quelconque)
un batiment est construit au moins sur 1 terrain et au plus sur un terrain
Dans ce cas il faudra ajouter à la table batiment la clef de la table
terrain. Ce sera donc un "clef étrangère" de la table terrain dans la
table batiment. Il est bon dans ce cas de mettre en oeuvre une intégrité
référentielle.
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7
Enfin pour l'association n:m il faut ajouter une table de jointure qui
possède les deux clefs des table.
Tout ceci s'apelle de la modélisation de données et vous pouvez lire les
quelques pages que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/modelisation/merise/
Merci pour l'explication, j'ai bien compris le principe. Et vos documents me
semblent parfaits, ça imprime :)
Fred Brouard - SQLpro sur fr.comp.applications.sgbd le mercredi 07 février 2007 11:30
J'éspère être un minimum compréhensible...
Tout dépend si votre "liaison" est 1:1 (un a un), 1:n (un à plusieurs) ou n:m (plusieurs à plusieurs). Et cette "cardinalité" (car c'est son nom) dépend de la nature du "lien" (en fait on parle d'association).
En effet dans le cas 1:1 vous pouvez fusionner les tables en une seule. Exemple si l'association est terrain (situé en dessous du) batiment => 1:1 donc tout dans la même table.
Dans le cas du 1:n il faut reporter la clef de la table coté n dans celle côté 1. Exemple : batiment (est construit sur) terrain on peut avoir plusieurs batiment sur le même terrain. Donc les cardinalité sont : batiment [1:1] (est construit sur) [0:n] terrain ce qui se lit : sur un terrain on peut construire au moins 0 batiment et au plus n batiments (c'est à dire un nombre quelconque) un batiment est construit au moins sur 1 terrain et au plus sur un terrain Dans ce cas il faudra ajouter à la table batiment la clef de la table terrain. Ce sera donc un "clef étrangère" de la table terrain dans la table batiment. Il est bon dans ce cas de mettre en oeuvre une intégrité référentielle. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7
Enfin pour l'association n:m il faut ajouter une table de jointure qui possède les deux clefs des table.
Tout ceci s'apelle de la modélisation de données et vous pouvez lire les quelques pages que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/modelisation/merise/
Merci pour l'explication, j'ai bien compris le principe. Et vos documents me semblent parfaits, ça imprime :)
À bientôt Romain
Jean-Marc Molina
Fred Brouard - SQLpro wrote:
Tout ceci s'apelle de la modélisation de données et vous pouvez lire les quelques pages que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/modelisation/merise/
Et pour modéliser rien de tel qu'un petit outil comme DBDesigner 4 [1]. Son développeur s'est fait débauché par MySQL AB ce qui donne naissance à MySQL Workbench, actuellement en version 1.1 Alpha et téléchargeable sur la page "MySQL GUI Tools Downloads" [2]. Après on pourrait aussi parler des diagrammes de classe UML mais ceci est une autre histoire...
Romain, comme tu sembles débuter, je te conseille vivement d'essayer DBDesigner 4. Libre et accessible, idéal pour le débutant. Il m'avait permis de visualiser l'une de mes premières bases MySQL sous la forme d'un juteux plat de spaghettis :)
Tout ceci s'apelle de la modélisation de données et vous pouvez lire
les quelques pages que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/modelisation/merise/
Et pour modéliser rien de tel qu'un petit outil comme DBDesigner 4 [1]. Son
développeur s'est fait débauché par MySQL AB ce qui donne naissance à MySQL
Workbench, actuellement en version 1.1 Alpha et téléchargeable sur la page
"MySQL GUI Tools Downloads" [2]. Après on pourrait aussi parler des
diagrammes de classe UML mais ceci est une autre histoire...
Romain, comme tu sembles débuter, je te conseille vivement d'essayer
DBDesigner 4. Libre et accessible, idéal pour le débutant. Il m'avait permis
de visualiser l'une de mes premières bases MySQL sous la forme d'un juteux
plat de spaghettis :)
Tout ceci s'apelle de la modélisation de données et vous pouvez lire les quelques pages que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/modelisation/merise/
Et pour modéliser rien de tel qu'un petit outil comme DBDesigner 4 [1]. Son développeur s'est fait débauché par MySQL AB ce qui donne naissance à MySQL Workbench, actuellement en version 1.1 Alpha et téléchargeable sur la page "MySQL GUI Tools Downloads" [2]. Après on pourrait aussi parler des diagrammes de classe UML mais ceci est une autre histoire...
Romain, comme tu sembles débuter, je te conseille vivement d'essayer DBDesigner 4. Libre et accessible, idéal pour le débutant. Il m'avait permis de visualiser l'une de mes premières bases MySQL sous la forme d'un juteux plat de spaghettis :)
