Imf 704

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
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:
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
Page 6 of 21
Draft
DIPNR
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.
Page 7 of 21
Draft
General Guidelines:
DIPNR
An attribute should have:
Attribute Name
Data Type
Field Length
Data Integrity Controls
Definition
Data Type
Field Length
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.
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
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
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
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.
Page 9 of 21
Draft
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
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.
Page 10 of 21
Draft
DIPNR
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.
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
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
Page 12 of 21
Draft
Physical Models
DIPNR
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.
Page 13 of 21
DIPNR
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]
Page 14 of 21
Draft
References:
DIPNR
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
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
Draft
REVENUE
SCHEDULE
SEARCH
SECONDARY
SECTION
SEQUENCE
SERVICE
SQUARE METERS
STATEMENT
STATUS
STATUTORY
STATISTICS
TEXT
TRANSACTION
TYPE
USERID
VALUE
YEAR
YEAR TO DATE
RVNU
SCHEDL
SRCH
SEC
SCTN
SEQ
SRVC
SQM
STMT
STS
STAT
STATS
TXT
TXN
TYP
UID
VAL
YR
YTD
Page 16 of 21
DIPNR
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
Page 17 of 21
Draft
Attachment B: Oracle built-in Data Types
DIPNR
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)
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
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)
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
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)
DIPNR
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
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

Imf 704

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Imf 704

Uploaded by

Copyright:

Available Formats

Draft

Department of Infrastucture, Planning and

SIP Project Representative

Data Custodian Representative

Data Administrator Representative

Manages and maintains the final model

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

Data modelling procedures

Changes after feedback from Ron Paynter, Andrew Man, Olga

Proofed and read document as final draft

Data Model Naming and Display Conventions

File server location

Document Release Information

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

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

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

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

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

Data model naming conventions

What is a Data Model

About this document

Data model naming conventions

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

Naming conventions are evolutionary

Logical vs Physical Data Model names

Logical Data Models

Logical Entity Relationship Diagram (ERD)

Physical Data Models

Logical ER Data Model

Physical Data model

Data model naming conventions

Data model naming conventions

There are some general for name creation.

Data model naming conventions

An attribute should have:

Data Integrity Controls

Data Integrity Controls

Attribute names have the following characteristics:

Examples: _Type, _Name, _Date, _ID, _Number

Data Integrity Controls

Attachment B lists the most common Oracle Data types.

Data Integrity Controls

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

4. Data Integrity Controls

Data Integrity Controls

The following should be decided:

Data model naming conventions

Data Integrity Controls

Example - Bad Definition

Data model naming conventions

Data model naming conventions

Data model naming conventions

Physical Data Model Names

Logical Model Name

Physical Model Name

Changing Entities to Table names

SALIS (Soil Properties and Landscapes)

Licence Agreements (LAS)

Data model naming conventions