You are on page 1of 21

Draft

Department of Infrastucture, Planning and


Natural Resources
Natural Resource Information Systems

Data Model
Naming Conventions
Information Management Framework (IMF)
IMP02/10.1.3 Data quality assurance and management standard

IMF704

May 2003

Reviewers
Name

Role

Jane Deller-Smith

SIP Project Representative

Ray Boyton

Data Custodian Representative

Trev Mount

Data Administrator Representative

Ron Paynter

IT Reviewer

Anne Bell

Editorial Reviewer

Signature

Date

Signature

Date

Regional Reviewer
Andrew Man

DBA Reviewer

Tony Shields

Peer Reviewer

Project approvals
Name

Role
GM, Natural Resource Information Systems
GM, Information Management &
Technology (Chief Information Officer)
Group GM, Natural Resource Products

Audience
Role

Responsibility

Data Manager

Manages and maintains the final model

Data Administrator

Reviews and maintains this document. Maintains these standards for the Department
and validates any logical model against these

Application Developer

Ensures these conventions are followed during the development and documentation of
databases
Recommends improvements to Data Administrator

Operational Data Custodian

Recommends to Executive Data Custodian adoption of data model once developed

Executive Data Custodian

Approves adoption of data model

Data Base Administrator

Ensures these standards meet the technical specifications of the current Database
Management System.

Related documents
Document Name

Location

Data modelling procedures

http://imf.dsnr/binarydata/IMF705.doc

History
Version

Date

Author-Editor(s)

Notes

v1 d1

20 May 2003

Adrian Richardson

V1d3

12 June 2003

Adrian Richardson

Changes after feedback from Ron Paynter, Andrew Man, Olga


Jouklova

V1d4

16 June 2003

Anne Bell

Proofed and read document as final draft

File details
Filename

Data Model Naming and Display Conventions

File server location

\\PAR01\DATA1\GROUP\IMTIIC\CORPORAT\IMT\COORD\NRIS\Projects\SIP\10.1_Dat
a_Management\10.1.3 Data Quality Assurance\Information Management
Framework\Guidelines and Templates\IMF704_DatModNaming_v1d4.DOC

Online location

http://imf.dsnr/binarydata/IMF704.doc

Draft

Document Release Information

ABOUT THIS DOCUMENT................................................................................................................... 4


PURPOSE................................................................................................................................. 4
SCOPE...................................................................................................................................... 4
WHAT IS A DATA MODEL ....................................................................................................... 4
NAMING CONVENTIONS ........................................................................................................ 5
The need for naming conventions ................................................................................ 5
Naming conventions are evolutionary........................................................................... 5
Logical vs Physical Data Model names ........................................................................ 5
Logical Data Models ..................................................................................................... 5
Physical Data Models ................................................................................................... 6
GENERAL GUIDELINES:..................................................................................................................... 7
ENTITY NAME .......................................................................................................................... 7
DEFINING AN ATTRIBUTE.................................................................................................................. 8
1.

ATTRIBUTE NAME....................................................................................................... 8

2.

DATA TYPE .................................................................................................................. 9

3.

FIELD LENGTH ............................................................................................................ 9

4.

DATA INTEGRITY CONTROLS ................................................................................... 9

5.

DEFINITION................................................................................................................ 10
Definition Conventions ................................................................................................ 10

PHYSICAL MODELS .......................................................................................................................... 12


PHYSICAL DATA MODEL NAMES ........................................................................................ 12
Changing Entities to Table names.............................................................................. 12
ABBREVIATIONS ................................................................................................................... 13
REFERENCES:................................................................................................................................... 14
ATTACHMENT A: ABBREVIATIONS................................................................................................ 15
ATTACHMENT B: ORACLE BUILT-IN DATA TYPES ...................................................................... 17
ATTACHMENT C: ATTRIBUTES FOR DATA MODELS................................................................... 18
ATTACHMENT D: STANDARD CLASS PHRASES.......................................................................... 21

