imf704

Draft

Department of Infrastucture, Planning andNatural Resources

Natural Resource Information Systems

Data ModelNaming Conventions

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

IMF704

May 2003

Draft

Document Release InformationReviewers

Name Role Signature DateJane Deller-Smith SIP Project Representative

Ray Boyton Data Custodian Representative

Trev Mount Data Administrator Representative

Ron Paynter IT Reviewer

Anne Bell Editorial Reviewer

Regional Reviewer

Andrew Man DBA Reviewer

Tony Shields Peer Reviewer

Project approvalsName Role Signature Date

GM, Natural Resource Information Systems

GM, Information Management &Technology (Chief Information Officer)

Group GM, Natural Resource Products

AudienceRole ResponsibilityData Manager Manages and maintains the final model

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

Application Developer Ensures these conventions are followed during the development and documentation ofdatabasesRecommends 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 DatabaseManagement System.

Related documentsDocument Name LocationData modelling procedures http://imf.dsnr/binarydata/IMF705.doc

HistoryVersion Date Author-Editor(s) Notesv1 d1 20 May 2003 Adrian Richardson

V1d3 12 June 2003 Adrian Richardson Changes after feedback from Ron Paynter, Andrew Man, OlgaJouklova

V1d4 16 June 2003 Anne Bell Proofed and read document as final draft

File detailsFilename Data Model Naming and Display Conventions

File server location \\PAR01\DATA1\GROUP\IMTIIC\CORPORAT\IMT\COORD\NRIS\Projects\SIP\10.1_Data_Management\10.1.3 Data Quality Assurance\Information ManagementFramework\Guidelines and Templates\IMF704_DatModNaming_v1d4.DOC

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

Draft

ContentsABOUT THIS DOCUMENT................................................................................................................... 4

PURPOSE................................................................................................................................. 4SCOPE...................................................................................................................................... 4WHAT IS A DATA MODEL ....................................................................................................... 4NAMING CONVENTIONS ........................................................................................................ 5

The need for naming conventions ................................................................................ 5Naming conventions are evolutionary........................................................................... 5Logical vs Physical Data Model names ........................................................................ 5Logical Data Models ..................................................................................................... 5Physical Data Models ................................................................................................... 6

GENERAL GUIDELINES:..................................................................................................................... 7ENTITY NAME .......................................................................................................................... 7

DEFINING AN ATTRIBUTE.................................................................................................................. 81. ATTRIBUTE NAME....................................................................................................... 82. DATA TYPE .................................................................................................................. 93. FIELD LENGTH ............................................................................................................ 94. DATA INTEGRITY CONTROLS ................................................................................... 95. DEFINITION................................................................................................................ 10

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

PHYSICAL MODELS.......................................................................................................................... 12PHYSICAL DATA MODEL NAMES ........................................................................................ 12

Changing Entities to Table names.............................................................................. 12ABBREVIATIONS ................................................................................................................... 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

DIPNR Data model naming conventions

IMF704_DatModNaming_v1d4.DOC Page 4 of 21

Draft

About this document

Purpose

The following are conventions for creating consistent data models. These conventions will be usedduring 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 anycorporately motivated data management. This document presents a convention for naming systemcomponents that is precise, logical and conforms with DIPNRs application development andinformation management methodologies. Techniques described are used throughout the industry.

Where possible these conventions have been derived from established departmental practice. When adiscrepancy was found the convention was based on recognised best practice.

Scope

These conventions will ensure consistency within the department for data models and the integrationof databases.

Some knowledge of data model definition, use and creation has been assumed. The processes neededto create a data model, both logical and physical modelling, including normalisation, is dealt with in anumber of texts and will not be reproduced here.

An Operational Data Custodian (ODC) initiates the data modelling process, like any business systemimprovement. However, in order to maintain a corporate standard the conventions for adherence aremaintained by the Corporate Data Administrator (CDA). Both of these positions are required toapprove the logical data model. The Database Administrator (DBA) then approves the physicalimplementation.

Data models should be easy to understand, faster and easier to produce than program code and alloweffective 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 thestructures of programs that deal with data (such as storage, update, query, reporting, analysis anddisplay functions). So, a well designed data model will have practical consequences in making datamanagement 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 forwhich the data was initially collected.

2. Stability and Flexibility, as the model has to be generic and flexible enough to cope withchange. A model is stable if it does not need to be modified in the event of a change inrequirements. A model is flexible if it can be readily extended to accommodate newrequirements.



Draft3. 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.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 betweenbusiness areas dictates the need for highly organised systems development. The names used to identifyfacts about objects, concepts and events are critical to the general understanding and knowledge ofstaff. Using good naming standards that are easy to follow, systems designers can produce productsthat do not introduce ambiguity or misunderstanding into the business. Without adherence to namingconventions, confusion is created. Standard naming conventions provide a platform to ensure datasharing and consistency within the organisation. It improves communications for both developers andusers.

