Discussion :

[heretik25]

Mis à part le sondage, peut-on dire que le MCD est validé ?

En effet, j'aimerais passer à l'étape suivante : réinjecter les données dans le nouveau modèle.

Ensuite, re-développer l’entièreté du site pour prendre en compte le nouveau modèle.


EDIT : je viens de générer le SQl, je travail avec une base de données MYSQL 5.0. J'ai un problème sur la génération de la table article_page.

Code SQL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
create table ARTICLE_PAGE
(
   ID_ARTICLE           int not null,
   ID_ARTICLE_PAGE      int not null auto_increment,
   ARTICLE_PAGE_NUM     int not null,
   ARTICLE_PAGE_CONTENU text not null,
   primary key (ID_ARTICLE, ID_ARTICLE_PAGE)
);

MySQL a répondu: Documentation
#1075 - Un seul champ automatique est permis et il doit être indexé

NB : D'autres tables génèrent la même erreur.

[fsmrel]

Bonjour,

Désolé, je vous avais complètement oublié !

Je regarde tout cela et je vous réponds avant ce soir.

[CinePhil]

je viens de générer le SQl, je travail avec une base de données MYSQL 5.0. J'ai un problème sur la génération de la table article_page.

Code SQL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
create table ARTICLE_PAGE
(
   ID_ARTICLE           int not null,
   ID_ARTICLE_PAGE      int not null auto_increment,
   ARTICLE_PAGE_NUM     int not null,
   ARTICLE_PAGE_CONTENU text not null,
   primary key (ID_ARTICLE, ID_ARTICLE_PAGE)
);

MySQL a répondu: Documentation
#1075 - Un seul champ automatique est permis et il doit être indexé

NB : D'autres tables génèrent la même erreur.

N'ayant pas suivi toute cette (longue) discussion, je suppose qu'il s'agit d'identifier relativement la page par rapport à l'article ?

Il ne faut pas utiliser l'auto-incrémentation dans ce cas mais vous inspirer de l'exemple de trigger que j'ai posté sur mon blog... en espérant que vous avez suffisamment de droits sur le serveur pour créer ce trigger !

[fsmrel]

Pas d'inquiétude CinePhil, qu'on me laisse une paire d'heures, je suis en train de répondre...

[fsmrel]

A propos de l’identification relative et du message d’erreur de la part de MySQL.


Dans ce message j’avais précisé qu’on utilisait l’identification relative pour l’entité-type ARTICLE_PAGE :


Par comparaison, dans votre MCD, un des deux attributs suivants est en trop car faisant double emploi : id_article_page, article_page_num.
Conservons par exemple l’attribut article_page_num. Votre MCD devrait alors être le suivant :


D’où le MLD :


Et le code SQL :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE TABLE ARTICLE_PAGE
(
   ID_ARTICLE           int  not null,
   ARTICLE_PAGE_NUM     int  not null,
   ARTICLE_PAGE_CONTENU text not null,
   PRIMARY KEY (ID_ARTICLE, ARTICLE_PAGE_NUM) 
) ;

