Discussion :

[sudtek]

Bonjour fsmrel,

J’ai transformé le MCD en intégrant la factorisation et suis passé en version V10_7_P le tout via paint !

Au passage la relation :

PROFESSEUR ---0,1--- R ---0,N---ADRESSE--- 0,N--- R--- 0,1--- ELEVE

est devenue PERSONNE ---0,1---R---1,N---ADRESSE

J’ai changé la cardinalité 0,N pour 1,N car dans la 1er relation l’adresse était attribué à un PROFESSEUR ou un ELEVE et très rarement au deux, alors que dans la seconde relation elle est toujours attribué in fine à une personne ou plus rarement à plusieurs.

J’ai conservé à titre indicatif sur le MCD le schéma de la relation PERSONNE ---0,1---R---1,N---ADRESSE pour que l’on constate l’origine de PERSONNE_ADRESSE.

Vous noterez dans ce MCD que PROFESSEUR et ELEVE ont seulement des identifiants alternatifs (EleveMatricule, ProfMatricule, Login (si 2 profs ne peuvent pas avoir le même login)) mais pas d’identifiant « primaire » puisque celui-ci est hérité de PERSONNE et sera présent au niveau MLD, en l’occurrence avec comme clé primaire {PersonneId} (rien ne vous empêche à ce stade de remplacer le nom PersonneId par IdProfesseur (table PROFESSEUR) d’une part et IdEleve d’autre part (table ELEVE)).

J’ai fait un test, voici le résultat du MLD :

Envoyé par sudtek
en fait sur le MCD il faut être un expert pour s'en rendre compte, c'est bien plus évident à voir sur le MLD !

Exact... Vérifiez s’il n’y a pas le même genre de coup fourré pour les modules...

idModule,#idUE composent la clef primaire, la seule clef alternative possible serait de faire une AK composé de tous les autres identificateurs hormis libelléModule mais je trouve que c’est pas très parlant pour un humain ! {| rangModule, coefModule, choixModule, numAnneeModule, #idCNU, #idTypeEpreuve |}




Ci joint le binder MCD + MLD de la V10_7_P.

Cordialement SUDTEK

[fsmrel]

Bonsoir sudtek,


PAINT est effectivement un allié d’une puissance redoutable en modélisation...


Vous avez intégré la spécialisation de notations, c’est bon, à ceci près que le terme NOTATION_EFFECTIF donne l’impression qu’on note un effectif, c'est-à-dire un ensemble d’élèves : c’est trompeur, il faudrait revenir au sens de notation effective, effectuée, faite, présente...

De la même façon, il faudrait remplacer le terme NOTATION_ABSENCE par NOTATION_ABSENTE, car, nuance subtile, dans le 1er cas vous dites que vous notez une absence alors que dans le 2e cas on dit que la notation est absente (l’attribut CodeAbsence disant pourquoi).

Par ailleurs, votre clé de PMACU est incomplète : idProfesseur doit en faire partie et à défaut cet attribut ne peut pas figurer dans la table NOTATION_EFFECTIF où par ailleurs il ne peut pas être élément de la clé, sinon cela voudrait dire que plusieurs professeurs peuvent noter la même copie d’un élève. Comparez votre MLD au mien (où j’ai eu à remplacer une cardinalité 0,N par 0,1 (bug PowerAMC))...


Entité-type PERSONNE

Je vois que le 2e prénom de l’élève et sa date de naissance ont été déplacés dans l’en-tête de l’entité-type PERSONNE. Pour le 2e prénom, pourquoi pas, mais quant à la date de naissance, est-ce à dire que désormais on doit aussi connaître celle des professeurs ?


Entité-type PROFESSEUR

Le login ne fait pas l’objet d’une clé alternative ?


Entité-type ADRESSE

Les adresses sont considérées jusqu’ici comme autonomes (à ceci près que désormais à une adresse habite au moins une personne et comme vous dites, rarement plus d’une). J’ai constaté que dans les entreprises où l’on gère les adresses des clients, la modélisation actuelle a le plus souvent posé de gros problèmes de performance dans les traitements de masse (batch) quand le nombre de clients commençait à atteindre cent mille (a fortiori quand on dépasse le million) : en l’occurrence, pour que les traitements percutassent, il fallait finalement modéliser ainsi (notez les parenthèses de l’identification relative) :

[PERSONNE]----0,N----(localiser)----(1,1)----[ADRESSE]

Vous m’objecterez que vous n’avez pas cent mille élèves et donc que cette solution alternative n’est pas déterminante dans le cadre de l’IUT. Néanmoins, si un jour, en tant que spécialiste des bases de données , vous êtes confronté à cette situation dans une grande banque, une administration, une caisse de retraite, etc., souvenez-vous de ma réflexion. Quant à la programmation relative à la gestion des adresses, elle me paraît plus naturelle et simple avec cette alternative, même si nous traitons ici de la modélisation des données et pas des traitements.

