|
Nova Scotia's
Geographic Information
Standards
Chapter 7
Linkage
(Continued)
7.3 Topic:
Corporate Code Identifiers - Rationale and Guidelines
7.3.1 Background:
The material within this section provides the reader with an overview as to how databases may be
developed. It also gives an overview on how specific standards codes were selected.
The Standards development process has attempted to provide a standard set of corporate code
identifiers for a variety of geographic entities. Entities in this list include administrative Reporting
Regions, Counties, and Municipalities. Over time, this list will grow to include such entities as
Communities, etc. For background information and formal standards material related to each of these
entities please refer to the appropriate section.
7.3.2 Database Development Guidelines [Endnote 1]:
The development guidelines provided below are intended to assist database providers when creating
spatially referenced corporate databases. Good database development requires good database
planning. When a database is being created one of the more important questions to ask is who,
besides yourself, will be accessing the data. The more activity surrounding a given database(s), the
more critical it is to have consistency between it and other databases. To facilitate use and to avoid
duplication, databases should be created as corporate resources -- created once, used many times.
7.3.2.1 Field Names, Type and Size:
Database design consistency is often thought of in terms of the content of the database. Spelling,
coding, capitals vs lower case letters, are all important design considerations, as will be noted in the
next section. Equally important, however, is the field name associated with the data. Whether a
series of databases are being designed by one person or by many people, good database design
requires all field names to be unique. Some common problems in database design include:
- fields with the same name but different meaning
- fields with different names but the same meaning
- fields with the same name and meaning but different formats
or coding rules
Table 7.3.2.1 outlines the format guidelines for field name, type and size for corporate data.
7.3.2.2 Field Content:
As mentioned above the content of a database is also critical to its ease of application. For example,
have you ever tried searching a database in which you know the data exists, only to have the software
tell you that there was no data found ? Most likely the unsuccessful search was a result of spelling
errors in the search string or a simple matter of case sensitivity.
Table 7.3.2.1
Guidelines for Database Modelling
|
Field Name
(not to be any more than 10 characters in length)
|
Field Type
|
Field Size
|
Definition / Comments
|
|
RPT_RG_N
|
Character
|
15
|
Field for storing the full name of the Reporting Region. Reporting Regions were developed by the
Priorities and Planning Secretariat.
|
|
RPT_RG_CD
|
Character
|
2
|
Field for storing the 2 character Reporting Region codes.
|
|
COUNTY_N
|
Character
|
20
|
Field for storing the full name of the County
|
|
COUNTY_CD
|
Character
|
2
|
Field for storing the 2 character County codes
|
|
MUN_N
|
Character
|
45
|
Field for storing the full name of the Municipality
|
|
MUN_CD
|
Character
|
2
|
Field for storing the 2 character Municipal Code
|
Spelling errors are, no matter how much we want to believe otherwise, a fact of life. Yes there are
steps a database developer can take to prevent spelling errors within the database, but preventing
users from making spelling errors is a virtual impossibility. To assist database developers in their
quest for better data, the standards process has provided a standard set of names for entities such as
county and municipality.
Case sensitivity issues can be easier to deal with. A database administrator can make the content of
the database all upper case, all lowercase or a combination of the two. Within the confines of a single
database case is not usually an issue. However, when comparing its content with that of another
database, case becomes a problem. It is recommended that the coded entities (not necessarily
restricted to those in Table 7.3.2.1) should be UPPER CASE. Input and output routines can be
used to make the database more "user friendly".
7.3.3 Coding Rationale for Reporting Regions, Counties and Municipalities:
7.3.3.1 Standard Names [Endnote 2]:
As a part of the standards development process, the following agencies have provided the standard
names for the geographic entities Reporting Region, County, and Municipality, respectively:
|
Reporting Region
|
- Priorities and Planning Secretariat
|
|
County
|
- Department of Municipal Affairs, Municipal Services Division
|
|
Municipality
|
- Department of Municipal Affairs, Municipal Services Division
|
7.3.3.2 Standard Codes - Guiding Principles:
The codes associated with the geographic entities Reporting Region, County and Municipality are
based upon a two character alphanumeric. In determining a coding structure for these entities a
number of factors were considered [Endnote 3]:
- Shareability - the structure of the code must ensure that the associated
information is useable by more than one database.
- Exchangeability - allows the application of the code in one system and yet
also ensures it is understandable by other systems.
- Expandability - because a coding system cannot cover all possible levels of
detail, the codes have to be flexible. Expandability therefore refers to the ability to have other codes
added to the existing standard and still maintain the integrity of the standard.
- Storage (compact) - the coding system should not place unnecessary
demands on storage.. For example implementing a code based upon 3 alphanumeric characters require
1.5 times the storage as does a code based upon two alphanumeric characters.
- Reliability / Integrity - the coding structure has to be reliable at all levels of
data capture.
- Simplistic (Self Verification, Intuitive, Understandable, Key punch ease) -
codes must be structured so as to allow operators a level of understanding when applying the codes.
If necessary such codes should be able to stand on their own and be legible by users in other agencies
without special translation.
- Changeability - refers more to maintenance of the code. As entities change
there must be sufficient flexibility to change the code and still adhere to the other guiding
principles.
- Conversion Effort - this relates to the need for agencies to migrate to the
standard. While it is understood that some agencies have a great deal invested in existing systems,
it is these same systems that have generated an interest in the standard, therefore over time the older
systems will need to migrate to the standard.
7.3.3.3 Standard Codes - Rules for Code Selection:
In generating the two character alphanumeric codes for Reporting Regions, Counties, and
Municipalities a number of rules were followed. They are as follows:
-
All codes within a given entity type are to be unique.
-
Codes are to be based upon the primary name for the entity. i.e. The terms town, municipality,
district, or county would not be referenced in the coding scheme.
-
Single word entities - whenever possible, the first two characters of the entity are to be used as the
code. Exceptions include (a) if there are two entities with the same first two characters, the code
would still use the first character, but the second character would be the next logical / intuitive letter
in the entity's name. For example, Halifax County and Hants County. HA would not be an
acceptable code as it would not provide distinction to either entity.
-
Two word entities - whenever possible, the first letter of each word make up the code.
-
When a rural or regional municipality has the same name as the county, the code will be the same for
each. [This is permitted because in a database, each entity type will be stored in separate fields.]
-
When two municipalities have the same primary name (For example, Municipality of the County of
Antigonish and Town of Antigonish) the code will contain the first character plus the next unique
character (in terms of character selection, the rural municipality takes precedence over the town).
NOTE: The rules above hold for codes established as of April 1996. In the event that
a new municipality is created after a town has been coded, the original codes must remain in tact. A
new code will be assigned to the new entity and as a result a number of the above mentioned "rules"
will not apply to the new entity.
Chapter 7 continued -
[Sections 7.0 to 7.2]
[Sections 7.4 to 7.5]
[Sections 7.6]
Endnotes:
(1) There are many good books specifically dedicated to the issue of database design. The material
here is not intended to replace such text, only to draw the attention of the reader to the need for care
in all aspects of database development.
(2) Given that the Nova Scotia Gazetteer is based upon a federal model, the Standard Names applied
to the entities County and Municipality do not necessarily correspond to those found in the Gazetteer.
Rather the standard names are based upon information found in provincial statute.
(3) The justifications for the two character code are not presented in any particular order.
 Chapter Seven Table of Contents
|
