Digitizing a cat rescue that ran on memory and binders.

The brief.

S.A.L.T., based in St. Thomas, Ontario, and entirely volunteer run, rescues 200+ cats a year and rehomes them. Zero paid staff. Zero digital systems. One founder named Bonnie who keeps everything in her head or in a stack of binders.

A fire in 2020 destroyed most of the paper records proving the fragility of the current system. The cats still needed care. Nobody knew what care they'd already received.

Our Data Management final project: design a database that fixes this.

From binders to Barker notation.

We started by mapping how a cat actually moves through the rescue and how the rescue itself operates through a data lens.

Then we built outward. Who handles the intake? Where does the cat live? What medical care has it received? Who applied to adopt it? Did anyone follow up after the adoption? Where did the food come from? Who donated the money that paid for it?

Each question became an entity. Each connection became a relationship. We ended up with 20 entities across four areas: the cats, the people, the process, and the operations, all modelled in Barker notation.

The relationship that made it click.

Most connections were intuitive. Cat links to medical record. Foster home links to foster placement. Straightforward.

The one that took the most thought: the donation chain.

A donor gives money → that's a donation record → the donation funds a supply item → the supply gets used → the usage is logged against a specific cat.

Four tables deep. But when it works, Bonnie can trace a bag of cat food from the person who paid for it to the cat who ate it. That accountability didn't exist before; not in paper, not in memory, not anywhere. This also enables the donors to see how their donations were spent, something that could encourage them to donate further.

From diagram to working database.

We implemented the full model in MySQL through XAMPP. 20 tables, every foreign key constraint, every relationship from the diagram enforced in the actual schema.

Then we populated it 6095 rows of synthetic data across all tables cats with names, medical histories that make sense across time, foster placements that don't overlap, adoption applications that reference real cats and real adopters.

That sounds simple until you realize row 3,000 needs to be consistent with row 47. A cat can't be in two foster homes at once. A medical record can't reference a cat that hasn't been taken in yet. An adoption can't exist without an approved application.

Making fake data behave like real data was its own kind of data modelling.

What S.A.L.T can ask now.

We wrote SQL queries from Bonnie and S.A.L.T.'s perspective to answer things she currently can't without a dozen phone calls or flipping through several binders.

For example: which cats are overdue for a vet visit, and where are they right now?

One query. Returns every overdue cat, if they are at the shelter or with a foster, if at foster then their foster home, the foster parent's phone number. Sorted by how overdue they are.

What used to take hours now takes seconds. And this information isn't dependent on one single person to remember and can be accessed by any volunteer with access. That's the whole point of the database.

The takeaway.

The hardest part of this project wasn't SQL. It was the loop.

Write the case → build the model → realize the case doesn't mention a field the model needs → rewrite the case → realize the model now has a broken relationship → fix the model → regenerate the test data → realize row 2,000 contradicts row 47.

Over and over. Probably fifteen times. Plus we had to keep to 20 entities or under and that was a whole another difficult task.

That loop is the actual skill. Not "I can write a CREATE TABLE statement." Anyone can learn that. The skill is going back and forth between a messy real-world situation and a clean data structure until they match and knowing when to stop.