Virtual Data Model (VDM)
I am a retired software developer and I developed a simple strategy for productivity during my career: abstraction.
The library I created was called Virtual Data Model (VDM) which placed all of the business logic for rendering data graphically, reading/writing data, and selecting specific data in a reusable set of components.
 | Graphical rendering is not limited to the screen; the same components that render to the screen also render to deliverable formats like printed documents, PDF, CGM, and several proprietary formats. | ||||||||||||
| Data access includes formats common to the oil industry (DLIS and LAS) as well as several proprietary formats including a ZIP based container format that is many times smaller than the industry formats. | ||||||||||||
| Hit testing at the component level relieves the user interface of needing to know about the details of the data set or how the document is being presented: rotation, zooming, and panning. | ||||||||||||
| Efficient handling of large data sets. | ||||||||||||
|
A greatly expanded concept of the data dictionary:
|
Lots of Data and Graphical Formats
This video demonstrates working with different file and graphical formats while using simple application code to demonstrate the productivity provided by abstraction.
Developer Productivity
The following video demonstrates an application which was used to train students how to write a complex application in less than two hours using VDM and then shows how that application was later used to improve the productivity of our end users.
End User Productivity
Productivity of the developer is a good goal but it should not be the primary goal. The primary goal of software should be the user experience. In the oil business we worked on telemetry data that could have several thousand streams of floating point information and many of those could contain millions of data points.
A good user experience not only must include a clean user interface but needs to be fast regardless of how much data is involved. The VDM library is optimized to process large amounts of data quickly as the following video demonstrates.
One scenario is a single stream of resistivity data with over a half million levels and 240 floating point columns of information (120 million floating point values) being displayed in three different formats at once.
Another scenario is a stream of acoustic data with over 3,000 columns of integer data.
This is a video of worst case scenarios:
Redacting Sensitive Customer Data
Another feature of VDM is its sophisticated data dictionary component which has non-standard information like a flag to indicate sensitive customer data. If the application sets a redact property to true, the VDM components will test the data dictionary to see if this column of the table contains sensitive data which needs to be redacted.
This is a video of illustrating support for metadata (data other than telemetry):
