A Discussion on Late Binding Data Warehouse

Late binding is a computer programming mechanism in which the method is called upon an object is looked up by name at runtime. That is the data is named and grouped after and not at the point in which it is entered into the Late Binding Data Warehouse. The opposite of late binding is early binding. Early binding is the process where traditional data warehouses try to model the perfect database from the outset, determining in advance every possible business rule and vocabulary set that will be needed. This early binding practice is a time-consuming, expensive undertaking. In healthcare, business rules and vocabularies are dynamic and improve rapidly – and so do the use the cases that data linked across different source systems can serve. Mappings must be redone again and again as data models shift. Early binding architectures – like those espoused by Bill Inmon, Ralph Kimball, and others – force early data bindings into proprietary enterprise data models. Time has proven early-binding architectures to be inflexible, one-size-fits-all solutions, enforcing a compromised, least-common-denominator warehouse.  With early binding, the compilation phase fixes all types of variables and expressions. Late binding is also referred to as dynamic binding while early binding is also referred to as static binding.

The term Late Binding dates back to the 1960s and refers to a computer programming mechanism in which the method of programming does not require the compiler to reference the libraries that contain the object at the time of compilation. Late binding proves to solve the problem of version conflicts and modification accidents. The process of mapping the data in the enterprise data warehouse (EDW). Mapping a data is just one of the processes required as data must undergo massive transformations. The Late binding technique is used to map the data into the enterprise data warehouse from source systems to standardized and central vocabularies and business rules and systems. The idea of late binding in data warehousing borrows from the lessons learned in the early years of software engineering. In those early years, very large software programs characterized software development. It was very common and a widespread practice to program hundreds of thousands of lines of code in a single module, supporting numerous and widely different business functions. The code for these varied business functions was tightly bound or coupled together all at once, at compile time. It was a time-consuming process to write and troubleshoot these large programs. If one piece of the program failed at compile time, the entire program failed. It was all-or-nothing programming.

Before choosing a storage system or deciding between late-binding and early-binding techniques, health organizations need to consider the organizational needs for the storage, choose a data storage plane that will help the organization remain agile and form a data health storage plan.

A good Late-Binding Data Warehouse will help achieve the following:

  • Minimize remodeling data in the data warehouse until the analytic use case requires it. Leverage the natural data models of the source systems by reflecting much of the same data modeling in the data warehouse.
  • Delay binding to rules and vocabulary as long as possible until a clear use case requires it.
  • Earlier binding is appropriate for business rules or vocabularies that change infrequently or that the organization wants to lock down for consistent analytics.
  • Late binding in the visualization layer is appropriate for what-if scenario analysis.
  • Retain a record of the changes to vocabulary and rule bindings in the data models of the data warehouse. This will provide a self-contained configuration control history that can be invaluable for conducting retrospective analysis that feeds forecasting and predictive analytics.

Late binding is more popular than early-binding because early binding has some pitfalls. Traditional data warehouses try to model the perfect database from the outset, determining in advance every possible business rule and vocabulary set that will be needed. This practice, called early binding, is a time-consuming, expensive undertaking. In healthcare, business rules and vocabularies change rapidly – and so do the use the cases that data linked across different source systems can serve. Mappings must be redone again and again as data models shift.