Variations in the use of the NUMBER Class (see Class Phrase for definition)

CLASS ABBREVIATION Used by

_NO SALIS, LAS, GDS, NativeVegetation, HYDSYS*, EDB

_NUM 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 manytable and column names that do not conform to the current standard. It is expected that all newdevelopments 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 toData Modelling Procedures (IMF705).

Logical Data Models

The Logical Data Model (LDM) visually represents the data needed satisfy business requirements andshows how entities both within and outside this environment relate. The LD is created without anyspecific computer environment in mind. No optimisation for performance, data storage or evenapplication development is done (nor is desired). The intent is to produce a purely logical view of thedata required by the business area.

Logical model names are likewise not concerned with physical storage restriction, so can be anylength with no need for abbreviation. This adds clarity to the information we are trying to represent.

A Logical Data Model is made up of:



Draft Logical Entity Relationship Diagram (ERD) Data Dictionary definitions

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

PRIMARY_KEY

Attribute 1Attribute 2

PRIMARY_KEY

Attribute 1Attribute 2

ENTITY_NAME1 ENTITY_NAME2

Entity

Attribute

Identifier

Relationship

Physical Data Models

The purpose of the physical data model is to show how the data elements will be implemented andstored on the database. Physical models may vary from the logical model in that the physical modelmay 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, improvemaintenance turnaround, or for other reasons.

Physical model names are restricted to physical storage limits so some abbreviation and ingenuity isrequired when translating logical model names to physical model names. Some restrictions from thelogical model rules still apply, e.g., table names, like entity names, must be unique throughout thedepartment.

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



Draft

General Guidelines:There are some general for name creation.

Note: As the corporate Database Management System (DBMS) is already known to be Oracle forDIPNR, 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 usercommunity.

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 insome cases, there may be a need to distinguish between tables replicated from external datasources 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.



Draft

Defining an AttributeAn attribute should have:

Attribute Name Data Type Field Length Data Integrity Controls Definition

1. 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 isnamed, 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.



Draft 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


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 DateDifferent data types have different functions and will allow the data placed in them to be manipulatedin different ways.

Some data types have special manipulation capabilities (e.g., the DATE data type showed true dataarithmetic) and which only works on comparisons of the same data types.

3. Field Length


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


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.



Draft

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

5. 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 Example - Bad DefinitionCLIENT Any individual ororganisation that is dealing, hasdealt, or plans to deal with theDepartment.

CLIENT - A departmental client.

Definition Conventions

Nouns: The first sentence of the definition should give a noun or group of nouns, with modifyingadjectives 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 thereaders 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 isnot a valid member of the group is also useful in showing the boundary from the other side. Oftenwording that explains why examples are, or are not, included is necessary. The definition shouldinclude 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 anEmployee 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 tounderstand the rationale for the entity and fit their own understanding of the business into the onerepresented by this entity.



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

Differentiation: Where there may be confusion between two similar entities, either because theirnames are similar or because their descriptions or relationships are similar, there should be explicittext which that the difference.

e.g., the Worker entity may be confused with the Employee entity. The Worker entity is used tocollect information about clients who are supported in the work they do.



Draft

Physical Models

Physical Data Model Names

These names need to fit into the conventions set by the DBMS. At this point some abbreviation mayneed to occur. A simple procedure for abbreviation is shown below, a standard list of abbreviations areincluded 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 ineither 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 noambiguity of custodianship, any cross-functional tables should have the system which relisedon the information the most as the Qualifier. (See Data Modelling Procedure (IMF705) forDefinition),

ENTITY_NAME: is the name of the entity with which the attribute is associated. The entitytype name may be used to make the attribute name explicit. It is almost always the identifierattribute, 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



Draft

PA_ Property Agreement and Management Contracts

WP_ Work Program management

MC_ Ministerial Correspondence

COM_ Compliance with legislation/Acts

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 characterscannot be a word. A simple process for determining abbreviations for words/terms that do not appearin 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.

Example1. 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.



Draft

References: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 May2003]

Department of Infrastructure, Planning & Natural Resources, Enterprise Data Model Version 1.7

Hoffer, JA, Prescott, MB, McFadden, R., 2002, Modern Database Management 6th ed., PearsonEducation, New Jersey.

Nicewarner, M, 2001, Data Model Reference [online], Available fromhttp://www.datamodel.org/DataModelReference.html [accessed 30 March 2003]



Draft

Attachment A: AbbreviationsThese standards provide a means to determine standard abbreviations for use in defining applicationcomponents.

