Organon introduction: Ripple effect (Part 3)

Software modularity and layering became the heart of modern programming and the main reason for large systems to be exist. Unfortunately, no joy without pain. modularity introduce the dependency problem which became a real pain for maintaining large systems which has hierarchical dependencies design, A change in one lower module usually forces a ripple effect of changes in other higher modules.

Database and information stores are usually the lower module in any information system, the problem appears with time and as the development grows changing a decision in the physical model will become more complex and sometimes unavoidable because it will require reflect the changes in all the data manipulation in the system. I think every developer said "O-M-G I have to change tons of queries because of that change" at least once. But why? Usually, a developer creates a conceptual model represents the real world and transform it to physical model which the others modules will depend on it to manipulate the required information, and therefore, data manipulation is strongly depend on the physical model which cause all this problems.

Lets take an example "Who is working in the Blah project?" to answer the question we will need to write a query with full knowledge of the physical model and will access objects not exist in the conceptual design level imposed by the physical representation model, for example (project, employee and assignment) on the other hand, in the conceptual level we will only need knowledge of two objects Project and Employee to answer the question. The problem appears when the innocent customer comes and tell you "oooh, please we start working in groups. can we assign a group to project?"

In this case you have 3 choices after study the butterfly effect of the required change:

1. Your lucky because you knew the customer will ask for this and you put it in the physical model from the beginning. (God knowledge)
2. Unlucky you, spend extra hours fixing it. (Man power)
3. Tell the customer, sorry not everything possible!

Well, I think nobody safe from reach the third option unless you use ORGANON. Not because it will give you the God knowledge or unlimited man power but it will make you use the conceptual model direct without the need to access the physical model in a modular way.

Lets take the above example and see how ORGANON will save most of your data manipulation:

1. Before customer request the model will contains: Person, Employee, Project and Assignment
2. After customer request the model will contains: Person, Employee, Groups, Project and Assignment

In both cases the model dose not look different that a normal physical model but lets see how we can query it.

SELECT employee.name FROM employee WHERE project.name = 'Blah'

The great news that the query applies in the first model exactly as the second model! Yes it dose. sure you will still need fix the data I/O like forms to reflect the new data model after all. but imagine with more complex data model how many reports you can make only by knowing which objects you working on.

Also, ORGANON provides modular functionality to perceive the data model for example:

Subsets: You can subset any object in the data model by naming it and reuse it, like LocalEmployee IS A Employee WHERE (type='local') later on you can use it as another object like (SELECT employee.name FROM LocalEmployee WHERE project.name = 'Blah')

Functions: You can define piece of calculations and apply it to a set, like TotalSalaries "employee.salary.sum()" and you can use it with any set related to the function scope like (SELECT TotalSalaries() FROM project WHERE project.name = 'Blah') or (SELECT TotalSalaries() FROM organization WHERE organization.name = 'Accorpa')

This query language called PQL (Perception Query Language) is a extension of SQL and very similar to it, We did our best to make it looks familiar to the SQL developer.

HAPPY ORGANON!