Vous m’objecterez aussi que lorsque deux personnes habitent au même endroit, il y aura redondance d’information : mais comme vous dites, cela sera rare et je dirais aussi que ça sera avec une incidence epsilonesque...

[sudtek]

Bonjour fsmrel,

Entité-type NOTATION_EFFECTIF
donne l’impression qu’on note un effectif … NOTATION_ABSENCE par NOTATION_ABSENT car, nuance subtile, dans le 1er cas vous dites que vous notez une absence alors que dans le 2e cas on dit que la notation est absent

Oui effectivement avec le recul je constate que c’est noms d’entités sont sujet à confusion !
NOTATION_EFFECTIF – > NOTATION_EFFECTIVE
NOTATION_ABSENCE – > NOTATION_ABSENTE

Entité-type PMACU
Par ailleurs, votre clé de PMACU est incomplète :
- idProfesseur doit en faire partie
- à défaut cet attribut ne peut pas figurer dans la table NOTATION_EFFECTIF où par ailleurs il ne peut pas être élément de la clé, sinon cela voudrait dire que plusieurs professeurs peuvent noter la même copie d’un élève. Comparez votre MLD au mien (où j’ai eu à remplacer une cardinalité 0,N par 0,1 (bug PowerAMC))...

J'ai modifié :

Entité-type PERSONNE
Je vois que le 2e prénom de l’élève et sa date de naissance ont été déplacés dans l’en-tête de l’entité-type PERSONNE. Pour le 2e prénom, pourquoi pas, mais quant à la date de naissance, est-ce à dire que désormais on doit aussi connaître celle des professeurs ?

En fait cela sera réservé à l’administration pour bien faire la différence entre les profs homonymes je cacherai cette info aux élèves via une vue.

Entité-type PROFESSEUR

Le login ne fait pas l’objet d’une clé alternative ?

Je vais me heurter à un pb humain : certains profs sont à demeure à l’iut d’autres enseignent sur plusieurs zone de l’université ex insa, ups , iut il y a même des intervenants extérieurs … aucun de ces établissements n’a la même politique de construction de login chacun gère son informatique du coup il y a ceux qui vont vouloir un login identique à celui de l’insa même s’ils enseignent à l’iut …

L’idéal serait de construire un double login obligatoire (comme les sites administratifs) exemple :

login : leclerc.jean
date de naissance : 09/12/1968
mot de passe : **********

ainsi les profs rechigneront moins à adopter ce principe de login mémo technique et je règle le cas des homonymes en filtrant/verifiant avec la date de naissance. Il y a une très faible probabilité d’avoir deux professeurs qui portent les mêmes noms et prénoms et que ceux-ci soinet nés le même jour !
Par contre je prends le risque d’avoir des doublons sur le login quand les 2 profs s’appelle pareil et ont le même prénom (on à quelques cas ...) du coup je me vois mal en faire une clef alternative !

Entité-type ADRESSE

Les adresses sont considérées jusqu’ici comme autonomes (à ceci près que désormais à une adresse habite au moins une personne et comme vous dites, rarement plus d’une). J’ai constaté que dans les entreprises où l’on gère les adresses des clients, la modélisation actuelle a le plus souvent posé de gros problèmes de performance dans les traitements de masse (batch) quand le nombre de clients commençait à atteindre cent mille (a fortiori quand on dépasse le million) : en l’occurrence, pour que les traitements percutassent, il fallait finalement modéliser ainsi (notez les parenthèses de l’identification relative) :
[PERSONNE]----0,N----(localiser)----(1,1)----[ADRESSE]
Vous m’objecterez que vous n’avez pas cent mille élèves et donc que cette solution alternative n’est pas déterminante dans le cadre de l’IUT. Néanmoins, si un jour, en tant que spécialiste des bases de données , vous êtes confronté à cette situation dans une grande banque, une administration, une caisse de retraite, etc., souvenez-vous de ma réflexion. Quant à la programmation relative à la gestion des adresses, elle me paraît plus naturelle et simple avec cette alternative, même si nous traitons ici de la modélisation des données et pas des traitements.

Vous m’objecterez aussi que lorsque deux personnes habitent au même endroit, il y aura redondance d’information : mais comme vous dites, cela sera rare et je dirais aussi que ça sera avec une incidence epsilonesque...

Je comprends votre solution met en avant la différence entre la théorie de la modélisation et la pratique. Les deux choix sont conceptuellement identiques et valables mais n’offrent pas les mêmes performances une fois mis en oeuvre.
D’un point de vue effectif par année universitaire à l’iut informatique on à au moins 200 personnes; imaginons que les 4 iuts du campus fusionnent leur informatique ce qui n’est pas improbable ( restrictions budgétaires) cela peut faire presque 1000 personnes par an; si on conserve l’historique sur 10 ans ...
Je vais opter pour votre solution tout en expliquant la raison de la subtilité dans le choix sur le rapport !


