Discussion :

[A.i.A]

Bonjour à tous,

On doit faire une application pour communiquer 2 pc par voix sur ip,

Voici un premier essai de conception,

Je voulais connaitre votre avis et conseils

On a pensé de faire une association porteuse "Appelle" qui sera comme un historique des conversations, ou on peut sauvegarder les informations sur la conversation ( émetteur / récepteur / date / on peut ajouter après "voix" ==> conversation elle même)

L'entité clients c'est pour sauvegarder les liste des contacts de chaque utilisateur,

On sait pas pas si c'est bien fait ou non, alors on demande l'avis des spécialistes.

Merci d'avance

[qi130]

C'est délicat de se prononcer sur la validité d'un modèle sans connaitre le cahier des charges...

Au demeurant: revoir les cardinalités autour de "Appelle"

L'entité clients c'est pour...

cette entité est absente du schéma proposé.
De plus: peut-on appeler en dehors de cette liste de contacts ? Si la réponse est non, il faut revoir "Appelle" qui ne serait plus réflexive sur "user".
Si la réponse est oui, y a t-il un mécanisme de mémorisation automatique de ce nouveau contact dans "contact_list" ? si oui, alors on revient au cas ci dessus !

Au passage, contact_list est un très mauvais nom ! Préférer "Contact", puisque la liste sera composée de l'ensemble des contacts.

Pas de durée de l'appel ?

[CinePhil]

Effectivement, le schéma proposé ne correspond pas vraiment à ce qui est dit dans le message !

Pourquoi la clé de contact_list (effectivement mal nommé) est id_user alors qu'il existe une entité user qui possède une clé id_authentifier ?
=> La clé de user devrait s'appeler id_user et la clé de contact devrait s'appeler id_contact.

Je pense que deux users peuvent s'appeler plusieurs fois ?
==> La date devrait participer à la clé dans l'association appelle.

on peut ajouter après "voix" ==> conversation elle même

Ceci n'est pas modélisé. D'ailleurs, faut-il le modéliser ? Je ne suis pas sûr qu'enregistrer les conversations vocales entre deux utilisateurs de PC soit très légal.

L'entité clients c'est pour sauvegarder les liste des contacts de chaque utilisateur,

Il s'agit donc de l'entité contact ?

On pourrait aussi chipoter sur le fait que tu as des colonnes identiques dans user et contact puisque ce sont tous deux des personnes. Un héritage serait souhaitable.

Il faudrait aussi décomposer l'adresse des contacts en isolant la commune dans une entité séparée.

[A.i.A]

Tout d'abord, je voudrais vous remercier pour votre aide,

C'est vrai, parce qu'on l'a modifié j'avais laissé des erreurs par précipitation,

Revoici le nouveau modèle,

Pour l'appel, ce que j'ai pensé, c'est que chaque user pour utiliser l'application doit d'abord s'inscrire, après il devra s'authentifier chaque fois pour accéder à l'application et ensuite pouvoir parler avec un autre...

La liste des contacts, c'est juste pour qu'il retrouve ses contacts lorsqu'il se reconnecte.

Je pense que deux users peuvent s'appeler plusieurs fois ?

Oui, c'est vrai, mais j'ai pas trouvé la case à cocher pour indiquer que "date" est aussi une clé primaire !!

Je ne suis pas sûr qu'enregistrer les conversations vocales entre deux utilisateurs de PC soit très légal.

J'avais pas pensé à ceci, on pourrait donner au user le choix d'enregistrer !?

En ce qui concerne l'héritage, je ne l'ai pas encore étudié, comment l'appliquer...

Il faudrait aussi décomposer l'adresse des contacts en isolant la commune dans une entité séparée.

Qu'est ce que tu veux dire par "commune" ?

[CinePhil]

Pour l'appel, ce que j'ai pensé, c'est que chaque user pour utiliser l'application doit d'abord s'inscrire, après il devra s'authentifier chaque fois pour accéder à l'application et ensuite pouvoir parler avec un autre...

Ça tient de la modélisation des traitements (MCT) et pas de la modélisation des données.

Oui, c'est vrai, mais j'ai pas trouvé la case à cocher pour indiquer que "date" est aussi une clé primaire !!

