Modelling Physical Library Inventory and Circulation

Managing a physical library requires more than a list of titles. An institution needs to know which individual copies exist, how they are categorised, and whether each specific item is currently available, issued, or returned, detail that a simple book-title list cannot represent on its own. iEncode Tech built the Library Management System alongside the Online Examination Portal for the same education-sector client relationship, giving institutions that level of operational clarity on a Java and Spring Boot foundation without pretending to be a digital-content or e-book platform. The interesting part of this case study is the modelling decision at its centre: treating a title and its physical copies as related but genuinely distinct records, which is what makes accurate circulation tracking possible at all.

Within iEncode Tech's wider education technology work, physical-library administration typically runs on paper registers or spreadsheets that track titles reasonably well but struggle once individual copies, periodicals, and circulation activity are layered on top. A spreadsheet can list what a library owns; it is far weaker at answering which specific copy of a given title is currently issued, to whom, and when it is due back. That gap between owning something in general and tracking a specific physical item is exactly where informal systems tend to break down as a collection grows.

Physical-inventory systems look simple on the surface but carry real modelling difficulty once circulation activity is involved:

• A book title and its individual physical copies are not the same thing, and the system had to represent both without conflating them into a single record type
• Periodicals introduced a distinct record type with their own lifecycle, separate from standard book titles and copies, and needed their own structure rather than being forced into the book model
• Circulation activity, issues and returns, needed to stay connected to the specific physical item involved, not just to the title, so staff could always answer "which copy" and not only "which book"
• Category structures had to support practical browsing and reporting without becoming an administrative burden that staff would eventually stop maintaining
• Administrative controls needed to give staff oversight of the collection without adding unnecessary complexity to routine issue-and-return work, which happens many times a day in an active library

Because this project was developed alongside the examination portal for the same institutional relationship, discovery benefited from an existing understanding of how the client's administrative staff worked and what a dependable, low-friction system needed to feel like day to day. The specific question for the library brief was structural: what are the real entities in a physical collection, title, copy, category, periodical, circulation event, and how do they relate without collapsing into each other. The goals that followed were direct: give staff one place to manage the collection, keep the copy-level detail that a working library actually depends on, and avoid over-engineering a system that needed to support daily issue-and-return work rather than complex cataloguing scenarios the institution did not have.

iEncode Tech modelled titles and individual physical copies as related but distinct records, so an institution could always answer both "what do we own" and "which specific copy is where" without one question obscuring the other. Category records gave the collection a browsable structure, and periodicals were handled as their own record type rather than being forced into the same model as standalone books, since a periodical's lifecycle, issues, volumes, subscription-based arrival, does not match a book's.

Issue and return activity was built to reference the specific physical copy involved, keeping circulation history accurate at the item level rather than only at the title level. Administrative controls sat on top of this structure, giving library staff the oversight needed to manage the collection, copies, categories, and periodicals day to day, without requiring them to understand the underlying data model to use the system effectively.

The interface was designed around the tasks library staff perform most often, issuing a book, recording a return, checking whether a specific copy is available, rather than around the full depth of the underlying data model. Category browsing was kept structured but simple, since the goal was helping staff and, indirectly, patrons find what they were looking for quickly, not building an elaborate taxonomy management tool. SMS notifications for due dates and overdue items were designed to reduce the manual follow-up work staff would otherwise carry, turning a task that previously required someone to check records and personally notify borrowers into something the system handled on its own.

Title and category records

Books and categories form the catalogue layer, giving the collection a structured, browsable foundation distinct from the inventory of individual physical copies sitting underneath it.

Copy-level inventory

Physical copies are tracked separately from title-level records, which is what lets staff answer exactly which copy of a title is currently issued, available, or in circulation review.

Periodical management

Periodicals are handled as their own distinct record type with a lifecycle separate from standard books, avoiding the mismatch that would come from forcing a subscription-based resource into a book-shaped model.

Issue and return workflows

Circulation activity is tied to the specific physical copy involved, keeping the collection's circulation history accurate at the item level rather than only at the title level.

Notifications and administration

SMS notifications handle due-date and overdue reminders automatically, while administrative controls give staff day-to-day oversight of the collection without adding friction to routine issue-and-return work.

• Backend: Java and Spring Boot handle application workflows, sharing the same proven foundation used across iEncode Tech's education-sector projects for consistent, maintainable server-side logic.
• Database: MySQL provides structured storage for catalogue, copy, category, periodical, and circulation information, a relational model well suited to the strict links between titles, individual copies, and their issue-and-return history.
• Supporting services: Google APIs support staff authentication and give administrators usage visibility through analytics, while Firebase enables notification delivery, an SMS gateway sends due-date and overdue reminders directly to borrowers, and AWS (EC2, Lambda, S3, Route 53) hosts the application and its infrastructure.

The genuine difficulty in this project was resisting the simpler but less accurate option: modelling a "book" as a single record with a quantity field, rather than as a title connected to individually tracked copies. A quantity field is faster to build and looks fine in a demo, but it cannot answer which specific copy is currently with which borrower, which matters the moment a library needs to chase an overdue item or investigate a damaged or lost copy. Committing to copy-level modelling from the outset meant more upfront schema design, but it is the only approach that produces circulation records an institution can actually rely on.

Periodicals presented a related but separate challenge: they share enough characteristics with books, a title, a category, that it was tempting to reuse the book model directly. Building periodicals as their own record type took additional design work but avoided awkward workarounds later, such as fabricating fake "copies" of a periodical issue just to fit an inventory model that was never designed for that kind of resource.

The platform centralised physical-library administration for an educational setting, giving staff a structured way to manage titles, copies, categories, periodicals, and circulation activity from one system instead of manual logs or disconnected spreadsheets. The relational data model keeps titles, copies, categories, and periodicals properly connected, while SMS reminders reduced the manual follow-up work staff previously had to do themselves.

Because it was developed alongside the examination portal, it also demonstrates reusable education-domain and administrative-system capability that iEncode Tech can carry into related institutional projects, without ever implying e-book or digital-content functionality the system was not built to provide.

Getting the entity model right before writing screens is what separates a system staff can trust from one that quietly loses accuracy over time. That principle underpins iEncode Tech's approach to education platform development generally, and it is worth remembering that database design decisions made early in a project are often the ones with the longest-lasting consequences.

Looking to replace manual registers or spreadsheets with a structured administrative system? Talk to iEncode Tech about a platform modelled around how your institution actually operates, or see the Library Management System project overview for a concise summary of what was delivered.