Data Dictionary

This section describes the various domains (fields) in the relations, their uses and the rules for their contents. The following general rules apply to all the domains:

• A '?' in any of the domains indicates that the information appropriate to that domain has not been entered. Hopefully the number of these entries will reduced as more work is done on the database.

Note that some domains are purely Factual, others are Subjective and some are a Combination of the two. The following descriptions indicate into which of these categories each domain falls, together with the type (string, integer etc.) of that domain.

This section is intended to provide some rules to guide both me as I add to the database and any of you who may wish to modify it. To be explicit as explicit as possible I have defined some terms which most dancers will consider very basic. The upshot of this is that unless you are modifying the database, or you want to check on the way I have used a particular term and what it means, there is no more for you to read.

bars		Factual	Numeric
This is a numeric field giving the number of bars of the specified type of music required for one time through the dance. Typical values are multiples of 8, though some dances do use unusual numbers of bars. The most common values are 32 and 48.
comments		Factual	Text
This field, which appears in the dances relation, is intended for short comments giving important information about the dance. It is not free format, but is restricted to a combination of the following strings, separated by commas. Longer, free format comments are catered for by the comments relation. The valid strings are:
	double progression	This is used where there is a double progression in a longways set, which are normally assumed to involve a single progression.
	single progression	This is the default case for longways sets, and is normally assumed. This string is only used to distinguish between two versions of the same dance, one with a single progression and one with a multiple progression. This is not strictly necessary - the same information could be given by leaving the comments field blank, but this ensures that the distinction is explicit.
couples		Factual	Text
This field does not appear in the main relations, where a code is used to represent the number of couples. Instead this text field appears in a special relation which allows the code to be presented in a more understandable form when generating reports. Where there is a fixed number of couples in each set this field is simply a number. Where there is no limit on the number of couples in each set this is indicated by n. In some dances (for example a Sicilian circle), there is no limit on how many couples, provided there is an even number. This is indicated by 2n and so on. Others such as solo dances have some other appropriate message.
couple_code		Factual	Numeric
This is the couple coding used in the main relations. It contains a key into the couples relation and is used to indicate the number of couples in each set. Since this database contains some dances that are based around individuals rather than couples (e.g. Horses Brawl), the extra relation is used to allow the use of a simple, rapidly searched key, whilst providing the option of a clear textual output. The numeric codes have been chosen in a (mnemonic) relation to the formation they represent. For example, all threesome dances are in the minus three hundreds, while a dance for 8, 9 or 10 couples would be coded as -890, and one for 6, 8 or 10 couples would be coded as -680. As a result of this choice the codes are not continuous, and the only valid entries for this domain are those in the couple_code domain of the couples relation.
dance_different		Factual	Numeric
This domain is used for housekeeping within the database and bears no relation to anything in the outside world. Consequently it is not sensible to include it in output from the database. Although the dance_name is used as the main key when combining relations, problems arise due to the fact that there are several totally different dances with identical names. Consequently the dance_name is not sufficient to ensure a correct mapping from say dance to source. To get around this this dance_different domain is introduced. It is simply used to ensure that the combination of dance_name and dance_different is unique for every different dance. In particular it does not imply that two dances of the same name are slightly different versions of one another.
dance_name		Factual	Text
This contains the name of the dance. It is the main key field when combining relations. The text for this field is taken directly from the printed source for the entry, with the following exceptions: Prefixes such as a, the, le, la, les are moved to the end of the name and separated from the rest of the name by a comma and a space. Thus, The Phoenix becomes Phoenix, The. This allows simple alphabetic sorting on the important section of the name and also caters for the way some publications tend to drop these words. The first character of every word is capitalised. All other characters are lower case. The exception to this are words which appear to be abbreviations. Thus O.A.T.A. REEL (which is how it appears in the book), is entered as O.A.T.A. Reel.
dance_type		Combination	Text
This field describes the type of the dance. It consists of a combination of factual and subjective information. It is factual in so far as an contra dance is definitely not a new England Square dance. Equally, it is subjective in that you may not agree with my definition of a contra as opposed to one of the English village longways sets. The legal values for this field are given in dance types appendix, and to help you interpret this field the appendix also describes some of the rules which have governed our categorisation.
dance_version		Factual	Numeric
This is similar in use to dance_different, except that instead of being used to distinguish between totally different dances with the same name, it is used to distinguish between slightly different versions of what is basically the same dance.
formation		Factual	Text
This domain gives the name of the formation. It is not used in the main tables, where a code representing each formation is used for efficiency. This textual representation is presented in another relation so that it may be used when generating reports. To make it clear what the naming scheme we have used means, a detailed description of each formation is given in the formations appendix.
formation_code		Factual	Numeric
This field contains the code used as a key into the formations relation and is used as a concise way of encoding the formation used in a dance. It is used in a similar fashion to couple_code and was introduced for similar reasons.
level		Highly Subjective	Numeric
This is my estimate of the difficulty of the dance. It is merely an impression! I have not attempted to employ an objective measure such as the piece counts used by Larry Jennings in Zesty Contras. Piece counts may be added at a later stage. The difficulty of the dance is expressed on a scale of 0 to 9. 0 is easy, 9 is a brain bender. I used the descriptions given in the dance level appendix as a guide when assigning the values in this domain.
location		Factual	Text
This field describes where within a particular source this dance may be found. Since some dance books give a number to each dance, while others use page numbers, we have used a prefix to indicate what is actually meant. If the source does not provide any form of numbering, this field is left blank. The entries may be of the following forms:
	px	The dance is to be found on page number x.
	nx	The dance is numbered as x in the book.
music_name		Factual	Text
The name of a piece of music. The rules for the format of this name are exactly the same as those for dance_name, as described earlier.
music_type		Combination	Text
This indicates the type of music that the source suggests should be used for this dance: this is the factual aspect. If the source makes no suggestion I have included one which I think is appropriate: this is the subjective part. In some cases several types of music are appropriate, and the decision about the most suitable type depends on the type of dancers for the event. The valid entries for this field are:
	reel	A reel is a tune in 2/4, 4/4 or rarely 6/4 time. Reels tend to feel faster than jigs, and do not have as much 'bounce'.
	American reel	The distinction between a reel and an American reel is highly subjective. Indeed American reel is probably totally the wrong term. In Britain, we tend to use it to mean reels which feel fast because they have lots of notes crammed into them, and which may not be as clearly phrased as other reels.
	jig	A lively tune in 6/8 or 12/8 time. Due to the nature of their beat, jigs tend to lead the dancers into using a much more 'bouncy' step.
source_name		Factual	Text
This field provides a key to a source publication. It is basically the name of the book, and so can be used as textual output, but it can also be used as a key into another relation which gives a prettier version of the source name, or it can be used as a key for a BiBTeX database, to produce a full, detailed bibliography. The values for this field are the title of the source, converted to lower case, with all punctuation replaced by spaces. Multiple spaces are then condensed into a single space and the remaining spaces are replaced with underline characters. The only exception to this is the single apostrophe, which is simply removed, since this leads to a more 'natural' result. Thus Down Back O't Shoddy becomes down_back_ot_shoddy and Barn Dancin' 'n Country Dancin' becomes barn_dancin_n_country_dancin.