[MCD] Gestion d'historique des mails envoyés, recus

**vodasan** · 14/09/2006, 11h31

Merci de votre aide

**Le Pharaon** · 14/09/2006, 14h30

Envoyé par D4rK_C0uaK6

j'ai aussi pensé à faire un héritage mail envoyé / recus héritant de mail

.
Héritage ou pas héritage tout dépend des propriétés de tes différents type de mail (mail-type, mail-simple, ...) que je souhaiterais voir ici clairement, sans les clefs étrangères.

Merci

**vodasan** · 15/09/2006, 09h07

Bonjour,

voici la liste des proprietés :
mail : dateReception, dateEnvoi, sujet, commentaire.

mail-type : libelle, objet

merci bien,
David

**Le Pharaon** · 15/09/2006, 14h48

Voici ce que je te propose.

Mail(idMail,DateReception,DateEnvoi,Sujet,Commentaire,Message)
Mail-Type(idMail-Type,DateReception,DateEnvoi,Sujet,Commentaire,Message)

Je confonds libelle et commentaire, et Objet et Sujet. Et dans un mail-type je crois que la date de réception et la date d'envoi pourraient être utiles.

Les deux tables citées plus haut (à savoir mail et mail-type) pourraient être regroupées en une seule avec une propriété supplémentaire (typeMail) pour les défférencier.

A toi de voir si ça résoud ton problème

Bonne journée

**fsmrel** · 15/09/2006, 17h06

Une variante (il y en a d'autres...)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
/* Administrateurs */

CREATE TABLE Admin (
  Admin_Id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  Admin_Nom TEXT NOT NULL,
  PRIMARY KEY(Admin_Id)
);

/* Clients */

CREATE TABLE Client (
  Cli_Id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  Cli_Nom TEXT NOT NULL,
  PRIMARY KEY(Cli_Id)
);

/* Table des mails envoyés par les admin aux clients */
/* Le séquenceur est relatif au couple  {Admin, Client}. Il permet d'éviter les doublons */

CREATE TABLE AdminMail (
  Admin_Id INTEGER UNSIGNED NOT NULL,
  Cli_Id INTEGER UNSIGNED NOT NULL,
  Sequenceur INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  Date_Envoi DATE NOT NULL,
  Sujet TEXT NOT NULL,
  Commentaire TEXT NOT NULL,
  PRIMARY KEY(Admin_Id, Cli_Id, Sequenceur),
  FOREIGN KEY(Admin_Id)
    REFERENCES Admin(Admin_Id)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION
);

/* Types de mails */

CREATE TABLE Type_Mail (
  Type_Mail_Id TEXT NOT NULL AUTO_INCREMENT,
  Type_Mail_Libelle TEXT NOT NULL,
  PRIMARY KEY(Type_Mail_Id)
);

/* Type de mail d'un mail d'un admin, seulement si mail typé */  
/* Pour éviter les valeurs nulles (on peut aussi utiliser une valeur par défaut) */

CREATE TABLE Admin_Mail_Type_Mail (
  Cli_Id INTEGER UNSIGNED NOT NULL,
  Admin_Id INTEGER UNSIGNED NOT NULL,
  Sequenceur INTEGER UNSIGNED NOT NULL,
  Type_Mail_Id TEXT NOT NULL,
  PRIMARY KEY(Cli_Id, Admin_Id, Sequenceur),
  FOREIGN KEY(Admin_Id, Cli_Id, Sequenceur)
    REFERENCES AdminMail(Admin_Id, Cli_Id, Sequenceur)
      ON DELETE CASCADE
      ON UPDATE CASCADE
);

/* Mails reçus des clients */
/* Comme pour Outlook, il n'est pas nécessaire de mettre dans le même sac les mails reçus et les mails envoyés */
/* en cas de besoin, une bonne union entre les mails admin et les mails clients, et puis voilà (l'algèbre realtionnelle, ça sert) */

CREATE TABLE ClientMail (
  Cli_Id INTEGER UNSIGNED NOT NULL,
  Sequenceur INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  Date_Envoi DATE NOT NULL,
  Sujet TEXT NOT NULL,
  Commentaire TEXT NOT NULL,
  PRIMARY KEY(Cli_Id, Sequenceur),
  FOREIGN KEY(Cli_Id)
    REFERENCES Client(Cli_Id)
      ON DELETE CASCADE
      ON UPDATE CASCADE
);

**Le Pharaon** · 15/09/2006, 17h10

Code fsmrel :

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

 en cas de besoin, une bonne union entre les mails admin et les mails clients, et puis voilà (l'algèbre realtionnelle, ça sert)

Je crois qu'on traite du Niveau Conceptuel

**fsmrel** · 15/09/2006, 18h54

A l'attention de Bujuman,

J'ai effectivement écrit :

En cas de besoin, une bonne union entre les mails admin et les mails clients, et puis voilà (l'algèbre relationnelle, ça sert)

Et vous faites observer :

Je crois qu'on traite du Niveau Conceptuel

Il est évident que, si l'on ne dispose malheureusement pas de langage de manipulation de données au niveau conceptuel, alors on doit différer les opérations sur les données, à un stade donc où l'on produit et, hélas ! il est parfois trop tard. En fait, l'union dont je parle peut faire l'objet d'une vue, qui n'est jamais qu'une spécialisation de table, au même titre que les tables de base obtenues à partie du niveau conceptuel (une table de base est une table et une vue est une table).
Je pense qu'il n'est pas interdit, même au niveau conceptuel de se poser des questions sur les conséquences de ce que l'on modélise et des lacunes à combler (réfléchissez par exemple au métabolisme des données : quelles sont les conséquences de la suppression d'une occurrence sur celles qui lui sont liées (leurs réactions), etc.)
Pour tout dire, je me sens à l’étroit au strict niveau conceptuel statique et, pour y voir plus clair, j’ai besoin de toute la puissance de la Théorie relationnelle (je n’ai pas dit SQL qui, je vous fais une confidence, signifie Sorry Query Language). Inversement, il est des situations où Merise m'aide beaucoup. Bref, tout ça se complète et je m'en sers.

Salutations

[MCD] Gestion d'historique des mails envoyés, recus

Schéma

Discussions similaires

Partager

Partager