Data consistency is quite commonly heard both for MySQL like DBMS and big data. With the phrase “consistency”, in case of database systems, we want to refer towards meeting the requirement for any given database transaction. That is, any database transaction must only change affected data in allowed ways. For example, if we were storing a number in a database, only the numerical values are allowed. In other words – any data which will be written to the database must be valid maintaining all the defined rules of a particular system. However, data consistency is not a guarantee of correctness of the transaction in all ways. It is mostly for identifying any programming errors resulting in the violation.
A database can be said to be data consistent when the content under question does not give us the chance to infer a contradiction directly or indirectly. These conclusions are derived by keeping the database constraints specified in the database schema and any other inference rules in mind.
We can say that data that is consistent is the data which is formatted consistently. This makes the job of the people working with data easy simply because consistent data means that all the data can be handled in the same way. Also, data consistency when we have a weather dataset, in case of consistent data there will be no missing data such as of days/hours. In the case of data science, data inconsistency can render a useful data-set to completely unusable.
By definition, database transaction should be Atomic, Consistent, Isolated and Durable which makes the acronym ACID. A database transaction ideally should follow all-or-none law. That is, either the writing should be complete or nothing should be written. Consistency is a general term. All validation rules must be checked to ensure consistency. The entire transaction must be cancelled upon facing fault and the affected rows rolled back to their pre-transaction state.
That means, an ACID compliant database is not consistent while data is being written.