International Journal of Computational Intelligence and Information Security, March 2013, Vol. 4 No.

3, ISSN: 1837-7823

Improved Data Integrity Through Integrated Database Trigger Model
Yaya Itai (PHD student of Babcock University) Computer Science & Math Department Babcock University, Nigeria AWODELE OLUDELE PhD Computer Science & Math Department Babcock University, Nigeria OKOLIE S.O. PhD Computer Science & Math Department Babcock University, Nigeria NICOLAE GOGA PhD Molecular Dynamics Group University of Groningen, the Netherlands and Faculty of Engineering Politehnica University of Bucharest Romania Bujor Pavaloiu Politehnica University of Bucharest Romania

Database integrity ensures data entered into the database is accurate, valid, and consistent. The need to continuously audit database modifications cannot be overemphasize. The challenges faced in-terms of insufficient audit trail log being captured as a result of using the Data Manipulation Language (DML) commands, by privileged users has not been adequately addressed by the traditional database audit set up currently in place. Most business consulting auditors has raised concerns regarding the increasing level of database updates by information technology staff. As the auditors have no way of knowing what were inserted, deleted or updated in the database by privileged users. An integrated database trigger model developed using the benchmarked dynamic object technology model to supplement the built-in auditing features of the database. The resultant output from the proposed model was measured and analyzed using the oracle toad analyzer with a structured statistical questionnaire feedback mechanism. This model enhances Database Integrity, yield business systems with higher levels of integrity. The improved systems will allow financial auditors to rely more heavily on these techniques, which will improve audit quality and decrease costs.

Keywords: DML, Event Condition Action (ECA), Trigger, Data Integrity. 1.0 Introduction
Data integrity is a fundamental component of information security. In its broadest use, “data integrity” refers to the accuracy and consistency of data stored in a database, data warehouse, data mart or other construct; however it could also be used as a proxy for data quality. Data with integrity is said to have a complete or whole structure. All characteristics of the data must be correct; including business rules, relations, dates, definitions and lineage for the data to be complete. Data integrity is imposed within a database when it is designed and is authenticated through the ongoing use of error checking and validation routines. Integrity, in database terms, is therefore the quality of trustworthiness that the data in a database is imbued with; high levels of integrity. Database technologies are a core component of many computing systems. They allow data to be retained and shared electronically and the amount of data contained in these systems continues to grow at an exponential rate. So does the need to ensure the integrity of the data and secure the data from unintended access. Data modeling in terms of integrity is one of the most critical tasks in building an information system. Pair a welldeveloped and solid database design with extensive but appropriate integrated database triggers; the end result will be a database implementation that consistently yields accurate and timely information. Additionally, the database and its underlying data will realize greater data integrity with the reliance on external and sometimes faulty applications minimized, which will in turn contribute to higher audit quality and decreased business costs[1]. One of the most interesting types of integrity concerns is adherence to business rules. Those standard operating procedures and policies that dictate how an organization conducts transactions in its business environment. While such rules can be enforced in programs that use the database. If the business rules are implemented within the


International Journal of Computational Intelligence and Information Security, March 2013, Vol. 4 No. 3, ISSN: 1837-7823 database, they need not be recreated when new applications are developed but will be automatically enforced for all applications. The default database Audit trail that captures the DML activities entries (Update, Delete and Insert), does not capture the details of what were modified. It merely shows that entries were modified on database tables. Financial Institution auditors therefore have no way of knowing what were inserted, deleted or updated in the financial database tables which are risky to the business. Most business consultant /auditors today have raised concerns regarding the increasing level of database updates. For the purpose of this paper an integrated database trigger model developed using the benchmarked dynamic object technology model will supplement the built-in auditing features of the database. This model will enhance Database Integrity, yield business systems with higher levels of integrity. The importance of this paper cannot be overemphasized because of its significance to different groups of people that will benefit from the findings of this research work. The beneficiaries of this study include but are not limited to Financial Auditors, Financial Accountants, Auditing Companies, Regulators, Revenue Assurance experts etc. It will also serve as secondary source to those intending to carry out similar study in the same area. A better trigger exceptions handling capability will be used in this research, with ability to capture real values during DML operations. Update of transactions effectively limits the total number of triggers that can be specified for performance reasons. With a trigger, it is possible to check conditions such as “did not change” or “did not change within a certain percentage of a given period. These conditions can be true even if the relevant data is not updated, so they cannot be checked correctly in a trigger system driven by update events.