Standard Acronyms and AbbreviationsADMINISTRATION ADMNALTERNATE ALTAPPLICATION APPLAUTHORITY AUTHBRANCH BRBUSINESS BUSCLASSIFICATION CLASSNCLIENT CLNTCOMMENT CMNTCOMMITTEE CTTECOMPANY CMPNYCONTROL CTLCORPORATION CORPCREDIT CRDESTINATION DESTDEPARTMENT DEPTDISTRICT DISTDIVISION DIVNEFFECTIVE EFFERROR ESTEXECUTIVE EXECFEDERAL FEDIDENTIFICATION IDINDEX INDXINITIALS INTLSINDICATOR INDLENGTH LNTHLICENCE LICLOAD LDMANAGEMENT MGMTMARK MRKMETHOD MTHDORGANIZATION ORGPAYMENT PYMNTPERCENT PCTPERMIT PRMTPIECE PCEPOSITION POSNPRIMARY PRIPRODUCT PROPROJECT PROJRECEIVED RECDREGION REGREGISTRATION REGNREQUIRED REQDRETURN RTN



Draft

REVENUE RVNUSCHEDULE SCHEDLSEARCH SRCHSECONDARY SECSECTION SCTNSEQUENCE SEQSERVICE SRVCSQUARE METERS SQMSTATEMENT STMTSTATUS STSSTATUTORY STATSTATISTICS STATSTEXT TXTTRANSACTION TXNTYPE TYPUSERID UIDVALUE VALYEAR YRYEAR TO DATE YTD



Draft

Attachment B: Oracle built-in Data TypesOracle 9i Spatial is the current supported corporate Database Management System. The most commonof these include:

Table 2-1 Built-In Data Type SummaryData Type Description

Character VARCHAR2(size) Variable-length character string having maximum length sizebytes or characters. Maximum size is 4000 bytes, and minimum is1 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.BLOB A binary large object. Maximum size is 4 gigabytes. Can be used

for Pictures, soundsNumeric NUMBER(p,s) 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 fixedand floating-point numbers with magnitudes between 1.0 x 10-130and 9.9...9 x 10125 (38 nines followed by 88 zeroes) with 38 digitsof precision. If you specify an arithmetic expression whose valuehas a magnitude greater than or equal to 1.0 x 10126, then Oraclereturns an error.

Date/Time DATEValid date range from January 1, 4712 BC to December 31, 9999AD.

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 thedefault time is 12:00:00 am (midnight). If you specify a date valuewithout a date, then the default date is the first day of the currentmonth.

You can add and subtract number constants as well as other datesfrom dates.

TIMESTAMP(fractional_seconds_precision)

Year, month, and day values of date, as well as hour, minute, andsecond values of time, where fractional_seconds_precision is thenumber of digits in the fractional part of the SECOND datetimefield. Accepted values of fractional_seconds_precision are 0 to 9.The default is 6.

MDSYS.SDO_GEOMETRY

SPATIAL object data type



Draft

Attachment C: Attributes for data modelsThe intent of these is to ensure better integration of data though ensuring everyone refers to the sameattributes in the same way.

These have been taken from the Enterprise Data model (v1.7).

Field Name Data Type DefinitionADDR_ID NUMBER(10) System assigned key to ensure address

uniqueness.ADDRESS_LINE_1 VARCHAR2(100)ADDRESS_LINE_2 VARCHAR2(100)ADDRESS_LINE_3 VARCHAR2(100)ADDRESS_LINE_4 VARCHAR2(100)

Four address lines hold the unstructuredaddress, they length in the EDB is 4000 so itshould not exceed that in any model

STREET_NAME VARCHAR2(30) Name of the Street or Road where property islocated e.g. Browns (Street)

STREET_TYPE VARCHAR2(8) Refer to the list of Street Type codes as per AS4590-1999 e.g. RD - road, ST - Street, CRES -Crescent, etc.

SUBURB VARCHAR2(40) Note the suburb and postcode combinationcould be validated against Australia Post data.

CITY_NAME VARCHAR2(50)COUNTY VARCHAR2(25) This is a variation from the AS4212 standard.

In the standard The county description is storedas part of the information in the parish field.The county and parish information are notrecorded in the AS4590 standard.

PARISH VARCHAR2(25) Parish NameSTATE VARCHAR2(25) Under AS4212 the state field also stores the

country if not Australia. In AS4590 a separatefield is used to represent the country. Aseparate field is used here and the state fieldonly stores state information. The countryabbreviations are defined in AS2632.

COUNTRY VARCHAR2(3) e.g. AUS - Australia, NZL - New ZealandPOST_CODE VARCHAR2(12) A field length of 12 accommodates all known

international postal codes.POSTAL_SERVICE_TYPE VARCHAR2(3) Identification of type of service. e.g. GPO -

General Post Office Box, PO - Post Office Box,RMS - Roadside Mail Delivery.

POSTAL_SERVICE_ID VARCHAR2(6) The service number to be used in conjunctionwith a type of service For example: GPO Box123, PO Box 32.