Supposons maintenant que la table ARTICLE_PAGE contienne déjà les lignes suivantes (notez que la numérotation des pages commence à 1 pour chaque article, par respect du principe de l'identification relative) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
ARTICLE_PAGE   {ID_ARTICLE    ARTICLE_PAGE_NUM    ARTICLE_PAGE_CONTENU}
                ----------    ----------------    --------------------
                       1                 1        Le VTT c’est chouette !
                       1                 2        Vive les balades !
                       1                 3        Le VTT au cinéma
                       2                 1        Les débuts du VTT
                       3                 1        Quelques périples

Pour insérer une nouvelle page relative à l’article 3, l’instruction INSERT correspondante pourrait ressembler à ceci (j’utilise SQL Server, donc à adapter pour MySQL, en tenant compte de ce qu’écrit CinePhil dans son article) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
INSERT INTO ARTICLE_PAGE 
    SELECT 3, 
           (SELECT COALESCE(MAX(ARTICLE_PAGE_NUM), 0) + 1
            FROM   ARTICLE_PAGE
            WHERE  ID_ARTICLE = 3), 
           'Le billard à trois bandes c’est chouette aussi !' ;

Au résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
ARTICLE_PAGE   {ID_ARTICLE    ARTICLE_PAGE_NUM    ARTICLE_PAGE_CONTENU}
                ----------    ----------------    --------------------
                       1                 1        Le VTT c’est chouette !
                       1                 2        Vive les balades !
                       1                 3        Le VTT au cinéma
                       2                 1        Les débuts du VTT
                       3                 1        Quelques périples 
                       3                 2        Le billard à trois bandes c’est chouette aussi !

Je vais regarder le reste (validation du MCD, sondages...)

[heretik25]

Merci pour l'explication de cet aspect que je n'avais pas bien cerné. Faut-il procéder par un trigger ou par la méthode que tu préconises ?

@bientôt pour la suite.

[fsmrel]

Bonsoir,

Faut-il procéder par un trigger ou par la méthode que tu préconises ?

Je ne préconise pas de méthode, j’ai simplement fourni un exemple d’INSERT dans le contexte SQL Server. Cela dit, si les insertions sont unitaires et si l’on connaît l’article pour lequel on veut créer une page, ce genre d’INSERT suffit, sinon il est plus prudent de mettre en œuvre un trigger façon CinePhil.

Mis à part le sondage, peut-on dire que le MCD est validé ?

On va dire qu’il l’est. Toutefois, j’aimerais en savoir plus sur les attributs de l’entité-type FICHIER_GPS, autrement dit m’assurer que la deuxième forme normale est respectée (je rappelle qu’elle était initialement violée dans le cas des départements et des balades).

le secteur d'un périple peut être considéré comme le département d'une balade.

Si le nom d’un périple ne dépend pas de l’article, il faut effectivement procéder comme dans votre PJ.


A propos des sondages. Voici une proposition de MCD :

L’entité-type POSSIBILITE permet de mettre en œuvre une structure pour les différentes possibilités de choix mis à la disposition de l’auteur du sondage : « Oui », « Moyen », « Génial », « Pas d’opinion », etc.

Concernant les votes : Je remplace « VOTER » par « NOTER », pour marquer la différence entre les modes d’appréciation d’un article (note ou choix).

L’entité-type SONDAGE_POSS permet de mettre en relation les sondages (entité-type SONDAGE) et les possibilités de choix (entité-type POSSIBILITE), au gré des auteurs des sondages.

L’association-type CHOISIR_POSS (entre les entités-types UTILISATEUR et SONDAGE_POSS) permet à un utilisateur de retenir un choix parmi les choix proposés par l'auteur d'un sondage.

Observations :

Entité-type SONDAGE_POSS : Il s’agit donc en réalité d’une association-type entre SONDAGE et POSSIBILITE mais que j’ai déguisée en entité-type afin que l’on puisse mettre en œuvre une relation (association-type CHOISIR_POSS) avec l’entité-type UTILISATEUR (bien noter la double identification relative !) Lors du passage au MLD, l’en-tête de la table SONDAGE_POSS comportera les deux attributs ArticleId et PossibiliteId, mais au niveau MCD, Power AMC n’en ayant manifestement pas conscience, il est nécessaire de décocher la case « Existence d’attribut » avant passage au MLD :



Power AMC ne proposant rien au sujet des CIF et autres DF, j’ai dessiné à la main une contrainte d’unicité, une dépendance fonctionnelle (DF) entre l’association-type CHOISIR_POSS et l’entité-type POSSIBILITE. Cette contrainte exprime le fait que pour un utilisateur et un article, il n’y a qu’un seul choix possible. En conséquence, il faut intervenir manuellement dans le MLD, à savoir expulser l’attribut PossibiliteId de la clé primaire de la table CHOISIR_POSS.

MLD :

Si un article peut être, soit noté soit faire l’objet d’un choix, mais pas les deux à la fois, prévoir un trigger d’exclusion entre les tables NOTER et SONDAGE_POSS (la valeur x prise par l'attribut ArticleId ne pouvant pas en l'occurrence figurer simultanément dans les deux tables).


Quand le MCD sera au point, n’oubliez pas de joindre votre MLD.

[heretik25]

Bonsoir,

Je ne préconise pas de méthode, j’ai simplement fourni un exemple d’INSERT dans le contexte SQL Server. Cela dit, si les insertions sont unitaires et si l’on connaît l’article pour lequel on veut créer une page, ce genre d’INSERT suffit, sinon il est plus prudent de mettre en œuvre un trigger façon CinePhil.

J'ai essayé la requête que vous avez mis en exemple, elle fonctionne très bien dans MySQL 5.0. Dans mon cas, on connaîtra l'article pour lequel on créer la ou les pages donc, je vais utiliser votre méthode. Sans vouloir vexer CinePhil et son explication intéressante.

On va dire qu’il l’est. Toutefois, j’aimerais en savoir plus sur les attributs de l’entité-type FICHIER_GPS, autrement dit m’assurer que la deuxième forme normale est respectée (je rappelle qu’elle était initialement violée dans le cas des départements et des balades).

Ok, j'ai par-contre relevé un souci similaire à l'entité type "article_page". En effet, l'entité type "sous_categorie" possède aussi une identification relative. Faut-il enlever un identifiant en trop comme pour le cas "article_page" ?

Pour l'entité "fichier-gps", il s'agit d'une entité contenant les attributs d'un fichier GPS. Le fichier GPS au format GPX est un XML contenant des données pour chaque point GPS. ces données seront parsées avec simpleXml et envoyées en base. Ainsi, on y trouve l'altitude du point, sa longitude, sa latitude, son datetime. Un point GPS peut ensuite être associé à une photo. (principe de la géolocalisation). En comparant le datetime du point GPS et de la photo, je suis capable d'injecter l'url de la photo géolocalisée. Cela me permait ensuite de tagger la photo sur une carte à l'endroit géographique ou j'ai prise la photo. En théorie, un point GPS pourrait être associé à 0 ou n photos. Pour simplifier la chose, je limite à 0 ou une photo par point GPS.

Si le nom d’un périple ne dépend pas de l’article, il faut effectivement procéder comme dans votre PJ.

Tout comme pour les balades qui sont inféodées à un département Français, un périple est inféodé à un secteur (France, Europe, Asie...) et il faudra être en mesure de savoir lequel. je pense qu'il faut donc procéder comme pour les balades.

A propos des sondages. Voici une proposition de MCD :

L’entité-type POSSIBILITE permet de mettre en œuvre une structure pour les différentes possibilités de choix mis à la disposition de l’auteur du sondage : « Oui », « Moyen », « Génial », « Pas d’opinion », etc.

Concernant les votes : Je remplace « VOTER » par « NOTER », pour marquer la différence entre les modes d’appréciation d’un article (note ou choix).

L’entité-type SONDAGE_POSS permet de mettre en relation les sondages (entité-type SONDAGE) et les possibilités de choix (entité-type POSSIBILITE), au gré des auteurs des sondages.

L’association-type CHOISIR_POSS (entre les entités-types UTILISATEUR et SONDAGE_POSS) permet à un utilisateur de retenir un choix parmi les choix proposés par l'auteur d'un sondage.

Observations :

Entité-type SONDAGE_POSS : Il s’agit donc en réalité d’une association-type entre SONDAGE et POSSIBILITE mais que j’ai déguisée en entité-type afin que l’on puisse mettre en œuvre une relation (association-type CHOISIR_POSS) avec l’entité-type UTILISATEUR (bien noter la double identification relative !) Lors du passage au MLD, l’en-tête de la table SONDAGE_POSS comportera les deux attributs ArticleId et PossibiliteId, mais au niveau MCD, Power AMC n’en ayant manifestement pas conscience, il est nécessaire de décocher la case « Existence d’attribut » avant passage au MLD :



Power AMC ne proposant rien au sujet des CIF et autres DF, j’ai dessiné à la main une contrainte d’unicité, une dépendance fonctionnelle (DF) entre l’association-type CHOISIR_POSS et l’entité-type POSSIBILITE. Cette contrainte exprime le fait que pour un utilisateur et un article, il n’y a qu’un seul choix possible. En conséquence, il faut intervenir manuellement dans le MLD, à savoir expulser l’attribut PossibiliteId de la clé primaire de la table CHOISIR_POSS.

MLD :

Si un article peut être, soit noté soit faire l’objet d’un choix, mais pas les deux à la fois, prévoir un trigger d’exclusion entre les tables NOTER et SONDAGE_POSS (la valeur x prise par l'attribut ArticleId ne pouvant pas en l'occurrence figurer simultanément dans les deux tables).


Quand le MCD sera au point, n’oubliez pas de joindre votre MLD.

Merci pour cette proposition très bien expliquée. Après réflexion, je part du principe que chaque article peut être noté et que le sondage est facultatif et ajouté selon le bon vouloir du créateur de l'article. Il n'y a donc pas besoin de trigger et cette modélisation convient donc ?

En PJ, le MCD 2.7.

Dans l'attente de vous lire, je vous souhaite une bonne journée.

[fsmrel]

Bonjour,

j'ai par-contre relevé un souci similaire à l'entité type "article_page". En effet, l'entité type "sous_categorie" possède aussi une identification relative. Faut-il enlever un identifiant en trop comme pour le cas "article_page" ?

Dans le MCD, aucun attribut de l’entité-type SOUS_CATEGORIE n’est superflu. Même chose concernant la table SOUS_CATEGORIE du MLD. Toutefois, vous avez retenu le type séquentiel pour l’attribut id_sous_categorie, ce qui revient à mettre en œuvre l’auto-incrémentation, donc l’identification absolue (du moins MySQL l’interprète semble-t-il ainsi), ce qui est contradictoire avec le choix initial de l’identification relative : comme dans le cas de l’attribut article_page_num (entité-type ARTICLE_PAGE), il faut remplacer le type séquentiel par le type entier pour l’attribut id_sous_categorie. Ceci vaut bien sûr à chaque fois que vous utilisez l’identification relative.

Tout comme pour les balades qui sont inféodées à un département Français, un périple est inféodé à un secteur (France, Europe, Asie...) et il faudra être en mesure de savoir lequel. Je pense qu'il faut donc procéder comme pour les balades.

Il le faut. En effet, le nom d’un secteur ne dépend pas de l’article, principe qui serait violé si vous rapatriiez ce nom dans l’en-tête de l’entité-type SECTEUR_DEPT (viol de la 2e forme normale).

En passant : il faudrait renommer l’entité-type LISTE_SECTEUR en SECTEUR. En effet, une occurrence de cette entité-type ne décrit pas une liste de secteurs, mais un secteur en particulier. Même chose concernant l’entité-type LISTE_DEPT qu’il serait préférable de renommer en DEPARTEMENT. Dans la foulée, renommer DEPT_BALADE par exemple en ART_DEPARTEMENT (ou ART_BALADE, ou ART_...), car il s’agit quand même d’un appendice de l’article plutôt que du département. Même principe concernant SECTEUR_DEPT.

je pars du principe que chaque article peut être noté et que le sondage est facultatif et ajouté selon le bon vouloir du créateur de l'article. Il n'y a donc pas besoin de trigger et cette modélisation convient donc ?

S’il n’y a pas exclusion, c'est-à-dire qu’un article peut être noté et faire aussi l’objet d’un choix (Bon, moyen, médiocre, ...) alors le trigger chargé de s’assurer de l’exclusion n’a de facto pas lieu d’être. Toutefois quelque chose me fait tiquer, car vous écrivez maintenant qu’un article peut d’une part être noté et d’autre part faire l’objet d’un sondage, ce qui revient à dire que la patte d’association entre SONDAGE et NOTER disparaît, pour être remplacée par une patte entre ARTICLE et NOTER. Qu’en est-il exactement ?


Concernant les fichiers GPS, je n’ai pas tout compris, donc je ne me prononce pas ; on laisse comme c’est...

[heretik25]

Dans le MCD, aucun attribut de l’entité-type SOUS_CATEGORIE n’est superflu. Même chose concernant la table SOUS_CATEGORIE du MLD. Toutefois, vous avez retenu le type séquentiel pour l’attribut id_sous_categorie, ce qui revient à mettre en œuvre l’auto-incrémentation, donc l’identification absolue (du moins MySQL l’interprète semble-t-il ainsi), ce qui est contradictoire avec le choix initial de l’identification relative : comme dans le cas de l’attribut article_page_num (entité-type ARTICLE_PAGE), il faut remplacer le type séquentiel par le type entier pour l’attribut id_sous_categorie. Ceci vaut bien sûr à chaque fois que vous utilisez l’identification relative.

Effectivement, par contre je voudrais m'assurer que vous ayez bien compris que pour l'entité "ARTICLE_PAGE", l'attribut "article_page_num" n'était pas un identifiant mais bien l'attribut stockant le numéro de page.

Il le faut. En effet, le nom d’un secteur ne dépend pas de l’article, principe qui serait violé si vous rapatriiez ce nom dans l’en-tête de l’entité-type SECTEUR_DEPT (viol de la 2e forme normale).

En passant : il faudrait renommer l’entité-type LISTE_SECTEUR en SECTEUR. En effet, une occurrence de cette entité-type ne décrit pas une liste de secteurs, mais un secteur en particulier. Même chose concernant l’entité-type LISTE_DEPT qu’il serait préférable de renommer en DEPARTEMENT. Dans la foulée, renommer DEPT_BALADE par exemple en ART_DEPARTEMENT (ou ART_BALADE, ou ART_...), car il s’agit quand même d’un appendice de l’article plutôt que du département. Même principe concernant SECTEUR_DEPT.

Les modifications ont été apportées.

S’il n’y a pas exclusion, c'est-à-dire qu’un article peut être noté et faire aussi l’objet d’un choix (Bon, moyen, médiocre, ...) alors le trigger chargé de s’assurer de l’exclusion n’a de facto pas lieu d’être. Toutefois quelque chose me fait tiquer, car vous écrivez maintenant qu’un article peut d’une part être noté et d’autre part faire l’objet d’un sondage, ce qui revient à dire que la patte d’association entre SONDAGE et NOTER disparaît, pour être remplacée par une patte entre ARTICLE et NOTER. Qu’en est-il exactement ?

Tous les articles peuvent être noté. Par-contre, le sondage est optionnel. Ceci implique la modification que vous avez avancée ?

Concernant les fichiers GPS, je n’ai pas tout compris, donc je ne me prononce pas ; on laisse comme c’est...

EDIT :

Je viens de me rendre compte que cela n'allait pas pour l'entité "fichier_gps" car par "fichier_gps" j'entends des milliers de points gps issus du fichier gps (et donc potentiellement des milliers d'entrées par article).

