Description de la base de données SWISSLOG


Pour travailler efficacement avec SWISSLOG, il est primordial de comprendre certains des concepts les plus importants de la base de données SWISSLOG. (Cette section couvre un peu plus la théorie du fonctionnement... OK, je sais que les radio-amateurs n'aiment pas lire – ils préfèrent parler – mais parfois comprendre la théorie de base aide beaucoup –, veuillez lire cette section. Mci de HB9BJS).

La  base de données SWLOG_V5.MDB est la base de données principale utilisée dans SWISSLOG. C'est une base de données relationnelle et elle contient un certain nombre de tables qui sont reliés entre elles. Les quatre tables les plus importantes sont indiquées dans le diagramme suivant:

e d t

Les six tables ci-dessus constituent le coeur du LOG de station pour SWISSLOG. Nous allons regarder de plus près comment un QSO est représenté dans ces tableaux – Toutefois, tout d'abord, nous allons analyser les trois éléments de base qui composent un QSO:

Maintenant voyons comment SWISSLOG représente ces éléments dans la base de données du LOG :

La table Callbook contient des informations sur la personne qui possède l'indicatif. Dans SWISSLOG, nous appelons ça la Station étant donné que d'autres entités, en plus des particuliers, peuvent avoir des indicatifs. La Station reste la même, indépendamment du QTH. Il n'y a qu'une seule entrée pour chaque Station (indicatif).  Par conséquent, toutes les infos étroitement liées à l'indicatif sont stockées dans la table Callbook. Par exemple:

La table PQTH contient des informations sur le QTH du partenaire. Il s'agit d'une table très importante parce que la plupart des diplomes sont basés sur le QTH de la station partenaire. Pour chaque station, il peut y avoir plusieurs données PQTH. En fait, il doit y avoir une donnée de PQTH pour chaque QTH différent d'où vous avez contacté la station partenaire.

De meme, la table de LOG a un lien :

Comme vous pouvez en juger, pour récupérer toutes les informations sur un QSO, vous avez besoin d'informations extraites de toutes les tables. Dans des bases de données relationnelles, il est facile de faire une "jonction" entre les tables pour extraire les informations relatives à un QSO spécifique.Il est également possible de définir des tables « virtuelles » (appelées vues) qui relient les champ dans les différentes tables et présentent l'information comme si c'était une table unique. Dans SWISSLOG,  deux vues sont définies et généralement vous allez travailler avec l'une de ces vues.

Cela peut paraître un peu malaisé ou confus à ce stade – un exemple facilitera  peut-être la compréhension...

l'exemple suivant montre quelques QSO que j'ai eu avec John, HB9JO – J'ai contacté John dans trois de ses différents QTH :

  1. Son QTH domicile à Genève
  2. Son  QTH de week-end à Bienne
  3. Et quand il était en France

Reportez-vous à la  table PQTH ci-dessous  – vous verrez trois entrées, une pour chacun  de ses QTH.

Lorsque j'ai contacté John la première fois, il m'a donné des informations personnelles relatives à son statut de radio-amateur, comme son nom, ses numéros Ten-Ten et DIG et quelques autres renseignements que j'ai mis dans le champ commentaires de la station. Cette information est figée et ne change pas lorsqu'il opère à partir d'un autre QTH. Et donc, les données sont stockées dans la table Callbook.

Moi-même, j' opère également depuis différents QTH. Si vous regardez les entrées dans la table MyConds, vous verrez quatre QTH différents, mais pour simplifier cet exemple, nous supposerons, que j'ai effectué tous les QSO avec John de mon QTH-Domicile.

J'ai utilisé une couleur différente pour désigner chaque QSO avec John depuis ses divers QTH . Vous pouvez voir que les QSO 3, 4, 6, et 7 ont été réalisés  lorsque John opérait de son QTH de week-end à Bienne. Les informations sur ce QTH, par exemple la région et le QTH Locator, ne sont stockées qu'une seule fois dans SWISSLOG, mais elles sont liées à ces QSO.

Question: Devinez ce qui se passe si je change un champ qui est contenu dans la table PQTH ?

Réponse : Le champ est modifié pour tous les QSO liés à cette donnée PQTH. Donc, si je modifie le QSO  numéro 4 et que je fais passer le QTH Locator de JN37OD à JN36OD, alors le QTH Locator est modifié pour tous les quatre QSO (numéro 3, 4, 6 et 7) parce qu'ils partagent toutes les informations pour la donnée QTH nommée JN37OD.

Si vous essayez de faire une telle modification, SWISSLOG vous demandera si vous souhaitez modifier la valeur, ou si vous voulez créer une nouvelle donnée PQTH pour John. Donc, si John opérait en portable depuis un QTH différent pour le QSO numéro 3 et que le QTH-locator est correct pour les QSO 4, 6 et 7 (JN37OD), vous devez ajouter une nouvelle entrée PQTH avec la valeur de QTH Locator JN36OD. SWISSLOG fera ensuite le lien entre le QSO numéro 3 et la nouvelle entrée.

Cela peut sembler trop compliqué et cependant, cela donne la souplesse nécessaire pour gérer les nombreuses situations pouvant survenir. Et l'intégrité de la base de données est toujours  préservée en ne liant  pas les données de façon erronée..

Callbook (Stations)
Call Name Ten-Ten DIG
DF1SD Kuno 99999 0381
HB9JO Jo 111111 4711
PQTH (Partner QTH Table)
QTH-Name QTH DXCC Region QTHLoc
HomeQTH Geneva HB9 GE JN36WF
JN37OD Biel HB9 BE JN37OD
/F France F 037 JN27ON
Logbook (QSO's)
QSONr Date/Time Band Mode RSTR
1 26.04.03 08:00 10m SSB 59
2 03.09.03 11:33 20m SSB 59
3 04.09.03 10:14 15m CW 599
4 07.09.03 15:06 20m SSB 59
5 10.09.03 20:11 40m SSB 58
6 11.09.03 23:27 15m CW 599
7 12.09.03 O9:57 20m SSB 59
8 22.09.03 10:22 20m SSB 59
MyQTH WCONDS EVENTS
MyQTH MyCall QTHLoc Rig Contest
HomeQTH HB9BJS JN47QA TS950  
Weekend HB9BJS JN46SU SB104  
OE9 OE9/HB9BJS JN47XD FR290  
H26 HB9BJS JN47KH TS950 H26

Copyright © 2004 SWISSLOG
Last modified:10 jul. 2018