Bonjour,
J'essaie d'apprendre SQL mais avec l'approche mathématique (algebre
relationnel).
Ceci dit, je n'ai pas vraiment un niveau "supérieur" dans ce domaine, juste
un niveau L2 de Maths on va dire (*).
En prenant comme exemple ce qui est dit ici:
http://webtic.free.fr/sql/mldr.htm
Comme nous pouvons le constater, le modèle relationnel est un modèle
d'organisation des données sous forme de Tables (Tableaux de valeurs)
ou chaque Table représente une Relation, au sens
mathématique d'Ensemble.
Ok. De toutes façons, je retrouve aussi un discours similaire dans les
autres ouvrages, comme celui Brouard/Soutou.
Par contre j'ai du mal à modéliser la chose dans ma tete et c'est ce qui me
gene le plus.
J'ai du mal à modéliser une relation R en tableau.
Par exemple, soit la relation D (pour "double") qui a tout entier "n"
associe son double "n*2".
Si je dois représenter cette relation R sous forme de tableau,
comment je fais? Sachant qu'un relation est mathématiquement définie par son
ensemble de départ, ensemble d'arrivé et l'expression de la "relation".
A la louche, je dirais que je peux m'en sortir avec un tableau a une colonne
de la forme
n
0
2
4
6
...
Mais le problème, si on me donne juste ce tableau et qu'on me dit que c'est
une relation, c'est qu'on n'a pas tous les éléments de la relation:
Nulle par n'est mentionné l'ensemble de départ, par exemple.
J'imagine que si plusieurs ouvrages disent la meme chose et que je ne
comprends pas, c'est je me pose les mauvaises questions. Mais je ne vois
pas quelles autres questions me poser. Pouvez-vous m'aiguiller un peu?
Merci.
(*) En réalité j'ai validé un niveau d'étude plus élevé, mais pour etre sur
de ce que je sais...
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
Jerome PAULIN
du mal à modéliser la chose dans ma tete et c'est ce qui me
gene le plus. J'ai du mal à modéliser une relation R en tableau. Par exemple, soit la relation D (pour "double") qui a tout entier "n" associe son double "n*2". Si je dois représenter cette relation R sous forme de tableau, comment je fais? Sachant qu'un relation est mathématiquement définie par son ensemble de départ, ensemble d'arrivé et l'expression de la "relation".
Je pense que le soucis que tu as rencontré est lié au fait que tu as confondu les enregistrements (ils s'identifient de manière unique par leur clé primaire par exemple par ID_DEPART et ID_DESTINATION) et les valeurs des enregistrements.
gg
du mal à modéliser la chose dans ma tete et c'est ce qui me
gene le plus.
J'ai du mal à modéliser une relation R en tableau.
Par exemple, soit la relation D (pour "double") qui a tout entier "n"
associe son double "n*2".
Si je dois représenter cette relation R sous forme de tableau,
comment je fais? Sachant qu'un relation est mathématiquement définie par son
ensemble de départ, ensemble d'arrivé et l'expression de la "relation".
Je pense que le soucis que tu as rencontré est lié au fait que tu as
confondu les enregistrements (ils s'identifient de manière unique par
leur clé primaire par exemple par ID_DEPART et ID_DESTINATION) et les
valeurs des enregistrements.
du mal à modéliser la chose dans ma tete et c'est ce qui me
gene le plus. J'ai du mal à modéliser une relation R en tableau. Par exemple, soit la relation D (pour "double") qui a tout entier "n" associe son double "n*2". Si je dois représenter cette relation R sous forme de tableau, comment je fais? Sachant qu'un relation est mathématiquement définie par son ensemble de départ, ensemble d'arrivé et l'expression de la "relation".
Je pense que le soucis que tu as rencontré est lié au fait que tu as confondu les enregistrements (ils s'identifient de manière unique par leur clé primaire par exemple par ID_DEPART et ID_DESTINATION) et les valeurs des enregistrements.
gg
Mihamina Rakotomandimby (R12y)
Jerome PAULIN wrote:
J'ai du mal à modéliser une relation R en tableau. Par exemple, soit la relation D (pour "double") qui a tout entier "n" associe son double "n*2". Si je dois représenter cette relation R sous forme de tableau, comment je fais? Sachant qu'un relation est mathématiquement définie par son ensemble de départ, ensemble d'arrivé et l'expression de la "relation".
Je ferai un tableau pour l'ensemble de depart t_depart ID_DEPART Valeur 1 3
[...]
Un autre tableau pour l'ensemble de destination t_destination ID_DESTINATION Valeur 1 2 2 4 ou ID_DESTINATION est une clé primaire La table relation permet de définir un lien entre les deux autres tables t_relation ID_DEPART ID_DESTINATION 1 4 2 5 3 1
Ok. Pour représenter une relation sous forme de table, il nous a fallu 3 tables. Pourquoi dans les exemples, comme celui que j'ai cité, on donne une table et on dit qu'elle représente une relation? Je pense qu'on sous-entend certaines choses [1] et ce sont justement ces sous-entendus qui m'achappent.
[1] Par exemple que les ensembles de départ ont une forme pré-établie (laquelle?), ou autre...
Jerome PAULIN wrote:
J'ai du mal à modéliser une relation R en tableau.
Par exemple, soit la relation D (pour "double") qui a tout entier "n"
associe son double "n*2".
Si je dois représenter cette relation R sous forme de tableau,
comment je fais? Sachant qu'un relation est mathématiquement définie par
son ensemble de départ, ensemble d'arrivé et l'expression de la
"relation".
Je ferai un tableau pour l'ensemble de depart
t_depart
ID_DEPART Valeur
1 3
[...]
Un autre tableau pour l'ensemble de destination
t_destination
ID_DESTINATION Valeur
1 2
2 4
ou ID_DESTINATION est une clé primaire
La table relation permet de définir un lien entre les deux autres tables
t_relation
ID_DEPART ID_DESTINATION
1 4
2 5
3 1
Ok. Pour représenter une relation sous forme de table, il nous a fallu 3
tables.
Pourquoi dans les exemples, comme celui que j'ai cité, on donne une table et
on dit qu'elle représente une relation? Je pense qu'on sous-entend
certaines choses [1] et ce sont justement ces sous-entendus qui
m'achappent.
[1] Par exemple que les ensembles de départ ont une forme pré-établie
(laquelle?), ou autre...
J'ai du mal à modéliser une relation R en tableau. Par exemple, soit la relation D (pour "double") qui a tout entier "n" associe son double "n*2". Si je dois représenter cette relation R sous forme de tableau, comment je fais? Sachant qu'un relation est mathématiquement définie par son ensemble de départ, ensemble d'arrivé et l'expression de la "relation".
Je ferai un tableau pour l'ensemble de depart t_depart ID_DEPART Valeur 1 3
[...]
Un autre tableau pour l'ensemble de destination t_destination ID_DESTINATION Valeur 1 2 2 4 ou ID_DESTINATION est une clé primaire La table relation permet de définir un lien entre les deux autres tables t_relation ID_DEPART ID_DESTINATION 1 4 2 5 3 1
Ok. Pour représenter une relation sous forme de table, il nous a fallu 3 tables. Pourquoi dans les exemples, comme celui que j'ai cité, on donne une table et on dit qu'elle représente une relation? Je pense qu'on sous-entend certaines choses [1] et ce sont justement ces sous-entendus qui m'achappent.
[1] Par exemple que les ensembles de départ ont une forme pré-établie (laquelle?), ou autre...
Jogo
Sur fr.comp.applications.sgbd, Mihamina (R12y) Rakotomandimby disait :
Par exemple, soit la relation D (pour "double") qui a tout entier "n" associe son double "n*2". Si je dois représenter cette relation R sous forme de tableau, comment je fais? Sachant qu'un relation est mathématiquement définie par son ensemble de départ, ensemble d'arrivé et l'expression de la "relation".
L'expression de la relation, ce sont les couples qui satisfont la relation. Ce sont ces couples qui forment la table.
Pour double la table ressembleraît donc à : 0 0 1 2 2 4 3 6 4 8 etc...
Peut-être as-tu des difficultés parce que tu assimiles une relation à une fonction. Les fonctions ne sont que des cas particuliers. Pense par exemple à la relation "est perpendiculaire" sur l'ensembles des droites (ou sur *un* ensemble de droites).
Dans ton exemple la relation mathématique est une relation entre 2 ensembles. Les relations d'une BDD sont entre n ensembles, n étant le nombre de colonnes.
Par exemples on pourraît définir la relation "est coplanaire" entre 4 points de l'espace.
Inversement, considérons un répertoire d'adresse. On peut le modéliser comme une relation entre une personne et une adresse. On aura alors 2 colonnes (certainement des clefs étrangères). Une modélisation plus classique consiste à considérer une relation entre un nom, un prénom, un code postal, une ville, une adresse. On aura alors une table avec 5 colonnes.
La différence entre ces relations et SQL dans la réalité, c'est qu'une table peut contenir des doublons, ce qui n'a pas de sens pour une relation (voir <45d2cc31$0$21144$).
-- L'attente stimule l'imagination, les promesses de concrétisation semblant d'autant plus douces qu'elles sont différées - Serge Chaumier - La déliaison amoureuse -
Sur fr.comp.applications.sgbd, Mihamina (R12y) Rakotomandimby disait :
Par exemple, soit la relation D (pour "double") qui a tout entier "n"
associe son double "n*2".
Si je dois représenter cette relation R sous forme de tableau,
comment je fais? Sachant qu'un relation est mathématiquement définie
par son ensemble de départ, ensemble d'arrivé et l'expression de la
"relation".
L'expression de la relation, ce sont les couples qui satisfont la
relation. Ce sont ces couples qui forment la table.
Pour double la table ressembleraît donc à :
0 0
1 2
2 4
3 6
4 8
etc...
Peut-être as-tu des difficultés parce que tu assimiles une relation à
une fonction. Les fonctions ne sont que des cas particuliers. Pense par
exemple à la relation "est perpendiculaire" sur l'ensembles des droites
(ou sur *un* ensemble de droites).
Dans ton exemple la relation mathématique est une relation entre 2
ensembles. Les relations d'une BDD sont entre n ensembles, n étant le
nombre de colonnes.
Par exemples on pourraît définir la relation "est coplanaire" entre 4
points de l'espace.
Inversement, considérons un répertoire d'adresse. On peut le modéliser
comme une relation entre une personne et une adresse. On aura alors 2
colonnes (certainement des clefs étrangères). Une modélisation plus
classique consiste à considérer une relation entre un nom, un prénom,
un code postal, une ville, une adresse. On aura alors une table avec 5
colonnes.
La différence entre ces relations et SQL dans la réalité, c'est qu'une
table peut contenir des doublons, ce qui n'a pas de sens pour une
relation (voir <45d2cc31$0$21144$7a628cd7@news.club-internet.fr>).
--
L'attente stimule l'imagination, les promesses de concrétisation
semblant d'autant plus douces qu'elles sont différées
- Serge Chaumier - La déliaison amoureuse -
Sur fr.comp.applications.sgbd, Mihamina (R12y) Rakotomandimby disait :
Par exemple, soit la relation D (pour "double") qui a tout entier "n" associe son double "n*2". Si je dois représenter cette relation R sous forme de tableau, comment je fais? Sachant qu'un relation est mathématiquement définie par son ensemble de départ, ensemble d'arrivé et l'expression de la "relation".
L'expression de la relation, ce sont les couples qui satisfont la relation. Ce sont ces couples qui forment la table.
Pour double la table ressembleraît donc à : 0 0 1 2 2 4 3 6 4 8 etc...
Peut-être as-tu des difficultés parce que tu assimiles une relation à une fonction. Les fonctions ne sont que des cas particuliers. Pense par exemple à la relation "est perpendiculaire" sur l'ensembles des droites (ou sur *un* ensemble de droites).
Dans ton exemple la relation mathématique est une relation entre 2 ensembles. Les relations d'une BDD sont entre n ensembles, n étant le nombre de colonnes.
Par exemples on pourraît définir la relation "est coplanaire" entre 4 points de l'espace.
Inversement, considérons un répertoire d'adresse. On peut le modéliser comme une relation entre une personne et une adresse. On aura alors 2 colonnes (certainement des clefs étrangères). Une modélisation plus classique consiste à considérer une relation entre un nom, un prénom, un code postal, une ville, une adresse. On aura alors une table avec 5 colonnes.
La différence entre ces relations et SQL dans la réalité, c'est qu'une table peut contenir des doublons, ce qui n'a pas de sens pour une relation (voir <45d2cc31$0$21144$).
-- L'attente stimule l'imagination, les promesses de concrétisation semblant d'autant plus douces qu'elles sont différées - Serge Chaumier - La déliaison amoureuse -
