next up previous contents
Next: Data retrieval Up: From Cards to Computer Previous: Relational database systems

Subsections

A revised system

It was decided at the outset that after the system had been in operation for a while, it would be reviewed. Many of the shortcomings gradually became clear as transcription got under way. The development of hardware and software technology (the appearance of 386 machines on the one hand and the Windows operating system with a graphical interface and a sort of multitasking capability) has meant that a revision was felt necessary earlier than the completion of the first 50 interviews.

Although the original system was designed to be flexible enough to work even with a completely different set of data - due to the fact that the operation of the program was controlled by data stored in easily editable tables - the radical change in the software environment meant that the whole data entry program had to be abandoned and rebuilt from scratch.

Redesigned data model

Although, the program has been given a completely different look and feel, more important is the way the data model was redesigned.

First of all, all the output data have now been brought to a consistent, uniform structure and are stored in a single file. In order to achieve this, the following changes were required:

1.
Consistent and unique identifiers have been assigned to language items.
Recall that the original system had very serious flaws in failing to distinguish inside the data files between slow and fast readings, between different variables using the same card etc. Now the whole scheme was converted to one where all the linguistic variables are numbered consistently whatever their source (module). This identifier, termed item here, now takes over the function of the card number reference. It replaces the card numbers but the link is kept in a table in the background so it will be possible to look up something by the card number reference, such as it is.
2.
Alphabetical types of responses have been converted into numerical code

This was a fairly trivial task. At the same time the consecutive numbering of responses to the same card was abolished.

3.
Remarks have been incorporated into data files

Notes by transcribers and checkers are now kept together with the responses in the same record. They are kept in a memo field whose length can grow or shrink as desired.

A sample of the revised output data file is displayed in Tables 4.1 and 4.2.


  

Kommentárja:
Kommentárja:
``Ja, hogy ban vagy ba                      
ja értem.''RA                      
B7103 40     RA             2., majd kétszer 1. RA
B7103 50 2   RA              
B7103 60 2   RA              
B7103 70 1   RA              
B7103 80 2   RA              
B7103 90 2   RA              
B7103 100 2   RA              
B7103 110 1   RA              

  Field name Description
1 Inf_ID Informant's ID
2 Item Unique identifier of the language variable
3 Ans Transcriber's coding of the response
4 Date Date of above
5 Tr_Name Transcriber's name
6 Ch1 Response value by first checker
7 Ch1_Name Name of first checker
8 Ch1_Date Date of first checking
9 Ch2 Response value by second checker
10 Ch2_Name Name of second checker
11 Ch2_Date Date of second checker
12 Note Notes by any three


The input data file for the data entry screen was also drastically redesigned. Earlier what was shown on the cards and the expected responses to a variable were rigidly controlled by the way the data was structured. A maximum of 9 alternatives was allowed per card.

The major innovation here was to break this rigid mould and separate the invariant card header information from the alternatives. Accordingly, a separate table was set up to store the prompt skeleton inormation. This table called PROMTS, stores two further pieces of data: 1) the physical card number, to maintain the link with the old reference system and 2) a field called STATUSto indicate whether the variable is explicitely focused on (primary variable) or not (secondary variable). The structure of the PROMPTS table is shown in Tables 4.3 and 4.4.


  

  
Table 4.4: The structure of the Prompts table Table 4.3: The contents of the Prompts table
Item Card_No Stat S1 S2
10 1601 2 Ebben a ............... jól nézel ki.  
20 1701 2 Ebben a ............... jól nézel ki.  
30 1802 1 ............. igazad van, mint legtöbbször.  
40 1903 2 Mari ....... egy ingemet tegnap.  

  Field name Description
1 Item The unique ID number of the variable
2 S2 Optional second line of the prompt on the card
3 Card_No The old card number reference
4 Status The primary or secondary status of the variable
5 S1 First line of the prompt on the card


Anticipated possible responses are now stored in a table called OPTIONS. Its structure is displayed in Tables 4.5 and 4.6.


  

  
Table 4.6: The structure of the Options table Table 4.5: Contents of Options table
Item Order Option Value
10 10 ebben 1
10 20 ebbe 2
20 10 farmerben 1
20 20 farmerbe 2
20 30 farmerban 3
20 40 farmerba 4
30 10 természetesen 1
30 20 természetes hogy 2
30 30 természetesen hogy 3
30 40 természetesen 4

  Field name Description
1 Item The unique ID number of the variable
2 Order Sequence number of alternatives
3 Option Form of the anticipated alternative
4 Value Numerical code of the alternative


Each alternative is put in a separate record. This meant we didn't have to impose any artificial ceiling on the maximum number of alternatives. As each alternative carried the newly redesigned item reference number, they could be unambiguously attributed to the item they belonged to and the number of alternatives could be arbitrarily large or small. This simple but most powerful device, the central idea behind relational database systems, is illustrated in Figure 4.1. The arrows show how the records are linked by the identical content of a shared key field, ITEM.


  
Figure 4.1: Linking the PROMPT and the OPTIONS tables
4#4

The overall design of all the datafiles are displayed in Figure 4.2. In addition to the three central tables discussed so far it shows some auxiliary tables to store data about tape counter settings MAGNO, informants AKLISTA and transcribers LEJEGYZO, respectively.


  
Figure 4.2: The linking of data tables in the revised system
5#5

The graphical user interface

The revised data model allows a much simplified controlling program. Gone is the need to juggle with a number of different files as there are practically only the three tables above each stored in a single file. The windowing environment means that the transcription and the coding of the data could be done simultaneously in separate windows. The rest of the menu functions in the earlier system have been incorporated in the data entry screen which allows the user to choose between transcribing, first or second checking of data (lejegyzo `transcriber', 1. ellenor , `1st checker' and 2. ellenor , `2st checker' options). Also, there is an additional facility to revise one's own work (Bevitel , `data entry', vs. Javìtás options). Depending on what function is selected, the card next in line for that operation is displayed on the screen (i. e. if the transcriber and data entry buttons are selected, the screen will show the first card in row which is not yet transcribed from the given informant.) However, with the help of the vertical row of navigation buttons one go back and forward, jump to the top or the bottom of the cards available for processing for the given operation. In addition, a given item may be jumped to directly by selecting its number in the drop-down window situated in the middle of the top row of small windows.


  
Figure 4.3: The revised data entry screen
6#6


next up previous contents
Next: Data retrieval Up: From Cards to Computer Previous: Relational database systems
Tamás Váradi
12/26/1997