It’s been about a year since my “Databases and Landwork” presentation was approved for CE credit, and I enjoy speaking to my colleagues in the land industry whenever possible. Due to space limitations, this article is a very condensed (and non-visual) version of the presentation, but I hope I can cover the essential points in a manner helpful to the readers. We will be posting the PowerPoint and a video of the presentation in our About Us section in the next few days, wherein I go into much greater depth.

 

We all work with databases in our everyday lives. A database is “a comprehensive collection of related data organized for convenient access, generally in a computer”. I like the generally in a computer part, because there are many non-electronic databases out there, including phone books, dictionaries, index books, even note pads, etc.

 

For everyday databases in landwork, we can point to courthouse indexes (both printed and electronic), state mineral websites (Sonris, NDIC, etc.), search engines and even social media. All of these tools are databases.

 

Electronic databases provide speed, convenience, control and standardization that non-electronic databases simply cannot match, particularly when accessible via the internet (this section alone takes 10 minutes in the presentation but we will simply touch on it for now).

 

When it comes to databases for land data, there are two primary areas of broad distinction--Flat vs. Relational structure and Tract vs. Contract orientation, allowing for essentially four permutations (actually five-see below). Flat databases are basically one big table in the form of a spreadsheet and can therefore be relatively easy to set up, but as each of you knows, there is typically quite a bit of repeated data, regardless of orientation. Flat databases can be difficult to retrieve accurate metrics from due to that repetition. As a result, flat (spreadsheet) databases are easy to set up but are more difficult to maintain.

 

Relational databases, as the term implies, use multiple tables and relate them in a manner appropriate to the task. An example would be linking tract records to contracts (leases). In a tract-oriented database, the tract record would only be entered once and then linked to all of the contracts to which it is attached. The reverse would be true for a contract-oriented system. More difficult to set up, easier to maintain.

 

As a rule, database systems are going to be relational, providing a much greater degree of efficiency. As another general rule, the front end or acquisition phase of land work tends to be better served with a tract-oriented system, as the primary concern at that phase is where you are with regard to your tracts--percent signed, restrictive requests from grantors, etc. It is also important to note that tract-oriented data is easy to map.

 

The back end, or management phase of landwork generally benefits most from a contract-oriented database, which makes sense when you consider that the primary purpose is to manage the rights and obligations associated with a block of assets (leases). Both orientations have their respective pros and cons, so neither is perfect, but they both certainly have their roles in the land industry. Both are great for capturing data to be used for reports and executable documents, but the nature of those reports and executable documents differs greatly.

 

Relational land database systems can also be non-oriented, as in the case of TotaLand. This is accomplished simply by using cross tables instead of sub tables, eliminating many of the restrictions inherent in tract- and contract-oriented systems.

 

Regardless, databases are not only here to stay for the land industry, their importance and prominence continue to grow year after year. I hope this article provides you with enough knowledge to help you in your work. I would be happy to come speak at your local luncheon or seminar.

 

Bill Justice, Founder / President - TotaLand Technologies