Issuu on Google+

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 in­flight 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 “backed­out” 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 in­synch and represent the true status of the application. Therefore, in my view it is in best interest to keep data on Trust­by­Trust 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 Trust­by­Trust 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 Trust­by­Trust 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 multi­stage  inference process. After updating the Data it should not affect its speed, availability and cost.


It should be Dynamic Data and Functional distribution, High­thoughtput,  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 Trust­by­Trust basis, so the data is easy to manage, easy to  access, fast, cost effective.


data