Draft

Contents

DIPNR

Data model naming conventions

Purpose
The following are conventions for creating consistent data models. These conventions will be used
during development of all databases and as a basis for validation and approval.
Creation of precise, logical names for the corporate data language is essential to the success of any
corporately motivated data management. This document presents a convention for naming system
components that is precise, logical and conforms with DIPNRs application development and
information management methodologies. Techniques described are used throughout the industry.
Where possible these conventions have been derived from established departmental practice. When a
discrepancy was found the convention was based on recognised best practice.

Scope
These conventions will ensure consistency within the department for data models and the integration
of databases.
Some knowledge of data model definition, use and creation has been assumed. The processes needed
to create a data model, both logical and physical modelling, including normalisation, is dealt with in a
number of texts and will not be reproduced here.
An Operational Data Custodian (ODC) initiates the data modelling process, like any business system
improvement. However, in order to maintain a corporate standard the conventions for adherence are
maintained by the Corporate Data Administrator (CDA). Both of these positions are required to
approve the logical data model. The Database Administrator (DBA) then approves the physical
implementation.
Data models should be easy to understand, faster and easier to produce than program code and allow
effective data and database management to be carried out.
These naming conventions are relevant for all types of data models, both textual and spatial.

What is a Data Model


Like all Metadata, a data model describes data and how it is organised. The data model influences the
structures of programs that deal with data (such as storage, update, query, reporting, analysis and
display functions). So, a well designed data model will have practical consequences in making data
management simpler and cheaper.
Evaluation criteria relevant to this document are:
1. Data Re-usability, as the model needs to allow data to be used for purposes beyond those for
which the data was initially collected.
2. Stability and Flexibility, as the model has to be generic and flexible enough to cope with
change. A model is stable if it does not need to be modified in the event of a change in
requirements. A model is flexible if it can be readily extended to accommodate new
requirements.

IMF704_DatModNaming_v1d4.DOC

Page 4 of 21

Draft

About this document

DIPNR

Data model naming conventions

These criteria are taken from the Australian National Groundwater Data Transfer Standard

Naming conventions
The need for naming conventions
The size of the department, its applications and the high degree of information exchange between
business areas dictates the need for highly organised systems development. The names used to identify
facts about objects, concepts and events are critical to the general understanding and knowledge of
staff. Using good naming standards that are easy to follow, systems designers can produce products
that do not introduce ambiguity or misunderstanding into the business. Without adherence to naming
conventions, confusion is created. Standard naming conventions provide a platform to ensure data
sharing and consistency within the organisation. It improves communications for both developers and
users.
Variations in the use of the NUMBER Class (see Class Phrase for definition)
CLASS ABBREVIATION
_NO
_NUM

Used by
SALIS, LAS, GDS, Native
Vegetation, HYDSYS*, EDB
EDB A-spatial core.

* HYDSIS does not always use an underscore. Eg SECTNO instead of SECT_NO

Naming conventions are evolutionary


The naming standards outlined in this guide will continue to evolve and change. There exist many
table and column names that do not conform to the current standard. It is expected that all new
developments within DIPNR will comply, or will need to document reason for non-compliance.

Logical vs Physical Data Model names


For a more complete discussion on the differences between Logical and Physical Data Models, refer to
Data Modelling Procedures (IMF705).

Logical Data Models


The Logical Data Model (LDM) visually represents the data needed satisfy business requirements and
shows how entities both within and outside this environment relate. The LD is created without any
specific computer environment in mind. No optimisation for performance, data storage or even
application development is done (nor is desired). The intent is to produce a purely logical view of the
data required by the business area.
Logical model names are likewise not concerned with physical storage restriction, so can be any
length with no need for abbreviation. This adds clarity to the information we are trying to represent.
A Logical Data Model is made up of:

IMF704_DatModNaming_v1d4.DOC

Page 5 of 21

Draft

