Database Design Documentation​

​
I. Problem Statement & System Requirements​
Animal shelters and pet adoption organizations often face complex operational challenges when
managing data related to pets, adopters, donors, volunteers, staff, and veterinary care. Many
such organizations still rely on spreadsheets, paper records, or disjointed systems that lead to
inefficiencies, data redundancy, and human error. Without a centralized and automated
database system, it becomes difficult to track pet histories, manage adoptions, coordinate
volunteers, handle donations, and ensure timely veterinary checkups. These issues can hinder
the organization’s mission to provide effective care and find loving homes for animals in need.

This project proposes the design and implementation of a Pet Adoption Management System
(PAMS) – a comprehensive, relational database solution that supports the core functions of a
pet adoption center. The system will store and organize data about pets, their health and
adoption status, adopters, donations, staff involvement, vet checkups, and volunteer activities.

With this system, the organization can streamline:

●​ Pet intake and adoption tracking, ensuring each pet has a complete history from
arrival to adoption.​

●​ Donor management, to track contributions and the staff assigned to handle them.​

●​ Volunteer assignments, including managing who is caring for which pets.​

●​ Adoption processing, ensuring transparency and traceability of adopter-pet

relationships.​

●​ Veterinary checkups, making sure each pet receives proper medical attention and
follow-ups.​

●​ Reporting and analytics, such as adoption rates, donation trends, and volunteer
engagement.​

By solving these challenges, the database improves operational efficiency, enhances animal
welfare, increases transparency, and supports strategic planning and community engagement.
This project not only addresses administrative bottlenecks but also promotes responsible pet
adoption practices through reliable information management.
System Requirements
🔹 Functional Requirements
1.​ Pet Management​

○​ Add, update, and retrieve pet profiles including species, breed, health status, and
adoption status.​

○​ Track pet arrival dates and assign health checkups.​

2.​ Adoption Management​

○​ Record and manage adoptions including adopter information, adoption dates,

follow-up dates, and assigned staff.​

○​ Update pet status upon successful adoption.​

3.​ Adopter Management​

○​ Store and retrieve detailed adopter information.​

○​ Link adopters to the pets they have adopted.​

4.​ Donation Management​

○​ Record donations with donor details, purpose, type, and assigned staff.​

○​ Track donation history by donor.​

5.​ Donor Management​

○​ Maintain records of all donors including contact info and donor types (individual,
corporate, etc.).​

6.​ Veterinary Checkup Management​

○​ Record vet checkup details including date, diagnosis, treatment, and assigned
vet.​

○​ Link checkups to specific pets.​

7.​ Volunteer Management​

 ○​ Manage volunteer profiles including skills and total hours served.​

○​ Assign volunteers to pets and log assignment dates.​

8.​ Staff Management​

○​ Track staff roles and assign them to handle donations, adoptions, or volunteers.​

9.​ Reporting​

○​ Generate reports such as:​

■​ Number of adoptions per month​

■​ Total donations received​

■​ Pet status summaries​

■​ Volunteer activity logs​

10.​Security and Data Integrity​

○​ Enforce data constraints (e.g., foreign keys, unique constraints).​

○​ Trigger updates (e.g., pet status changes after adoption).​

○​ Prevent deletion of records with active relationships (referential integrity)

II. Conceptual Design

●​ E-R Diagram: A complete Entity-Relationship diagram showing all entities, relationships,

attributes, and cardinalities​
●​ ER Schema Diagram using (min, max) notation: Enhanced E-R diagram with minimum
and maximum cardinality notations
●​ UML Class Diagram: Representing the database schema using UML notation
III. Logical Design

●​ Relational Schema: Conversion of your E-R design to relational schema with proper
notation

●​ Normalization Analysis: Documentation showing your normalization process (up to 3NF

or BCNF)

First Normal Form (1NF)​

A table is in 1NF if:

●​ All attribute values are atomic (indivisible).​

 ●​ There are no repeating groups or arrays.​

Analysis:​
All entities in the design (e.g., Donor, Staff, Volunteer, Pet, Vet) satisfy 1NF:

●​ Each field contains a single value per record (e.g., phone, email, name).​

●​ No multi-valued or nested attributes exist.​

