| Course | BU 453 Database Management |
|---|---|
| Unit | Unit 7 |
| Paper type | Integrity and transactions |
| Length | About 750 words, 5 pages |
| Format | APA 7 student paper |
| School | Herzing University |
| Program | BS in Business Analytics |
| Updated | September 2026 |
Free sample paper for BU 453 Unit 7
Five Rules the Database Enforces and One Enrollment That Must Happen Whole or Not at All: Integrity and Transactions for a Composite Boise Music School
Student Name
Business, Herzing University
BU 453: Database Management
Instructor Name
April 8, 2026
Five Rules the Database Enforces and One Enrollment That Must Happen Whole or Not at All: Integrity and Transactions for a Composite Boise Music School
Rules That Come From the Business
Harmony Hill's schema, built for this course's fictional Boise music teachers, already enforces keys, required fields and allowed values. The relationship register recorded three business rules that cardinality could not express, and the office has since added two more. This unit implements all five in PostgreSQL 16, ties each to the business fact that demands it, shows the statement the database turned away, and then works through a sequence of changes that must succeed together or leave no trace.
Where a rule lives is itself a decision. The school's scheduling screen is used by three office staff, and a booking tool is planned for parents. A rule written only in one program would be bypassed by the other. Rules that protect the meaning of the data are therefore placed in the database, where every program must pass them; rules about presentation, such as which weekday a form shows first, stay in the application.
The Five Rules
Each rule names its source, its mechanism and the statement it refused during testing.
| Rule | Business fact (narrative sentence) | Mechanism | Statement refused in testing |
|---|---|---|---|
| 1. No overlapping lessons in a room | Each lesson is in one room at a fixed time (S2) | Exclusion constraint: same room, term and weekday may not have overlapping minute ranges | A 30-minute lesson at 16:30 in room 4 on Tuesday, overlapping a 60-minute lesson at 16:00 |
| 2. An instrument is out to one student at a time | Only one student at a time (S7) | Exclusion constraint: same serial number may not have overlapping rental date ranges | A rental of VN-2201 starting March 1 while an earlier rental of it had no end date |
| 3. A minor has at least one guardian | Under-18 students need a guardian (S4) | Constraint trigger checked when the transaction commits | A new 9-year-old student committed with no guardian row |
| 4. Payments never exceed the invoice | The family is billed a set amount (S5) | Trigger comparing total payments with the invoice amount | A $200 payment against a $180 invoice |
| 5. Lesson outcomes from a fixed list | Four outcomes listed by the owner (S8) | Check constraint | A lesson marked 'teacher sick' |
Rules 1 and 2 solve the problem the schema unit left open. The unique constraint on start times blocked two lessons starting together but allowed overlaps. An exclusion constraint compares ranges instead: PostgreSQL rejects a new row if another row with the same room, term and weekday has a time range that overlaps it, using an extension that lets ordinary columns and ranges be compared in one index (PostgreSQL Global Development Group, 2024). The same mechanism enforces the rental rule by comparing date ranges, with an open rental treated as running indefinitely.
Rule 3 is checked at commit rather than immediately, because a new child and their guardian are entered in two steps. Checking the moment the student row arrives would reject every new child; checking when the transaction ends allows the guardian to be added in the same transaction and rejects only a child left without one.
A Sequence That Must Hold Together
Enrolling a returning student for the summer term involves three changes: an enrollment row, the first month's invoice and the deposit payment the family makes at the desk. If the enrollment were saved and the invoice failed, the student would have a lesson slot and no bill; if the invoice were saved and the enrollment failed, the family would be billed for nothing. The three changes are therefore wrapped in one transaction: the office program begins a transaction, makes the three inserts, and commits only if all succeed. Haerder and Reuter (1983) named the properties such a transaction must have, atomicity, consistency, isolation and durability, and atomicity is the one at stake here: all of it happens, or none of it does.
| Step | Statement | Outcome |
|---|---|---|
| 1 | BEGIN | Transaction opened |
| 2 | Insert enrollment for student 118, room 3, Monday 17:00, 45 minutes, summer term | Accepted, not yet visible to other users |
| 3 | Insert invoice for account 42, $180 | Accepted, not yet visible |
| 4 | Insert payment of $200 against that invoice | Refused by rule 4: payment exceeds invoice |
| 5 | ROLLBACK issued by the program on the error | Steps 2 and 3 undone; no enrollment or invoice remains |
| 6 | Repeat with a $180 payment, then COMMIT | All three rows saved together |
What the Rules Cost
Each rule has a cost that the design accepts knowingly. The exclusion constraints need an extension installed in the database and an index that slows inserts slightly; with a few hundred enrollments a term, the delay is too small to measure. The guardian rule, checked at commit, means a program that forgets to add the guardian in the same transaction will see its whole transaction refused, which is inconvenient but correct. The payment trigger must be updated if the school ever allows prepayment credit, since that would make an overpayment legitimate. These costs are recorded in the design log beside each rule, so that a future change in the business can be traced to the rule it affects rather than discovered when a valid entry is refused.
Testing the Failure, Not Only the Success
The sequence worked on the first normal run, which proved little. A transaction's value lies in what happens when something goes wrong, so each step was made to fail on purpose: an invalid room in step 2, a missing account in step 3 and the overpayment in step 4. In every case, a query afterward confirmed that no partial rows remained. Isolation was tested too: two office sessions tried to book the last Monday 17:00 slot in room 3 at the same moment. The exclusion constraint let the first commit and refused the second, so the double booking the school had suffered twice last year could not happen. Connolly and Begg (2015) recommend testing concurrency explicitly, since conflicts that never occur with one user appear quickly with several. Harmony Hill and all its data are invented for the course.
References
Connolly, T., & Begg, C. (2015). Database systems: A practical approach to design, implementation, and management (6th ed.). Pearson.
Haerder, T., & Reuter, A. (1983). Principles of transaction-oriented database recovery. ACM Computing Surveys, 15(4), 287-317. https://doi.org/10.1145/289.291
PostgreSQL Global Development Group. (2024). PostgreSQL 16 documentation. https://www.postgresql.org/docs/16/
BU 453 Unit 7 instructions, in plain terms
BU 453 Unit 7 asks students to implement integrity rules and demonstrate transactions. Common requirements include tying each constraint to a business rule, choosing the right mechanism, showing statements the database rejects, and working through a multi-step change that must be atomic. Many instructors ask whether rules belong in the database or the application; rules that protect data meaning generally belong in the database. Students are often told that a transaction that always succeeds proves little and should be tested with failures. Documenting constraints on a system administered at work is discouraged. A rule table, a transaction walkthrough and APA 7 explanation are typical deliverables for this unit.
How this BU 453 Unit 7 example is built
The paper explains where rules should live given several programs using the data. A table lists five rules with their business source, mechanism and a refused statement. Paragraphs explain range-based exclusion constraints and why the guardian rule is checked at commit. A section describes the enrollment, invoice and deposit sequence and why it must be atomic, citing the origin of transaction properties, followed by a step table showing a refusal and rollback. A section records what each rule costs. The final section describes testing each step's failure and two simultaneous bookings of the same slot, and notes that the double booking the school once suffered is now impossible. Every refused statement is kept in a test script, so the rules can be checked again after any future change to the schema.
Reading the BU 453 Unit 7 rubric
Integrity and transaction rubrics at Herzing usually reward rules tied to business facts, appropriate mechanisms, demonstrated refusals, a correct atomic sequence and testing of failure and concurrency, with writing and sources. Business ties earn full credit when each rule cites its source. Mechanisms score highest when matched to the rule, such as range constraints for overlaps. Refusals reward showing a specific rejected statement. The transaction criterion is judged on whether partial changes are impossible and a rollback is shown. Testing earns points when failures and simultaneous users are tried on purpose. Instructors also credit discussion of where each rule should live and what it costs.
Common BU 453 Unit 7 mistakes, and how to avoid them
Integrity exercises often lose points by listing constraints without saying which business rule each enforces. Another common problem is enforcing rules only in the application, where another program can bypass them. Students frequently use unique constraints on start times to prevent overlaps, which misses partial overlaps. Some check age-dependent rules too early, rejecting valid multi-step entries. Others show a transaction that succeeds but never demonstrate a rollback. Concurrency is rarely tested. Many ignore the cost of rules, such as blocking legitimate cases later. Finally, documenting constraints on a system you administer at work may expose security details that should stay private.
Get a BU 453 Unit 7 example written to your instructions
Share the Unit 7 brief along with your BU 453 rubric, the schema you built earlier, and whatever scenario the assignment supplies. The custom example ties each rule to a sentence in the case, shows the statements the database refused, and interrupts a multi-step sequence deliberately to report where the rows were left. First custom sample free, back in 24 to 48 hours.
More BU 453 papers and business analytics samples
- BU 453 Unit 1: Requirements to entities exercise
- BU 453 Unit 2: Entity relationship diagram
- BU 453 Unit 3: Normalization exercise
- BU 453 Unit 4: Schema implementation
- BU 453 Unit 5: Single-table queries
- BU 453 Unit 6: Joins and aggregation queries
- BU 453 Unit 8: Database design project
- BU 351 Unit 7: Reporting to a business audience
- BU 407 Unit 7: Simulation output brief
- BU 451 Unit 7: Error handling and validation
- BU 455 Unit 7: Cost and capability analysis
BU 453 Unit 7 questions, answered
Should the rules live in the database or in the application?
Both positions are defensible and the unit generally wants the argument rather than a verdict. A rule enforced by the database holds regardless of what connects to it, which is why a requirement the organization cannot afford to have broken is commonly placed there. A rule in the application can explain itself to a person more gracefully. Say where you put each one and what the placement costs.
My sequence works every time I run it. Now what?
Break it on purpose, which is the exercise rather than a sign that something went wrong. Interrupt the run between two statements, or attempt a change the constraints will refuse, then record where the rows stood afterward. A submission reporting only clean runs has shown the database working under easy conditions and has left the part of the criterion about protection completely unaddressed.
Could I document the constraints on a system I administer at work?
Not inside a graded file. A constraint list is a map of the rules the organization runs on, and the sequences you would use to illustrate it are its real transactions. Administering that system is your own job, on your employer's terms, and it is never work we would draft. Build the example on the assignment schema, where nothing is exposed and a marker can check every line.
Where can I find a free BU 453 Unit 7 sample paper?
Read the full BU 453 Unit 7 integrity and transactions example above without paying, including the rule table, the rollback walkthrough and margin notes. For different rules or systems, send the assignment and a custom example is prepared free, usually within two days.
Should rules live in the database or the application in BU 453 Unit 7?
Rules that protect what the data mean belong in the database, where every program must obey them. The sample keeps presentation choices in the application and enforces all five business rules in PostgreSQL.