3. Simplicity and Elegance, in that the data model provides a reasonably natural classification of
data. Elegant models are inherently simple, consistent and easily described and summarised.
4. Communication Effectiveness, because the model has to be an effective communication tool for
data management.

DIPNR

Logical Entity Relationship Diagram (ERD)


Data Dictionary definitions

The basic elements of a Logical ERD are shown below. Entity and Attributes are described in more
detail in this document.
Relationship
Entity

ENTITY_NAME1
PRIMARY_KEY

ENTITY_NAME2
PRIMARY_KEY

Identifier

Attribute 1
Attribute 2

Attribute 1
Attribute 2

Attribute

Physical Data Models


The purpose of the physical data model is to show how the data elements will be implemented and
stored on the database. Physical models may vary from the logical model in that the physical model
may introduce objects that do not contribute to meeting the business requirements of the application.
These new objects may be created in order to speed response times, reduce storage requirements,
ensure that the application fits within the physical limitations of the computing environment, improve
maintenance turnaround, or for other reasons.
Physical model names are restricted to physical storage limits so some abbreviation and ingenuity is
required when translating logical model names to physical model names. Some restrictions from the
logical model rules still apply, e.g., table names, like entity names, must be unique throughout the
department.
There is a slight variation in terminology between Logical and Physical Data models. This includes:

Logical ER Data Model

UML Model

Physical Data model

Entity

Object

Table

Attribute

Class

Column

IMF704_DatModNaming_v1d4.DOC

Page 6 of 21

Draft

Data model naming conventions

DIPNR

Data model naming conventions

There are some general for name creation.


Note: As the corporate Database Management System (DBMS) is already known to be Oracle for
DIPNR, some of the restrictions of the Oracle DBMS have been factored into the naming conventions,
e.g., avoiding Oracle Reserve words.

Entity Name
Entity names have the following characteristics:
1. An Entity name should come from the entity description, which has meaning to the user
community.
2. Should be a noun, singular and current tense.
3. Written in upper case.
4. Where necessary, underscores should join the words.
5. Where possible, avoid using the organisations name as part of the table name, e.g.,
DLWC_ROLES as this may become outdated. However, this may not always be practical as in
some cases, there may be a need to distinguish between tables replicated from external data
sources and those where additional attributes have been added to meet local requirements.
6. For physical implementation, Entity Names can have a maximum of 44 characters.
7. Names for the entities must be meaningful and must not conflict with other entity names. Where
abbreviations are used, the full words must be obvious.
8. Should be unique with no two entity types within the agency having the same name.

IMF704_DatModNaming_v1d4.DOC

Page 7 of 21

Draft

General Guidelines:

DIPNR

Data model naming conventions

An attribute should have:

Attribute Name

Data Type

Field Length

Data Integrity Controls

Definition

Data Type

Field Length

Data Integrity Controls

Definition

1. Attribute Name
Attribute Name

Attribute names have the following characteristics:


1. Attribute names should be in upper case.
2. Where necessary, underscores should join the words.
3. Should be unique with no two attributes of an entity type having the same name. Attributes of
different entities can have the same name and definition.
4. Similar attributes should use the class phases.
5. When creating attribute names in Oracle, you need to be aware that some words are reserved
and have special functions in the DBMS. A list of these can be found at:
http://otn.oracle.co.kr/docs/oracle78/precomp1x/LGPAD/apd.htm
The following process should be used for deriving a full name for an attribute. Once an attribute is
named, the abbreviation process should be used to develop shorter names where necessary.

Attribute Composition
Attribute names are composed of three constituents: prime words, class phrases and qualifiers.
PRIME_WORD|_CLASS_PHRASE| _Qualifying_Number
Examples:

ADDRESS_ID (PRIME_WORD|_CLASS_PHRASE)
ADDRESS_LINE_1 (PRIME_WORD|_CLASS_PHRASE| _Qualifying_Number)