2.0 Literature Review
Martin Leissler, 2009 describe database triggers as a mechanism used to define a set of operations which are to be executed by the DBMS as soon as a given part of the data in the database changes. Using triggers to update an information visualization client has some advantage that no unnecessary database requests have to be made. That the delay in updating the information visualization on the client side is only dependent on the time it takes to send a message from the server to the client. Don Schlichting, 2009 defined triggers are stored TSQL code that is used to automatically perform a task when some type of SQL Server action occurs. As their name implies, a trigger is triggered or set off by some monitored action. These monitored actions can be one of three categories: DML, DDL, or a Logon Event. A DML trigger fires when an Insert, Update, or Delete statement is performed. DDL Triggers (Data Definition Language) are activated by a schema level event such as creating a table or altering an index. The last trigger type, Logon Trigger, is executed when a user begins a SQL Server session. David H. Olsen, 2009 defined data integrity as the quality of trustworthiness that the data in a database is imbued with high levels of integrity. It is axiomatic that integrity is crucial to accountants that use and audit such systems because no one would use or rely on a suspect accounting system. One of the most interesting types of integrity concerns is adherence to business rules; those standard operating procedures and policies that dictate how an organization conducts transactions in its business environment. Mahi Sony, 2006 describes database trigger as a set of instructions that runs automatically when a particular change operation is executed on a table in the database. This change operation happens when a SQL update, delete or insert operation is performed. Numerous corporate users use SQL triggers to enforce certain business guidelines, keep review check and validate input data. The basic problem that a user might encounter while executing a trigger is change in the programming code of the trigger while executing numerous set of instructions. The errors in programming code might occur due to improper shutdown, fatal virus attacks and more. Once the programming code of the trigger gets changed, the set of instructions followed by the trigger also changes, which might lead to serious database corruption. For example, a user is working in a bank and has created a SQL trigger which includes certain set of instructions to update the account of the user every time a user deposits some money. In such a scenario due to trigger corruption, instead of amount getting updated in the account, the amount might get deleted. Also, the account gets updated by some other amount. There can be numerous scenarios like this, which can corrupt the entire database. To resolve the above issue, the user needs to use effective SQL repair tool. This tool uses advanced scanning algorithms and extracts the valuable data from the database. This SQL recovery utility is 45

International Journal of Computational Intelligence and Information Security, March 2013, Vol. 4 No. 3, ISSN: 1837-7823 extremely useful when the database gets corrupted due to internal program errors, hardware malfunctioning, accidental deletion of data and more. Stellar Information Systems Ltd. provides the best SQL database recovery software. Stellar Phoenix SQL Database Recovery uses effective scanning algorithms, which enables perfect extraction of your critical data from SQL Server database. Steve Callan, 2004 categorized System triggers into two: those based on Data Definition Language (DDL) statements, and those based upon database events. Use of system triggers can greatly expand a DBA's ability to monitor database activity and events. Moreover, after having read this article, you'll be able to sharp shoot someone who asks, "How many triggers does Oracle have?" Most people will seize upon the before/during/after insert/update/delete on row/table easy-to-answer OCP test type of question (and answer), which is largely correct where plain vanilla DML triggers are concerned. How would you count INSTEAD-OF triggers when it comes to DML? So, how many other triggers does Oracle have or allow? There are a great many things you can do with triggers, whether they are based on DML statements or system events. As a developer or DBA (or both), there is no such thing as having too many tricks up your sleeve. In terms of job or role separation, think of the DML triggers as being in the purview of the developer, and the system event triggers being in the DBA's, but a good DBA should possess some decent programming skills of his or her own, and that's where knowing how to avoid problems with DML triggers comes into play. Decker, 2000 described a detailed method for generating provably correct triggers from declarative integrity constraints specified as first-order predicate calculus sentences. The method essentially consists of a translation of the results of the sound check approach (Decker, 1987) to SQL. Thibault Dambrine, 2001described database trigger automation as new for most researchers as they have only skimmed the surface. The concept is simple enough: Attach the process to the database level, and forget having to put it at the application level, but then there are so many other considerations. Commitment control can be a key component of a trigger-driven strategy for database integrity. It must however, be well understood and planned before starting out. A referential constraint is another powerful new tool available and it seems like a natural to work hand-in-hand with triggers. These two examples are obvious ones, but truly, the potential for using trigger process in daily data processing situations can be much wider.