ADDRESS_TYPE VARCHAR2(10) A 10 Char Code representing the type ofaddress. Unit, Overseas, Service, Street, Lot,Rural, Unformat. Additional Codes likeMailing address, Home address or Workaddress may be added.

LGA_CODE VARCHAR2(4) A four digit code used by Department of LocalGovernment (Local Government Area) Uniquewithin NSW. A 5-digit code is unique withinAustralia

COUNCIL_NAME VARCHAR2(50) Name of the Council. Should not need to be



Draft

used as relationship should be made throughthe LGA_Code field

LOT_NO NUMBER(5) The Lot reference number allocated to anaddress prior to Street numbering.

LOT_SUFFIX VARCHAR2(1) e.g. Lot 23 ALOT_NO Varchar(6) An alternative approach if the LOT_SUFFIX is

included as part of this fieldPLAN_NO NUMBER(8) Represents the number of either the Strata Plan

or the Deposit Plan. A combination ofPLAN_TYPE, PLAN_NUM, SECTION_NUMand LOT_NUM uniquely identify a parcel ofland.

PLAN_TYPE VARCHAR2(2) DP - Deposited Plan, SP Strata PlanSECTION_NO VARCHAR2(4) SECTION_NUM is an optional field, which

may only occur in Deposit Plans. It is storedleft-justified with blank spaces padded to theright.

DATA_SOURCE VARCHAR2(10) The system that supplied the original data eg.LAS, VEGNET, IPW. Eventually all recordswill be owned by IPW.

VALIDATION_SOURCE VARCHAR2(30) The Oracle USER that created or updated therecord.

VALIDATION_DATE DATE The date a record was created or last updated.Before records are updated, a historic copy ofthe original is created if the current date isdifferent to the last validation_date.

VALID_FROM DATE The date a record was initially valid. The timeportion is truncated to midnight

VALID_TO DATE The date a record expired. The time portion istruncated to midnight. Current records have avalue of ''01-JAN-3000'' Records can only beupdated if the valid_to date is greater than thecurrent date.

PREVIOUS_ID NUMBER(10) Points to the record that holds the previousvalues of the current record. Column is null ifthere is no prior history.

UPDATE_COUNT NUMBER(9) Counts the number of times a record is updatedand prevents concurrent updates to the samerecord.

LOCALITY VARCHAR2(40) Describes the suburb or location of the parcelof land.

STATUS VARCHAR2(10) The possible values are: CURR = CurrentCANC = Cancelled PCAN = Cancelled -Residue remains

MGMT_BOARD_ID NUMBER(5) Number identifying the Management BoardPHONE_NO VARCHAR2(15) A telephone number that can be dialled using

any telephone services to contact a client.Leading zeros should be included and the entryshould be left justified.

PHONE_COMMENT VARCHAR2(40) Comments relating to the availability andusage. For Example home, work, Monday am.

DATE_OF_BIRTH DATEEMAIL VARCHAR(60)FAMILY_NAME VARCHAR2(40)



Draft

GIVEN_NAMES VARCHAR2(40)PIVOTAL FIELDS TO REFERENCE INTO EDB

DLWC_ROLE_IDNUMBER(10) Key value for the linked Role record.

DLWC_LOT_ID NUMBER(10)DLWC_ADDR_ID NUMBER (10)LOT_ADDR_ID NUMBER(10) Primary key value assigned by DIPNR to

allow EDB to store records not held by IPW.



Draft

Attachment D: Standard Class phrasesPOST_CODE and LGA_CODE have the same class, but apply to different entities. The standard classname or its abbreviation should be used in the development of attribute names.

So it should be Creation_Date not Data_Created.

Standard Class Name Possible AbbreviationsADDRESS ADRSAMOUNT (A NUMERIC VALUE OF MONEY) A,AMT,AMNTCODE C,CD,CDECOUNT CNTDATEDAY DYDESCRIPTION DESC , DSCRPTN, DESCRIPTORFEATURE FTREFLAG FLGFROM FROMGEOMETRY (spatial data type)IDENTIFIER IDLINE LNELOCATION LCNMONTH MNTHNAME NMNUMBER NOPREFIX PRFXSERVICE SRVCSIZE SZE, SIZESOURCE SRCESTATUS STTSSUFFIX SUFFIXSYSTEMTEXT TXTTOTYPEUNIT UNTYEAR YR

About this documentPurposeScopeWhat is a Data ModelNaming conventions

General GuidelinesEntity Name

Defining an Attribute1. Attribute Name2. Data Type3. Field Length4. Data Integrity Controls5. Definition

Physical ModelsPhysical Data Model NamesAbbreviations

ReferencesAttachment A: AbbreviationsAttachment B: Oracle built-in Data TypesAttachment C: Attributes for data modelsAttachment D: Standard Class phrases

Documents

imf704