Prime_Words:
Are a noun or noun phrase which describes the subject and main focus of the name, such as
VALID or ROLE.
May be the Entity Name with which the attribute is associated.
Describe the subject area of the data.
Place data elements within the logical context of the information model.
Examples: Address, Property, Unit, Division, Street, Birth, Pay, Opening_method, Licence
Class Phrases:
An Optional word from a list defined by the agency as the permissible characteristics of
entities. (See Attachment D for the list of standard class phases).
Identify a distinct category or classification of data.
Describe the major classification of data associated with a data element.

IMF704_DatModNaming_v1d4.DOC

Page 8 of 21

Draft

Defining an Attribute

DIPNR

Class phrases can also be Prime words, depend on context but you would not use the same
Prime and Class word for an attribute, e.g., Address_Address

Examples: _Type, _Name, _Date, _ID, _Number


Qualifying Number:
Used when the same Prime_word and Class_Phase is essential.
Differentiates between by adding a number.
This is an alternative to the common Qualifier before the prime number, which for the
examples below would instead have Prime_Address_Line, Secondary_Address_Line.
Examples: Address_Line_1, Address_Line_2

2. Data Type
Attribute Name

Data Type

Field Length

Data Integrity Controls

Definition

Attachment B lists the most common Oracle Data types.


Data Types define the type of data to be stored in a particular column. Types of data include:

Character (alphanumeric)
Numeric
Date

Different data types have different functions and will allow the data placed in them to be manipulated
in different ways.
Some data types have special manipulation capabilities (e.g., the DATE data type showed true data
arithmetic) and which only works on comparisons of the same data types.

3. Field Length
Attribute Name

Data Type

Field Length

Data Integrity Controls

Definition

A field length is the maximum length a field can be.


This has an impact on the physical implementation of a database as it will impact on the size.

4. Data Integrity Controls


Attribute Name

Data Type

Field Length

Data Integrity Controls

Definition

The following should be decided:


Null value control: if the value is a Null or Not Null.
Range control: limits the set of permissible values an attribute may assume. This can either be a
list of permissible values (domain), or if a numeric data type the lower to upper range.

IMF704_DatModNaming_v1d4.DOC

Page 9 of 21

Draft

Data model naming conventions

DIPNR

Referential integrity: is a form of range control where the list of permissible values is an attribute
of another table. This guarantees a value is cross-referenced but does not mean the value selected
is the correct one.

5. Definition
Attribute Name

Data Type

Field Length

Data Integrity Controls

Definition

Entity type and attribute definitions should clearly describe what business information they record,
using:
precision - they resolve ambiguities and qualify imprecise terms.
completeness - all terms are defined.
clarity - plain English, few if any buzzwords and jargon.
brevity - brief and to the point.
compatibility - with other definitions.
It should clearly state:
What the attribute is in terms of its business use.
What is included and not included.
Any aliases or alternative names for the attribute can be specified in the definition.
The source of values/domain if referential integrity has been used.
Example Good Definition
CLIENT Any individual or
organisation that is dealing, has
dealt, or plans to deal with the
Department.

Example - Bad Definition


CLIENT - A departmental client.

Definition Conventions

Nouns: The first sentence of the definition should give a noun or group of nouns, with modifying
adjectives or phrases that summarise the meaning of the entity.
e.g., an Employee is any person, alive or dead, who works or has worked, for the company.

Use examples: Typical examples should be included. The example should solidly reinforce the
readers understanding and reveal the bounds of the entity. This requires anticipating values
(instances) where there may be confusion for the reader. An example of a value (instance) which is
not a valid member of the group is also useful in showing the boundary from the other side. Often
wording that explains why examples are, or are not, included is necessary. The definition should
include a clear explanation of why these examples are or are not entities.
e.g., as soon as a person becomes a candidate for a position in the company, they become an
Employee whose status is un-hired. This allows personal information to be entered only once.
Applicants who are not considered for a position are not Employees.