Pour mieux comprendre, peut-être que l'on devrait appeler cette entité type "coordonnee_gps".

Une balade peut avoir des centaines de coordonnées gps. Avec la succession de points gps, on créer ce que l'on appel une trace (un parcours). Lorsque je regarde le MPD pour cette partie, je remarque que l'identifiant unique est "id_article".

Ce n'est pas suffisant sachant qu'un article (une balade par exemple) peut posséder de nombreuses coordonnées gps. Chaque point gps ne sera donc pas identifié de façon unique . Il semble nécessaire de rajouter un identifiant unique dans cette entité type (à moins que je me trompe).

En PJ, le MCD 2.8.

[heretik25]

Je me permet d'ajouter ces questions aux précédentes car il me semble que vous aimez travailler tard la nuit et il m'a semblé opportun de grouper au maximum les questions.

J'ai fait quelques ajouts dans le MCD afin de coller au maximum à mes attentes, merci de me dire ce que vous en pensez.


1) Ajout de deux entités types "duree" et "difficulte" pour permettre d'avoir une liste de possibilité pour l'entité type "entretien" sur la durée et la difficulté. Cela pourrait s'apparenter à des tables de références.

2) Ajout d'une entité type "test" qui va permettre d'ajouter des informations propres au test de matériel. La marque, le prix du produit testé... J'explose par contre la marque car j'aimerai aussi avoir une table de référence et piocher dans une liste de marque prédéfinie.