Ne connaissant pas le logiciel de modélisation que tu as utilisé, je ne peux pas t'aider sur ce point.

J'avais pas pensé à ceci, on pourrait donner au user le choix d'enregistrer !?

Il faudrait que les deux soient d'accord. Enfin c'est à voir au niveau du cahier des charges.

En ce qui concerne l'héritage, je ne l'ai pas encore étudié, comment l'appliquer...

Contact -(1,1)----Etre----0,1- Personne
User -(1,1)----Etre----0,1-------------|

Les cardinalités entre parenthèses signifient qu'il y a identification relative des entités filles par rapport à l'entité mère. Ce qui veut dire que l'identifiant du contact sera celui de la personne. Idem pour le USer.

Ça donnera les tables :
Personne (prs_id, prs_nom, prs_prenom...) <= tous les attributs communs à toutes les personnes.
Contact (cnt_id_personne, cnt_adresse, cnt_num_tel...) <= seulement les attributs propres aux contacts + l'identifiant de la personne
User (usr_id_personne, usr_login, usr_password) <= seulement les attributs propres aux users + l'identifiant de la personne.
cnt_id_personne et usr_id_personne sont à la fois clé primaire et clé étrangère.

Qu'est ce que tu veux dire par "commune" ?

Commune : Une commune est une division administrative, formée d'un territoire clairement défini, qui correspond généralement à une partie d'une ville[1], à une ville entière, ou à un bourg avec ses villages et hameaux (France), ou un groupe de villages (Allemagne, Pays-Bas, Belgique, Suède, etc…).
Exemple : Toulouse

Tu pourrais avoir le modèle suivant pour éviter la répétition du nom des communes, potentiellement écrites avec des orthographes différentes (Saint-Etienne, St Etienne, Saint Étienne...) :
Contact -1,1----Résider----0,n- Commune -1,1----Situer----0,n- Pays

Si tes contacts sont tous en France, tu peux même introduire entre Commune et Pays les départements et les régions.

[A.i.A]

Rebonjour,

Commune : Une commune est une division administrative.....

Je comprends maintenant, mais j'habite pas en France.
(On peut la remplacer par "ville" ! )

Ne connaissant pas le logiciel de modélisation que tu as utilisé, je ne peux pas t'aider sur ce point.

J'utilise PowerDesinger,

Pour l'héritage, voila ce que j'ai essayé, je crois que c'est bon (il existe quelques warning lors du géneration du MPD)
Et je trouve pas ou modifier les cardinalités..!!

Et pour la clé Data, je l'ai ajouté manuellement sur le MLD !

Voici un aperçu
Quesqeue vous en pensez ?

Cordialement.

[A.i.A]

Bonjour,

Je crois que dans le MCD les entités filles doivent être sans clé primaire !

Mais après la création de la base de données, quand on veut créer un user, il faut absolument l'avoir déjà dans la table personne d abord !!!

Sa parait non pratique !
Comment est ce la méthode pour interroger la base avec L'héritage !?!

[CinePhil]

L'identifiant de User et de Contact est à la fois clé primaire et clé étrangère faisant référence à l'identifiant de la personne. Il ne doit pas y avoir en plus d'id_user ni d'id_contact.
Regarde mieux ce que j'avais donné comme modèle :

Ça donnera les tables :
Personne (prs_id, prs_nom, prs_prenom...) <= tous les attributs communs à toutes les personnes.
Contact (cnt_id_personne, cnt_adresse, cnt_num_tel...) <= seulement les attributs propres aux contacts + l'identifiant de la personne
User (usr_id_personne, usr_login, usr_password) <= seulement les attributs propres aux users + l'identifiant de la personne.
cnt_id_personne et usr_id_personne sont à la fois clé primaire et clé étrangère.

Les attributs communs aux contacts et aux users ne doivent figurer que dans la table personne.

Login et password devraient je pense être plutôt dans user (un contact a t-il un login ?) mais first_name, last_name, num_tel, address ne devraient figurer que dans Personne.
N'appelle pas une colonne "date", c'est un mot du langage SQL.

[A.i.A]

