Discussion :

[Nip]

Bonjour,
à partir de mon diagramme de classe, j'ai généré ma base de données avec les 2 tables suivantes liées; elles possèdent, pour simplifier, les attributs suivants:

Code :

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

1
2
3
4
5
6
Table Documents :
-IdDocuments 
-FK Utilisateur(non explicite mais donné par le lien d'agrégation entre les 2 classes)

Table Utilisateur :
-nom

Chaque document consulté donne une nouvelle entrée dans la table Documents .
Je dois établir les statistiques de consultation des documents. Je peux le faire classiquement en triant les documents et en rangeant chaque entrée dans un nouveau tableau equipé d'un compteur. Le problème c'est que cette fameuse table Documents comportera au final plusieurs centaines de milliers d'entrées.
Du coup la requête de départ va prendre beaucoup trop de ressources.

Du coup j'ai pensé à créer dans mon diagramme de classe une classe annexe DocumentsCompteur possédant les mêmes attributs que la classe Documents + un attribut compteur.
Du coup cette nouvelle classe DocumentsCompteur se retrouve sans aucun lien avec aucune classe de mon diagramme et est juste là pour que le compteur soit incrémenté dès l'entrée du document dans la table.
Mais je ne suis pas sûr du tout de l'idée et si ce modèle serait valable.

J'aimerai bien votre opinion la dessus,

Merci

[ego]

Ton problème ne me parait pas suffisamment clair.
Si ta table "Documents" contient 2 FKs, une vers le document consulté et un vers l'utilisateur qui l'a consulté, je ne vois pas pourquoi il y a 'IdDocuments'.
D'autre part, que veux-tu faire exactement ?
Peux-tu exprimer ton besoin sans parler de la solution que tu as initié ?

Est-ce que le modèle objet suivant exprime ton besoin ?

consulte
Utilisateur 0..* ------------------ 0..* Document

Si oui, tu peux avoir un modèle physique de données avec :

- Table "Utilisateur"
- Table "Document"
- Table "Consultation"

La table "Consultation" contenant les colonnes suivantes :
- FK_Utilisateur
- FK_Document
- compteur

Chaque tuple de la table Consultation représente le nombre de fois qu'un utilisateur à consulté un document particulier. Ainsi, tu n'auras qu'un tuple par couple (Utilisateur X, Document Y).

Est-ce que cela t'aide ?

[Nip]

Merci ego d'avoir répondu; effectivement mon modèle n'est pas correctement présenté je reprends donc;
j'ai au départ 2 classes :

Code :

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

1
2
classe Utilisateur avec pour attribut : nom
classe Documents avec pour attributs : nom et date_de_consultation

note IdDocuments de mon premier post est remplacé par nom

A chaque consultation de document par l'utilisateur, une nouvelle entrée est crée dans la table Documents (avec donc comme parametres le nom et la date de consultation).
Je cherche à récupérer le nombre de fois ou chaque document a été consulté et ce indépendamment de l'utilisateur.

Le modèle objet est le suivant (avec une agrégation)

Utilisateur 1<>------------------ 0..* Documents


L'idée de la classe d'association que tu m'a proposée ne peut donc pas convenir à mon modèle

[alex00]

Attention Nip aux mots que tu utilises :
pour toi la table Document ne contient pas des documents mais l'historique des consultations !

La modelisation de ego est plus appropriée, avec les modifications suivantes :
Consultation contient l'id_utilisateur, l'id_document et la date_de_consultation.
Document contient uniquement dans un premier temps l'id_document.

Dans un deuxième temps , Document peut contenir le compteur de nombre de consultation (pour chaque document).

Il te reste alors à garantir l'incrément de ce compteur lors d'ajout dans la table consultation.

[ego]

Tout à fait d'accord avec alex00 vu que tu viens de faire intervenir la date de consultation. La date remplace donc mon compteur qui n'a plus lieu d'être.
Pour savoir combien de fois un doc a été consulté indépendamment de l'utilisateur, tu dois faire :

select count(FK_Document) from Consultation where FK_Document = 'id du document que tu cherches'

si tu le veux pour une date donnée, ajoute le critère date dans la clause where.

Note qu'il n'est pas besoin de créer une classe Consultation.

[Nip]

Merci pour vos interventions;
Alex00 tu as tout à fait raison j'ai particulièrement mal choisi mes noms de classes (moi qui voulait simplifier )
après y avoir réfléchi et en suivant vos conseils voilà comment j'ai l'intention de modéliser mon système

Code :

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

1
2
3
Consultation : date_de_consultation. 
Document : Compteur
Utilisateur : nom

Le modèle objet est le suivant

Document 1<>---------- *..0 Consultation 0..* ----------<>1 Utilisateur

Ainsi je me retrouverai au niveau de ma base de données avec les tables suivantes :

Code :

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

1
2
3
Consultation : (IdConsultation) date_de_consultation, FK_IdDocument, FK_IdUtilisateur. 
Document : (IdDocument) Compteur
Utilisateur : (IdUtilisateur) nom

A chaque document consulté je pourrai incrémenté le compteur de la classe Document, ce qui me permettra d'obtenir la liste des documents classés en fonction de leur nombre de consultation (avec une requête simple ce qui est le but recherché étant donné la taille future de la table).
Et par la classe consultation je pourrai avoir toutes les infos dépendantes de l'utilisateur.

Ce modèle vous paraît il convenable ? (et après j'arrête de vous embêter)

[ego]

Mon avis est que le nom de ta classe Document est mal choisie si tu n'y mets qu'un Id et un compteur. Cette classe ne devrait-elle pas tout simplement s'appeler "Compteur" ?

D'autre part, en termes de modélisation UML, ton modèle n'est pas totalement juste. Tu devrait avoir une association N-N entre ta classe Document (qui doit changer de nom) et Utilisateur. La classe Consultation étant une classe d'association reliée à l'association N-N. En fait ton modèle objet ressemble plus à un MCD.
Au final le résultat sera le même.

[tipiak]

Mon avis est que le nom de ta classe Document est mal choisie si tu n'y mets qu'un Id et un compteur. Cette classe ne devrait-elle pas tout simplement s'appeler "Compteur" ?

je pense qu'il y aura tout plein d'autres trucs inutiles dans le cadre du problème qu'il a rencontré : tel que l'auteur du document, sa date de d'écriture, etc

D'autre part, en termes de modélisation UML, ton modèle n'est pas totalement juste. Tu devrait avoir une association N-N entre ta classe Document (qui doit changer de nom) et Utilisateur. La classe Consultation étant une classe d'association reliée à l'association N-N. En fait ton modèle objet ressemble plus à un MCD.
Au final le résultat sera le même.

+1 : mais le résultat sera affectivement le même. à la nuance prêt que je ne créérai pas de classe Consultation ( la table de consultation intervient qu'au niveau du MCD selon moi )

[Nip]

Mon avis est que le nom de ta classe Document est mal choisie si tu n'y mets qu'un Id et un compteur. Cette classe ne devrait-elle pas tout simplement s'appeler "Compteur" ?

Gardons pour l'instant le nom Document qui prendra alors comme attributs (nom, compteur), de cette façon je garde une certaine cohérence au niveau des noms. (c'est de toute façon plus proche de ce que je souhaite faire)

D'autre part, en termes de modélisation UML, ton modèle n'est pas totalement juste. Tu devrait avoir une association N-N entre ta classe Document (qui doit changer de nom) et Utilisateur. La classe Consultation étant une classe d'association reliée à l'association N-N. En fait ton modèle objet ressemble plus à un MCD.
Au final le résultat sera le même.

Effectivement sur mon premier post j'avais donnée une relation 1-N entre la classe Documents et la classe Utilisateur.
Cette relation n'est plus valable et passe en N-N dans le modèle avec la classe d'association Consultation. Là dessus je suis d'accord ego.
Une fois cela établit, le modèle te paraît correct et efficace pour ce que j'ai envie de faire
c'est à dire obtenir la liste des documents classés en fonction de leur nombre de consultation, sachant que ma table contienda des centaines de millier d'entrées.

je pense qu'il y aura tout plein d'autres trucs inutiles dans le cadre du problème qu'il a rencontré : tel que l'auteur du document, sa date de d'écriture, etc

Je peux t'assurer que les attributs que j'ai donné ne sont pas inutiles même dans le problème que je rencontre.

à la nuance prêt que je ne créérai pas de classe Consultation

Le problème que j'ai c'est qu'il me faut à la fois la date de consultation du document et un compteur pour savoir combien de fois le document a été consulté par tous les utilisateurs; et je ne vois pas comment faire à part en passant par une classe d'association (et en évitant une requête trop complexe étant donné la taille de la table)

Merci pour vos remarques

[tipiak]

en fait on c'est mal comprit

pour les attributs je suis d'accord avec toi ceux que tu as cité interviennent dans ce problème (c'est juste que tu peux rajouté une fois ton p résolu des attributs a la classe Document)

sinon pour la consultation ce que je voullai dire : c'est la présence d'une table au Niveau du MCD (pas de soucis pour tes requettes donc)

par contre plutot que d'avoir 3 classes : j'en ferai Deux Document et Utilisateur
(ce qui correspond à la traduction de la relation (n n) de l'UML)
alors que pour le MCD tu ne peux pas modéliser la relation (n n) sans passer par une table de relation (la table Consultation)

enfin je crains que je m'enbrouille légèrement dans les appélations
mais en gros j'ai l'impression que ton Pb vient de MCD - UML

en gros avec tes deux classes Document et Unitilisateur, tu peux tres bien avoir une méthode dans Document qui s'appel genre

Consulter(id-Utilisateur , Date ) qui inscrit l'enregistrement dans la table consultation.

[ego]

il me semble que nous avons en gros tous raison à propos de la classe Consultation.
En fait, tout dépend de ce que l'on veut faire avec les informations sur la date de consultation. Soit on la mets simplement à jour dans la base et on n'a pas vraiment besoin de la classe Consultation, soit on a besoin de faire des traitements en mémoire avec cette information et là on aura sûrement besoin de la classe.

[Nip]

soit on a besoin de faire des traitements en mémoire avec cette information et là on aura sûrement besoin de la classe.

Voilà c'est exactement ça. Donc je vais rester sur le dernier modèle qui correspond plus à mes besoin.
Je vous remercie tous les 3 ego, tipiak et alex00, votre aide m'a été très utile