3) Ajout d'une entité type "statistiques" lié à "utilisateur". J'aimerais être capable d'avoir quelques infos sur mes utilisateurs, notamment savoir quelles pages ils aiment bien visiter.


Vous trouverez des captures du mcd pour les questions 1, 2 et 3 en PJ et le mcd 2.8.1 en PJ.

@bientôt et merci

[fsmrel]

Déjà un premier lot de réponses...

je voudrais m'assurer que vous ayez bien compris que pour l'entité "ARTICLE_PAGE", l'attribut "article_page_num" n'était pas un identifiant mais bien l'attribut stockant le numéro de page.

Jusqu’ici j’ai compris que l’attribut article_page_num correspondait au numéro de page de l’article, mais a priori pour un article donné, un numéro de page ne peut pas exister en double (!) c'est-à-dire que les valeurs prises par le couple K1 {ArticleId, article_page_num} sont toutes distinctes, donc que ce couple constitue la clé primaire pour la table ARTICLE_PAGE. Une clé supplémentaire K2 {ArticleId, article_page_id} (devenant clé primaire, tandis que K1 deviendrait clé alternative (alternate key)) ne devrait être définie que si K1 pouvait changer de valeur et servait de référence pour une autre table.

Tous les articles peuvent être noté. Par-contre, le sondage est optionnel. Ceci implique la modification que vous avez avancée ?

Avant que n’interviennent les possibilités de choix, la situation était la suivante :

Avec l’intervention des possibilités de choix, la situation devient la suivante :

Mais vous aviez écrit :

je pars du principe que chaque article peut être noté et que le sondage est facultatif et ajouté selon le bon vouloir du créateur de l'article

Ce qui signifie littéralement que noter est une chose et sonder en est une autre, ce qui se traduit ainsi dans le MCD :

D’où la question que j’ai posée dans mon message précédent :

Vous écrivez maintenant qu’un article peut d’une part être noté et d’autre part faire l’objet d’un sondage, ce qui revient à dire que la patte d’association entre SONDAGE et NOTER disparaît, pour être remplacée par une patte entre ARTICLE et NOTER. Qu’en est-il exactement ?

Je reformule donc ainsi ma question : que retient-on finalement, la figure B ou la figure C ?

Une balade peut avoir des centaines de coordonnées gps

Supposons qu’un fichier GPS contienne des informations qui le caractérisent en propre, plus un tas de coordonnées, le MCD deviendrait le suivant (la ventilation des attributs est ici pour l’exemple, à vous de les redistribuer) :

