![]() |
![]() |
|
![]() |
Data Integrity Introduction By: Liz Woodhouse Paradox Community Introduction This article assumes the reader has a basic knowledge of interactive Paradox including how to make tables, how to make forms, how to link tables in a data model and how such links work. When designing a database, assuring the integrity of the data our database will hold is vital. Before we can implement measures to ensure our data's integrity, we must understand what data integrity is. Simply put, it is consistency. Our data has integrity when it is consistent with the limits we set for it. Without that consistency, analysis of our data can range from inaccurate to difficult to impossible, thus eliminating the reasons for having a database in the first place. In this article, we'll discuss some of the threats to our data's integrity and the interactive features built into Paradox® to help us protect against those threats. (Note that this article is not meant to be all inclusive on the subject; it is meant as an introduction or overview of data integrity issues.) Threats to Data Integrity A good policy to adopt regarding data integrity is that if it can be compromised, it will be. That said, it's up to each of us individually to assess the threats to our data and take what steps we deem necessary and reasonable to protect it from integrity loss. The following are some of the threats our data's integrity may face (I'm sure I've missed some, but it's a starting point):
Preventing Integrity Loss Malicious attack: To help prevent damage via malicious attack, Paradox includes the ability to password protect your tables. However, this feature is not secure enough to prevent someone with serious intent. Additional steps we might take to protect our data from the malicious attacker might include: secure physical access (that is, prevent the attacker from getting to the computer which holds the data or to a computer linked to the one holding the data); take advantage of any operating system security features on the computer and/or network which holds the data and on those computers linked thereto; secure our application interface to prevent unauthorized access (via usernames, passwords and code); install Paradox Runtime (which disallows direct table access); have a good backup plan, implement the plan, test the plan (including testing data recovery steps). Hardware problems: These are usually associated with corruption, which can impact integrity even after the corruption is "repaired." To prevent damage from hardware problems, we might try some of the following: attach every computer (and any other data collection device) to a battery backup, test the backup power regularly, replace as needed, ensure the backup either automates graceful shutdown or allows sufficient time for the user to do so and train the user; run available maintenance and testing utilities regularly and don't dismiss errors; have a good backup plan, implement the plan, test the plan (including testing data recovery steps). Data entry error: I only know of three ways to protect data against user error. One is user behavior: hire the right ones, train them, discipline them, fire them, etc. The second is application design and utilizing the features available to force integrity constraints. We'll discuss these in the next section. The third is to have a good backup plan, implement the plan, test the plan (including testing data recovery steps). Application design: An application's design can greatly affect data integrity. An easy to understand interface can go a long way toward making data entry easier and, by extension, more correct. A poorly designed database (table structure) can cause data to be unnecessarily duplicated thus increasing the possibility of inconsistency between tables (violating referential integrity, which we'll discuss in a separate article). A poorly designed database can also leave our tables themselves exposed to data entry or modification which is not consistent with desired limits if users gain access to the tables or if we don't design the interface to ensure inconsistencies are not allowed. We'll discuss how to use application design to help assure data integrity in more detail in the next section. For now, it's enough to note that to prevent loss of integrity due to application design we should have a good backup plan, implement the plan, test the plan (including testing data recovery steps). For more information on good application design and especially data normalization (which is vital to both data integrity and referential integrity), please visit the Paradox Resources page at RDA World Wide. The papers on Data Normalization, Database Basics and Containership (all by Denn Santoro) cover topics relevant to good application design. Other: Whatever the threat, to avoid loss, we should establish a procedure which the database administrator can follow on a regular basis to reveal loss of integrity. The procedure might include a series of manual steps as well as a fixed set of queries and/or code which will reveal integrity loss and provide sufficient information to determine probable causes. This procudure should be executed when no users are in the system in order to avoid false results caused by partially completed records, records being changed, a collection of deletes which isn't done yet, etc. The procedure should also be executed whenever corruption has occured (that a table was "successfully" repaired does not mean that data integrity has not been compromised). In addition to using the information provided by this procedure to fix the data, we should also use it to identify and plug holes in our application design, identify and investigate potential hardware problems, identify needs for user training, etc. And most importantly, we should have a good backup plan, implement the plan, test the plan (including testing data recovery steps). Built-in Data Integrity Features Paradox includes a number of built in features we can use to help ensure out data's integrity. It should be noted, however, that just because the feature exists doesn't me we have to use it. Whether we decide to use the built in feature, use code or other application design elements, or not to use anything at all, we must know what's available in order to make decisions about its use. Table structure features: The following features are available in the table structure dialog to help keep data within desired limits. I am assuming that the reader has some familiarity with Paradox and therefore, these will be not be discussed in detail here, but for those interested, they'll be covered in a future article in the "Building Tables" series. For now, more detail than what's offered here, can be found in the Paradox help files.
ObjectPAL®: ObjectPAL code can be used to enforce integrity constraints, however, as this article is intended for all users and to cover interactive features, we won't go into any further detail here. Conclusion The integrity of our data is vital, and Paradox includes a number of features to help us maintain data integrity. Knowing what these features are, we can make educated decisions on which ones are best for our environment, which ones we might want to investigate further, and which ones we may need to combine with additional steps in order to fully protect our data from integrity loss. Discussion of this article |
![]() Feedback | Paradox Day | Who Uses Paradox | I Use Paradox | Downloads ![]() |
|
![]() The information provided on this Web site is not in any way sponsored or endorsed by Corel Corporation. Paradox is a registered trademark of Corel Corporation. ![]() |
|
![]() Modified: 15 May 2003 Terms of Use / Legal Disclaimer ![]() |
![]() Copyright © 2001- 2003 Paradox Community. All rights reserved. Company and product names are trademarks or registered trademarks of their respective companies. Authors hold the copyrights to their own works. Please contact the author of any article for details. ![]() |
![]() |
|