---
title: "MDS 5.0.0 User Functionality Guide"
canonical: "https://servicedesk.maxgeo.com/space/MDS/1847296025/MDS%205.0.0%20User%20Functionality%20Guide"
format: markdown
---
# Introduction

The primary purpose of the Maxwell GeoServices Database Schema (MDS) is to provide reliable, auditable and compliant storage of raw technical data in a single, definitive reference set.  This manual covers the SQL MDS Geological **Module Version 5.0.0 which is compatible with SQL 2019 and SQL2022.**

# ** **Database Structure

The MDS consists of a hierarchy of joined data tables supported by system and library tables.

### Data Tables

The data tables stored in the MDS Geological Module are grouped into core ‘modules’, which cannot be modified*****:

·         Downhole data (tblDH)

·         Point data (tblPT)

·         Linear data (tblLS)

·         Face data (tblFS)

·         Production data (tblProd)

·         Miscellaneous tables

·         Standard Reference data (tblStandard or tblSYSQCReference)

·         Assay and Sample Dispatch Management (tblAssay or tblSYSAss)

·         XRF Result Management (tblXRF or tblSYSXRF)

·         Contract Management (tblContract)

·         Rehabilitation (tblRehab)

·         Lease information data (tblLease)

·         Government Reporting set up tables (tblGV) – set up via DS5 only

·         Libraries (tblLIB)

***** Custom modifications are able to be performed, but only adding new tables/libraries/views or adding new fields to existing tables/libraries/views. No core objects can be altered or removed.

The tblDHColl table, for recording drill hole collar attributes, sits at the top of the hierarchy of drill hole (DH) data tables. Within the tblDHColl table, the ‘DataSet’ (convenient second tier project label) and ‘Hole_ID’ fields form a unique identifier for each drill hole. Coordinates are stored in a separate normalised table, tblDHCoordinates.

Drill holes contain sampled intervals and logged lithology and other downhole data intervals that reside within their own sets of data tables. These tables reside beneath the collar table in the table hierarchy. Sampled intervals are uniquely identified by ‘DataSet’ and ‘SampleID’ fields. Logged lithology and other downhole data records are uniquely identified by ‘DataSet’, ‘Hole_ID’, ‘Depth_From/Depth’ and ‘Priority’ fields.

The tblFSSite table, for recording face sample location attributes, sits at the top of the hierarchy of face sample (FS) data tables. Within the tblFSSite table, the ‘DataSet’ (convenient second tier project label), ‘Site_ID’ and ‘Line_ID’ fields form a unique identifier for each face sample. Coordinates are stored in a separate normalised table, tblFSCoordinates.

Face samples contain sampled intervals and logged geology and other face data intervals that reside within their own sets of data tables. These tables reside beneath the face site table in the table hierarchy. Sampled intervals are uniquely identified by ‘DataSet’ and ‘SampleID’ fields. Logged geology and other downhole data records are uniquely identified by ‘DataSet’, ‘Site_ID’, Line_ID and ‘Depth_From/Depth’ fields.

The tblLSSite table, for recording linear location attributes, sits at the top of the hierarchy of linear (LS) data tables. Within the tblLSSite table, the ‘DataSet’ (convenient second tier project label), ‘Site_ID’ and ‘Line_ID’ fields form a unique identifier for each face sample. Coordinates are stored in a separate normalised table, tblLSCoordinates.

Linear samples contain sampled intervals and logged geology and other linear data intervals that reside within their own sets of data tables. These tables reside beneath the linear site table in the table hierarchy. Sampled intervals are uniquely identified by ‘DataSet’ and ‘SampleID’ fields. Logged geology and other downhole data records are uniquely identified by ‘DataSet’, ‘Site_ID’, ‘Line_ID ‘, ‘Length_From/Length’ and ‘Priority’ fields.

Unlike the other location table in the MDS, the tblProdLocation table, for recording production locations and other production data attributes, is a general location table with no spatial references, and is not the parent hierarchy to the production module. Within the tbProdLocations table, the ‘LocationID’ field forms a unique identifier for each production location (Figure 73).

The tblPTSite table, for recording surface geochemistry and other point data attributes, sits at the top of the hierarchy of point (PT) data tables. Within the tblPTDite table, the ‘DataSet’ (convenient second tier project label) and ‘Site_ID’ fields form a unique identifier for each point site. Coordinates are stored in a separate normalised table, tblPTCoordinates.

Point sites contain sampled intervals and logged geology and other point data depths that reside within their own sets of data tables. These tables reside beneath the point site table in the table hierarchy. Sampled intervals are uniquely identified by ‘DataSet’ and ‘SampleID’ fields. Logged geology and other downhole data records are uniquely identified by ‘DataSet’, ‘Site_ID’ and ‘Priority’ fields.