Contact (cnt_id_personne, cnt_adresse, cnt_num_tel...) <= seulement les attributs propres aux contacts + l'identifiant de la personne
User (usr_id_personne, usr_login, usr_password) <= seulement les attributs propres aux users + l'identifiant de la personne.

Je croyais qu'on doit ajouter aussi id des entités fils !

=> Donc Je dois renommer id_personne en usr_id_personne au niveau du MLD ?!

Login et password devraient je pense être plutôt dans user (un contact a t-il un login ?)

Password juste pour user, login pour contact aussi, c'est son pseudo avec koi le user reconnaît ses contacts (juste pour ne pas créer un autre champ: pseudo)

Une autre question, maintenant l'entité contact au MCD est vide
=> et après la génération du MPD avec PowerDesigner, les entités fils se remplissent avec les attributs communs !!? et ce n'est pas normal d'après ce que tu m'a dis,

enfin, Merci,merci.

[CinePhil]

Contact (cnt_id_personne, cnt_adresse, cnt_num_tel...) <= seulement les attributs propres aux contacts + l'identifiant de la personne
User (usr_id_personne, usr_login, usr_password) <= seulement les attributs propres aux users + l'identifiant de la personne.

Je croyais qu'on doit ajouter aussi id des entités fils !

=> Donc Je dois renommer id_personne en usr_id_personne au niveau du MLD ?!

Dans l'entité "contacts" de ton MLD, tu as mis id_personne et id_contact. id_contact est inutile, supprime-le.
Idem pour l'entité "user", supprime id_user qui est inutile.

Une autre question, maintenant l'entité contact au MCD est vide
=> et après la génération du MPD avec PowerDesigner, les entités fils se remplissent avec les attributs communs !!? et ce n'est pas normal d'après ce que tu m'a dis,

Je ne connais pas PowerDesigner.
D'après le texte figurant sur ton MLD (parce que le dernier schéma que tu as donné est un MLD, pas un MCD !), j'ai l'impression que tu as dû utiliser une fonction du logiciel pour l'héritage des tables. Peut-être y a t-il dans cette fonction une option permettant de choisir le type d'héritage qu'on souhaite faire ?
En effet, quand on fait un héritage de table dans Postgresql par exemple, la structure de la table mère est affichée dans la table fille (mais je ne sais pas comment ça se passe physiquement pour les données). Certains cours donnent plusieurs possibilités pour faire de l'héritage mais la manière que je mets toujours en pratique est celle qui est issue de la programmation objet et qui veut que la classe fille hérite des propriétés de la classe mère mais que celles-ci ne sont pas explicitement programmées dans la classe fille. Ici ça devrait selon moi être pareil avec un héritage de tables, contrairement à ce que semble faire Postgresql et ton logiciel de modélisation, les entités filles ne doivent comporter que les attributs spécifiques et les tables qui en résultent ne doivent comporter que les colonnes spécifiques + l'identifiant venant de la table mère.

Pour plus d'infos sur l'héritage des tables, voir le cours de SQLPro.

[A.i.A]

Re Bonjour
Re Merci

Voila, j'ai suivi les conseils,
Pour information, j'ai du utiliser ces options de génération :



pour obtenir les résultats souhaités :



J'ai ajouté "date_appel" comme Clé primaire,
Et voici le résultat des requêtes du script sql en Postgres :

Code :

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

1
2
3
4
5
6
NOTICE:  CREATE TABLE / PRIMARY KEY créera un index implicite « pk_appelle » pour la table « appelle »
NOTICE:  CREATE TABLE / PRIMARY KEY créera un index implicite « pk_contacts » pour la table « contacts »
NOTICE:  CREATE TABLE créera des séquences implicites « personne_id_personne_seq » pour la colonne serial « personne.id_personne »
NOTICE:  CREATE TABLE / PRIMARY KEY créera un index implicite « pk_personne » pour la table « personne »
NOTICE:  CREATE TABLE / PRIMARY KEY créera un index implicite « pk_user » pour la table « USER »
La requête a été exécutée avec succès en 750 ms, mais ne renvoie aucun résultat.

