Description of the SWISSLOG Database
To work efficiently with SWISSLOG it is very helpful to understand some of the more important concepts of the SWISSLOG database. (This section covers more of Theory of Operation... OK, I know Hams don't like to read – they prefer to talk – however sometimes understanding basic theory helps very much – so, please READ this section. Thx de HB9BJS).
The Logbook-DB is the main database used in SWISSLOG. It is a relational database and contains a number of tables which are linked together. The four most important tables are shown in the block diagram below:
The six tables shown above make up the core of the station log for SWISSLOG. Let's take a closer look how a QSO is represented in these tables – however, first we will analyze the three basic elements which make up a QSO:
Now lets see how SWISSLOG represents these elements in the Logbook database:
The Callbook table contains information about the person who owns the call sign. In SWISSLOG, we call this the Station because there are other entities besides individuals who can have callsigns. The Station remains the same independently of which QTH it works. There is exactly one entry for each Station (callsign). Therefore, all information closely linked to the callsign is stored in the Callbook table. For example:
- Name – However, note: the name of the Operator may be different because a guest may operate the Station
- Club memberships like DIG, DOK, Ten-Ten, etc.
- Comments describing the callsign owner
The PQTH table contains information about the QTH of the Partner. This is a very important table because most awards are based on the QTH of the partner station. For each station, there can be several PQTH entries. Actually, there must be a PQTH entry for each different QTH where you contacted the partner station.
Also, the Logbook table is linked to the following entries:
- In the MyQTH table which describes the QTH you are working from
- In the PQTH table which describes the QTH of your QSO Partner
- And in the Callbook table which describes the callsign owner
As you can appreciate, to retrieve all of the information about a QSO, you need information from all of the tables. In relational databases, it is easy to 'Join' tables to extract the information for a specific QSO. It is also possible to define 'virtual' tables (called views) which link together the entries in different tables and present the information as if it was a single table. In SWISSLOG, there are two defined views and generally you will be working with one of these views.
This may seem a bit awkward or confusing at this point – perhaps an example will make it easier to understand...
The following example shows a few QSO's I made with John, HB9JO – I worked John at three different QTH's:
Refer to the PQTH table below – you will see three entries, one for each of his QTH's.
When I first worked John, he provided some personal information related to
being a Ham, such as his name, his Ten-Ten and Dig numbers, and a few other
facts that I put in the station comment field. This information stays the same
and does not change when he operates from another QTH. Therefore, the data is
stored in the Callbook table.
Myself, I also work out of different QTH's. If you look at the entries in the MyConds table, you will see four different QTH's, however to make this example easier we will assume, that I had all QSO's with John from my Home QTH.
I have used a different color to designate each QSO's with
John at his different QTH's. You can see that QSO's 3, 4, 6, and 7 where made
when John was operating from his weekend QTH in Biel. The information about
this QTH for example the Region and the QTH-Locator are stored only once in
SWISSLOG, but they are linked to these QSO's.
Question: Guess what happens if I change a field which is contained in the
PQTH table?
Answer: The field is changed for all QSO's linked to this
PQTH entry. Therefore, if I edit QSO number 3 and change the QTH Locator from
JN37OD to JN36OD, then the QTH Locator is changed for all four QSO's (number
3, 4, 6, and 7) because they all share the information for the QTH entry named
JN37OD.
If you attempt to make a change like this, SWISSLOG will ask you if you want
to change the value or, do you want to create a new PQTH entry for John. So,
if John was operating portable at a different QTH for QSO number 3, and the
QTH Locator for QSO 4, 6, and 7 is correct (JN37OD) you would need to add a
new PQTH with a QTH Locator value of JN36OD. SWISSLOG will then link QSO
number 3 with the new entry.
By default, Swisslog handles this automatically and user don't need to worry about all this, creating new PQTH entries when needed. However, it's explained in case user enables the "Issue warning if a new QTH is needed" in the QSO Entry window (disabled by default), because SWISSLOG will prompt if you want to change the current PQTH entry or you want to add a new PQTH entry. Then you need to know all this in order to decide properly if you want to add a new QTH or change the existing one to apply this value in all QSOs with this station.
This may seem overly complicated, however it provides the flexibility necessary to handle many different situations that arise and still maintains the integrity of the database by not linking data incorrectly.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
Copyright © 2004 SWISSLOG
Last modified: 18 dic. 2022