Sample and quality control (QC) data tables join to a common normalised assay table, in which records are uniquely identified by a combination of ‘DataSet’, ‘SampleID’, ‘GenericMethod’, ‘Element’, ‘Repeat’, ‘and ‘Preferred’ fields, independent of the ‘LabCode’ and ‘Batch_No’ fields (final results are defined by the generic method priority).

All data tables record Data_Source (required), Loaded_By; Load_Date; Modified_By and Modified_Date. A trigger updates the Modified fields automatically and also prevents the Loaded_By and Load_Date fields to be updated (for audit trail purposes).

#  Library Tables

Library tables contain permissible codes associated with specific fields in tables within the database.  Tables linked to libraries with table relationships (Foreign Key (FK) check constraints) and in certain instances a FK in combination with triggers (e.g. Sample_Type fields FK to tblLIBSampleType). 

#  System Tables

The system tables are prefixed tblSYS* and are required by DataShed and stored procedures in the MDS to run core functionality.  The structure of these tables is not able to be modified. 

tblSYSParam stores information about the default values that are assumed about specific data in the database, a snapshot of which is shown below:

## Database Integrity

The MDS strictly applies integrity to all downhole, face, linear, point and production measurement recordings.  If data fails the integrity rules, the data is NOT loaded into the database. A full list of the Check Constraints (CK) on the data for each field is listed in the data dictionary.

In general, the following rules are applied:

·         Intervals Depth_To/Length_To > Depth_From/Length_To

·         Intervals or Depths < Max depth

·         No overlapping intervals

·         No mixture of interval and point data in the same table

·         Dips between -90 & 90°

·         Azimuths, dip direction, alpha, beta are all between 0 & 360°

·         Gamma between 0 & 90°

·         Individual percentage values <= 100%; total of all percentage values <=100%

·         Recovery values <= 110%; RQD values <= 100%

·         Incremental values must have data in preceding values before the next can be entered (e.g. Cannot have Lith2 unless Lith1 exists)

·         Cannot enter qualifiers unless the primary code is populated (e.g. Cannot have a Lith_Grainsize or a Lith_Colour unless Lith_Code is populated)

·         QC samples cannot be loaded unless the corresponding parent (original) sample (ID) is loaded

·         Dates <= current daily (load) date; start dates <= complete dates etc.

·         Logging/sampling dates cannot be before the start date of the drill hole, face site or linear site drill/face sample/linear construction date

·         Codes for fields linked to corresponding library tables can only be loaded if they are set to Is_Active = ‘TRUE’ in the library table

·         Once drill holes, linear sites and point sites have been set to Validated = ‘TRUE’, no data related to these can be updated, inserted or deleted

·         Once Load_Date and Loaded_By fields have been populated upon database loading these fields are unable to be modified. Instead any updates are recorded in the Modified_Date and Modified_By fields

·         A Data_Source field is required for ALL data tables

## Database Compliancy

The MDS fulfils the requirements ascribed by the Australian JORC (2012), South African SAMREC (2016), Canadian NI 43-101 recording guideline codes and the American Sarbanes-Oxley Act.

Key points in all the codes are accurate recording of:

·       Field sampling and sample preparation techniques

·       Sample quality and recovery

·       Analytical sample preparation and analytical techniques

·       Geological context of samples

·       Drilling techniques

·       Accuracy and method of the location of data point.

·       Sample collection and analytical technique QC


Critical fields commonly left out in the recording process:

·         Complete descriptions of grid coordinates

·         Drill collar, linear site and point site location survey method (e.g. DGPS)

·         Drill collar, linear site and point site location survey date

·         Drill collar, linear site and point site location survey personnel/company

·         Drill start and finish dates

·         Exploration data collecting company name and responsible person

·         Downhole survey instrument type (e.g. Eastman)

·         Downhole survey method (e.g. Single Shot)

·         Downhole survey date

·         Downhole survey operator

·         Drill sample category (e.g. original field sample, resplit)

·         Drill sample method (e.g. riffle split, grab)

·         Drill sample type (e.g. 4m composites, half core)

·         Drill sample quality (e.g. wet, dry)

·         Drilling company and/or operator

·         Drill rig meta data (rig name, hole diameter, casing etc.)

These are the minimum requirements expected for acceptable data reported to the various stock exchanges conforming to the above compliance standards.  In instances where this data is unobtainable, the code NR (not recorded) is recommended to be used to state that this information was not located. 

In addition, the MDS stores every instance (record) of data loading, data modification, and who loaded and modified the specific data, as well as data sources where appropriate.  This makes the data loading process highly auditable.

For more information please download the compete User Functionality guide below: