When analyzing databases for cloud computing or SOA, or SOA using cloud computing, integrity issues constantly crop up. In order to address these, it is important to understand the rules and logic that were applied to the construction of the database. For example, will the application allow the update of customer information in a customer table without first updating demographics information in the demographics table?
Most middleware, such as the middleware that connects on-premise systems to clouds, take into account the structure or rules built into the databases being connected. As a result, there exists the very real threat of damage to the integrity of target databases when relationships are not properly understood and/or defined.
While some databases, including on-premise and cloud-based, do come with built-in integrity controls (such as stored procedures or triggers), most rely upon the application logic to handle integrity issues on behalf of the database. Unfortunately, the faith implicit in this reliance is not always well-placed. Indeed, all too often it is painfully naïve when you consider the fact that your cloud computing system will be widely distributed, which makes it difficult to create a common control mechanism to protect database integrity.
The lack of integrity controls at the data level (or, in the case of existing integrity controls, bypassing the application logic to access the database directly) could result in profound problems. Architects and developers need to approach this danger cautiously, making sure they do not compromise databases' integrity in their zeal to move to cloud computing.