Mais, en parlant du physique,
Par exemple, la première fois, la personne doit d'abord s'inscrire, alors elle devra être un "User", mais sur la BD, on a deux tables différentes, Personne et User !!
Je dois stocker l'utilisateur sur les 2 tables avec même id_personne ?
C'est comme cela que ca marche l'héritage ?
j'ai pas encore bien compris l'application sur la BD ? J'espère me clarifier

[CinePhil]

la première fois, la personne doit d'abord s'inscrire, alors elle devra être un "User", mais sur la BD, on a deux tables différentes, Personne et User !!
Je dois stocker l'utilisateur sur les 2 tables avec même id_personne ?
C'est comme cela que ca marche l'héritage ?

Oui.
Dans la table Personne, tu auras par exemple {1, 'AiA', 'ton_prenom', 'ton_nom', 'ton_num_tel', 'ton_adresse'} et dans la table user, tu auras {1, 'ton_password'}.

[A.i.A]

Bonsoir,

Dans la table Personne, tu auras par exemple {1, 'AiA', 'ton_prenom', 'ton_nom', 'ton_num_tel', 'ton_adresse'} et dans la table user, tu auras {1, 'ton_password'}.

1. Donc pour les opérations par exemple "insertion" on devra faire 2 requêtes (au lieu d'une seule) ! Ce n'est pas un traitement de plus ? ou bien l'utilité d'héritage c'est juste au niveau du stockage ?


2. J'ai revu le MCD, et en visitant d'autres Sujets ! Je me demande :
On aurait pas du faire une seule entité "User" ou "personne" avec une association réflexive "contact" !? puisque les contacts sont aussi des users de l'application
[User] ---1.n---(Contact)-----1.n---[User]
Règle de gestion : Un user peut avoir plusieurs contacts, les contacts sont bien sur des users de l'application !

Par ex : http://www.developpez.net/forums/d80...e/#post4635879

Merci Philippe.

[CinePhil]

1. Donc pour les opérations par exemple "insertion" on devra faire 2 requêtes (au lieu d'une seule) ! Ce n'est pas un traitement de plus ? ou bien l'utilité d'héritage c'est juste au niveau du stockage ?

Oui deux requêtes mais ça peut être pris en charge par un trigger.
On fait une vue qui rassemble les propriétés de la table mère et de la table fille et on y associe un trigger qui répartit les données correctement dans les deux tables. Côté programme, il n'y aurait qu'une seule requête d'insertion vers la vue.

Mais apparemment, tu ne vas pas avoir besoin de cet héritage !

2. J'ai revu le MCD, et en visitant d'autres Sujets ! Je me demande :
On aurait pas du faire une seule entité "User" ou "personne" avec une association réflexive "contact" !? puisque les contacts sont aussi des users de l'application
[User] ---1.n---(Contact)-----1.n---[User]
Règle de gestion : Un user peut avoir plusieurs contacts, les contacts sont bien sur des users de l'application !

Ça, tu ne l'avais pas dit, même si j'avais imaginé que cela pouvait être le cas !

Pourtant, à un moment, j'avais demandé :

Login et password devraient je pense être plutôt dans user (un contact a t-il un login ?)

Donc la modélisation change !
Je récris ta nouvelle règle de gestion :
Un user peut contacter plusieurs users et un user peut être contacté par plusieurs users.

MCD :
User -0,n----Contacter----0,n- User

S'est effectivement une association réflexive qui va quand même engendrer une table associative :
User (usr_id, usr_login, usr_password, usr_nom, usr_prenom, usr_adresse, usr_num_tel...)
Contacter (cnt_id_usr_appelant, cnt_id_user_appele, cnt_date_heure...)

Et plus besoin d'héritage de personne vers contact et user, on remet tout dans user.

[A.i.A]

Bonjour,

En ce qui concerne les contacts, c'est juste pour sauvegarder chaque user et ses contacts, quand l'utilisateur se connecte, retrouve ses contacts (d'ailleurs je dois ajouter un "statut") mais il peut ne pas les appeler !
Et la table Appel sera pour l'historique des conversations (Émetteur/ip source/récepteur/ etc.....)
C'est comme ceci que j'ai vu les choses, je vous demande votre avis:



J'espère que cette fois ci, je suis tout proche du version finale.

J'ai changé les noms des champs dans le MLD, je sais pas si c'est permis.


Merci encore.

[CinePhil]

Si un user devient contact d'un autre seulement à partir du moment où il l'a appelé au moins une fois, l'entité "Contact" est inutile puisqu'on peut retrouver tous les contacts d'un utilisateur à l'aide de la table associative "appelle".

Si par contre un user peut en choisir d'autres pour constituer sa liste de contacts sans forcément les appeler, alors la table "Contact" est nécessaire.
Et si un user ne peut appeler que ses contacts, alors l'association "appelle" doit s'opérer entre "user" et "Contact".

J'ai changé les noms des champs dans le MLD, je sais pas si c'est permis.

Oui bien sûr pour éviter les noms du style FK_APPELLE_APPELLE_USER qui ne sont vraiment pas beaux et dans le cas présent tu aurais quasiment deux fois le même nom snas qu'on sache qui est l'émetteur et qui est le récepteur.

Il ne faut pas se fier aveuglément au MLD généré par le logiciel de modélisation mais toujours le vérifier et l'affiner.

[A.i.A]

Effectivement c'est :

Si par contre un user peut en choisir d'autres pour constituer sa liste de contacts sans forcément les appeler, alors la table "Contact" est nécessaire.

On veut même que l'utilisateur envoie une invitation, et le contact peut accepter ou non. (Mais je crois que c'est un traitement, pas la peine/ pas possible de le modéliser ?!)

Merci.

[CinePhil]

On veut même que l'utilisateur envoie une invitation, et le contact peut accepter ou non. (Mais je crois que c'est un traitement, pas la peine/ pas possible de le modéliser ?!)

Tu ajoutes des trucs au fur et à mesure, toi !

Dans la mesure ou l'utilisateur invité n'est pas forcément en ligne au même moment que l'utilisateur invitant, il faut mémoriser cette invitation.

On peut donc avoir ce MCD :
Utilisateur -0,n----Contacter----0,n- Utilisateur

Ce qui donnerait les tables :
Utilisateur (usr_id, usr_login, usr_mot_passe...)
Contact (cnt_id_invite, cnt_id_invitant, cnt_accepte)

cnt_accepte est un booléen ayant FALSE pour valeur par défaut et quand l'utilisateur invité a accepté l'invitation, il passe à TRUE.

Finalement, Contact n'est pas une table issue d'une entité mais une table associative.

[A.i.A]

Bonjour,

Tu ajoutes des trucs au fur et à mesure, toi !

J'espère que je n'ai pas abusé,
(Désole, je ne sais pas vraiment, quelles sont les limites d'aide, s'ils existent)

Voici la table contact, généré par l'association réflexive "contacter" de l'MCD
(Je répète juste pour m'assurer, (Prière de me corriger si j'ai fait une faute)):