2.1 The need for data integrity
Data integrity is the assurance that data is consistent, correct, and accessible, as we move into the database world, data integrity comes in many different types: null rules, unique column values, primary key values, referential integrity rules and complex integrity checking [13]. Without data integrity, we cannot even begin to be concerned with data quality since it assumes that we might not have all the data, or that we cannot access it either physically or logically, or that we can have no certitude of its condition. It becomes important to track logical data integrity as applications are implemented on architectures where data movement, operations or migrations might altar, truncate, delete or corrupt the data. This is particularly important in the context of systems of record. These are information storage systems that are considered the authoritative data source for a given piece of data or information. As a process, Data integrity verifies that data has remained unaltered in transit from creation to reception. As a state or condition, Data Integrity is a measure of the validity and fidelity of a data object. As a function related to security, a data integrity service maintains information exactly as it was inputted, and is auditable to affirm its reliability. Data undergoes any number of operations in support of decision-making, such as capture, storage, retrieval, update and transfer. Data integrity can also be a performance measure during these operations based on the detected error rate. Data must be kept free from corruption, modification or unauthorized disclosure to drive any number of missioncritical business processes with accuracy. Inaccuracies can occur either accidentally (e.g. through programming errors), or maliciously (e.g. through breaches or hacks) [9]. Businesses sometimes choose to use triggers over standard Oracle audit features because triggers offer the flexibility to tailor the audit transactions in the database to the unique business requirements. Using a trigger also presents the possibility to tune the performance of auditing activities and the option to store the audit trail in a user-defined tablespace to alleviate maintenance burdens on the SYSTEM tablespace.


International Journal of Computational Intelligence and Information Security, March 2013, Vol. 4 No. 3, ISSN: 1837-7823

2.2 Application of Triggers in data integrity
• • • • • Enforcement of Business Rules Provide sophisticated auditing Automatic generation of derived column values Prevention of Invalid Transactions. Fine-grained access control security policies

3.0 Methodology 3.1 Cheque management systems: model business rules explained.
The Integrated Cheque Management System is a web based application used in Cheque Management Center (CMC). The application is meant to automate the manual processes involve in cheque requisition and encoding. The application interacts with an Encoder machine to prints a branch’s name, customer’s name and the MICR CODELINE which are sent on-line from the branches on a physical Cheque. The prototype system illustrates using integrated database triggers. The company uses the following business rules: 1. Customer submits his/her reorder slip to request for a new chequebook at the branch. 2. The branch customer service officer captures the customer’s details in the reorder slip into systems using the appropriate menu, and then passes the slip to the head customer service. 3. The head customer service verifies the captured indents and post it if all entries are okay. A transaction-id is generated once the indent is verified. The transaction-id is written at the back of the customer’s reorder slip for record purposes. A transaction-id is generated because of the transaction that took place, the customer’s account is debited for the cost of chequebook and the branch’s cheque draft suspense account is credited on application. 4. Once the request is verified at the branch, it is available for the cheque management systems to process. 5. At the Cheque Management Center, the indent can be seen on the server database using the indent status enquiry menu on the application browser. The workstations connect to the server using the TNS name on the database to pull the record to the Encoder machine for printing. 6. After printing and binding at the Cheque Management Center, the cheque booklets are dispatch per branch using the Dispatch menu. The dispatch process batches the cheque booklets, with each batch having a dispatch number and a print-out. The printing and dispatch processes updates a table Job_queue on the cheque management database. All records tagged dispatched in the Job_queue table are moved by the feedback service back to host database. 7. Branches come to collect their physical cheque booklets from Cheque management center or from other locations. Do call over using the dispatch print-out and signs-off. 8. The Customer service officer at the branch receives the cheque booklets per customer on the application. Those that appear on the menu but the physical is not yet available are skipped. 9. The Customer service officer then ranges all the received cheque booklets in the host application. During ranging, the branch’s cheque draft suspense account is debited and the account of the cheque management center concerned is credited. Also the customer’s cheque range is uploaded to the account verified and acknowledged. 10. Customer comes to pick up his /her cheque book and signs on the print-out for collection.

3.2 Sample
The participants were 50 Database Administrators, IT Security personnel, Systems auditors and Financial Control randomly sampled from the three categories of financial institutions in Nigeria: • Continental Trust Nigeria limited and First-Trade of Nigeria limited • ABC Discount House The participants were stratified into male and female.