Intent: Where possible the intent of the entity should be shown. This allows the reader to
understand the rationale for the entity and fit their own understanding of the business into the one
represented by this entity.

IMF704_DatModNaming_v1d4.DOC

Page 10 of 21

Draft

Data model naming conventions

DIPNR

Data model naming conventions

Differentiation: Where there may be confusion between two similar entities, either because their
names are similar or because their descriptions or relationships are similar, there should be explicit
text which that the difference.
e.g., the Worker entity may be confused with the Employee entity. The Worker entity is used to
collect information about clients who are supported in the work they do.

IMF704_DatModNaming_v1d4.DOC

Page 11 of 21

Draft

e.g., the intent of the Employee entity is to capture any information about a person the company
deals with in an employee-employer relation. This includes personal information, tax and statute
information and skills and capabilities. Information relating to contracted individuals is kept with
the client entity.

DIPNR

Data model naming conventions

Physical Data Model Names


These names need to fit into the conventions set by the DBMS. At this point some abbreviation may
need to occur. A simple procedure for abbreviation is shown below, a standard list of abbreviations are
included in Attachment A.
Example: Differences between Logical and Physical model names

Logical Model Name

Physical Model Name

ROLE

SA_ROLE

ROLE_GENERATION_DATE

ROLE_GNRTN_DATE

Changing Entities to Table names


The following process should be used for deriving a full name for a table. This can be carried out in
either the initial modelling or during the conversation from Logical to Physical Models.
QUALIFIER|_ENTITY_NAME

QUALIFIER: A link to the system in which the database is being implemented. To ensure no
ambiguity of custodianship, any cross-functional tables should have the system which relised
on the information the most as the Qualifier. (See Data Modelling Procedure (IMF705) for
Definition),
ENTITY_NAME: is the name of the entity with which the attribute is associated. The entity
type name may be used to make the attribute name explicit. It is almost always the identifier
attribute, e.g., CLIENT_ID.

Qualifier

Description

SA_

SALIS (Soil Properties and Landscapes)

LA_

Licence Agreements (LAS)

GW_

Groundwater

NV_

Native Vegetation

EDB_

Enterprise database tables that are needed by systems throughout the Agency

WQ_

Water Quality

LC_

LandCare

IMF704_DatModNaming_v1d4.DOC

Page 12 of 21

Draft

Physical Models

DIPNR

Data model naming conventions

Property Agreement and Management Contracts

WP_

Work Program management

MC_

Ministerial Correspondence

COM_

Compliance with legislation/Acts

Draft

PA_

Abbreviations
A list of standard abbreviations can be found in Attachment A.
No abbreviations may duplicate those appearing on the Attached list. An abbreviation of 4 characters
cannot be a word. A simple process for determining abbreviations for words/terms that do not appear
in Attachment A is as follows:
1. Determine length of abbreviation.
2. Put first and last letter of word in first and last position of abbreviation.
3. Remove vowels.
4. Remove one of any double consonants.
5. Fill remaining spaces of abbreviation with consonants of the word in the order in which they
appear until the required number of letters is obtained.
Example
1. To abbreviate ABBREVIATION to 5 characters.
2. Put A in location 1 and N in location 5.
3. Remove E, I, A, I, and O.
4. Remove one B.
5. This leaves BRVT for 3 spaces.
6. Select the first three remaining characters and fill spaces 2 to 4 (unless it results in a double
consonant).
7. Result is ABRVN.

IMF704_DatModNaming_v1d4.DOC

Page 13 of 21

DIPNR

Data model naming conventions

Bureau of Rural Science, 2003, Australian National Groundwater Data Transfer Standard [online]
Available from http://www.brs.gov.au/land&water/groundwater/components.html [accessed 21 May
2003]
Department of Infrastructure, Planning & Natural Resources, Enterprise Data Model Version 1.7
Hoffer, JA, Prescott, MB, McFadden, R., 2002, Modern Database Management 6th ed., Pearson
Education, New Jersey.
Nicewarner, M, 2001, Data Model Reference [online], Available from
http://www.datamodel.org/DataModelReference.html [accessed 30 March 2003]