Raison de la subtilité dans le choix :

Choix de modélisation & conception pour la relation entre PERSONNE et ADRESSE


A défaut de consignes quant au choix de modélisation & conception pour la relation entre PERSONNE et ADRESSE plusieurs solutions sont envisageables pour modéliser la relation.

NOTE : PERSONNE est une entité factorisé qui comprend ainsi l’ensemble des ELEVEs et PROFESSEURs.

La logique du quotidien voudrait :
Qu’une personne puisse ne pas fournir d’adresse ou qu’elle puisse en avoir plusieurs.
Que plusieurs personnes puissent résider à une même adresse.
Qu’une adresse enregistrée soit a minima affectée à une personne, car on enregistres pas des adresses pour le plaisir.


Solution 1 :
[PERSONNE]----0,1----(localiser)----1,N----[ADRESSE]
Une PERSONNE à au minimum aucune ADRESSE et est localisée au maximum à une seule et unique ADRESSE
A une ADRESSE est localisée au minimum une PERSONNE et au maximum plusieurs PERSONNEs.

PB, la cardinalité 0 (NULL) implique perte de relation bivalente; du fait on lui préférera un schéma équivalent qui conserve la bivalence tout en préservant l’entité [PERSONNE] :
[PERSONNE]----0,1----(R)----(1,1)----[PERSONNE_ADRESSE]----1,1----(R)----1,N----[ADRESSE]

Solution 2 :
[PERSONNE]----(1,1)----(localiser)----1,N----[ADRESSE]
Une PERSONNE est localisée à une seule et unique ADRESSE
A une ADRESSE est localisée au minimum une PERSONNE et au maximum plusieurs PERSONNEs.


Solution 3 :
[PERSONNE]----0,N----(localiser)----1,N----[ADRESSE]
Une PERSONNE est localisée au minimum a aucune ADRESSE et au maximum à plusieurs ADRESSEs.
A une ADRESSE est localisée au minimum une PERSONNE et au maximum plusieurs PERSONNEs.

La présence des cardinalités x,N de part et d’autre de la relation, celle-ci sera traduite par le schéma équivalent :
[PERSONNE]----0,N----(R)----1,1----[PERSONNE_ADRESSE]----1,1----(R)----1,N----[ADRESSE]

Ce n’est pas trivial mais fixer les cardinalités 1,N du coté ADRESSE est un choix de conception peut judicieux. En effet la probabilité que plusieurs personnes (professeur(s) et/ou élevé(s)) résident à la même adresse et soient enregistrées dans notre BD dans le cadre de l’IUT sont des cas exceptionnels ! Exemple si deux personnes Pierre et Maryse habitent en collocation. Pendant l’année universitaire Maryse quitte la collocation.Pierre lui reste dans son logement. Étant donné que Maryse & Pierre ont le même identificateur d’adresse {idAdresse} on ne peut pas simplement mettre à jour l'adresse de Maryse sans affecter aussi celle de Pierre. Ainsi il est nécessaire de créer une nouvelle adresse pour Maryse => nouvel identificateur unique d’adresse.

Le seul «gain» qu’un identificateur d’adresse commun peut apporté dans notre cas serait:
- Économiser une ligne dans adresse néanmoins dans le cadre de notre application nous ne sommes pas à quelques lignes prés.

- Le cas ou une erreur ce serait glissée dans {adresse1, adresse2} et qu’un grand nombre de personnes seraient localisées à cette même adresse néanmoins ADRESSE utilise l’identification relative, toute correction apporté aux villes & code postaux se répercutent automatiquement dans ADRESSE grâce à l’identification relative.


De plus on constate que d’un point de vue gestion de la BD il est bien plus simple d’affecter une unique adresse par personne quitte à avoir de temps à autres quelques répétitions d’adresses.

In fine dans notre cas avoir recours à l’identificateur commun d’adresse pour n personnes à plus d’inconvénients que d’avantages. D’un point de vue conceptualisation il est judicieux de ne pas construire une relation sur une exception mais sur une généralisation :

A une ADRESSE est localisé une seule PERSONNE.
Une PERSONNE peut avoir aucune ou plusieurs ADRESSEs.

[PERSONNE]----0,N----(localiser)----(1,1)----[ADRESSE]


L’identification relative (1,1) évite de recourir aux jointures et permet l'optimisation du processus de traitement quand le nombre de ligne est très grand (>100000).