3.3 Survey Instrument
The survey instrument used for this research was developed based on established procedures in literature and stated objectives. The survey instrument has four broad areas: • DML operations • Enforcement of Business Rules


International Journal of Computational Intelligence and Information Security, March 2013, Vol. 4 No. 3, ISSN: 1837-7823 • Database auditing/security • Database performance evaluation Each area contained two sections A and B. Section A focused on demographic information of the Database Administrators, IT Security personnel, Systems auditors and Financial Control personnel Knowledge. Section B focused on the need to continuously audit database modifications in-terms of insufficient audit trail log being captured as a result of using the Data Manipulation Language (DML) commands.

3.4 Demographic
Table1: Demographic Variable Gender Male Female Area of Database Administrators specialization IT Security Personnel Systems Auditors Financial Control N 45 5 10 20 15 5 % 90 10 20 40 30 10

The demographic information of the participants is given in Table 2. The table indicates that 90% were male while female respondents were 10%; this shows that both male and female respondent were fairly represented base on the nature of this research. With regard to Rank representation the table shows that Database Administrators has 20% %, IT Security Personnel 40%, Systems Auditors has 30%, while Financial Control has 10%, of respondents, respectively; this indicates that all various key stakeholders were fairly represented.

3.5 Integrated Database Trigger Model
This paper requires a technology model that has predefined trigger concepts that can be easily modified to suite users’ needs. The DOM design has a structure that best suitable for handling changes [Riehle Et al 2000]. It will allow trigger and its components (Event, Condition, Action) to be changed at runtime. CMC DATABASE

Business Rule

Events, Condition &Action

Database predefined trigger rule and processing

Exception database store

End-User Reporting Web-view

Figure 1: Integrated database trigger model The integrated database trigger model is based on the fact that action taken to ensure data integrity depends on business rule that the data need to satisfy. It starts with preprocessed (original) database manipulation with a variety of exceptions. Database manipulations is checked against predefined triggers (in figure 1) in the database with the objective of obtaining correct and consistent data, and then are loaded into data exception database store. The effectiveness of the proposed model will depends on the triggers (rules) defined in the database [15].


International Journal of Computational Intelligence and Information Security, March 2013, Vol. 4 No. 3, ISSN: 1837-7823 Normally a trigger is defined in the Event-Condition-Action (ECA rule) fashion. Given this structure of a trigger language, a simple trigger can be generated automatically when supplied with necessary attributes. An event part of the model (a trigger) was used to perform operations such as updating, inserting, loading, etc. Complex predicates, functions or checks are contained in the condition part for checking errors, duplicate data, inconsistency, missing values, etc. It is necessary to specify the condition criteria for accepting that values are outside the exceptions band for the specified purpose. The condition criteria can apply to individual values as well as set of values. The condition criterion helps to identify the problem or problems. Once identification has been made then some transformation rules have to be implemented. The transformation rule specifies the action to be taken to transform data. This could be omitting a record, substituting a value, confirmation operations such as sending message alerts or other database operations, etc. The action part of a trigger will be activated when the condition is satisfied. The approach in this model consists of four stages namely: Business Rule, Database predefined trigger rule, Exception database store, End-User Reporting Web-view the trigger processing stages. The database defined trigger processing stage is for creation and manipulation of triggers and their components. Several different triggers are used in this model against CMC Database and one that is attached to SecurityChequeNumber table. 1. Validation of Security Number Duplication/Overlap: The system-wide validation should throw up an exception to prompt the user to reconfirm the entered security number. This is to cater for recycling of security number. However overlap/duplication on account level should throw up an outright error which the user must correct before proceeding. An additional validation to confirm the number of leaves on the indent and the sum of number of leaves (especially where there are replacements) on the SecurityNumber table should be done. Update of the Security number should be mandatory at printing. As a second level check, a validation run of any orphaned indent (without security number record) should be done during End of day processing. Provision to correct or input any wrong/missing securitynumber details should be provided. SecurityChequeNumber (Stores the primary Security Cheque Number) ChequeType (Stores the Cheque Types utilized for encoding. Modified to now include the number of leaves in a booklet for a specified cheque type). SecurityChequeStates (Stores the various cheque states of security cheque number items (e.g. un-used, missing, used items etc. )). SecurityReusableItems (Stores the Security Cheque Number Items that were skipped during encoding and thus can yet be used for encoding)