IMF704_DatModNaming_v1d4.DOC

Page 14 of 21

Draft

References:

DIPNR

Data model naming conventions

These standards provide a means to determine standard abbreviations for use in defining application
components.
Standard Acronyms and Abbreviations
ADMINISTRATION
ALTERNATE
APPLICATION
AUTHORITY
BRANCH
BUSINESS
CLASSIFICATION
CLIENT
COMMENT
COMMITTEE
COMPANY
CONTROL
CORPORATION
CREDIT
DESTINATION
DEPARTMENT
DISTRICT
DIVISION
EFFECTIVE
ERROR
EXECUTIVE
FEDERAL
IDENTIFICATION
INDEX
INITIALS
INDICATOR
LENGTH
LICENCE
LOAD
MANAGEMENT
MARK
METHOD
ORGANIZATION
PAYMENT
PERCENT
PERMIT
PIECE
POSITION
PRIMARY
PRODUCT
PROJECT
RECEIVED
REGION
REGISTRATION
REQUIRED
RETURN

IMF704_DatModNaming_v1d4.DOC

ADMN
ALT
APPL
AUTH
BR
BUS
CLASSN
CLNT
CMNT
CTTE
CMPNY
CTL
CORP
CR
DEST
DEPT
DIST
DIVN
EFF
EST
EXEC
FED
ID
INDX
INTLS
IND
LNTH
LIC
LD
MGMT
MRK
MTHD
ORG
PYMNT
PCT
PRMT
PCE
POSN
PRI
PRO
PROJ
RECD
REG
REGN
REQD
RTN

Page 15 of 21

Draft

Attachment A: Abbreviations

DIPNR

IMF704_DatModNaming_v1d4.DOC

Draft

REVENUE
SCHEDULE
SEARCH
SECONDARY
SECTION
SEQUENCE
SERVICE
SQUARE METERS
STATEMENT
STATUS
STATUTORY
STATISTICS
TEXT
TRANSACTION
TYPE
USERID
VALUE
YEAR
YEAR TO DATE

Data model naming conventions

RVNU
SCHEDL
SRCH
SEC
SCTN
SEQ
SRVC
SQM
STMT
STS
STAT
STATS
TXT
TXN
TYP
UID
VAL
YR
YTD

Page 16 of 21

DIPNR

Data model naming conventions

Oracle 9i Spatial is the current supported corporate Database Management System. The most common
of these include:
Table 2-1 Built-In Data Type Summary
Data Type
Character VARCHAR2(size)

BLOB

Numeric

NUMBER(p,s)

Description

Variable-length character string having maximum length size


bytes or characters. Maximum size is 4000 bytes, and minimum is
1 byte or 1 character. You must specify size for VARCHAR2.
BYTE indicates that the column will have byte length semantics;
CHAR indicates that the column will have character semantics.
Convention is to use an even number for the size.
A binary large object. Maximum size is 4 gigabytes. Can be used
for Pictures, sounds
Number having precision p and scale s. The precision p can range
from 1 to 38. The scale s can range from -84 to 127.
The NUMBER Data Type stores zero, positive, and negative fixed
and floating-point numbers with magnitudes between 1.0 x 10-130
and 9.9...9 x 10125 (38 nines followed by 88 zeroes) with 38 digits
of precision. If you specify an arithmetic expression whose value
has a magnitude greater than or equal to 1.0 x 10126, then Oracle
returns an error.

