Abstract
Organizations have many business rules (constraints) to implement in their daily operations. This is done mainly by action assertions traditionally implemented in procedural logic buried deeply within user’s application program in a form that is virtually unrecognizable, unmanageable, and inconsistent. This approach places a heavy burden on the programmer, who must know all the constraints that an action may violate and must include checks for each of these constraints. An omission, misunderstanding, or error by the programmer will likely leave the database in an inconsistent state.
Entity Relationship (ER) model is a common conceptual database design tool used for relational database design. To enforce the business rules, some business rules can be included in this ER model in the form of constraints. However, including constraints in this graphical model is just a reminder for the programmer to include them in his database implementation. The problem is that constraint is very rigid and the database becomes programmer dependent and there is no grantee that programmer will include them in his implementation.
An alternative solution for this problem is to implement the constraints in the form of triggers. Trigger is a program and is more flexible than a constraint. Trigger has Event, Condition and Action (ECA) property. When an event take place and consequently a condition becomes true, the trigger takes action automatically and modifies the database as needed. To write trigger, there is option of before and after. The option before means before the operation be performed, the trigger will be executed to make sure it is ok for the operation to be performed. If this is the case, the operation will be executed otherwise the operation will not be executed.
In the airplane maintenance system, there are a set of mechanics, a set of services and a set of tools. Mechanics provides service. Each service requires certain training. To provide a service, the mechanic must have received the required training before the service is provided. Also, the mechanic must use proper tools for that service. All these rules will be represented in the ER diagram as constraints and will be implemented by writing triggers. This system grantees that every service will be done by proper mechanic at the right time using proper tools. This is a sample project that students in our database class implement to get hands-on experience.
In this paper, we use the ER notation to represent some business rules (constraints) graphically for airplane maintenance database system and write triggers to implement them to ensure the consistency of the data in the database and proper services for the airplanes.
Are you a researcher? Would you like to cite this paper? Visit the ASEE document repository at peer.asee.org for more tools and easy citations.