2. 3. • • • •

3.6 Tables Descriptions

3.7 Result
The Experiment showed how a wide range of security requirements for a database can be met by building application specific controls on a suitable trigger mechanism. The technique was illustrated using a detailed trigger model build around important tables in the database. The requirements of this application cover most aspects of security, including confidentiality, integrity and audit. This paper was also compared with similar researches in this area, the issue of real value tracking and database performance are addressed in this paper. Original SecurityChequeNumber table 2 ChequeNumber CusName SecurityNumber Operator_id PrintStatus PrintDate CaptureDate CusAcctNo 00000001 Musa 80881234 Sn01100 Y 15-0312-03-2013 0000565648 Ayeni 2013 00000002 Olufemi 97881234 Sn02400 Y 18-0311-03-2013 0123864765 Ojo 2013 00000111 Yekinni 00881234 Sn02401 N 19-0312-03-2013 9871235412 Ola 2013

When an updated SQL is fired on a cheque Number filed on the Original SecurityChequeNumber table, it inserts the updated new records in the ‘inserted’ logical tables. The old records, i.e. records before updating are entered into the trigger table as shown below. Exceptions handling were properly documented and used the programming section as shown in the appendix.


International Journal of Computational Intelligence and Information Security, March 2013, Vol. 4 No. 3, ISSN: 1837-7823 Original SecurityChequeNumber table3

ChequeNumber (old) 00000001

CusName Musa Ayeni

Security Number 80881234

Updated by Aderonke Adeshina

Updated date 18-032013

ChequeNumber (new) 57710856

In table3 above the ability to report before aspect of the DML operation in the cheque management systems database has been completely addressed. The CMC database health was examined for the most expensive sessions, and found to be normal using oracle toad utilities. An oracle third-party tool MGA’s Eagle eye was used to perform regression testing to get immediate of any change in the CMC database, by performing load testing as well as tracking the response times that the production users are receiving to serve as the service level agreement.

4. Conclusion
Data integrity is an important part of an organization’s daily operations and technology has a vital part to play in ensuring adequacy of data integrity. With the rising complexity of data integrity challenges, database triggers techniques go a long way to improving the effectiveness of data integrity issues. The use of the various database trigger techniques such as prevention of invalid transactions, financial business rule enforcement, sophisticated auditing and automatic column values derivation. Database trigger therefore has an important role to play in the enforcement of data integrity that would be capable of standing up to data integrity challenges we face in our operating environment today.

[1] Eric N. Hanson (2010), Integrity constraints in a transaction database using Triggers. [2] Martin Leissler, Matthias Hemmje, Erich Neuhold (2009)(GMD – German National Research Center for Information Technology. [3] Don Schlichting (2009), DML Triggers in SQL Server 2008 [4] David H. Olsen, Olga Yatsenko and Nicole Forsgren Meek ,“ENHANCING DATABASE INTEGRITY AND PROCESS AUTOMATION THROUGH SMART TRIGGERS” ( IACI 2002): 490-496 [5] Craig Mullins and Steve Callan (2004). Collaborative computing. [6] Steve Callan (2004), the trigger-happy DBA series on data manipulation language [7] Craig Buckler, 2011 database triggers operations and constraint’s. Crossman, P. (2007). The Less-Than-Obvious Costs of Ignoring Data Architectures . Wall Street & Technology. [8] David H. Olsen, Olga Yatsenko and Nicole Forsgren Meek ,“ENHANCING DATABASE INTEGRITY AND PROCESS AUTOMATION THROUGH SMART TRIGGERS” ( IACI 2002): 490-496 [9] Fergal Glynn (2012). Ensuring database integrity checks. [10] Steven H. Blackwell (2007). The importance maintaining data integrity and availability. [11] Trigger Functions, SQL Server 2012 [12] Y Jin (2009). A framework of fuzzy triggers for XML database systems. [13] Juff Ash(2006). Using triggers to maintain database integrity. [14] Chandrasekaran, S. & Kehoe, B. (2003). Technical comparison of Oracle real application Clusters vs. IBM DB2 UDB ESE. [15] Kanana Ezekiel and Farhi Marir (2006) enhancing data preparation processes using triggers for active data warehousing.


Sign up to vote on this title
UsefulNot useful