LifeLine Design in One Page

“Brooks Chapter 9: ‘Show me your [code] and conceal your [data structures], and I will continue to be mystified. Show me your [data structures] and I won’t usually need your [code], it will be obvious. ‘”

LifeLine’s design has taken this principle to heart – focusing on doing as much work as possible through generic data structures, and then building what code is needed around that. To understand the LifeLine interface, the LifeLine load tools, you must first understand the design concepts behind LifeLine’s data structures. The common framework that unifies the Relational and Object view is Set Theory applied to Graphs. LifeLine focuses on identifying Base Sets (nodes), Identifying Proper Subsets (edges as Parent/Child relations among tables) , Intersection Sets (more edges as Chained Parent/Child Relations, Link tables)

What are the key design considerations?

1. Objects (Base Sets)
2. Abstraction (Abstract Classes)
3. Modularity (Proper Subsets)
4. Smallest Path (Efficient Queries)
5. Single Metaphor that drives Domain Models
6. Relational Objects (Sets as Classes)
7. Invariance (One Data Structure through which Diverse data instances can flow)
8. Semantic Content through Meta Information (Self Documenting, Self Describing data structures)
9. Normalization Constraints, aliases (Table Therapy)
10. Referential Integrity (The Grand Principle -- No Orphan Childs, No lonely Tables)

What are my base objects/ (Stands – as Polygons). What exists in a Stand? (Trees, Soil, Wildlife).

How do I measure trees? (In plots, in strip surveys, in various “subplots” like soil pits, density plots, etc). What do I measure on Trees? (Height, diameter).

What exists in trees (Insect Damage).

What exists around trees (Vegetation).

Can I abstract then, from these details some general classes of modular/hierarchical Objects? (Stands, Plots, Plot Attributes, Subplots, Subplot Attributes, Trees, Tree Attributes).

Would these objects be valid for several types of data (yes, they could represent silvicultural surveys, growth and yield plots, forest inventories). Can I define some table structures and table relationships that would be valid for these objects across a number of programs – i.e. invariant? (Yes).

Can I assign some common fields that should always be associated with certain objects, and standard definitions for them? (Yes, this is a form of meta-information). Can I normalize this data to at least 3rd normal form? (Of course, it should be close to this form already, if all the above design considerations have been adhered to).

Does every piece of unique information exist in one place only, does every object in a “child table” have a corresponding match in a “parent table” (is every plot assigned to a stand?) so the database as a whole has referential integrity, and is highly normalized (Yes, but lets check by explicitly setting referential integrity constraints as part of our data load process, and by explicitly checking our table designs against normality criteria).

What about those cases where we can’t build a hierarchical design (“Child tables” with > 1 “parent table”) such as spatial relationships, or nonlinear classifications (Build link tables to maintain referential integrity, take two aspirins, and call me in the morning).

LifeLine Design Examples

.... Coming soon, we'll post several LifeLine models from classic "database textbook" examples, to key models useful in forestry, GIS, other domains. If you have a model to post, we'd love to hear from you.

-- MishtuBanerjee - 24 May 2005
to top