Bien s=FBr, l'association =E0 laquelle on songe naturellement est celle qui
lie les enseignants aux mati=E8res. Mais, il se trouve
-- que certaines mati=E8res sont enseign=E9es par certains enseignants en
1=E8re ann=E9e mais par d'autres en 2=E8me ann=E9e ;
-- que certaines mati=E8res soient enseign=E9es en 1=E8re ann=E9e par un
certain enseignant en cours et par un autre en TD, etc.
J'ai donc l'impression d'avoir affaire =E0 une association n-naire
(n=3D4) pour laquelle il faudrait construire une table de jointure,
nomm=E9e, par exemple, =AB interventions =BB et dont les enregistrements
contiendraient par exemple :
Or, j'ai souvent lu que ces associations n-naires =E9taient =E0 =E9viter et=
=E0
remplacer, ce qui est presque toujours possible, par des
associations binaires. Et l=E0, paf, je ne vois pas tr=E8s bien comment il
serait judicieux de mod=E9liser les choses. Aussi, malgr=E9 mes nombreuses
lectures, en particulier sur SQLPro, je me tourne vers vous pour un
petit conseil.
1/ attention à ce que tu définis comme 'matières'. S'agit-t'il de la / d'une des spécialités d'un enseignant (genre capes de géo) ou d'un rassemblement plus ou moins arbitraire de cours (genre informatique)
2/ pour modéliser, je te conseille de te limiter aux relations pertinentes (et non toutes les relations possibles). ça ne mange pas de pain de définir quelques attributs majeurs des entités (ça permet de clarifier la définition de l'entité)
3/ après analyse du modèle, des entités peuvent fusionner ou se transformer en simple attribut.
pour donner un exemple, tu pourrais dans ton cas avoir un modèle du genre :
enseignant 1-n cours (ou n-n) public/classe 1-n cours type 1-n cours (ou type comme attribut) cours 1-n tranche_horaire*salle
la matiere serait un attribut d'enseignant ou bien de cours ou bien une entité liée à cours.
cours peut avoir des attributs propres tq coefficient, nombre d'heures au programme, dépendance avec un autre cours (genre pour s'inscrire à SGBD 101 il faut avoir réussi Orthographe 213, ou pas de TD sans Amphi), etc.
mes deux centimes. -- Geoffroy
Denis Bitouzé wrote:
Je cherche à mettre en place un système d'édition d'emploi du temps
dans l'établissement où j'enseigne.
1/ attention à ce que tu définis comme 'matières'. S'agit-t'il de la /
d'une des spécialités d'un enseignant (genre capes de géo) ou d'un
rassemblement plus ou moins arbitraire de cours (genre informatique)
2/ pour modéliser, je te conseille de te limiter aux relations
pertinentes (et non toutes les relations possibles). ça ne mange pas de
pain de définir quelques attributs majeurs des entités (ça permet de
clarifier la définition de l'entité)
3/ après analyse du modèle, des entités peuvent fusionner ou se
transformer en simple attribut.
pour donner un exemple, tu pourrais dans ton cas avoir un modèle du genre :
enseignant 1-n cours (ou n-n)
public/classe 1-n cours
type 1-n cours (ou type comme attribut)
cours 1-n tranche_horaire*salle
la matiere serait un attribut d'enseignant ou bien de cours ou bien une
entité liée à cours.
cours peut avoir des attributs propres tq coefficient, nombre d'heures
au programme, dépendance avec un autre cours (genre pour s'inscrire à
SGBD 101 il faut avoir réussi Orthographe 213, ou pas de TD sans Amphi),
etc.
1/ attention à ce que tu définis comme 'matières'. S'agit-t'il de la / d'une des spécialités d'un enseignant (genre capes de géo) ou d'un rassemblement plus ou moins arbitraire de cours (genre informatique)
2/ pour modéliser, je te conseille de te limiter aux relations pertinentes (et non toutes les relations possibles). ça ne mange pas de pain de définir quelques attributs majeurs des entités (ça permet de clarifier la définition de l'entité)
3/ après analyse du modèle, des entités peuvent fusionner ou se transformer en simple attribut.
pour donner un exemple, tu pourrais dans ton cas avoir un modèle du genre :
enseignant 1-n cours (ou n-n) public/classe 1-n cours type 1-n cours (ou type comme attribut) cours 1-n tranche_horaire*salle
la matiere serait un attribut d'enseignant ou bien de cours ou bien une entité liée à cours.
cours peut avoir des attributs propres tq coefficient, nombre d'heures au programme, dépendance avec un autre cours (genre pour s'inscrire à SGBD 101 il faut avoir réussi Orthographe 213, ou pas de TD sans Amphi), etc.
mes deux centimes. -- Geoffroy
Denis Bitouzé
Le Mon, 15 Nov 2004 23:01:20 +0100 "P'tit Marcel" a écrit:
1/ attention à ce que tu définis comme 'matières'. S'agit-t'il de la / d'une des spécialités d'un enseignant (genre capes de géo) ou d'u n rassemblement plus ou moins arbitraire de cours (genre informatique)
Ni l'un ni l'autre ;) : 1) une matière n'est pas une des spécialités d'un enseignant : elle peut être enseignée par différents enseignants selon que : a) ce sera en 1ère année, en 2ème année,..., en CAPES, etc. ; b) ce sera en cours, TD, TP, etc. donc, à ce titre, chaque matière peut être vue comme un rassemblement plus ou moins arbitraire de « cours » (mais je ne suis pas tout à fait sûr de ce que tu entends par « cours ») ; 2) chaque matière peut être vue comme une spécialité ; par exemple, chez nous, l'informatique est un tout et ne se décline pas en sous-matières.
Autrement dit, -- chaque matière est en soit atomique : par exemple, il n'y a pas *une* matière « physique », mais *des* matières « électricité », « mécanique des fluides», « thermodynamique », etc. ; -- il y a une déclinaison de chaque matière à faire : -- selon le public (1ère année, en 2ème année,..., en CAPES, e tc.) -- selon le type de séance (cours, TD, TP, etc.).
2/ pour modéliser, je te conseille de te limiter aux relations pertinentes (et non toutes les relations possibles). ça ne mange pas de pain de définir quelques attributs majeurs des entités (ça permet de clarifier la définition de l'entité)
Euh, je ne suis pas sûr de bien te comprendre. Pourrais-tu donner un exemple d'attribut majeur d'entité ?
En fait, si je souhaite préciser tant les choses, c'est pour faciliter la tâche et limiter les erreurs de la secrétaire qui saisira les données de l'emploi du temps avec l'interface Web prévue ; par exemple, lorsqu'elle aura choisi, pour une séance d'une heure donnée d'un jour donné : -- le public dans la liste des publics ; -- le type de séance dans la liste des types de séance ; -- la matière dans la liste des matières ; l'enseignant soit pré-sélectionné dans la liste des enseignants. J'ai oublié de préciser que, chez nous, l'emploi du temps change chaque semaine et que, donc, rendre la chose ergonomique pour la secrétaire est loin d'être un luxe...
Ces précisions ont aussi pour but de pouvoir facilement faire des bilans, par exemple pour être en mesure de donner en cours d'année, le nombre d'heures effectuées par l'enseignant Duschmol, en cours et en TD...
3/ après analyse du modèle, des entités peuvent fusionner ou se transformer en simple attribut.
Euh, là encore, pourrais-tu me donner un exemple d'entités fusionnant ou se transformant en simple attribut ?
pour donner un exemple, tu pourrais dans ton cas avoir un modèle du genre :
enseignant 1-n cours (ou n-n) public/classe 1-n cours type 1-n cours (ou type comme attribut) cours 1-n tranche_horaire*salle
Je vais examiner cela mais, euh, peux-tu me dire ce que tu entends par ce * ?
la matiere serait un attribut d'enseignant
Certains enseignants enseignent plusieurs matières (informatique et maths par exemple), donc ça irait à l'encontre de je ne sais plus quelle forme normale, non ?
ou bien de cours
Oui, mais on aimerait pouvoir par exemple distinguer le cours « cours magistral de maths en 1ère année » du cours « TD de maths en 2ème année » donc il faudrait, à l'entité « cours », ajouter les att ributs « type de séance » et « public », me trompè-je ?
ou bien une entité liée à cours.
Je vais examiner cela...
cours peut avoir des attributs propres tq coefficient, nombre d'heures au programme, dépendance avec un autre cours (genre pour s'inscrire à SGBD 101 il faut avoir réussi Orthographe 213, ou pas de TD sans Amphi), etc.
Tout à fait !
mes deux centimes.
Bien plus que cela ! Merci beaucoup ! -- Denis
Le Mon, 15 Nov 2004 23:01:20 +0100
"P'tit Marcel" <geononauxspams@centrale-lyon.org> a écrit:
1/ attention à ce que tu définis comme 'matières'. S'agit-t'il de la
/ d'une des spécialités d'un enseignant (genre capes de géo) ou d'u n
rassemblement plus ou moins arbitraire de cours (genre informatique)
Ni l'un ni l'autre ;) :
1) une matière n'est pas une des spécialités d'un enseignant : elle
peut être enseignée par différents enseignants selon que :
a) ce sera en 1ère année, en 2ème année,..., en CAPES, etc. ;
b) ce sera en cours, TD, TP, etc.
donc, à ce titre, chaque matière peut être vue comme un rassemblement
plus ou moins arbitraire de « cours » (mais je ne suis pas tout à fait
sûr de ce que tu entends par « cours ») ;
2) chaque matière peut être vue comme une spécialité ; par exemple,
chez nous, l'informatique est un tout et ne se décline pas en
sous-matières.
Autrement dit,
-- chaque matière est en soit atomique : par exemple, il n'y a pas
*une* matière « physique », mais *des* matières « électricité », «
mécanique des fluides», « thermodynamique », etc. ;
-- il y a une déclinaison de chaque matière à faire :
-- selon le public (1ère année, en 2ème année,..., en CAPES, e tc.)
-- selon le type de séance (cours, TD, TP, etc.).
2/ pour modéliser, je te conseille de te limiter aux relations
pertinentes (et non toutes les relations possibles). ça ne mange pas
de pain de définir quelques attributs majeurs des entités (ça permet
de clarifier la définition de l'entité)
Euh, je ne suis pas sûr de bien te comprendre. Pourrais-tu donner un
exemple d'attribut majeur d'entité ?
En fait, si je souhaite préciser tant les choses, c'est pour faciliter
la tâche et limiter les erreurs de la secrétaire qui saisira les
données de l'emploi du temps avec l'interface Web prévue ; par exemple,
lorsqu'elle aura choisi, pour une séance d'une heure donnée d'un jour
donné :
-- le public dans la liste des publics ;
-- le type de séance dans la liste des types de séance ;
-- la matière dans la liste des matières ;
l'enseignant soit pré-sélectionné dans la liste des enseignants. J'ai
oublié de préciser que, chez nous, l'emploi du temps change chaque
semaine et que, donc, rendre la chose ergonomique pour la secrétaire
est loin d'être un luxe...
Ces précisions ont aussi pour but de pouvoir facilement faire des
bilans, par exemple pour être en mesure de donner en cours d'année, le
nombre d'heures effectuées par l'enseignant Duschmol, en cours et en
TD...
3/ après analyse du modèle, des entités peuvent fusionner ou se
transformer en simple attribut.
Euh, là encore, pourrais-tu me donner un exemple d'entités fusionnant
ou se transformant en simple attribut ?
pour donner un exemple, tu pourrais dans ton cas avoir un modèle du
genre :
enseignant 1-n cours (ou n-n)
public/classe 1-n cours
type 1-n cours (ou type comme attribut)
cours 1-n tranche_horaire*salle
Je vais examiner cela mais, euh, peux-tu me dire ce que tu entends par
ce * ?
la matiere serait un attribut d'enseignant
Certains enseignants enseignent plusieurs matières
(informatique et maths par exemple), donc ça irait à
l'encontre de je ne sais plus quelle forme normale, non ?
ou bien de cours
Oui, mais on aimerait pouvoir par exemple distinguer le cours «
cours magistral de maths en 1ère année » du cours « TD de maths en 2ème
année » donc il faudrait, à l'entité « cours », ajouter les att ributs «
type de séance » et « public », me trompè-je ?
ou bien une entité liée à cours.
Je vais examiner cela...
cours peut avoir des attributs propres tq coefficient, nombre
d'heures au programme, dépendance avec un autre cours (genre pour
s'inscrire à SGBD 101 il faut avoir réussi Orthographe 213, ou pas de
TD sans Amphi), etc.
Le Mon, 15 Nov 2004 23:01:20 +0100 "P'tit Marcel" a écrit:
1/ attention à ce que tu définis comme 'matières'. S'agit-t'il de la / d'une des spécialités d'un enseignant (genre capes de géo) ou d'u n rassemblement plus ou moins arbitraire de cours (genre informatique)
Ni l'un ni l'autre ;) : 1) une matière n'est pas une des spécialités d'un enseignant : elle peut être enseignée par différents enseignants selon que : a) ce sera en 1ère année, en 2ème année,..., en CAPES, etc. ; b) ce sera en cours, TD, TP, etc. donc, à ce titre, chaque matière peut être vue comme un rassemblement plus ou moins arbitraire de « cours » (mais je ne suis pas tout à fait sûr de ce que tu entends par « cours ») ; 2) chaque matière peut être vue comme une spécialité ; par exemple, chez nous, l'informatique est un tout et ne se décline pas en sous-matières.
Autrement dit, -- chaque matière est en soit atomique : par exemple, il n'y a pas *une* matière « physique », mais *des* matières « électricité », « mécanique des fluides», « thermodynamique », etc. ; -- il y a une déclinaison de chaque matière à faire : -- selon le public (1ère année, en 2ème année,..., en CAPES, e tc.) -- selon le type de séance (cours, TD, TP, etc.).
2/ pour modéliser, je te conseille de te limiter aux relations pertinentes (et non toutes les relations possibles). ça ne mange pas de pain de définir quelques attributs majeurs des entités (ça permet de clarifier la définition de l'entité)
Euh, je ne suis pas sûr de bien te comprendre. Pourrais-tu donner un exemple d'attribut majeur d'entité ?
En fait, si je souhaite préciser tant les choses, c'est pour faciliter la tâche et limiter les erreurs de la secrétaire qui saisira les données de l'emploi du temps avec l'interface Web prévue ; par exemple, lorsqu'elle aura choisi, pour une séance d'une heure donnée d'un jour donné : -- le public dans la liste des publics ; -- le type de séance dans la liste des types de séance ; -- la matière dans la liste des matières ; l'enseignant soit pré-sélectionné dans la liste des enseignants. J'ai oublié de préciser que, chez nous, l'emploi du temps change chaque semaine et que, donc, rendre la chose ergonomique pour la secrétaire est loin d'être un luxe...
Ces précisions ont aussi pour but de pouvoir facilement faire des bilans, par exemple pour être en mesure de donner en cours d'année, le nombre d'heures effectuées par l'enseignant Duschmol, en cours et en TD...
3/ après analyse du modèle, des entités peuvent fusionner ou se transformer en simple attribut.
Euh, là encore, pourrais-tu me donner un exemple d'entités fusionnant ou se transformant en simple attribut ?
pour donner un exemple, tu pourrais dans ton cas avoir un modèle du genre :
enseignant 1-n cours (ou n-n) public/classe 1-n cours type 1-n cours (ou type comme attribut) cours 1-n tranche_horaire*salle
Je vais examiner cela mais, euh, peux-tu me dire ce que tu entends par ce * ?
la matiere serait un attribut d'enseignant
Certains enseignants enseignent plusieurs matières (informatique et maths par exemple), donc ça irait à l'encontre de je ne sais plus quelle forme normale, non ?
ou bien de cours
Oui, mais on aimerait pouvoir par exemple distinguer le cours « cours magistral de maths en 1ère année » du cours « TD de maths en 2ème année » donc il faudrait, à l'entité « cours », ajouter les att ributs « type de séance » et « public », me trompè-je ?
ou bien une entité liée à cours.
Je vais examiner cela...
cours peut avoir des attributs propres tq coefficient, nombre d'heures au programme, dépendance avec un autre cours (genre pour s'inscrire à SGBD 101 il faut avoir réussi Orthographe 213, ou pas de TD sans Amphi), etc.
Tout à fait !
mes deux centimes.
Bien plus que cela ! Merci beaucoup ! -- Denis
Denis Bitouzé
Le Tue, 16 Nov 2004 23:14:32 +0100 "P'tit Marcel" a écrit:
> (mais je ne > suis pas tout à fait sûr de ce que tu entends par « cours ») ;
un enseignement par un professeur à un groupe d'élèves fixe, qui s'effectue par séances pendant un laps de temps long (semestre, année).
OK mais, avec mes maigres connaissances, je voyais ces cours regroupés en une table de jointure : celle dont je causais dans mon mail initial, que je nommais alors « interventions » et dont les enregistrements contenaient par exemple :
Je ne vois pas ce qui ne va pas dans cette approche...
exemple : "je vais plus au cours de TP LaTex, le prof veut plus qu'on load Unreal tournament sur les PC"
Tu as choisi l'exemple de LaTeX au hasard ? ;)
> Euh, je ne suis pas sûr de bien te comprendre. Pourrais-tu donner > un exemple d'attribut majeur d'entité ?
le nom, le nombre d'heures au programme, l'heure de début d'une tranche horaire de cours...
Ah oui, bien sûr ! Je croyais que ça cachait un concept précis...
> Euh, là encore, pourrais-tu me donner un exemple d'entités > fusionnant ou se transformant en simple attribut ?
a- deux entités liées par une relation 1-1 peuvent généralement être fusionnées.
Ça, OK.
b- dans un modèle de données classique de prise de commande, le client est une entité et l'entête de commande en est une autre. Dans certains modes de fonctionnement (vente au comptoir), on simplifie le schéma et les données du client sont stockées dans la commande sous forme d'attributs.
Entendu, mais où, dans le modèle dont je parlais initialement, ai-je pêché par manque de simplicité ? La table « interventions » plus haut est-elle vraiment trop atomisée ?
> Oui, mais on aimerait pouvoir par exemple distinguer le cours « > cours magistral de maths en 1ère année » du cours « TD de maths en > 2ème année » donc il faudrait, à l'entité « cours », ajou ter les > attributs « type de séance » et « public », me trompè-je ?
oui.
Euh (désolé pour le bruit) : « oui » pour
-- « me trompè-je »
ou pour
-- « il faudrait, à l'entité « cours », ajouter les attributs « type de séance » et « public » » ?
Merci ! -- Denis
Le Tue, 16 Nov 2004 23:14:32 +0100
"P'tit Marcel" <geononauxspams@centrale-lyon.org> a écrit:
> (mais je ne
> suis pas tout à fait sûr de ce que tu entends par « cours ») ;
un enseignement par un professeur à un groupe d'élèves fixe, qui
s'effectue par séances pendant un laps de temps long (semestre,
année).
OK mais, avec mes maigres connaissances, je voyais ces cours regroupés
en une table de jointure : celle dont je causais dans mon mail initial,
que je nommais alors « interventions » et dont les enregistrements
contenaient par exemple :
Je ne vois pas ce qui ne va pas dans cette approche...
exemple : "je vais plus au cours de TP LaTex, le prof veut plus qu'on
load Unreal tournament sur les PC"
Tu as choisi l'exemple de LaTeX au hasard ? ;)
> Euh, je ne suis pas sûr de bien te comprendre. Pourrais-tu donner
> un exemple d'attribut majeur d'entité ?
le nom, le nombre d'heures au programme, l'heure de début d'une
tranche horaire de cours...
Ah oui, bien sûr ! Je croyais que ça cachait un concept précis...
> Euh, là encore, pourrais-tu me donner un exemple d'entités
> fusionnant ou se transformant en simple attribut ?
a- deux entités liées par une relation 1-1 peuvent généralement être
fusionnées.
Ça, OK.
b- dans un modèle de données classique de prise de commande, le
client est une entité et l'entête de commande en est une autre. Dans
certains modes de fonctionnement (vente au comptoir), on simplifie le
schéma et les données du client sont stockées dans la commande sous
forme d'attributs.
Entendu, mais où, dans le modèle dont je parlais initialement, ai-je
pêché par manque de simplicité ? La table « interventions » plus haut
est-elle vraiment trop atomisée ?
> Oui, mais on aimerait pouvoir par exemple distinguer le cours «
> cours magistral de maths en 1ère année » du cours « TD de maths en
> 2ème année » donc il faudrait, à l'entité « cours », ajou ter les
> attributs « type de séance » et « public », me trompè-je ?
oui.
Euh (désolé pour le bruit) : « oui » pour
-- « me trompè-je »
ou pour
-- « il faudrait, à l'entité « cours », ajouter les attributs « type
de séance » et « public » » ?
Le Tue, 16 Nov 2004 23:14:32 +0100 "P'tit Marcel" a écrit:
> (mais je ne > suis pas tout à fait sûr de ce que tu entends par « cours ») ;
un enseignement par un professeur à un groupe d'élèves fixe, qui s'effectue par séances pendant un laps de temps long (semestre, année).
OK mais, avec mes maigres connaissances, je voyais ces cours regroupés en une table de jointure : celle dont je causais dans mon mail initial, que je nommais alors « interventions » et dont les enregistrements contenaient par exemple :
Je ne vois pas ce qui ne va pas dans cette approche...
exemple : "je vais plus au cours de TP LaTex, le prof veut plus qu'on load Unreal tournament sur les PC"
Tu as choisi l'exemple de LaTeX au hasard ? ;)
> Euh, je ne suis pas sûr de bien te comprendre. Pourrais-tu donner > un exemple d'attribut majeur d'entité ?
le nom, le nombre d'heures au programme, l'heure de début d'une tranche horaire de cours...
Ah oui, bien sûr ! Je croyais que ça cachait un concept précis...
> Euh, là encore, pourrais-tu me donner un exemple d'entités > fusionnant ou se transformant en simple attribut ?
a- deux entités liées par une relation 1-1 peuvent généralement être fusionnées.
Ça, OK.
b- dans un modèle de données classique de prise de commande, le client est une entité et l'entête de commande en est une autre. Dans certains modes de fonctionnement (vente au comptoir), on simplifie le schéma et les données du client sont stockées dans la commande sous forme d'attributs.
Entendu, mais où, dans le modèle dont je parlais initialement, ai-je pêché par manque de simplicité ? La table « interventions » plus haut est-elle vraiment trop atomisée ?
> Oui, mais on aimerait pouvoir par exemple distinguer le cours « > cours magistral de maths en 1ère année » du cours « TD de maths en > 2ème année » donc il faudrait, à l'entité « cours », ajou ter les > attributs « type de séance » et « public », me trompè-je ?
oui.
Euh (désolé pour le bruit) : « oui » pour
-- « me trompè-je »
ou pour
-- « il faudrait, à l'entité « cours », ajouter les attributs « type de séance » et « public » » ?
Merci ! -- Denis
Denis Bitouzé
Le Sat, 20 Nov 2004 00:01:43 +0100 "P'tit Marcel" a écrit:
Denis Bitouzé wrote: > > Je ne vois pas ce qui ne va pas dans cette approche...
moi non plus.
Aaaaahhh, ouf !
Cette table ne contiendra pas seulement ces identifiants, mais aussi des attributs propres (genre nb d'heures du programme, et autres que j'ai déjà décrits).
Tout à fait !
Le fait que l'entité est liée à de nombreuses données de référence (= quasi-invariante s) n'est amha pas une erreur en soi, cela traduit qu'elle est l'élément central de ton univers.
OK. Encore que « mon » univers, hein, c'est plus grand que ça, heureusement ;)
Au passage, je te recommande de choisir des noms plus parlants comme "matiere_id" ou "public_id". Le Ko ne coûte plus grand chose et les programmeurs qui maintiendront peut être ton code dans 10 ans t'en remercieront.
C'est vrai ; en fait, n'y connaissant pas grand chose mais cherchant à faire le mieux possible, j'ai voulu suivre les conseils « Normalisation des noms des objets des bases de données », de Frédér ic Brouard, qu'on trouve ici :
http://sql.developpez.com/standards/
et qui spécifient en particulier :
« Les noms de colonnes doivent être préfixée par le trigramme de la table d'origine et reprendre le nom d'attribut. »
> Tu as choisi l'exemple de LaTeX au hasard ? ;)
non, google est mon ami !
Argh, démasqué !
> Entendu, mais où, dans le modèle dont je parlais initialement, > ai-je pêché par manque de simplicité ? La table « interventions » > plus haut est-elle vraiment trop atomisée ?
c'est impossible à dire tant que tu n'auras pas formalisé la totalit é des données qui seront effectivement gérées (et à quelles fins) et que tu ne les auras pas regroupées en entités. Par exemple, si tu constatais que le "type" ou la "matière" est finalement une information facultative, inutilisée, subjective, variant dans le temps, etc., tu pourrais choisir de remplacer typ_id rep.mat_id par un simple attribut alphanumérique libre et supprimer la table de référence.
OK.
Je ne suis pas si perfide
Je n'ai jamais insinué une chose pareille, c'est pas mon genre ;)
Merci encore ! -- Denis
Le Sat, 20 Nov 2004 00:01:43 +0100
"P'tit Marcel" <geononauxspams@centrale-lyon.org> a écrit:
Denis Bitouzé wrote:
>
> Je ne vois pas ce qui ne va pas dans cette approche...
moi non plus.
Aaaaahhh, ouf !
Cette table ne contiendra pas seulement ces
identifiants, mais aussi des attributs propres (genre nb d'heures du
programme, et autres que j'ai déjà décrits).
Tout à fait !
Le fait que l'entité est
liée à de nombreuses données de référence (= quasi-invariante s) n'est
amha pas une erreur en soi, cela traduit qu'elle est l'élément
central de ton univers.
OK. Encore que « mon » univers, hein, c'est plus grand que ça,
heureusement ;)
Au passage, je te recommande de choisir des noms plus parlants comme
"matiere_id" ou "public_id". Le Ko ne coûte plus grand chose et les
programmeurs qui maintiendront peut être ton code dans 10 ans t'en
remercieront.
C'est vrai ; en fait, n'y connaissant pas grand chose mais
cherchant à faire le mieux possible, j'ai voulu suivre les conseils «
Normalisation des noms des objets des bases de données », de Frédér ic
Brouard, qu'on trouve ici :
http://sql.developpez.com/standards/
et qui spécifient en particulier :
« Les noms de colonnes doivent être préfixée par le trigramme de la
table d'origine et reprendre le nom d'attribut. »
> Tu as choisi l'exemple de LaTeX au hasard ? ;)
non, google est mon ami !
Argh, démasqué !
> Entendu, mais où, dans le modèle dont je parlais initialement,
> ai-je pêché par manque de simplicité ? La table « interventions »
> plus haut est-elle vraiment trop atomisée ?
c'est impossible à dire tant que tu n'auras pas formalisé la totalit é
des données qui seront effectivement gérées (et à quelles fins) et
que tu ne les auras pas regroupées en entités. Par exemple, si tu
constatais que le "type" ou la "matière" est finalement une
information facultative, inutilisée, subjective, variant dans le
temps, etc., tu pourrais choisir de remplacer typ_id rep.mat_id par
un simple attribut alphanumérique libre et supprimer la table de
référence.
OK.
Je ne suis pas si perfide
Je n'ai jamais insinué une chose pareille, c'est pas mon genre ;)
Le Sat, 20 Nov 2004 00:01:43 +0100 "P'tit Marcel" a écrit:
Denis Bitouzé wrote: > > Je ne vois pas ce qui ne va pas dans cette approche...
moi non plus.
Aaaaahhh, ouf !
Cette table ne contiendra pas seulement ces identifiants, mais aussi des attributs propres (genre nb d'heures du programme, et autres que j'ai déjà décrits).
Tout à fait !
Le fait que l'entité est liée à de nombreuses données de référence (= quasi-invariante s) n'est amha pas une erreur en soi, cela traduit qu'elle est l'élément central de ton univers.
OK. Encore que « mon » univers, hein, c'est plus grand que ça, heureusement ;)
Au passage, je te recommande de choisir des noms plus parlants comme "matiere_id" ou "public_id". Le Ko ne coûte plus grand chose et les programmeurs qui maintiendront peut être ton code dans 10 ans t'en remercieront.
C'est vrai ; en fait, n'y connaissant pas grand chose mais cherchant à faire le mieux possible, j'ai voulu suivre les conseils « Normalisation des noms des objets des bases de données », de Frédér ic Brouard, qu'on trouve ici :
http://sql.developpez.com/standards/
et qui spécifient en particulier :
« Les noms de colonnes doivent être préfixée par le trigramme de la table d'origine et reprendre le nom d'attribut. »
> Tu as choisi l'exemple de LaTeX au hasard ? ;)
non, google est mon ami !
Argh, démasqué !
> Entendu, mais où, dans le modèle dont je parlais initialement, > ai-je pêché par manque de simplicité ? La table « interventions » > plus haut est-elle vraiment trop atomisée ?
c'est impossible à dire tant que tu n'auras pas formalisé la totalit é des données qui seront effectivement gérées (et à quelles fins) et que tu ne les auras pas regroupées en entités. Par exemple, si tu constatais que le "type" ou la "matière" est finalement une information facultative, inutilisée, subjective, variant dans le temps, etc., tu pourrais choisir de remplacer typ_id rep.mat_id par un simple attribut alphanumérique libre et supprimer la table de référence.
OK.
Je ne suis pas si perfide
Je n'ai jamais insinué une chose pareille, c'est pas mon genre ;)