Date/Time DATE
Valid date range from January 1, 4712 BC to December 31, 9999
AD.
For each DATE value, Oracle stores the following information:
century, year, month, date, hour, minute, and second.
If you specify a date value without a time component, then the
default time is 12:00:00 am (midnight). If you specify a date value
without a date, then the default date is the first day of the current
month.
You can add and subtract number constants as well as other dates
from dates.
TIMESTAMP
Year, month, and day values of date, as well as hour, minute, and
(fractional_seconds_ second values of time, where fractional_seconds_precision is the
precision)
number of digits in the fractional part of the SECOND datetime
field. Accepted values of fractional_seconds_precision are 0 to 9.
The default is 6.
MDSYS.SDO_GEO SPATIAL object data type
METRY

IMF704_DatModNaming_v1d4.DOC

Page 17 of 21

Draft

Attachment B: Oracle built-in Data Types

DIPNR

Data model naming conventions

The intent of these is to ensure better integration of data though ensuring everyone refers to the same
attributes in the same way.
These have been taken from the Enterprise Data model (v1.7).
Field Name
ADDR_ID

Data Type
NUMBER(10)

ADDRESS_LINE_1
ADDRESS_LINE_2
ADDRESS_LINE_3
ADDRESS_LINE_4
STREET_NAME

VARCHAR2(100)
VARCHAR2(100)
VARCHAR2(100)
VARCHAR2(100)
VARCHAR2(30)

STREET_TYPE

VARCHAR2(8)

SUBURB

VARCHAR2(40)

CITY_NAME
COUNTY

VARCHAR2(50)
VARCHAR2(25)

PARISH
STATE

VARCHAR2(25)
VARCHAR2(25)

COUNTRY
POST_CODE

VARCHAR2(3)
VARCHAR2(12)

POSTAL_SERVICE_TYPE

VARCHAR2(3)

POSTAL_SERVICE_ID

VARCHAR2(6)

ADDRESS_TYPE

VARCHAR2(10)

LGA_CODE

VARCHAR2(4)

COUNCIL_NAME

VARCHAR2(50)

IMF704_DatModNaming_v1d4.DOC

Definition
System assigned key to ensure address
uniqueness.
Four address lines hold the unstructured
address, they length in the EDB is 4000 so it
should not exceed that in any model
Name of the Street or Road where property is
located e.g. Browns (Street)
Refer to the list of Street Type codes as per AS
4590-1999 e.g. RD - road, ST - Street, CRES Crescent, etc.
Note the suburb and postcode combination
could be validated against Australia Post data.
This is a variation from the AS4212 standard.
In the standard The county description is stored
as part of the information in the parish field.
The county and parish information are not
recorded in the AS4590 standard.
Parish Name
Under AS4212 the state field also stores the
country if not Australia. In AS4590 a separate
field is used to represent the country. A
separate field is used here and the state field
only stores state information. The country
abbreviations are defined in AS2632.
e.g. AUS - Australia, NZL - New Zealand
A field length of 12 accommodates all known
international postal codes.
Identification of type of service. e.g. GPO General Post Office Box, PO - Post Office Box,
RMS - Roadside Mail Delivery.
The service number to be used in conjunction
with a type of service For example: GPO Box
123, PO Box 32.
A 10 Char Code representing the type of
address. Unit, Overseas, Service, Street, Lot,
Rural, Unformat. Additional Codes like
Mailing address, Home address or Work
address may be added.
A four digit code used by Department of Local
Government (Local Government Area) Unique
within NSW. A 5-digit code is unique within
Australia
Name of the Council. Should not need to be

Page 18 of 21

Draft

Attachment C: Attributes for data models

DIPNR

Data model naming conventions

NUMBER(5)

LOT_SUFFIX
LOT_NO

VARCHAR2(1)
Varchar(6)

PLAN_NO

NUMBER(8)

PLAN_TYPE
SECTION_NO

VARCHAR2(2)
VARCHAR2(4)

DATA_SOURCE

VARCHAR2(10)

VALIDATION_SOURCE

VARCHAR2(30)

VALIDATION_DATE

DATE

VALID_FROM

DATE

VALID_TO

DATE

PREVIOUS_ID

NUMBER(10)