●​ Composite keys (used in weak entities like Pet_Assignment and Volunteer_Assignment)

are appropriate and do not violate atomicity.​

✅ Conclusion: All tables satisfy 1NF.

Second Normal Form (2NF)​

A table is in 2NF if:

●​ It is in 1NF.​

●​ All non-key attributes are fully functionally dependent on the entire primary key (no
partial dependencies).​

Analysis:​
Tables with composite primary keys (e.g., Pet_Assignment, Volunteer_Assignment)
were closely examined:

●​ All non-key attributes depend on the entire composite key (volunteer_id,

pet_id, assignment_date).​

●​ For single-attribute primary keys (e.g., adoption_id, pet_id, staff_id), partial

dependencies cannot exist.​

✅ Conclusion: All tables satisfy 2NF.

Third Normal Form (3NF)​
A table is in 3NF if:
 ●​ It is in 2NF.​

●​ There are no transitive dependencies (non-key attribute depending on another non-key

attribute).​

Analysis:

●​ Each table was reviewed to ensure that all non-key attributes depend only on the
primary key and not on another non-key attribute.​

●​ Example: In the Adoption table, attributes like contract_signed,

follow_up_date, and adoption_date are all direct facts about the adoption, not
about adopter or pet.​

●​ Potential issues (like storing adoption_status in both Pet and Adoption) are
justified based on current system usage and history tracking.​

✅ Conclusion: All tables satisfy 3NF.

Boyce-Codd Normal Form (BCNF)​

A relation is in BCNF if:

●​ Every determinant is a candidate key.​

Analysis:

●​ All functional dependencies originate from the primary keys.​

●​ No dependency violates the condition that only candidate keys determine other
attributes.​

✅ Conclusion: All relations are in BCNF as well.

 ●​ Data Dictionary: Comprehensive documentation of all tables, attributes, data types,
constraints, and descriptions

# Normalization Analysis for the Adoptions Data

UNF (Unnormalized Form)

- Structure: All information is stored in a single table, with repeating groups and non-atomic
fields (e.g., multiple pets and donations in one cell, delimited by `;` or `,`).

- Problems:

- Data redundancy (duplicate data).

- Update anomalies (difficult to update a single pet or donation).

- Insertion and deletion anomalies (adding or removing one element is difficult).

- Hard to query and maintain data integrity.

AdoptionID​ AdopterName​ AdopterPhone​StaffName​ AdoptionDate​ Pets​ Donations

1​ John Doe,​ 555-1234,​ Alice Brown,​ 2025-06-01,​ Max,Dog,Beagle,Healthy;

Bella,Cat,Persian,Sick​ 4001,Mary Smith,100,2025-05-31; 4002,Paul
White,50,2025-05-30

2​ Jane Smith,​ 555-5678,​ Bob Green,​ 2025-06-02,​

Charlie,Dog,Labrador,Healthy​ 4003,Anna Lee,75,2025-06-01

3​ Sam Wilson,​ 555-8765,​ Cathy Black,​ 2025-06-03,​ Oscar,Cat,Siamese,Healthy;

Daisy,Dog,Poodle,Healthy​ 4004,Tom Young,120,2025-06-02; 4005,Sue Kim,60,2025-06-02

4​ Linda Brown​ 555-4321,​ Alice Brown​ 2025-06-04​ Milo,Dog,Bulldog,Sick​

5​ Peter Parker​ 555-2468​ Bob Green​ 2025-06-03​ Luna,Cat,Bengal,Healthy;

Rocky,Dog,German Shepherd,Healthy; Coco,Bird,Parrot,Healthy​ 4006,Peter
Parker,200,2025-06-03

6​ Emily Davis​ 555-1357​ Cathy Black​ 2025-06-04​ Shadow,Cat,Tabby,Sick​

4007,Emily Davis,50,2025-06-04

---
1NF (First Normal Form)

- Rule: Eliminate repeating groups and ensure all fields contain atomic (single) values.

-Action:

- Each column contains only one value per row.

- Repeating groups (like multiple pets or donations) are removed by creating new rows or by
encoding as atomic fields (usually resulting in a wide table if not further normalized).

- Result:

- Still one table (wide and potentially sparse).

- No repeating groups, but still contains partial dependencies if there are composite keys.

---

2NF (Second Normal Form)

- Rule: Remove partial dependencies—every non-key attribute must depend on the whole of
every candidate key (for tables with composite keys).

- Action:

- Split the table into multiple tables to separate data that does not depend on the full primary
key.

- Typically, this means creating separate tables for entities like Pets and Donations, and linking
them via foreign keys to an Adoption or Adopter table.

- Result:

- Multiple tables: Adoptions, Pets, Donations, etc.

- Each non-key attribute is fully functionally dependent on the primary key of its table.

- Resolves partial dependency anomalies.

---
3NF (Third Normal Form)

- Rule: Remove transitive dependencies—non-key attributes must not depend on other non-key
attributes.

- Action:

- Further decompose tables so that every non-key attribute depends only on the primary key.

- For example, separate Adopter and Staff information into their own tables, and have the
Adoptions table reference them by foreign key.

- Result:

- Tables: Adopters, Staff, Adoptions, Pets, Donations, and linking tables like AdoptionPets.

- All non-key fields relate only to the primary key.

- Data redundancy is minimized, update anomalies are eliminated, and data integrity is
maximized

Example of Final Normalized Tables (3NF)

- Adopters (`AdopterID`, `AdopterName`, `AdopterPhone`)

- Staff(`StaffID`, `StaffName`)

- Adoptions (`AdoptionID`, `AdopterID`, `StaffID`, `AdoptionDate`)

- Pets (`PetID`, `Name`, `Type`, `Breed`, `HealthStatus`)

- AdoptionPets(`AdoptionPetID`, `AdoptionID`, `PetID`)

- Donations (`DonationID`, `AdoptionID`, `DonorName`, `Amount`, `DonationDate`)

IV. Physical Design

●​ SQL DDL Scripts: Complete set of SQL scripts for creating your database
schema (tables, constraints, indexes)
●​ Sample Data: SQL INSERT statements to populate your database with
meaningful sample data (minimum 10 records per table)
●​ Database Schema Diagram: Visual representation of your final database schema
showing all tables and relationships
V. Implementation and Queries

●​ SQL Query Set: At least 15 SQL queries demonstrating various SQL features:

Basic SELECT queries with filtering and sorting:​

​
Get all adopters ordered by last name​
Get all pets that are currently pending for adoption

Get volunteers who served more than 50 hours

Aggregate functions and GROUP BY queries:

Count of pets by species

Number of adoptions handled by each staff

donation type and count donations per donor
Joins (INNER, LEFT, RIGHT, FULL):

INNER JOIN: Get adopter info with their adopted pets

LEFT JOIN: List all pets and any corresponding vet checkup
RIGHT JOIN: Volunteers and pets they are assigned to care for
FULL OUTER JOIN

lists all pets and their checkups, including:

●​ Pets with or without checkups.​

●​ Checkups that may reference pets not listed

Subqueries and Nested Queries

Subquery: Get volunteers who have been assigned to more than 1 pet​
Nested Query: Find donors who have not made any donations

Views

View: Adopter and their adopted pets​

View: Volunteer with their assignment counts
Stored Procedures

Procedure to add a new pet

Update Pet Health Status
Triggers

Trigger: Automatically update pet adoption status after an adoption

Trigger: Automatically log assignment creation
VI. Final Report

Executive Summary: Overview of the Project and Key Features

The Pet Adoption Management System (PAMS) is a relational database solution developed to
support the daily operations of animal shelters and pet adoption centers. It offers a centralized
way to manage essential processes such as pet intake, adoption tracking, volunteer
coordination, donations, veterinary checkups, and staff responsibilities. By moving away from
paper-based or scattered digital records, the system helps shelters run more smoothly, keep
better records, and ultimately improve the quality of care for animals.

The system is built on a carefully designed Entity-Relationship (ER) model, which has been
normalized to Third Normal Form (3NF). This ensures that the database is efficient, consistent,
and free from unnecessary duplication. The structure allows shelters to scale their operations
and maintain clean, accurate data as they grow.

Key Features:

●​ Pet Management: Tracks details about each animal, including breed, age, weight,
health status, and intake date. Each pet’s journey from arrival to adoption is
documented.​

●​ Adoption Tracking: Records each adoption, linking the pet, the adopter, and the staff
member who assisted, making it easy to follow up and generate reports.​

●​ Donor and Donation Logging: Keeps a detailed history of donations and their
purposes, along with donor contact information and donation types.​

●​ Volunteer Assignments: Manages volunteer profiles, their assigned tasks, supervising

staff, and hours served—supporting recognition and scheduling.​

●​ Veterinary Records: Logs health checkups, diagnoses, treatments, and the vet
responsible for each case, supporting responsible animal care.​

●​ Data Integrity and Reporting: The database structure uses primary and foreign keys,
constraints, and sample data to support consistent entries and useful reporting through
SQL queries, views, procedures, and triggers.​

By centralizing all essential information, PAMS enhances transparency, reduces errors, and
improves operational decision-making. It empowers shelters to focus more on their
mission—caring for animals and connecting them with loving homes—while leaving the data
management to a reliable, well-structured system.
 ●​ Design Decisions: Explanation of major design decisions and alternatives considered

Several critical design decisions were made during development:

1.​ Use of Composite Keys in Assignment Tables:​

○​ Many-to-many relationships like volunteer-to-pet care and staff-to-volunteer

management were resolved using associative entities with composite primary
keys (e.g., volunteer_id + pet_id + assignment_date).​

2.​ Normalization to 3NF:​

○​ All tables were decomposed to remove partial and transitive dependencies,

ensuring minimal redundancy and better data integrity.​

3.​ Clear Role Separation:​

○​ Entities like Staff, Vet, and Volunteer were kept distinct despite potential
overlaps, for clarity in roles and responsibilities.​

4.​ Adoption Status in Pets:​

○​ A derived attribute (adoption_status) in Pet helps in quick querying without

requiring joins, while still maintaining referential integrity via the Adoption table.​

5.​ Alternative Considered:​

○​ Initially, storing checkups directly in the Pet table was considered. However, to
maintain normalization and allow multiple checkups per pet, a separate
Vet_Checkup_Details table was created.

●​ Implementation Challenges: Discussion of challenges faced and how they were

addressed

Complex Relationships:​

●​ Handling ternary relationships and many-to-many mappings (e.g., volunteer-pet

assignments) required careful modeling with proper foreign key constraints and
 composite keys.​

Trigger and Procedure Syntax:​

●​ Writing portable SQL triggers and procedures that work across systems
(MySQL/PostgreSQL) involved syntax-specific debugging and simplification.​

Sample Data Insertion:​

●​ Populating meaningful, interconnected sample data (10+ per table) without foreign key
violations required careful sequencing of inserts.​

Maintaining Referential Integrity:​

●​ Ensuring no record deletions would violate foreign keys (e.g., deletion of staff managing
active volunteers) was addressed through cascading rules and soft deletes.

• Future Enhancements: Potential improvements for your database system

User Interface Integration:​

●​ Build a web or mobile frontend using the database backend for real-time shelter
operations.​

Advanced Reporting:​

●​ Implement OLAP cubes or views for real-time dashboards, including adoption trends,
donation analytics, and volunteer performance.​

Notification System:​
 ●​ Add automated alerts/reminders for follow-up checkups, contract renewals, or volunteer
hour thresholds.​

Access Control Layer:​

●​ Develop a role-based access system to restrict different user roles (admin, volunteer,
vet) to relevant operations only.​

Soft Deletes & Audit Logging:​

●​ Enhance data integrity with non-destructive deletions and historical record tracking for
compliance.

Conclusion: Summary of what you learned from the project

This project provided a deep understanding of database design, normalization, SQL scripting,
and data modeling for real-world applications. From crafting the ERD to generating SQL scripts,
creating sample data, and writing advanced queries, each step reinforced best practices in
relational database development. Through challenges and iterations, the system evolved into a
scalable, maintainable solution that meets the complex needs of animal shelters and pet
adoption centers.

The project demonstrates how a well-architected database can transform a manual, error-prone
process into an efficient, data-driven operation — ultimately benefiting both the animals and the
humans who care for them.