| Course | BU 453 Database Management |
|---|---|
| Unit | Unit 4 |
| Paper type | Schema implementation |
| Length | About 760 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 4
Sixteen Tables Created, Six Statements Rejected and One Constraint Removed Because the School Was Right: A Schema Implementation for a Composite Boise Music School
Student Name
Business, Herzing University
BU 453: Database Management
Instructor Name
February 25, 2026
Sixteen Tables Created, Six Statements Rejected and One Constraint Removed Because the School Was Right: A Schema Implementation for a Composite Boise Music School
From Design to Statements
This unit builds Harmony Hill's database, for the invented Idaho music school this course follows, in PostgreSQL 16. It creates every table from the normalized design and the model's remaining entities, declares keys and constraints as deliberate choices, loads enough rows to show that the structure holds, and records each statement the database rejected along the way. The PostgreSQL documentation describes constraints as the way to give the database itself control over what data may be stored, rather than relying on every program that writes to it to behave (PostgreSQL Global Development Group, 2024). Each constraint below therefore corresponds to a business rule from the owner's narrative or to a decision made in the model.
Sixteen tables were created: the ten that came out of normalizing the roster, plus six from the model that the roster never covered, namely Billing Account, Lesson, Invoice, Payment, Recital and Performance. The table below summarizes the keys and constraints of the central tables.
| Table | Primary key | Foreign keys | Other constraints and why |
|---|---|---|---|
| student | student_id (identity) | account_id to billing_account | last_name and birth_date required; birth_date must be before today |
| student_guardian | (student_id, guardian_id) | student_id, guardian_id | is_primary boolean; the pair key prevents listing the same guardian twice for one child |
| teacher | teacher_id | None | hourly_rate greater than 0 |
| term | term_id | None | season in fall, spring, summer; end_date after start_date |
| rate_card | (term_id, lesson_minutes) | term_id | lesson_minutes in 30, 45, 60; price greater than 0 |
| enrollment | enrollment_id | student_id, teacher_id, room_id, term_id; (term_id, lesson_minutes) to rate_card | unique (room_id, term_id, weekday, start_time); weekday between 1 and 7 |
| instrument | serial_number (text) | None | monthly_fee of 0 or more; condition from a fixed list |
| rental | rental_id | serial_number, student_id | end_date null or after start_date |
Choices Behind the Keys
Most tables use a generated number as the primary key, because names change and are not unique; two students named Emma Johnson are enrolled this term. Instrument uses its serial number, since the school already identifies instruments that way, the number is printed on each case, and it never changes. A generated number there would add a second identifier that staff would have to look up every time an instrument came back from a rental. Student Guardian and Rate Card use composite keys made of the columns that genuinely identify a row, which also prevents duplicates that a generated number would allow.
Foreign keys are declared with deletion restricted. A teacher, room or term that is referenced by an enrollment cannot be deleted, because deleting it would either leave orphaned enrollments or, if deletion cascaded, erase the school's teaching history. The one exception is Lesson, whose rows are deleted with their enrollment if an enrollment is removed before the term begins, since no lesson can yet have happened. Hoffer et al. (2019) note that the choice between restricting and cascading deletes is a business decision about what the organization is allowed to forget, and it is recorded as one here.
Loading Rows to Prove the Structure
A test data set was loaded in dependency order, parent tables before children: 25 billing accounts, 40 students, 30 guardians and 42 pairings, 14 teachers, 9 rooms, the spring 2026 term, 3 rate card rows, 52 enrollments, 20 instruments and 12 rentals. The rows were written as insert statements in a script, so the load can be repeated on a fresh database. Loading in the wrong order was tried once on purpose: inserting enrollments before teachers failed at the first row, because each enrollment's teacher did not yet exist, which confirmed that the foreign keys were active rather than merely declared. The script now drops and recreates every table at the start, so each test begins from an empty database. After loading, a query counting rows in each table confirmed every expected number, and a join of enrollment to its student, teacher, room and rate card returned all 52 enrollments, showing that every foreign key resolved.
What the Database Rejected
Six statements failed during the build. Each rejection was expected or instructive, and each is recorded with the constraint that caused it.
| Statement attempted | Rejected by | What it showed |
|---|---|---|
| Enrollment with 50-minute lessons | Check: lesson_minutes in 30, 45, 60, and the rate card foreign key | Only priced lengths can be booked |
| Second enrollment in room 4, Tuesday 16:00, spring term | Unique room, term, weekday, start time | Exact double-booking blocked; overlapping times are not, handled in Unit 7 |
| Rental of serial VN-3321, not in instrument | Foreign key to instrument | Instruments must exist before they can be rented |
| Delete teacher 9, who has enrollments | Foreign key with restricted delete | Teaching history cannot be erased by accident |
| Student with no last name | Not null | Required facts are enforced |
| Second guardian sharing an email with another guardian | Unique constraint on guardian email | The rule itself was wrong |
The last rejection changed the design. The first version made guardian email unique, on the assumption that each person has their own address. The test data, drawn from the school's records, included a married couple who share one email and are both guardians of the same children. The database refused the second parent, and it was right to refuse under the rule as written; the rule was wrong. The unique constraint was removed, and the change is noted in the design log with the reason. Connolly and Begg (2015) recommend testing a schema with realistic data before relying on it for precisely this reason: constraints encode assumptions, and some assumptions turn out to be false.
The double-booking rejection also exposed a limit. The unique constraint blocks two lessons starting at the same time in the same room, but it would allow a 60-minute lesson at 16:00 and another at 16:30, which overlap. That rule needs a constraint on time ranges rather than on start times and is carried to the integrity unit. Harmony Hill and all its test rows are composites for this course.
References
Connolly, T., & Begg, C. (2015). Database systems: A practical approach to design, implementation, and management (6th ed.). Pearson.
Hoffer, J. A., Ramesh, V., & Topi, H. (2019). Modern database management (13th ed.). Pearson.
PostgreSQL Global Development Group. (2024). PostgreSQL 16 documentation. https://www.postgresql.org/docs/16/
Reading the BU 453 Unit 4 instructions
The fourth unit of BU 453 asks students to implement their design as a working schema. Requirements usually include creating every table with primary and foreign keys, declaring constraints that enforce business rules, loading sample data to show the structure works and documenting errors encountered. Many instructors ask which database system to use; most accept any mainstream relational system if it is named. Real data volumes are rarely needed. Implementing in an employer's environment is discouraged. The submission typically includes the SQL script, evidence of loaded rows and an APA 7 explanation, and strong work records what the database rejected and what those rejections revealed about the design.
How this BU 453 Unit 4 example is built
The paper begins by naming the system and explaining that constraints give the database control over what may be stored. A table summarizes keys and constraints for the central tables with reasons. A section explains the choice of generated, natural and composite keys and why deletes are restricted, with one justified exception. A loading section describes the test rows, the dependency order, a deliberate wrong-order test and verification by counts and a join. A table records six rejected statements and what each showed. The final section explains how one rejection revealed a wrong rule and how another exposed a gap that the integrity unit must close. The script that builds the database is written to drop and recreate every table, so each test run starts from an empty and predictable state.
Reading the BU 453 Unit 4 rubric
Schema implementation rubrics usually weigh fidelity to the design, correct keys and constraints, justified choices, evidence of working data and honest documentation of problems, with presentation and sources. Fidelity earns full credit when every designed table and relationship appears. Keys and constraints score highest when they match the business rules. Justification rewards explaining choices such as restricting deletes. Working data is judged on loaded rows and a verification query. Documentation earns points when rejected statements are recorded with their causes, since rejections are evidence that constraints work. Instructors also credit students who change a constraint when testing proves it wrong, and who say why.
BU 453 Unit 4 help: mistakes that cost points
Schema submissions often lose points by declaring tables without foreign keys, which lets orphan records slip in. Another common problem is constraints with no stated reason, or none at all beyond primary keys. Students frequently use names as keys and then discover duplicates. Some cascade deletes everywhere, allowing one mistake to erase history. Others load data in the wrong order and remove constraints to make it fit, rather than fixing the order. Many report only successful statements, hiding what the database refused. Finally, building the schema inside an employer's systems risks affecting live data; a separate practice database is the right place for coursework.
Get a BU 453 Unit 4 example written to your instructions
Forward your Unit 4 assignment page with the BU 453 rubric, the model you built earlier, and any platform or file format your section requires. The custom example creates the tables in a runnable order, ties every constraint to the scenario, includes inserts written to fail, and reports what the database refused. First custom sample free, returned 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 5: Single-table queries
- BU 453 Unit 6: Joins and aggregation queries
- BU 453 Unit 7: Integrity and transactions
- BU 453 Unit 8: Database design project
- BU 407 Unit 4: Optimization model summary
- BU 451 Unit 4: Control flow and functions
- BU 351 Unit 4: Exploratory analysis
- BU 454 Unit 4: Time series visualization
BU 453 Unit 4 questions, answered
Which database system should I build this in?
Whichever one your classroom names, and the instructions will say. Sections differ on this, and syntax for keys, types and constraints varies enough between systems that a submission written for the wrong one reads as careless even when the design is sound. If the choice is genuinely left open, say at the top which system your script targets so the marker reads your statements against the right rules.
Do I need to load real volumes of data?
No, and a large load usually hides the deliverable. What earns the criterion is a small set of rows selected to exercise the structure: one row that fills every column properly, one that violates each constraint in turn, and one that tests a relationship at both ends. A handful of rows with intent behind them demonstrates more than thousands generated at random.
Could I implement the schema inside my employer's environment?
Keep the work out of it entirely. Creating tables on a company server touches infrastructure somebody else is accountable for, connection details do not belong in a graded file, and any rows you load or query afterward are the organization's records. Build on a local install or whatever the classroom provides. Work you do inside the employer's systems is the employer's, on their terms, and it is never something we would draft.
Where can I find a free BU 453 Unit 4 sample paper?
This page offers the complete BU 453 Unit 4 schema implementation for free, including the constraint table, the rejected statements and margin notes. For your own design, email the prompt and a custom implementation write-up is prepared free, usually within 48 hours.
Which database system should BU 453 Unit 4 use?
Any mainstream relational system the course allows, named clearly. The sample uses PostgreSQL 16 because it supports the range-based constraints the school's booking rules later need.