MLD :
PERSONNE{idPersonne, dateNaissance, nom, prenom, prenom2 ,tel, email, photo}
ADRESSE{idAdresse, #idPersonne, adresse1, Adresse2, #idCodepostal,#idVille}

Cordialement SUDTEK

[fsmrel]

Bonsoir,

ainsi les profs rechigneront moins à adopter ce principe de login mémo technique et je règle le cas des homonymes en filtrant/verifiant avec la date de naissance. Il y a une très faible probabilité d’avoir deux professeurs qui portent les mêmes noms et prénoms et que ceux-ci soient nés le même jour !

Vous me donnez l’occasion d’une digression qui nous ramène (enfin, plus moi que vous ) en 1965... J’avais pour mission de programmer la gestion du personnel d’une administration, c’était en assembleur car les langages de 3e génération (COBOL, PL/1, Fortran, Algol,...) sortaient à peine des cartons. En ce temps-là pas de puissants serveurs, pas de virus, on disposait d’un seul ordinateur (un 1410, un monstre doté de 100 K de mémoire, alors qu’avant on ne travaillait qu’avec des ordinateurs 1401 à 16 K), équipé d’un lecteur de cartes perforées, de bandes magnétiques, mais pas de disques, pas d’écrans, pas de bases de données, pas de Merise (mais, je lui en suis profondément reconnaissant, Robert Aymé Mallet avait accouché de CORIG dont j’ai toujours les formules magiques en tête : OCCFP (—OCCFM + DM))... Mais, vous savez quoi ? On avait inventé l’identifiant significatif... Chaque employé avait son identifiant ainsi constitué : les 6 premiers caractères de son nom suivis de sa date de naissance au format JJMMAA. Notre polytechnicien de service, qui n’était pas la moitié d’un, s’était quand même posé la question de jumeaux : deux Dupont nés le même jour ça arrive, donc on fera naître l’un des deux à JJMMAA et l’autre à JJ+31. Et s’il y avait des « trumeaux » ? On fera encore JJ+31 et ça devrait suffire... J’avais fabriqué mes jeux d’essai en conséquence et ça marchait nickel. Le jour du démarrage officiel de l’application, un de mes camarades ayant développé le programme de contrôles des données (devant alimenter mes programmes) eut droit à un plantage et crut qu’il avait une grosse redondance injustifiée à défaut d'un gros bug dans son programme : en fait, pas mal d’employés avaient le même nom et étaient nés le même jour, mais ça n'était pas une erreur ! Ben forcément notre polytechnicien ne savait pas (nous non plus du reste) que si une personne ne connaissait que son année de naissance, l’administration le faisait « naître » le 31 décembre de cette année, et il y avait un certain nombre de personnes dans cette situation...


Vous avez modifié PMACU, très bien mais NOTATION_EFFECTIVE va se sentir frustrée, car il lui manquera une clé étrangère :

[sudtek]

Bonjour fsmrel,

Vous avez modifié PMACU, très bien mais NOTATION_EFFECTIVE va se sentir frustrée, car il lui manquera une clé étrangère :

Bien vu ...en fait j’ai fait une régression j’ai supprimé #idProfesseur de NOTATION_EFFECTIVE et je me suis mélangé les pinceaux jusque dans le rapport … travailler trop tard ça joue des sales tours.

deux Dupont nés le même jour ça arrive, donc on fera naître l’un des deux à JJMMAA et l’autre à JJ+31. Et s’il y avait des « trumeaux » ? On fera encore JJ+31 et ça devrait suffire... J’avais fabriqué mes jeux d’essai en conséquence et ça marchait nickel. Le jour du démarrage officiel de l’application, un de mes camarades ayant développé le programme de contrôles des données (devant alimenter mes programmes) eut droit à un plantage et crut qu’il avait une grosse redondance injustifiée à défaut d'un gros bug dans son programme : en fait, pas mal d’employés avaient le même nom et étaient nés le même jour, mais ça n'était pas une erreur ! Ben forcément notre polytechnicien ne savait pas (nous non plus du reste) que si une personne ne connaissait que son année de naissance, l’administration le faisait « naître » le 31 décembre de cette année, et il y avait un certain nombre de personnes dans cette situation...

me voilà plongé en pleine guerre des clones … « a l’insu de mon plein grès » dixit Richard.V … bon ok je vais «taper en touche» le PB :
Exit le login dans PROFESSEUR pour se loguer le professeur utilisera en guise de login son e-mail que je déclare AK au passage dans PERSONNE :

e-mail : leclerc.jean@free.fr
mot de passe : ********

Ainsi je coupe cour au PB car l’email est obligatoire,unique et c’est le prof qui choisira celui qu’il veut mettre en guise de login un perso ou pro et il s’en souviendra facilement.




Cordialement SUDTEK

[fsmrel]

Bonjour,


Dans le post #42, j’avais montré la solution à retenir chez certains de mes clients suite à prototypage ou expertise des performances :

[PERSONNE]----0,N----(localiser)----(1,1)----[ADRESSE]

Mais dans votre cas, une personne a au plus une adresse, ce qui donne lieu à ceci :

[PERSONNE]----0,1----(localiser)----(1,1)----[ADRESSE]

Mais, chaque personne a-t-elle au moins une adresse ? Si oui, cela donnerait :

[PERSONNE]----1,1----(localiser)----(1,1)----[ADRESSE]

Quel est votre choix ?

Exit le login dans PROFESSEUR pour se loguer le professeur utilisera en guise de login son e-mail que je déclare AK au passage dans PERSONNE.

D’accord pour les profs, mais par contrecoup, chaque élève devra avoir une adresse de courriel lui aussi.

Est-ce vrai ?

[sudtek]

Bonjour fsmrel,
[quote]

[PERSONNE]----0,N----(localiser)----(1,1)----[ADRESSE]

Mais dans votre cas, une personne a au plus une adresse, ce qui donne lieu à ceci :

[PERSONNE]----0,1----(localiser)----(1,1)----[ADRESSE]

Mais, chaque personne a-t-elle au moins une adresse ? Si oui, cela donnerait :

[PERSONNE]----1,1----(localiser)----(1,1)----[ADRESSE]

Quel est votre choix ?

En fait ma problématique ne vient pas tant du choix entre ses solutions mais d'un gros moment de doute lié aux conventions utilisées !

Sur le mcd j'ai exprimé l’identification relative par des cardinalités entre parenthèse par exemple :


[PERSONNE]----1,1----(localiser)----(1,1)----[ADRESSE]

[PERSONNE]----1,1----[PERSONNE_ADRESSE]----(1,1)----[ADRESSE]

MLD
PERSONNE {idPersonne, ...}
ADRESSE {idAdresse, ...}
PERSONNE_ADRESSE {#idAdresse,#idPersonne}

Sauf que :

Pour qu'il n'y ait pas de jaloux chez les AGL, mettez l'association R entre parenthèses, car en leur absence c'est la façon qu'a WinDesign de signifier l'identification relative...

Donc en convention windesign:

[PERSONNE]----1,1----(localiser)----(1,1)----[ADRESSE]
MLD
PERSONNE {idPersonne, #idAdresse...}
ADRESSE {idAdresse, ...}

Du coup je suis pas certain que nous soyons en phase sur ce point ... à laquelle faites vous référence dans votre citation fsmrel ?

Citation:
Envoyé par sudtek Voir le message
Exit le login dans PROFESSEUR pour se loguer le professeur utilisera en guise de login son e-mail que je déclare AK au passage dans PERSONNE.

D’accord pour les profs, mais par contrecoup, chaque élève devra avoir une adresse de courriel lui aussi.Est-ce vrai ?

Ce n'est pas problématique car tous les élèves ont obligatoirement un email en .edu de créé lors de l'inscription à l'IUT.

A+

[fsmrel]

Hello sudtek,

Du coup je suis pas certain que nous soyons en phase sur ce point ...

Pas de panique...

Si on représente les choses ainsi :

Cas 1 :

Avec PowerAMC, l'identification relative est effectivement symbolisée par la mise entre parenthèses de la cardinalité 1,1 du côté de l'entité-type faible :

[PERSONNE]----0,N----(LOCALISER)----(1,1)----[ADRESSE]

Avec WinDesign, on vire les parenthèses et on fait suivre 1,1 du symbole « (R) », cela donne :

[PERSONNE]----0,N----(LOCALISER)----1,1 (R)----[ADRESSE]

Au niveau MLD (pour reprendre vos conventions, avec le symbole « # » pour les clés étrangères) :

PERSONNE {PersonneId, Nom, ...}

ADRESSE {PersonneId#, AdresseId, Adresse1, ...}

Cas 2 :

PowerAMC :

[PERSONNE]----0,1----(LOCALISER)----(1,1)----[ADRESSE]

Avec WinDesign cela donne :

[PERSONNE]----0,1----(LOCALISER)----1,1 (R)----[ADRESSE]

Au niveau MLD, l’attribut AdresseId disparaît de la table ADRESSE puisque du fait de la cardinalité 0,1 portée par la patte connectant PERSONNE et LOCALISER, une personne peut avoir au plus une adresse :

PERSONNE {PersonneId, Nom, ...}

ADRESSE {PersonneId#, Adresse1, ...}

En principe, le cas 1 n’est pas à retenir, puisque jusqu’ici un élève (ou un prof) avait au plus une adresse.

On fait comme ça ? On retient le cas 2 ?

tous les élèves ont obligatoirement un email

D’accord.


On n’est pas loin de passer aux CREATE TABLE...

[sudtek]

Bonjour fsmrel,

PowerAMC :

[PERSONNE]----0,1----(LOCALISER)----(1,1)----[ADRESSE]

Avec WinDesign cela donne :

[PERSONNE]----0,1----(LOCALISER)----1,1 (R)----[ADRESSE]

Franchement un grand merci pour vos explications fsmrel car j'avais eut un gros moment de doute concernant le rôle des parenthèses d'une (RELATION) dans la création d'une relation relative ... mais en fait il s'agit d'une convention d'écriture cosmétique; la relation relative étant uniquement spécifiée par le (1,1) en PowerAMC est le 1,1(R) en windesign !

[PERSONNE]----0,1----(LOCALISER)----(1,1)----[ADRESSE]

PERSONNE {idPersonne, Nom, ...}

ADRESSE {#idPersonne, Adresse1, ...}

Au niveau MLD, l’attribut AdresseId disparaît de la table ADRESSE puisque du fait de la cardinalité 0,1 portée par la patte connectant PERSONNE et LOCALISER, une personne peut avoir au plus une adresse :

et mer ... je suis tombé dans le piège lors du passage au MLD ! J'avais pas intuité la subtilité de l'identification relative de cette façon :

cas 1 : La PERSONNE à une ADRESSE implique PERSONNE { idPersonne} existe par relation relative dans ADRESSE {#idPersonne} (une personne <-> une adresse) .

Cas 2 : la PERSONNE n'a pas d'adresse implique aucun NULL à gérer !

Je suis certain fsmrel que celle là (et d'autres) on doit être pas mal à la zapper ! Je pense qu'à l’occasion il faudrait compiler c'est cas d'écoles et les implémenter dans la faq ou votre PDF pour y faire un memento/référentiel des bonnes pratiques de conception expliquant les formes de conception à choisir avec des exemples très basiques qui mettent en évidence toutes ces subtilités cela réduirait de façon drastique les MCD de guingois !

Cordialement SUDTEK

[fsmrel]

Bonsoir sudtek,

Je suis certain fsmrel que celle là (et d'autres) on doit être pas mal à la zapper ! Je pense qu'à l’occasion il faudrait compiler c'est cas d'écoles et les implémenter dans la faq ou votre PDF pour y faire un memento/référentiel des bonnes pratiques de conception expliquant les formes de conception à choisir avec des exemples très basiques qui mettent en évidence toutes ces subtilités cela réduirait de façon drastique les MCD de guingois !

Compiler, pourquoi pas, mais je vous laisse le soin de dresser l’inventaire des points à prendre en compte, car c’est vous (et les autres) qui avez rencontré des problèmes que je n’avais pas soupçonnés... Quant à une date à laquelle je pourrais sortir un article, je ne peux rien promettre, j’ai pas mal de discussions en cours, et pour le moment il est rare que je trouve un créneau.


J’ai quand même fait du VBA, parfois c’est rigolo, parfois on a envie de le balancer par la fenêtre... :

http://www.fsmwarden.com/developpez_...ique_ecran.png

[sudtek]

Bonjour fsmrel,

"je vous laisse le soin de dresser l’inventaire des points à prendre en compte"

petit à petit je vais les "compiler" dans un googledoc !

J'ai repris le binder PDF pour qu'il soit plus clair, je modifie mon rapport et je porte le dernier MLD sur Access. La création des tables devrait commencer le weekend prochain.

Ci joint le dernier binder 16 octobre 2013 MCD & MLD_Projet_YS_10_7_P au format 7Z (plus de "quota" pour uploader en version PDF directement ...)

J’ai quand même fait du VBA, parfois c’est rigolo, parfois on a envie de le balancer par la fenêtre... :

http://www.fsmwarden.com/developpez_...ique_ecran.png

Je trouve la présentation pas mal via Access ! Bon après le VBA cela risque d'être une autre histoire ...

Cordialement SUDTEK

[fsmrel]

Bonsoir sudtek,


MCD et MLD paraissent corrects, il y a de l'application

Y a plus qu'à !

Je ne sais pas quand je pourrais me remettre à VBA qui me lance des défis, car j'ai plein de discussions en cours...

[fsmrel]

Hello sudtek,


Comment les choses avancent-elles ?

[sudtek]

Bonjour fsmrel,
partie acces j'ai rectifié totalement le MLD mais je ne peux pas le poster il est trop volumineux je pense coller un lien dropbox ce weekend, de plus l'export du schéma relationnel plante à chaque fois mon access et me colle une erreur DLL malgré un addon microsoft pour exporter au format PDF sous 2007 ...
J'ai avancé un petit peut sur les requêtes mais il faut que je les regroupes car c'est un peut bordélique à la fin je sais plus qu'elles requêtes fait quoi !
J'aurais bientôt la version 2010 MSDNA.

J'ai pas encore attaqué les create table sur mysql car en ce moment je suis en partiels et c'est chaud ... et en plus je découvre le cobol ...

A+

[fsmrel]

je découvre le cobol ...

Plus de 45 ans après moi et voyez-vous je n'en suis pas mort, il m'a rendu de fieffés services et je ne saurais être un ingrat ! Ne pleurez pas d’avance à cause des légendes que de mauvaises langues font courir... Dresserez-vous un bilan dans 45 ans ?

[sudtek]

Bonjour fsmrel,

Voici le MLD de la version V10_7_P fait sous Acces laborieusement reconstitué sous paint faute d'export Acces qui fonctionne correctement.

Plus de 45 ans après moi et voyez-vous je n'en suis pas mort, il m'a rendu de fieffés services et je ne saurais être un ingrat ! Ne pleurez pas d’avance à cause des légendes que de mauvaises langues font courir... Dresserez-vous un bilan dans 45 ans ?

C'est pas tant le langage qui me prend la tête mais en fait je fais une allergie poussée à tout truc du style compta, eco, gestion ... et quand je vois un sujet de cobol on me parle forcement de cela.

Cordialement sudtek.

[fsmrel]

Bonsoir sud,


D’accord pour le MLD, on retrouve bien tout. Une remarque : d’une façon générale, le 1er attribut figurant dans la clé primaire des tables est idAnneeUniversitaire (tables MACU, EMACU et compagnie). Au niveau physique, l’index utilisé pour la clé primaire ne sera pas filtrant lors des consultations : n’y a-t-il pas un attribut plus intéressant à faire figurer en tête de liste ? (quand je dis primaire et liste ça n’a rien à voir avec la primaire de Marseille...) D'une façon générale, il vaut mieux être économe avec les index (mises à jour alourdies).


Qu’entendez-vous par export ACCESS ?

[sudtek]

Bonjour fsmrel,

(quand je dis primaire et liste ça n’a rien à voir avec la primaire de Marseille...)

Une remarque : d’une façon générale, le 1er attribut figurant dans la clé primaire des tables est idAnneeUniversitaire (tables MACU, EMACU et compagnie). Au niveau physique, l’index utilisé pour la clé primaire ne sera pas filtrant lors des consultations : n’y a-t-il pas un attribut plus intéressant à faire figurer en tête de liste ?

MACU et les autres entités devraient je pense être ordonnées du plus significatif (le plus filtrant pour l'entité concernée) vers le moins significatif :

MACU :
idModule
idCategorie
idUE
idAnneeUnniversitaire

NOTATION
idNoTe
idEleve
idModule
idCategorie
idUE
idAnneeUnniversitaire

Problème : si je permute les attributs de la clef le schéma devient illisible, les entités adjacentes n'ayant pas forcement les attributs dans le même ordre Access fait des nœuds, les liens des relations se croisent comme dans un plat de nouilles et devient in fine illisible J'avoue qu'il aurait été tellement plus pratique que microsoft multiplexent la représentation graphique ... (comme dans les soft d’électronique de routage de PCB).

Qu’entendez-vous par export ACCESS ?

En fait mon Access 2007 plante erreur de dll et m'a même corrompu la base lors d'une tentative d'export de ce schéma relationnel du coup je fais à la mano des captures d’écran que je recompose dans paint via un merging manuel ... il me tarde d'avoir la version 2010 MSDNA car les plantages a répétions me prennent la tête.

Cordialement sudtek

[fsmrel]

Bonsoir sudtek,

Problème : si je permute les attributs de la clef le schéma devient illisible, les entités adjacentes n'ayant pas forcement les attributs dans le même ordre Access fait des nœuds, les liens des relations se croisent comme dans un plat de nouilles et devient in fine illisible.

Il est vrai que le mode de représentation graphique des liens inter-tables à la façon d’ACCESS est pour le moins lourd et inapproprié. Toutefois il serait absurde d’ordonner les colonnes dans les clés en fonction de contraintes de dessin ! Mieux vaut éviter de faire figurer les diagrammes d’ACCESS dans le dossier, et ressortir ceux que vous avez précédemment produits.


Cela dit, je ferai quelques remarques en relation avec l’ordre des attributs dans les clés.

A) Du rôle respectif de deux entités-types

1) Une entité, c'est-à-dire une instance d’entité-type peut être qualifiée de faible (weak entity de Chen¹, characteristic de Codd²) quand son existence est totalement dépendante d’une autre entité plus forte (regular entity de Chen, kernel de Codd). Pour prendre un exemple bateau, il en va ainsi d’une ligne de facture qui n’est jamais qu’un composant d’une facture, une propriété multivaluée de celle-ci. Dans le cas de votre modèle, un module est un composant d’une UE, on peut encore dire que ces éléments sont liés « à la vie à la mort », on retrouve la relation de composition d’UML : un module d’une UE ne peut pas être partagé avec une autre UE, et si une UE meurt, ses modules meurent aussi. Par voie de conséquence, bien qu’une clé soit un ensemble, donc que les attributs qui la composent ne sont pas à contraints à être présentés selon un certain ordre, il est quand même préférable dans le contexte SQL que les attributs d’une clé primaire y figurent selon un ordre qui n’a pas été choisi au hasard. Prenons l’exemple de la clé de la table MODULE : l’attribut idUE y précède l’attribut idModule et non pas l’inverse. En effet, certains SGBD SQL ont un comportement plutôt fruste qui fait que le physique impose son diktat au logique : l’ordre des attributs dans la clé primaire doit être celui de la clé de l’index correspondant (index « primaire »), cela est encore plus vrai avec MySQL pour qui une clé primaire n’est pas un ensemble (au sens de la théorie des ensembles), mais un vulgaire index (blurps !) de type unique, cf. MySQL 5.6 Reference Manual page 1351 :

A PRIMARY KEY is a unique index where all key columns must be defined as NOT NULL.

Le rédacteur est à côté de la plaque... Nonobstant, pourquoi respecter la séquence idUE, idModule plutôt que la séquence idModule, idUE pour cet index ? Revenons-en aux factures et descendons dans la soute.

2) Supposons que la séquence des attributs de la clé primaire de la table LIGNE_FACTURE des lignes de facture soit la suivante : idLigne, idFacture. Par construction (au moins avec MySQL qui manque pour le moins de souplesse), l’index correspondant sera l’index « cluster », c'est-à-dire que le SGBD rangera des lignes de la table LIGNE_FACTURE dans les pages du fichier qui héberge cette table en respectant la séquence idLigne, idFacture. Supposons encore qu’on gère 500000 factures. Comme je le connais beaucoup mieux, je passe à DB2 (mais le raisonnement vaut pour MySQL) et je choisis une taille de page de 4 kilooctets, soit environ 240 lignes de facture par page, c'est-à-dire qu’il faudra déjà environ 2080 pages pour loger les lignes de facture dont le numéro de ligne est égal à 1 : il est donc évident que si une facture comporte N lignes de factures, le SGBD devra lire N pages pour récupérer l’ensemble des lignes de la facture qui ont été éparpillées dans l’espace. A quelque chose comme 10 millisecondes l’accès à un enregistrement sur le disque, ça se ressent.

3) Inversons maintenant la séquence des attributs de la clé primaire de la table LIGNE_FACTURE : idFacture puis idLigne. Une page de 4K contiendra toujours 240 lignes de facture par page, mais cette fois-ci les N lignes d’une facture sont regroupées (clustered) dans la même page et le SGBD n’a plus à accéder à N pages pour rassembler les lignes de la facture, mais à une seule page, ce qui est quand même incomparablement plus performant.

Vous me direz que votre application ne traite pas 500000 UE, mais le jour où vous gérerez des bases de données à forte volumétrie, souvenez-vous que vous aurez intérêt surveiller l’ordre des attributs dans les clés (à moins d’une révolution technologique rendant caduques mes observations et recommandations...)


B) Influence des traitements

Pour reprendre la séquence des attributs que vous avez retenue pour la clé primaire de la table NOTATION :

idNote, idEleve, idModule, idCategorie, idUE, idAnneeUniversitaire

Quel est intérêt de placer l’attribut idNote en tête de liste (donc faire en sorte que l’index cluster de la table NOTATION soit calé sur l’attribut idNote) ? Cela reviendrait à dire que les requêtes portent d’abord sur les notes (et accessoirement sur les élèves), par exemple :

Combien d’élèves ont obtenu la note 20 ?

Si les traitements les plus fréquents portent plutôt sur les élèves :

Quelles ont été les notes obtenues par l’élève Raoul en 2012 ?

Alors l’attribut IdEleve doit figurer en tête de liste.

Autrement dit, ce sont les requêtes les plus fréquentes qui quelque part orientent la mise en œuvre des index, principalement l’index cluster.

________________

¹ Peter Chen The Entity-Relationship Model—Toward a Unified View of Data.

² E.F. Codd Extending the Database Relational Model to Capture More Meaning.

[sudtek]

Bonjour FSMREL,

si je reprends vos explications pour macu :

cas 1 :
Choix d'ordonnancement de la PK : Une UE est composée de module(s) composée(s) de catégorie(s) enseignés et doit être vu comme un bloc ordonné; la question à se poser est “Quelles catégories sont enseignés en 2013 ?”

on en déduit : MACU_ENSEIGNEMENT {#idUE, #idModule, #idCategorie, #idAnneUniversitaire, volumeHoraireMC}


cas 2 :Sauf que si je considéré le pb par année universitaire si on se pose la question “ Pour l'année universitaire 2013 quelle sont les catégories enseignés ?"

on en déduit : MACU_ENSEIGNEMENT {#idAnneUniversitaire, #idUE, #idModule, #idCategorie, , volumeHoraireMC}

Cela favorise le regroupement par année universitaire (sachant que le redoublement est un exception) et on favorise l'agrégation des catégories par années ce qui est bien pratique pour les traitements annuels (calculs moyennes, heures ...) hormis en cas de redoublement ou il faudra considérer plusieurs années pour prendre la meilleure note.

Donc si je comprends bien pour trancher ce genre de cas il faut se concentrer sur le cœur de l'entité dans ce cas pour MACU c'est l'enseignement qui prime sur l'année (cas 1) !?

Cordialement SUDTEK