Data Consistency It summarizes the validity, accuracy, usability and integrity of related data between applications and across the IT enterprise. This ensures that each user observes a consistent view of the data, including visible changes made by the user's own transactions and transactions of other users or processes. Data Consistency problems may arise at any time but are frequently introduced during or following recovery situations when backup copies of the data are used in place of original data. There are many kinds of Data Consistency Point in Time Consistency, Transaction Consistency and Application Consistency.
Point in Time consistency Data is said to be Point in Time consistent if all of the interrelated data components are as they were at any single instant in time. The data is considered time consistent, due to the fact that the entire processing environment failed at the same time. Several types of errors can occur where Point in Time consistency is not maintained. For example, consider the failure of a single logical volume containing data from several applications. If the only recovery option is to restore that volume from a backup taken sometime earlier, the data contained on the restored volume is not consistent with the other volumes, and additional recovery steps must be undertaken. Transaction Consistency A transaction is a logical unit of work that may include any number of file or database updates. The data will not be transaction consistent if transactions were inflight at the time of the failure. In most cases what occurs is that once the application or database is restarted, the incomplete transactions are identified and the updates relating to these transactions are either “backedout” or processing resumes with the next dependant write. Application Consistency Application Consistency is similar to Transaction consistency, but instead of data consistency within the scope of a single transaction, data must be consistent within the confines of many different transaction streams from one or more applications. Application consistency is the state in which all related files and databases are insynch and represent the true status of the application. Therefore, in my view it is in best interest to keep data on TrustbyTrust basis and independently. There are several key facts to be considered: 1) Large Data can be managed and monitored efficiently
2) Avoiding Trust based constraints which can be imposed easily without affecting other Trusts, hospitals and resources 3) If the data is kept centrally, the data will be much more complex and this could lead to too many unnecessary conflicting constraints on the data 4) If the data is kept centrally, if the central systems are down. This could lead to unavailability of the data to any trust or hospital, and it may paralyse the entire medical system 5) Backup and Restore policies would be much more complex Data Availability It is use to describe products and services that ensure that data continues to be available at a required level of performance in situations ranging from normal through "disastrous." In general, data availability is achieved through redundancy involving where the data is stored and how it can be reached easily. Data availability can be measured in terms of how often the data is available and how much data can flow at any given time. Therefore, if we keep the data on TrustbyTrust basis it’s easy and simple to access and retrieve data from the database. For e.g. If the data is kept centrally, and if the user want to retrieve the information for particular hospital, department or any resource, user has to go through the entire database to find the relevant information, which can be tedious and can be slow in terms of performance for retrieving the data. However, on the other hand if the data is kept on TrustbyTrust basis and in distributed locations, user can directly find that information according to which trust it belongs to. It makes easy to manage and much easier to access. However, this setup does have few disadvantages for e.g. If user wants to access information from different sources (Trusts), they need to have access to those sources, where if the data kept centrally can be accessed by the same source. However, it does have advantages over this draw back. Data would be safe and secure from redundant access and security breach. Update Propagation Update propagation is performed automatically by a deductive database system. It is one of the key tasks, which is expected by a deductive database system to perform. Propagating an update basically means to determine all logical consequences. A single change of some base data may affect various deductive rules. The process of propagation constitutes a complex multistage inference process. After updating the Data it should not affect its speed, availability and cost.
It should be Dynamic Data and Functional distribution, Highthoughtput, Optimistic Replication and Load Balancing. These are the important characteristics must be kept in focus for update propagation. Therefore, if we keep the data centrally, it will affect on its speed, availability, data will conflict within itself. Data should be dynamic and functional dependent and distributed. In order to overcome with these issues I have kept the database on TrustbyTrust basis, so the data is easy to manage, easy to access, fast, cost effective.