Publishing data is actually pretty easy. There are lots of ways to do that. Now securing and organizing your data is the important bit that requires some thought. The term we use to describe the organizing and policing of your data is Business Logic. The business logic of your system is made up of business rules. Each business rule is a constraint or rule imposed on your data for application functionality that is a result of real world business requirements.
The Four Pillars of Business Logic
Business logic can be divided into four different categories. When designing your business logic, consider how these four pillars apply to your business rules.
This is where the classic transactions belong. When one value changes, another changes to maintain consistency. The example is a bank transfer: when money is removed from one account, it needs to be deposited into another account. The consistency also means that if the deposit into the second account fails, the money removed from the first account needs to go someplace, most likely back into the first account.
You don’t want all your users to see all the data. That is where view control comes in. View control business rules regulate what data users can see. Generally, this comes down to limiting users to specific rows and columns in tables. A user might only be allowed to see the rows relating to their sales data, but not the columns that track information only visible to their manager.
Most likely, not all users will be allowed to modify all the data in your system, or even all the data they can view. For example, your end users should probably not add or modify states or countries. It is typically much easier to restrict user’s modification control based on tables, but it gets more interesting when you need to restrict modification control for specific rows or columns in a table. For example, if a user can only modify sales records in their assigned region.
When one action leads to another, that is a secondary action. In database speak this is a trigger. A common example is logging – if you need to keep track of each change.
Implementing Business Logic
The great thing about all these business rules is that they change frequently. Some of them more often than others. One solution is storing all the business rules in the database. This has the advantage of being able to change them without deploying a new client, it has the disadvantage that any interactions of the client require a round trip to the database to know if they are legal. Additionally, having a database system robust enough to handle the kind of business logic necessary for a real world application is usually really expensive to license and maintain.
Storing all your business logic in the client makes the client more responsive since a round trip to the server is not necessary to validate user input and actions. It has the major downside that once your data is exposed, a 3rd party could create their own client, circumventing all your business logic and gaining free access to your data. Not to mention each change in business logic means redeploying all the clients.
Enter Data Abstract Business Rules Scripting
Data Abstract makes it incredibly easy to publish your data, and Business Rules Scripting makes it easy to express even the most complex business logic with very little demand on the database back end. To learn more about business rules scripting, you can read the Business Rules Scripting wiki entry, watch the Business Rules Scripting video on ROTV, or check out the free chapter on Business Rule Scripting.
Remember, exposing your data is just the start. Securing your data requires Data Abstract.