Dans ce cas, on stockera tous ceux qui ont envoyé des invitations,
et si le contact accepte, on devra rendre le champ "accepte" au "True" dans les deux sens:
1 ........... 2
et :
2 ........... 1

C'est comme cela que ça doit marcher ?

Merci.

[CinePhil]

(Désole, je ne sais pas vraiment, quelles sont les limites d'aide, s'ils existent)

La seule limite c'est "Faites mes devoirs !" En gros si tu donnes un énoncé de problème sans montrer que tu as commencé à y travailler, tu te fais jeter !

Dans ce cas, on stockera tous ceux qui ont envoyé des invitations,
et si le contact accepte, on devra rendre le champ "accepte" au "True" dans les deux sens:
1 ........... 2
et :
2 ........... 1

C'est comme cela que ça doit marcher ?

Pas forcément.
On peut rechercher les contacts d'un utilisateur par une union de deux requêtes.
Quels sont les contacts de l'utilisateur 1 ?

Code SQL :

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

1
2
3
4
5
6
7
8
9
SELECT id_invite AS contact
FROM contacter
WHERE id_invitant = 1
  AND accepte = TRUE
UNION
SELECT id_invitant AS contact
FROM contacter
WHERE id_invite = 1
  AND accepte = TRUE

Ainsi, pas besoin d'ajouter la ligne inverse quand le contact est accepté.