Discussion :

[Appolonios]

Bonjour,

Après plusieurs sessions sur le forum à lire des réponses à des problèmes qui ressemblent au mien sans être identiques, j'ai finalement réussi à perdre confiance en mon MCD ! Je manque d'expérience en conception mais j'ai la volonté de bien faire, j'espère que vous pourrez m'éclairer...

En simlifiant un peu, il s'agit de capteurs qui effectuent des mesures sur des sites. Chaque mesures brutes du capteur correspond à une valeur horodatée (jj/mm/aaaa hh:mm:ss).
Les capteurs sont autonomes mais doivent être déloggués régulièrement car leur capacité de stockage est limitée. (La capacité de stockage d'un capteur peut être de 3 ou 6 mois de mesures)
Vous allez me dire cela ressemble fort à un poste récent :
http://www.developpez.net/forums/d12...ures-capteurs/

Sauf qu'ici, nos capteurs bougent... Une fois déloggué, un capteur peut être installé sur un autre site. Le but est de pouvoir suivre la flotte des capteurs tout en stockant les mesures brutes pour les retravailler facilement.

Pour pouvoir traiter convenablement les mesures brutes, on doit conserver un certain nombre d'information à chaque installation d'un capteur sur un site :
• l’heure à laquelle l’enregistrement est relancé (off->on) (vidage du cache)
• l’heure à laquelle l’installation est effective
• l’heure à laquelle le capteur est retiré du site
• un éventuel commentaire : par exemple, "capteur sal"


Un site peut éventuellement accueillir plusieurs capteurs en même temps.

J'en suis venu au MCD en pièce jointe, et aux relations suivantes :

Site (siteId, siteName, siteLong, siteLat, siteAlt)
Sensor(sensorId, sensorCapa, sensorVers)
Installation (instId, siteId #, sensorId #, instStartDate, instEndDate, instReboot, instCom)
rawMeasurement ( rmDate, instId #, rmVal)

J'y vois deux problèmes potentiels :

- Dans la pratique, on souhaite pouvoir visualiser le déplacement des capteurs et surtout les installations en cours (Notamment, savoir quels capteurs arrivent au bout de leur capacité de stockage et doivent être récupérés en premier). Je peux gérer ça en cherchant les installations qui ont le champ InstEndDate NULL, mais ça ne me semble pas très propre ?
- Rien n'empêche de créer deux installations sur un même intervalle de temps. Or, un capteur ne peux être sur deux sites à la fois. Comment gérer cette contrainte proprement ?


J'ai pensé à une autre option qui serait de considérer des entités-type ouvertureInstallation et fermetureInstallation (associés à Installation) d'un sur-type Evenement. (Ce sur-type pourrait aussi être parent d'intervention de maintenance, ou de modification du capteur). Mais le problème de l'ordonnancement reste le même. Faut-il gérer ça seulement au niveau des applications ?

J'espère que c'est à peu près clair. Merci de votre aide !

[punkoff]

Bonjour,


Pouvez-vous, par avance, prévoir une future installation d'un capteur sur un site ?

Ceci donc sans lui attribuer de date de fin non plus ?

[Richard_35]

Bonjour Appolonios,

Ton MCD tient la route, notamment en développant la partie n,n entre Site et Sensor.

Je peux gérer ça en cherchant les installations qui ont le champ InstEndDate NULL, mais ça ne me semble pas très propre ?
.../...
J'ai pensé à une autre option qui serait de considérer des entités-type ouvertureInstallation et fermetureInstallation (associés à Installation) d'un sur-type Evenement. (Ce sur-type pourrait aussi être parent d'intervention de maintenance, ou de modification du capteur).

==> ta chasse au bonhomme NULL va faire plaisir à Fsmrel !... De mon point de vue, seule une entité-type fermetureInstallation est nécessaire (à moins que crées des installations sans, au moins, une date de début) :

Installation_Fin(#instId, instEndDate, ...)

Mais le problème de l'ordonnancement reste le même. Faut-il gérer ça seulement au niveau des applications ?

==> nous n'y coupons pas... :

• une vue donnant Installation(instId, siteId #, sensorId #, instStartDate, instEndDate)
• trigger à chaque tentative d'ajout ou de modification d'une installation => instStartDate et instEndDate non compris entre des bornes existantes pour le même site.

[Edit] Bonjour à Punkoff dont l'intervention est venue se glisser avant la mienne [\Edit]

[Appolonios]

Re-bonjour,

Merci à vous deux pour vos réponses.
J'aurais besoin de quelques petites précisions :

notamment en développant la partie n,n entre Site et Sensor.

Il faut encore développer. Ou vous vouliez dire que que le n,n entre site et Sensor est respecté ?

ta chasse au bonhomme NULL va faire plaisir à Fsmrel !

Si ça peut faire plaisir, allons-y.

Dans ce cas, si j'ai bien compris, vous me proposez ce schéma :

Site (siteId, siteName, siteLong, siteLat, siteAlt)
Sensor(sensorId, sensorCapa, sensorVers)
Installation(instId, siteId #, sensorId #, instStartDate)
InstallationEnd(instId #, instEndDate,instReboot, instCom)
rawMeasurement ( rmDate, instId #, rmVal)

Pourquoi mettre instEndDate dans la clef primaire ? instId -> instEndDate puisque une installation (un capteur, sur un site, sur une période) ne se termine qu'une seule fois.

une vue donnant Installation(instId, siteId #, sensorId #, instStartDate, instEndDate)
trigger à chaque tentative d'ajout ou de modification d'une installation => instStartDate et instEndDate non compris entre des bornes existantes pour le même site.

Je ne suis pas familier avec les triggers et les vues. Je ne suis pas sûre de comprendre exactement ce que vous vouliez dire.
La "vue donnant Installation(instId, siteId #, sensorId #, instStartDate, instEndDate)" donne les installations terminée ou bien instEndDate peut-il être null ?
Dans les deux cas, j'ai l'impression de devoir faire 2 triggers. L'un pour les installations terminés, l'autre pour les installation en cours...

Bonjour,


Pouvez-vous, par avance, prévoir une future installation d'un capteur sur un site ?

Ceci donc sans lui attribuer de date de fin non plus ?

Non, les capteurs sont mis de façon un peu chaotique, en fonction des besoins et de la disponibilité.

[Richard_35]

Il faut encore développer. Ou vous vouliez dire que que le n,n entre site et Sensor est respecté ?

==> le n,n est bien respecté dans ton MCD : tu l'as correctement développé.

Pourquoi mettre instEndDate dans la clef primaire ? instId -> instEndDate puisque une installation (un capteur, sur un site, sur une période) ne se termine qu'une seule fois.

==> tu as parfaitement raison !... Donc :

InstallationEnd(instId #, instEndDate, ...)

instReboot, instCom ne sont renseignés que lors d'une EndDate ?

La "vue donnant Installation(instId, siteId #, sensorId #, instStartDate, instEndDate)" donne les installations terminée ou bien instEndDate peut-il être null ?

==> dans la vue, instEndDate peut être NULL car absent de la LEFT-jointure entre Installation et InstallationEnd (si NULL => 31/12/2500 arrangerait bien l'application). Mais, la valeur NULL n'est pas stockée dans une table (c'est ce que tu voulait éviter).

Dans les deux cas, j'ai l'impression de devoir faire 2 triggers. L'un pour les installations terminés, l'autre pour les installation en cours...

==> Oui, si tu gardes les deux tables. Non, si tu ne crées qu'une seule table.

[Appolonios]

Merci beaucoup pour ces précisions !

instReboot, instCom ne sont renseignés que lors d'une EndDate ?

Vous avez raison, il y a une erreur. instReboot est précisé lors de la mise en place du capteur. Le commentaire était plutôt prévu pour la fin. Mais on peut imaginer éventuellement deux commentaires, un au début et un à la fin qui correspondant aux deux passages de l'opérateur humain sur le site.

si NULL => 31/12/2500 arrangerait bien l'application

je dois manquer un peu d'expérience pour comprendre vraiment les problèmes que cela peut poser...

Pour valider, ce que je comprends du trigger, j'ai tenté un premier jet d'implémentation...

Pour la vue :

Code :

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

1
2
3
4
5
6
CREATE VIEW AllInstallation
SELECT *
FROM installation
LEFT JOIN installationEnd
ON installation.instId = installationEnd.instId

Pour le trigger, il faut tout de même distinguer les 2 cas : installation en cours / installation fermée, non ?
J'en profite aussi pour vérifier que la instStartDate < instEndDate.

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
CREATE OR REPLACE TRIGGER installDateCheck
  BEFORE INSERT OR UPDATE OF instStartDate, instEndDate ON AllInstallation
  FOR EACH ROW
  
  DECLARE
  beginEndOrder  EXCEPTION;
  ubiquity EXCEPTION;
  overlap NUMBER;
  
  IF (:NEW.instEndDate == NULL)
  	 /* On going installation */
	 SELECT COUNT(*) INTO overlap FROM 
		  (SELECT instId FROM InstallationClosed WHERE ( :NEW.instStartDate > instStartDate AND :NEW.instStartDate  < instEndDate)) 
		  IF overlap > 0 THEN
			 RAISE ubiquity;
		  END IF;
	  
  ELSE
	/* Closed installation */
	
	  IF (:NEW.instStartDate >  :NEW.instEndDate) THEN
			RAISE beginEndOrder;
	 END IF;
		  
		  SELECT COUNT(*) INTO overlap FROM 
		  (SELECT instId FROM InstallationClosed WHERE ( :NEW.instStartDate < instEndDate AND :NEW.instEndDate  > instStartDate)) 
		  IF overlap > 0 THEN
			 RAISE ubiquity;
		  END IF;
  END IF;
  
 
EXCEPTION
  WHEN beginEndOrder THEN
    Raise_application_error ("Fin de l'installation avec le debut");
  WHEN ubiquity THEN
	Raise_application_error ("Chevauchement des dates de l'installation avec un autre pour ce capteur sur ce site");
	
END;

J'espère que je n'écris pas trop de bêtises. En tout cas, merci de votre aide. J'avance avec plus de confiance

[Richard_35]

Mais on peut imaginer éventuellement deux commentaires, un au début et un à la fin qui correspondant aux deux passages de l'opérateur humain sur le site.

==> donc, nous avons :

Site(siteId, siteName, siteLong, siteLat, siteAlt)
Sensor(sensorId, sensorCapa, sensorVers)
Installation(instId, siteId #, sensorId #, instStartDate, instReboot, instCom)
InstallationEnd(instId #, instEndDate, instEndCom)
rawMeasurement(rmDate, instId #, rmVal)

si NULL => 31/12/2500 arrangerait bien l'application

je dois manquer un peu d'expérience pour comprendre vraiment les problèmes que cela peut poser...

==> eh bien, dans la vue, si l'on précise "si NULL => 31/12/2500" (via un CASE, sans doute), alors nous avons toujours des bornes de fins > aux bornes de début, sachant que, si la borne de fin est NULL, cela veut dire que le capteur est toujours installé (31/12/2500 veut dire "infini", en quelque sorte) : plus besoin de tester la valeur NULL dans le trigger.

Pour l'instant, le tout est de savoir si tu es OK sur le principe. Ensuite, il faudrait proposer ton code SQL sur le forum adéquat (SQL Server, MySQL, Access, ...).

*********************
Juste un aparté
*********************
Il y a deux écoles :
1°/

donnant :

Site(siteId, siteName, siteLong, siteLat, siteAlt)
Sensor(sensorId, sensorCapa, sensorVers)
Installation(instId, siteId #, sensorId #, instStartDate, instEndDate, instReboot, instCom, instEndCom)
rawMeasurement(rmDate, instId #, rmVal)

2°/

donnant :

Site(siteId, siteName, siteLong, siteLat, siteAlt)
Sensor(sensorId, sensorCapa, sensorVers)
Installation(instId, siteId #, sensorId #, instStartDate, instReboot, instCom)
InstallationEnd(instId #, instEndDate, instEndCom)
rawMeasurement(rmDate, instId #, rmVal)

Personnellement, je fixe le refus des NULL pour les clés étrangères, pas pour les autres attributs. Mais l'autre école possède toute légitimité, bien entendu.

[Appolonios]

Avec ces précisions je pense que tout est clair concernant le MCD. Pour la mise en place du trigger, je m'orienterai vers un autre forum si besoin.

Merci encore pour vos réponses. Bonne soirée !