[heretik25]

Jusqu’ici j’ai compris que l’attribut article_page_num correspondait au numéro de page de l’article, mais a priori pour un article donné, un numéro de page ne peut pas exister en double (!) c'est-à-dire que les valeurs prises par le couple K1 {ArticleId, article_page_num} sont toutes distinctes, donc que ce couple constitue la clé primaire pour la table ARTICLE_PAGE. Une clé supplémentaire K2 {ArticleId, article_page_id} (devenant clé primaire, tandis que K1 deviendrait clé alternative (alternate key)) ne devrait être définie que si K1 pouvait changer de valeur et servait de référence pour une autre table.

Ok, c'est bien ce que je pensais, merci pour l'explication

Avant que n’interviennent les possibilités de choix, la situation était la suivante :

Avec l’intervention des possibilités de choix, la situation devient la suivante :

Mais vous aviez écrit :

Ce qui signifie littéralement que noter est une chose et sonder en est une autre, ce qui se traduit ainsi dans le MCD :

D’où la question que j’ai posée dans mon message précédent :

Je reformule donc ainsi ma question : que retient-on finalement, la figure B ou la figure C ?

Nous retenons la figure C et voici la capture d'écran de mon MCD :

Supposons qu’un fichier GPS contienne des informations qui le caractérisent en propre, plus un tas de coordonnées, le MCD deviendrait le suivant (la ventilation des attributs est ici pour l’exemple, à vous de les redistribuer) :
[

A bien y réflechir, j'aimerai stocker des informations que l'on pourrait je pense attacher à l'entité "fichier_gps". Le nom tout d'abord. Puis, grâce aux coordonnées, je suis capable de déduire des informations comme la durée totale, la hauteur maximum de la balade, la vitesse moyenne, la distance totale... Est-ce que ces données pourraient être donc stocker ainsi ?




En PJ, le mcd 2.8.2

[fsmrel]

Bonsoir,

Ajout de deux entités types "duree" et "difficulte" pour permettre d'avoir une liste de possibilité pour l'entité type "entretien" sur la durée et la difficulté. Cela pourrait s'apparenter à des tables de références.

Ceci est tout à fait légitime. Mais est-on bien d’accord que l’attribut difficulte_note sert à attribuer une note seulement à la difficulté ? (Même principe pour l’attribut duree_note). N’oubliez pas de faire mention du caractère obligatoire des données (attributs : cocher la case « O »).

Ajout d'une entité type "test" qui va permettre d'ajouter des informations propres au test de matériel. La marque, le prix du produit testé... J'explose par contre la marque car j'aimerai aussi avoir une table de référence et piocher dans une liste de marque prédéfinie.

Selon votre modélisation, un test peut faire référence à un article : cela veut bien dire qu’un article peut relater un test de matériel ? OK pour « l’explosion ». N’oubliez pas de cocher la case « O » des attributs.

Ajout d'une entité type "statistiques" lié à "utilisateur". J'aimerais être capable d'avoir quelques infos sur mes utilisateurs, notamment savoir quelles pages ils aiment bien visiter.

N’hésitez pas à utiliser l’identification relative pour votre entité-type STATISTIQUES. Par ailleurs, si l’attribut statistique_page représente un numéro de page d’un article, en l’état on ne sait pas à quel article il est fait référence : il faudrait mettre en relation STATISTIQUES et ARTICLE_PAGE.

Nous retenons la figure C et voici la capture d'écran de mon MCD :

D'accord, mais l’utilisateur ne peut plus participer à quelque sondage que ce soit : ranimer l’association-type CHOISIR_POSS...

A bien y réflechir, j'aimerai stocker des informations que l'on pourrait je pense attacher à l'entité "fichier_gps". Le nom tout d'abord. Puis, grâce aux coordonnées, je suis capable de déduire des informations comme la durée totale, la hauteur maximum de la balade, la vitesse moyenne, la distance totale... Est-ce que ces données pourraient être donc stocker ainsi ?

Oui et non. Au niveau opérationnel (disons SQL) Le risque est évidemment que les données agrégées et redondantes, hébergées dans la table FICHIER_GPS diffèrent des résultats des calculs effectués à partir des données de base (table COORDONNEES_GPS). Commencez par ne pas mettre en œuvre les attributs redondants (déductibles) et définissez une vue ayant la nouvelle structure que vous proposez pour l’entité-type FICHIER_GPS et mettant à profit les opérateurs d’agrégation (SUM, COUNT, AVG, MAX, etc.) ; faites des tests pour vérifier si un SELECT portant sur la vue a une performance suffisante. Vous pouvez aussi mettre en oeuvre la structure redondante que vous proposez pour l’entité-type FICHIER_GPS et définir un trigger qui mette à jour la table FICHIER_GPS lors des INSERT, UPDATE, DELETE portant sur la table COORDONNEES_GPS, de telle sorte que les redondances soient toujours cohérentes en temps réel. Là encore, des tests de performance d’imposent.

[heretik25]

Bonjour,

Je sent qu'on touche bientôt à la fin

Ceci est tout à fait légitime. Mais est-on bien d’accord que l’attribut difficulte_note sert à attribuer une note seulement à la difficulté ? (Même principe pour l’attribut duree_note). N’oubliez pas de faire mention du caractère obligatoire des données (attributs : cocher la case « O »).

Ok. Effectivement, "duree_note" et "difficulte_note" permettent d'attribuer une note à la difficulté et à la durée.

Selon votre modélisation, un test peut faire référence à un article : cela veut bien dire qu’un article peut relater un test de matériel ? OK pour « l’explosion ». N’oubliez pas de cocher la case « O » des attributs.

Oui, un article peut relater un test de matériel. Ok pour la case "O" des attributs.

N’hésitez pas à utiliser l’identification relative pour votre entité-type STATISTIQUES. Par ailleurs, si l’attribut statistique_page représente un numéro de page d’un article, en l’état on ne sait pas à quel article il est fait référence : il faudrait mettre en relation STATISTIQUES et ARTICLE_PAGE.

Effectivement, c'est plutôt à l'entité "ARTICLE_PAGE" que "UTILISATEUR" sur laquelle je dois venir m'accrocher. J'utilise maintenant l'identification relative.



Merci pour la correction.

Oui et non. Au niveau opérationnel (disons SQL) Le risque est évidemment que les données agrégées et redondantes, hébergées dans la table FICHIER_GPS diffèrent des résultats des calculs effectués à partir des données de base (table COORDONNEES_GPS). Commencez par ne pas mettre en œuvre les attributs redondants (déductibles) et définissez une vue ayant la nouvelle structure que vous proposez pour l’entité-type FICHIER_GPS et mettant à profit les opérateurs d’agrégation (SUM, COUNT, AVG, MAX, etc.) ; faites des tests pour vérifier si un SELECT portant sur la vue a une performance suffisante. Vous pouvez aussi mettre en oeuvre la structure redondante que vous proposez pour l’entité-type FICHIER_GPS et définir un trigger qui mette à jour la table FICHIER_GPS lors des INSERT, UPDATE, DELETE portant sur la table COORDONNEES_GPS, de telle sorte que les redondances soient toujours cohérentes en temps réel. Là encore, des tests de performance d’imposent.

En fait, les informations comme "distance totale, haute max, min, durée totale", sont issues de calculs basés sur les coordonnées GPS. L'insertion de ces données se ferai donc en même temps que l'intégration des coordonnées GPS. Ainsi, par exemple, la longueur totale est calculée en 3D grâce à Pythagore a partir des données brutes que sont les coordonnées GPS.

Il me semble aussi plus opportun de pré-calculer ces données car ce sont des calculs assez complexe. Le créateur de l'article s'en verra "pénaliser" mais le lecteur, lui, aura une accélération de l'affichage de l'article et c'est le principal.

Qu'en pensez vous ?

En pièce jointe, le MCD 2.9.

@bientôt

[fsmrel]

Bonsoir,


Vérifiez que la case « O » est cochée pour tous les attributs (entités-types et associations-types). Par exemple, ça n’est pas actuellement le cas pour l’entité-type STATISTIQUES et l’association-type NOTER_ARTICLE.

N’oubliez pas au niveau MLD de tenir compte de la dépendance fonctionnelle (DF) ayant pour source CHOISIR_POSS et pour cible POSSIBILITE et rappelant qu’il faut expulser manu militari l’attribut PossibiliteId de la clé primaire de la table CHOISIR_POSS.


Quand j’écris :

N’hésitez pas à utiliser l’identification relative pour votre entité-type STATISTIQUES. Par ailleurs, si l’attribut statistique_page représente un numéro de page d’un article, en l’état on ne sait pas à quel article il est fait référence : il faudrait mettre en relation STATISTIQUES et ARTICLE_PAGE.

J’attends donc ceci :



En effet, l’identification relative joue entre les entités-types UTILISATEUR et STATISTIQUES, car les stats caractérisent ici un utilisateur, elles lui sont propres : STATISTIQUES est une propriété multivaluées d’UTILISATEUR et l’identifiant de STATISTIQUES est donc composé du couple {UtilisateurId, StatsId}. De l’autre côté, STATISTIQUES fait seulement référence à PAGE, histoire de savoir à quel article et à quelle page de cet article il est fait référence.

Il me semble aussi plus opportun de pré-calculer ces données car ce sont des calculs assez complexe. Le créateur de l'article s'en verra "pénaliser" mais le lecteur, lui, aura une accélération de l'affichage de l'article et c'est le principal.

C’est humain... Cela dit, je rappelle que ce sont les résultats des mesures des performances qui doivent influer sur le choix final, plus que le l’intuition et l’émotion... Mais vu le contexte, disons que des triggers (cf. mon message précédent) devraient faire l’affaire, sous réserve que l’on puisse y loger les calculs et leur complexité... Mais je connais très mal MySQL, voyez à interroger les connaisseurs de ce SGBD (forum MySQL) quant à la faisabilité d'un tel hébergement.


Quand le MCD sera bouclé, il serait opportun que je jette un coup d’œil au MLD.


Comment s’appelle(ra) le site où l’on pourra voir les résultats ? Sera-t-il accessible aux gens qui comme moi pratiquent le sport à la manière de Churchill ?


Un tuyau en passant. Si vous trouvez que votre MCD commence à être un peu encombré, voyez à l’aérer en fabriquant des vues (diagrammes supplémentaires). Par exemple en ce qui concerne les notes et les sondages, j’ai personnellement créé une vue que j’ai appelée Sondages. Pour réaliser ça :

Barre de menus générale :

Vue > Diagramme > Nouveau diagramme > Diagramme conceptuel

Il y a ouverture d’une fenêtre « Nouveau diagramme », vous y nommez le diagramme :



Le diagramme Sondages existe désormais, il est évidemment vide mais il figure dans l’explorateur d’objets :



Ce diagramme étant vide, on le remplit avec les objets qui vont bien :

Barre de menus générale : Symbole > Afficher les symboles

Il n’y a plus qu’à cocher les cases qui vont bien pour les entités-types (puis pour les associations, les liens...)


Avec au résultat (déjà présenté) :



J’ai procédé ainsi pour produire une vue concernant les stats (cf. plus haut), entre autres. Cette technique devient du reste indispensable quand le MCD ressemble à gros pâté, tel celui-ci :

[heretik25]

Vérifiez que la case « O » est cochée pour tous les attributs (entités-types et associations-types). Par exemple, ça n’est pas actuellement le cas pour l’entité-type STATISTIQUES et l’association-type NOTER_ARTICLE.

Effectivement, je fais un tour des attributs

N’oubliez pas au niveau MLD de tenir compte de la dépendance fonctionnelle (DF) ayant pour source CHOISIR_POSS et pour cible POSSIBILITE et rappelant qu’il faut expulser manu militari l’attribut PossibiliteId de la clé primaire de la table CHOISIR_POSS.

Oui, c'est noté quelque part, on y reviendra lors de la génération du MLD car j'avais eu un souci sur le SQL généré.

En effet, l’identification relative joue entre les entités-types UTILISATEUR et STATISTIQUES, car les stats caractérisent ici un utilisateur, elles lui sont propres : STATISTIQUES est une propriété multivaluées d’UTILISATEUR et l’identifiant de STATISTIQUES est donc composé du couple {UtilisateurId, StatsId}. De l’autre côté, STATISTIQUES fait seulement référence à PAGE, histoire de savoir à quel article et à quelle page de cet article il est fait référence.

Tout à fait d'accord !

C’est humain... Cela dit, je rappelle que ce sont les résultats des mesures des performances qui doivent influer sur le choix final, plus que le l’intuition et l’émotion... Mais vu le contexte, disons que des triggers (cf. mon message précédent) devraient faire l’affaire, sous réserve que l’on puisse y loger les calculs et leur complexité... Mais je connais très mal MySQL, voyez à interroger les connaisseurs de ce SGBD (forum MySQL) quant à la faisabilité d'un tel hébergement.

Effectivement, c'est peut-être un mauvais reflex. Je pense que quasiment tout est gérable sous MySQL. J'ai par-contre un doute sur le calcul 3D de la distance et le calcul de la distance totale...car sur mon serveur mutualisé, je ne suis pas sûr de pouvoir créer des trigger et des fonctions personnalisés sur MySQL.

Si l'on optait pour du pré-calculé comment verriez-vous la modélisation ?

Quand le MCD sera bouclé, il serait opportun que je jette un coup d’œil au MLD.

Plutôt dix fois qu'une.

Comment s’appelle(ra) le site où l’on pourra voir les résultats ? Sera-t-il accessible aux gens qui comme moi pratiquent le sport à la manière de Churchill ?

Le site est déjà existant sur le web : www.partir-en-vtt.com. Il fonctionne et fait à peu près ce que je lui demande mais la non modélisation de sa base engendre des difficultés d'évolutions et de maintenance. Je vais donc devoir réinjecter les données existantes et essayer de conserver les articles référencés... Le site a pour but de relater mes sorties... mais devrait s'ouvrir un jour aux utilisateurs inscrits. Pour l'instant, je souhaite obtenir des fondations solides (ce que je n'ai pas aujourd'hui) avant de partir en ce sens.

Est-ce que la modélisation permettra de gérer le fait que chaque utilisateur puisse proposer des articles et avoir son espace avec la gestion de ses articles ?

Un tuyau en passant. Si vous trouvez que votre MCD commence à être un peu encombré, voyez à l’aérer en fabriquant des vues (diagrammes supplémentaires).

Merci pour l'astuce mais pour l'instant c'est encore gérable et loin du diagramme de "fou" que vous avez ajouté à titre d'exemple

Peut-être que dans la version 10.0 ...

Quelques questions :


Un utilisateur ma fait remonter le besoin de partager sa trace GPS sans pour autant créer un article. Comment pourrait-on prendre en compte cette demande ?


L'entité "UTILISATEURS" qui est appelé à devenir dans le modèle physique une table va être supprimé au profit d'une table du même nom mais issue d'un forum (FSB2). Ceci permet une inscription puis une identification unique sur le forum et le site. Je n'ai donc pas la gestion des droits à penser...et c'est davantage "user-friendly" pour l'utilisateur. Je pensais (comme c'est le cas aujourd'hui) créer une base "site" et une base "forum". Étant donné que je suis capable de connaître l'id_utilisateur à tout moment grâce aux variables SESSION je me dis que cette manière est envisageable (celle de séparer les deux bases).

D'après vous, faut-il séparer les bases et exploiter la table UTILISATEUR de cette manière ou bien tout mettre dans la même base ?

En PJ, la V 3.0 du MCD

[fsmrel]

Bonsoir,

Votre site a l’air bien sympathique.

Si l'on optait pour du pré-calculé comment verriez-vous la modélisation ?

Puisque les résultats des calculs sont représentés par des attributs dans l’en-tête de l’entité-type FICHIER_GPS, on les conserve tels quels. Il n’y a que sous le capot que ça s’active : trigger or not trigger...

Est-ce que la modélisation permettra de gérer le fait que chaque utilisateur puisse proposer des articles et avoir son espace avec la gestion de ses articles ?

Pour le moment, il y a la structure d’accueil pour héberger les articles rédigés par un utilisateur. Vous avez prévu un attribut Article_validation (entité-type ARTICLE) : les propositions articles ne devraient pas poser de problèmes. Quant à le gestion de l’espace affecté à un utilisateur, le MCD semble bien muet pour l’instant à ce sujet.

Un utilisateur m’a fait remonter le besoin de partager sa trace GPS sans pour autant créer un article. Comment pourrait-on prendre en compte cette demande ?

Je vais réfléchir à ça, mais à chaud je ne vois qu’une solution pas très élégante, à savoir lui créer un article vide de contenu et ne servant qu’à établir un pont entre les entités-types UTILISATEUR et FICHIER_GPS.

L'entité "UTILISATEURS" qui est appelé à devenir dans le modèle physique une table va être supprimé au profit d'une table du même nom mais issue d'un forum (FSB2).

On sort du domaine de la modélisation et votre problème devrait faire l’objet d’une question à poser dans je ne sais trop quel forum...

[heretik25]

Bonjour,

Votre site a l’air bien sympathique.

Merci pour la remarque, voilà deux ans que je travail à le rendre "sympathique"

Puisque les résultats des calculs sont représentés par des attributs dans l’en-tête de l’entité-type FICHIER_GPS, on les conserve tels quels. Il n’y a que sous le capot que ça s’active : trigger or not trigger...

Même si c'est humain de vouloir pré-calculer ces données et que ce n'est peut-être pas la meilleur des solutions, je vais partir en ce sens. Le but est de pouvoir aussi de trouver les balades de plus de 10 kilomètres, avec une altitude inférieur à 1000m...et ainsi proposer une liste de balades dépendant de ces critères.

Pour le moment, il y a la structure d’accueil pour héberger les articles rédigés par un utilisateur. Vous avez prévu un attribut Article_validation (entité-type ARTICLE) : les propositions articles ne devraient pas poser de problèmes. Quant à le gestion de l’espace affecté à un utilisateur, le MCD semble bien muet pour l’instant à ce sujet.

Effectivement, un utilisateur peut créer un article. Selon ses droits, l'article doit être validé par l'administrateur. En gros seul les contributions de l'administrateur sont automatiquement validées. Côté administration, l'administrateur peut accéder à ses contributions et à celles des autres alors qu'un contributeur basique n'accède qu'à ses contributions. Comment prendre en compte ce besoin futur ?

Je vais réfléchir à ça, mais à chaud je ne vois qu’une solution pas très élégante, à savoir lui créer un article vide de contenu et ne servant qu’à établir un pont entre les entités-types UTILISATEUR et FICHIER_GPS

Ce n'est effectivement pas très simple. Le contenu de l'article pourrait se transformer en une description du fichier GPS. Je me demande s'il n'est quand même pas nécessaire de sortir du schéma : Article => Fichier GPS => Coordonnées GPS. Serait-il pertinent de créer des entités servant à stocker plus tard ces traces GPS sans article ?

On sort du domaine de la modélisation et votre problème devrait faire l’objet d’une question à poser dans je ne sais trop quel forum...

Oui, c'est sûr que l'on sort du domaine de la modélisation mais je me suis permis de poser la question car celle-ci me tracasse l'esprit !

@bientôt pour la suite des événements.

[fsmrel]

Bonsoir,

Effectivement, un utilisateur peut créer un article. Selon ses droits, l'article doit être validé par l'administrateur. En gros seul les contributions de l'administrateur sont automatiquement validées. Côté administration, l'administrateur peut accéder à ses contributions et à celles des autres alors qu'un contributeur basique n'accède qu'à ses contributions. Comment prendre en compte ce besoin futur ?

Si l’administrateur doit être caractérisé par des attributs qui sont sans objet pour les autres utilisateurs, vous pouvez définir un sous-type ADMIN ayant pour surtype UTILISATEUR. S’il n’y a pas besoin d’aller jusque là, vous pouvez vous contenter de définir une entité-type TYPE_UTILISATEUR en relation avec UTILISATEUR et permettant de savoir quel rôle joue tel utilisateur, donc s’il a des droits que n’ont pas d’autres utilisateurs.

Serait-il pertinent de créer des entités servant à stocker plus tard ces traces GPS sans article ?

On peut essayer quelque chose comme ceci :


MLD correspondant (Power AMC V11) :


A noter qu’il a fallu intervenir manuellement pour rendre correct le système des clés de la table FICHIER_GPS_AVEC_ART : évacuer l’attribut ArticleId de la clé primaire et en faire une clé à part entière (clé alternative, alternate key) symbolisée par le mickey <ak>.

Pour définir la clé alternative {ArticleId} (je décris la manip car elle n’est pas intuitive) :

Comme j’utilise Power AMC V11, je procède en fait au niveau du MPD (le niveau MLD n’existe pas avec la V11). Dans ce contexte, ouvrir la fenêtre des propriétés de la table FICHIER_GPS_AVEC_ART et cliquer sur l’onglet « Clés » (avec la V15, si vous procédez au niveau du MLD, ça sera sur l’onglet « Identifiants », suite à l’ouverture de la fenêtre des propriétés de l’entité FICHIER_GPS_AVEC_ART) :


Cliquer sur la 2e ligne du tableau présenté. Power AMC propose un nom de clé alternative : « Cle_2 » dans cet exemple :



Renommer Cle_2 (ça n’est pas une obligation !), par exemple en FICHIER_GPS_AVEC_ART_AK :


Sélectionner la ligne FICHIER_GPS_AVEC_ART_AK, cliquer sur le bouton « Appliquer » puis double-cliquer sur la ligne :


Cela provoque l’ouverture de la fenêtre « Propriétés de la clé » (« Propriétés de l’identifiant » avec la V15), dans laquelle c’est l’onglet Colonnes qui nous intéresse (onglet Attributs avec la V15) :


Quand on a cliqué sur l’onglet « Colonnes » (Attributs), il y a ouverture de la fenêtre suivante, dans laquelle on clique sur l’icône « Ajouter des colonnes » (« Ajouter des attributs ») de l’onglet « Colonnes » (Attributs) :


On coche la case correspondant à l’attribut ArticleId :

On clique sur « OK », même chose pour les fenêtres réaffichées, suite à quoi{ArticleId} est désormais clé alternative (cf. le mickey <ak> dans le modèle (MPD V11), le mickey <ai> (MLD V15)).

Ouf...