UPDATE_COUNT

NUMBER(9)

LOCALITY

VARCHAR2(40)

STATUS

VARCHAR2(10)

MGMT_BOARD_ID
PHONE_NO

NUMBER(5)
VARCHAR2(15)

PHONE_COMMENT

VARCHAR2(40)

DATE_OF_BIRTH
EMAIL
FAMILY_NAME

DATE
VARCHAR(60)
VARCHAR2(40)

IMF704_DatModNaming_v1d4.DOC

Page 19 of 21

Draft

LOT_NO

used as relationship should be made through


the LGA_Code field
The Lot reference number allocated to an
address prior to Street numbering.
e.g. Lot 23 A
An alternative approach if the LOT_SUFFIX is
included as part of this field
Represents the number of either the Strata Plan
or the Deposit Plan. A combination of
PLAN_TYPE, PLAN_NUM, SECTION_NUM
and LOT_NUM uniquely identify a parcel of
land.
DP - Deposited Plan, SP Strata Plan
SECTION_NUM is an optional field, which
may only occur in Deposit Plans. It is stored
left-justified with blank spaces padded to the
right.
The system that supplied the original data eg.
LAS, VEGNET, IPW. Eventually all records
will be owned by IPW.
The Oracle USER that created or updated the
record.
The date a record was created or last updated.
Before records are updated, a historic copy of
the original is created if the current date is
different to the last validation_date.
The date a record was initially valid. The time
portion is truncated to midnight
The date a record expired. The time portion is
truncated to midnight. Current records have a
value of ''01-JAN-3000'' Records can only be
updated if the valid_to date is greater than the
current date.
Points to the record that holds the previous
values of the current record. Column is null if
there is no prior history.
Counts the number of times a record is updated
and prevents concurrent updates to the same
record.
Describes the suburb or location of the parcel
of land.
The possible values are: CURR = Current
CANC = Cancelled PCAN = Cancelled Residue remains
Number identifying the Management Board
A telephone number that can be dialled using
any telephone services to contact a client.
Leading zeros should be included and the entry
should be left justified.
Comments relating to the availability and
usage. For Example home, work, Monday am.

DIPNR

IMF704_DatModNaming_v1d4.DOC

Key value for the linked Role record.

Primary key value assigned by DIPNR to


allow EDB to store records not held by IPW.

Page 20 of 21

Draft

GIVEN_NAMES
VARCHAR2(40)
PIVOTAL FIELDS TO REFERENCE INTO EDB
NUMBER(10)
DLWC_ROLE_ID
DLWC_LOT_ID
NUMBER(10)
DLWC_ADDR_ID
NUMBER (10)
LOT_ADDR_ID
NUMBER(10)

Data model naming conventions

DIPNR

Data model naming conventions

POST_CODE and LGA_CODE have the same class, but apply to different entities. The standard class
name or its abbreviation should be used in the development of attribute names.
So it should be Creation_Date not Data_Created.
Standard Class Name
ADDRESS
AMOUNT (A NUMERIC VALUE OF MONEY)
CODE
COUNT
DATE
DAY
DESCRIPTION
FEATURE
FLAG
FROM
GEOMETRY (spatial data type)
IDENTIFIER
LINE
LOCATION
MONTH
NAME
NUMBER
PREFIX
SERVICE
SIZE
SOURCE
STATUS
SUFFIX
SYSTEM
TEXT
TO
TYPE
UNIT
YEAR

IMF704_DatModNaming_v1d4.DOC

Possible Abbreviations
ADRS
A,AMT,AMNT
C,CD,CDE
CNT
DY
DESC , DSCRPTN, DESCRIPTOR
FTRE
FLG
FROM
ID
LNE
LCN
MNTH
NM
NO
PRFX
SRVC
SZE, SIZE
SRCE
STTS
SUFFIX
TXT
UNT
YR

Page 21 of 21

Draft

Attachment D: Standard Class phrases