The schema is the spine.
Airport ticketing systems sit at the intersection of about a dozen workflows that all have to stay consistent: passenger records that update across reservations, flight schedules that change while tickets are already issued, baggage tracking that has to attach to the right passenger and the right flight, ancillary services (meals, seat upgrades) that have to bill correctly even when the underlying booking is modified.
The schema is the spine of all of this. Get it wrong, and every workflow above it gets corrupted in a different way.
Seven entities, integrity by construction.
Seven core entities: Employee, Passenger, Flight, Reservation, Ticket, AdditionalServices, Baggage. Each has a clean primary key generated through a SQL Server sequence (e.g. EmployeeSeq paired with trgGenerateEmployeeID trigger). Foreign keys enforce the relationships that have to hold up over time: a Ticket cannot exist without its Reservation, a Reservation cannot exist without its Passenger and Flight.
Constraints do the rest of the work. CHECK constraints on date ordering (departure cannot precede arrival), NOT NULL on every field that can never be optional in a real ticketing workflow, UNIQUE constraints on the things that have to be unique (passport numbers, flight codes per date).
What shipped.
Full SQL Server schema with seven tables, automated ID generation via sequences and triggers, complete referential integrity through foreign keys, and constraint coverage across the operational surface. The repository includes the schema script and a project report walking through the design rationale.
Lessons.
Auto-generated IDs via sequences plus triggers is more elegant than the IDENTITY column approach when you need IDs that follow a specific format or naming pattern. Once it's wired up, every INSERT just works. The trigger does the work the application would otherwise have to do, and you get the benefit at the database layer.