Designing an airline passenger reservation system

15 November 2008

Data Model - Basics - Part 11 - The HuagatiRes data model converted to “M”

Filed under: Data Model, Tools — Tags: , , — Kristofer @ 18:35

Happy over Microsoft’s new commitment to data modelling, I have been playing around a bit with the “Oslo” CTP. It is time they come up with a replacement for Visio 2003 EA. The latest thing I tried was a conversion of the HuagatiRes datamodel into an M script. There’s not much to say about it - “M” and “Oslo” are still CTPs so some things can be defined in M models (e.g. table defs, foreign keys, PKs) while others can not be described in M (e.g. indexes, alias types, precision/scale on numeric/decimal types etc). I also haven’t figured out how to declare both nullability and length on members of type “Text”.   “:Text where value.Count <=100” works fine while “:Text? where value.Count <=100” will throw an error, but that might just be me not fully understanding the M syntax.

The M model for HuagatiRes can be downloaded from here:

http://blog.huagati.com/downloads/HuagatiResMmodel.zip

Huagati MGen / “Aker Brygge”

Now, I wasn’t stupid enough to actually type all of that into Intellipad. Instead, I did something even more stupid: I wrote a code snippet that extracts schema, type, table, column, foreign key, and index defs and generates M files.

If you’re interested in taking the schema->M tool (”Huagati MGen” a.k.a. “Aker Brygge”) for a test-spin, you can download it from here:

http://blog.huagati.com/downloads/HuagatiMGen.zip

It requires .net 3.5 SP1 and works against SQL Server 2005 and SQL Server 2008 databases only. Give it a connect string and an output folder and it will generate one M file per schema in the database you point it at, complete with code comments (based on object names and extended property descriptions) and all. Even [commented out] index definitions - prepared for the day when M gets support for index definitions…

Huagati MGen

 

MGen Output

In the guts of MGen

The first version of MGen was a single exe, but I have since divided it up into a DLL containing a simple object model (MCodeProvider) for generating M code, along with a class that will connect to a SQL Server to extract schema definition and generate M using the MCodeProvider.

The exe file adds the simple user interface shown above, but if you prefer you can use the MCodeProvider or the DBSchemaMGenerator from your code instead. Note that this is just an experimental piece of sample code - it does not support everything that can be done in M, and likewise the MCodeProvider and related classes also support [db-side] features that don’t exist in the CTP version of M. The generated M code will reflect unsupported things such as indexes, extended properties etc as code comments.

Usage example 1 - generate M from an existing database:

string connectString = "Data Source=(local);Initial Catalog=AdventureWorks;Integrated Security=True";
string targetFolder = "c:\temp";
//generate M from an existing db
Huagati.MGenCore.DBSchemaMGenerator mGenerator
    = new Huagati.MGenCore.DBSchemaMGenerator();
mGenerator.SchemaToM(connectString, targetFolder);
 

Usage example 2 - generate M code using the MCodeProvider:

//create a new module Â
MCodeProvider code = new MCodeProvider();
MModule module
    = new MModule
    {
        Name = "TestModule",
        DescriptionComment = "Test Module"
    };
code.Modules.Add(module);
//define a simple type for identifying codes, string less than or equal to 10 characters in length Â
MSimpleType idCodeType
    = new MSimpleType
    {
        Name = "CodeType",
        Inherits = new MTextType(),
        DescriptionComment = "Simple type used for storing identifying codes."
    };
idCodeType.Constraints.Add(
    new MMemberConstraint
    {
        MemberMember = ConstraintMemberEnum.Length,
        Operator = ConstraintMemberOperator.LessThanOrEqual,
        ConstraintValue
            = new MIntLiteral
            {
                Value = 10
            }
    });
module.Members.Add(idCodeType);
//define a simple type for names, string less than or equal to 255 characters in length Â
MSimpleType nameType
    = new MSimpleType
    {
        Name = "NameType",
        Inherits = new MTextType(),
        DescriptionComment = "Simple type used for storing names."
    };
nameType.Constraints.Add(
    new MMemberConstraint
    {
        MemberMember = ConstraintMemberEnum.Length,
        Operator = ConstraintMemberOperator.LessThanOrEqual,
        ConstraintValue
            = new MIntLiteral
            {
                Value = 255
            }
    });
module.Members.Add(nameType);
//define a base type for all ref tables Â
MComplexType refTableType
    = new MComplexType
    {
        Name = "RefTableType",
        DescriptionComment = "Reference table base type."
    };
MMember idCode
    = new MMember
    {
        Name = "Code",
        Inherits = idCodeType
    };
refTableType.Members.Add(idCode);
refTableType.Members.Add(
    new MMember
    {
        Name = "Name",
        Inherits = nameType
    });
refTableType.Members.Add(
    new MMember
    {
        Name = "SortSeq",
        Inherits = new MInt32Type()
    });
refTableType.Members.Add(
    new MMember
    {
        Name = "Active",
        Inherits = new MLogicalType()
    });
refTableType.IdentityMembers.Add(idCode);
module.Members.Add(refTableType);
//define a test table, inheriting from the ref table type Â
MExtent testTable
    = new MExtent
    {
        Name = "Test",
        DescriptionComment = "Test reference table.",
        Inherits = refTableType
    };
module.Members.Add(testTable);
//add an index to the test table Â
MIndex testTableIndex1 =
    new MIndex
    {
        Name = "ix_TestTable_SomeOtherField"
    };
testTableIndex1.Members.Add(refTableType.GetMember("Name"));
testTable.Indexes.Add(testTableIndex1);
//save all modules   
code.SaveCode("c:\\temp");  

The output from the code above will be an M file containing the following:

//Test Module
module TestModule
{
    //Simple type used for storing identifying codes.
    type CodeType : Text where value.Count<=10;
    //Simple type used for storing names.
    type NameType : Text where value.Count<=255;
    //Reference table base type.
    type RefTableType
    {
        Code : CodeType;
        Name : NameType;
        SortSeq : Integer32;
        Active : Logical;
    } where identity (Code);
    //Test reference table.
    //[ExtendedProperty("MS_Description", "Test reference table.")]
    Test : RefTableType*;
    // index ix_TestTable_SomeOtherField(Name);
}

29 June 2008

Data Model - Basics - Part 10 - Overview #2 and SQL-DDL script

Filed under: Data Model — Kristofer @ 5:00

The data model has evolved some since the last overview diagram so I figured it was time for another one.  The overview diagram is a now bit too big for inline viewing in this blog thingie so here is a link to it instead. (http://blog.huagati.com/res/wp-content/uploads/2008/06/overview2.png)

In addition to this I also generated a SQL-DDL script for generating a database matching the data model in its current stage. That script can be downloaded here. (http://blog.huagati.com/res/wp-content/uploads/2008/06/CreateResDB_sql.txt)

28 June 2008

Data Model - Basics - Part 9 - User Accounts, Security Rights

Filed under: Data Model — Kristofer @ 5:00

One core subject area I haven’t covered yet is user accounts/logins and security rights so it is time to start with an overview over that. I’m basing it on a model familiar from Windows - user accounts, user groups, and access control lists that give access to actions or objects either by group membership or group. In addition I will have validity periods at all levels; account, group membership and access control lists.

The table names are for the most part self-explanatory;

  • user_account stores information about individual user accounts; domain, login, hashed password, validity dates and a reference to the underlying person record.
  • user_group defines the different user groups; administrators, reservation agents, station agents, inventory maintenance, fare maintenance, accounting etc
  • user_group_user links users to user groups defining group membership
  • security_right is a recursive table defining the different areas of functionality down to individual functions, as well as object classes
  • user_group_security_right and user_security_right defines security rights for groups and individual users respectively
  • user_group_security_right_identifier defines object security rights for objects that are identified with a uniqueidentifier/guid, e.g. bookings, customers etc. Object security (i.e. what user groups are allowed to modify a certain customer record) is by group only to keep it simple.
  • user_group_security_right_code identifies object security rights for objects identified by codes, e.g. what user groups are allowed to modify information for a certain airline (code).

In addition to these new tables, all tables throughout the data model has been expanded with the created_by_user_id, created_date_time, last_modified_by_user_id, last_modified_date_time columns. All reference tables and other tables with an active_flag indicator also got inactivated_by_user_id and inactivated_date_time. These are all for tracking purposes; e.g. for tracking things like who removed passenger n from booking ABC123 or who added the YFLYCHEAP fare. None of these tracking fields have foreign key contraints to the user_account table to avoid adding unnecessary on the database. All of the tracking fields will be automatically set in a single place within the data context in the data access layer, using some of the partial method extensibility built into Linq2SQL data contexts, so the risk of breaking a constraint should be nil.

Coming up next: Data Model - Basics - Part 10 - Overview #2 and SQL DDL script

24 June 2008

Data Model - Basics - Part 8 - Checkin and Boarding

Filed under: Data Model — Kristofer @ 18:12

Although I am not attempting to add full DCS (departure and control system) functionality it can be useful to have some basic support for checking in and boarding passengers for airlines that don’t need all the fancy DCS features available in fullblown DCSes. At least the basic scenarios of a passenger checking in/boarding (or not showing up), getting assigned to a seat or two (yes, some passengers do need more than one seat), checking in luggage, getting a boarding pass can be neat to have support for directly in the reservation system. It also adds the advantage of being able to store a passenger’s actual travel history, actual booking outcome etc.

Checkin and Boarding

Check-in and boarding

 

The core table in the check-in and boarding subject area is flight_passenger_checkin. This table links together a flight with a passenger [on a booking], a seat with the option of assigning a second adjacent ‘extra seat’ for the larger passengers who may feel more comfortable using more than one seat, and a segment record on a booking. The reason for storing flight id in addition to the booking segment is for supporting checking in passengers on a different flight than the one they were booked on while maintaining what booked segment it refers to.

Records in flight_passenger_checkin are originally created when a passenger checks in, either at a checkin desk, website, sms or through other means of checking in. At this time the checkin timestamp is set, a boarding control sequence number is issued, a unique boarding pass number is generated, and the checkin/boarding status is set to checked in. Alternatively, if no checkin record has been created for a passenger by the time the flight is marked as departed (and that happens when a flight_departure record is created and flight.actual_departure_date_time is set), one will be created with checkin/boarding status set to checkin noshow.

As a passenger boards, the boarding_date_time is set and checkin/boarding status is set to boarded. Alternatively, if the passenger checks in but do not board it will be set to boarding noshow (triggering the offload flow which will be covered later).

Other supporting tables included in this diagram are:

  • checkin_boarding_remarks where any free-text remarks related to checkin/boarding can be stored.
  • checkin_boarding_deny_reason where the possible reasons for denied checkin or denied boarding are listed.
  • checkin_upgrade_downgrade where change in class of service a.k.a. upgrades or downgrades are stored along with a reference to any related financial transaction such as upgrade fee, fare difference collected or refunded
  • checkin_boarding_status listing the possible statuses of checkin/boarding: checkin initiated, checkin completed, checkin denied, checkin noshow, boarded, boarding denied, offloaded, boarding noshow etc.

The remaining tables shown in this diagram are shared from the previously covered subject areas bookings, flight schedules, seat reservations, and financials.

Not covered in this diagram but somewhat related to this subject area are: passenger identification (id / d/l, passport info), offloading details, milage accrual etc. Those and other related details will be covered in a later blog entry.

20 June 2008

Data Model - Basics - Part 7 - Travel Agencies, Corporate Customers etc

Filed under: Data Model — Kristofer @ 13:40

In a previous part of the data model I defined the abstract concept of a customer, basically anyone making a booking. Expanding on this I will add some tables supporting the specifics of contract customers; travel agencies, corporate customers and anyone else that may have an agreement giving them access to negotiated fares, credit limits, commissions, booking from external systems etc.

Contract Customer

  • contract_customer extends a customer record to become a contract customer. The customer_id PK is reused as this is a one-to-one relationship. contract_customer_code is the customer number or agency code for the customer, credit_limit defines the credit limit extended to the customer (if any), contract_customer_type_code identifies what type of contract customer this is (T/A, corporate, government, individual etc, all defined in contract_customer_type), and commission_structure_id links to the commission structure used for the customer in the case of customers that receive commission (normally only for travel agencies).
  • contract_customer_parent defines parent/child relationships between contract customers, this will be used for hierarchies such as travel agency consortiums, corporations with subsidiaries or separated booking for different cost centers etc
  • contract_customer_collateral stores information about any collateral deposited by a contract customer; cash, letter of credit or similar. Classes of collaterals are defined in collateral_type.
  • commission_structure is a wrapper for different commission structures / rates. A commission structure can be used by one or many agencies, and rate/floor/ceiling can be defined by rbd/booking class.

There will be more detailed attributes for contract customers such as identification of individual booking agents, API accessibility etc, but this first part at least defines the basic structure of how they will be stored and how credit line/collateral/commissions are stored.

19 June 2008

Data Model - Basics - Part 6 - Seat Reservations

Filed under: Data Model — Tags: , — Kristofer @ 14:28

As almost all airlines nowadays allow passengers to reserve seats when they book, support for seat reservations is a must. It is relatively simple; extending from the physical cabin definition originally defined in Data Model - Basics - Part 1 I will add tables defining seat map, rows and seats with various attributes describing them. Once seat maps/rows/seats are defined a single table can store seat reservations, linking together a flight, a seat and [usually] a passenger on a booking. I added “[usually]” to the previous sentence because a seat can be reserved or blocked out without an actual booking.

Seat Reservation

  • configuration_cabin is the table that holds definitions of the individual cabins within each aircraft configuration. It is specific to one or several aircraft with the same cabin layout. This table has changed from a combined primary key to a single field GUID PK from the original data model diagram in Part 1.
  • cabin_seat_map defines the seat map for each cabin; this is a separate table to allow layout changes while retaining the old (inactivated) seat layout. Besides the standard fields, this table has a 64 bit numeric field called row_layout_bitmap. This is basically a binary field indicating where the underlying rows are placed and where there are gaps, e.g. 11111101111111110000…. means the first six rows are consecutive followed by a gap followed by the next eight rows and so on.
  • seat_row defines the rows within a seat map, with a row number, a seat layout bitmap (works the same way as the row layout bitmap, but for seats within a row), when the row becomes and stops being available for reservation in hours before departure, and other important attributes indicating if it is an exit row/bulkhead/limited reclining/has extra leg space/has extra oxygen mask etc
  • seat holds seat definitions for the individual seats within a row, availability hours (if it differs from the rest of the row), whether it is blocked by default and if so the reason for blocking.
  • seat_block_reason holds the different possible reasons for blocking a seat, exit row/security/for airline staff/etc
  • seat_reservation stores the actual seat reservations, linking a flight to a seat to (optionally) a passenger on a booking. The same table is also used for blocking or internally reserving seats that are not linked to bookings which is why the booking_passenger_id is nullable. Reservation and release dates are used for tracking purposes when seats are reserved and later released due to booking changes.

Aircraft/Equipment/Cabin

The aircraft / equipment / cabin diagram from Part 1 has undergone some minor modifications so I am including an updated version of the data model diagram for it here.

In short, the changes are:

  • market_configuration linked to aircraft_cabin_configuration
  • configuration_cabin has a new single field PK
  • aircraft_cabin is linked to rbd/classes through the new table aircraft_cabin_rbd. This allows us to define what fare classes can sit in what cabin, e.g. A/B/F in first class, C/D/I/J in business, Y/B in premium economy and the rest in the back.

�

17 June 2008

Data Model - Basics - Part 5 - Overview, Fares, Taxes, Surcharges, Time Zones

Filed under: Data Model — Kristofer @ 18:22

So far this datamodel has grown to some 91 tables so I generated an overview diagram:

A larger version with readable text can be viewed by clicking on this link.

Some new functional areas were added before the overview above was generated; fares, taxes and surcharges, and time zones. Brief descriptions of the entities involved in those areas follows…

Time Zones

Although .net has some nice functionality built in for time zone calculations it doesn’t really allow it to be reused for duration calculations across time zones so instead of reusing the .net framework functionality for this I’m adding a couple of tables to define time zones and link them to cities with default zones for regions and countries.

The time_zone table defines each time zone with a code and offset in minutes against UTC (GMT) for normal vs daylight savings time. Dates when daylight savings is in effect are defined in the time_zone_daylight_savings_calendar table, for dates not defined here the standard offset in utc_offset_minutes will be used.

Cities need to have a time zone code specified, countries and regions have an optional/nullable default time zone code that can be suggested as the default for new cities.

Fares

The ‘fares’ functional area contain the tables used for defining fares used by the pricing engine. For pricing performance reasons, the fare definitions is a relatively flat/denormalized structure; a normalized template model may be added later to allow for a more flexible fare definition user interface;

  • fare_basis defines all fare basis codes for an airline/rbd pair
  • fare contain the actual fare definition with a reference to the fare basis, a status, what route the fare belong to, validity and departure dates, rbd (duplicated from the fare basis for index inclusion), passenger type, currency and an amount. Optionally it also allows an offset range from departure to be defined to allow fares to slide into validity for a certain time period before departure.
  • fare_calendar defines any specific dates when the fare is valid or not valid to allow “blackouts” or “holiday specials”
  • fare_flight links fares to specific flights, or excludes specific flights from a fare
  • customer_fare links private fares to the customer(s) the fare is available for
  • route and route_via defines routes with origin/destination and any required stopovers

Taxes and Surcharges

Taxes and surcharges are also defined in a denormalized manner; although the number of taxes and surcharges defined is typically far lower than the number of fares it is again important with very fast lookups against these tables.

  • tax defines each individual tax with validity and departure dates, optionally an origin or destination that the tax applies to, whether it is a percentage or fixed amount, and whether it applies to fares, to other taxes, fees, and surcharges. domestic_flag/international_flag defines if the tax applies to domestic only/international only or both. Floor amounts and ceiling amounts for the tax itself as well as for the basis (in case of percentage taxes) are also defined here.
  • tax_recipient allows for categorization of who the tax was collected for; airport operators, tax authorities, handlers etc
  • surcharge contain definitions of surcharges linked to fares through the fare_surcharge table
  • surcharge_type holds definitions of the different surcharge types; fuel, baggage/extra baggage etc

16 June 2008

Data Model - Basics - Part 4 - Inventory basics, Bookings and Financials

Filed under: Data Model — Tags: , , , — Kristofer @ 18:32

As the previous blog entry Data Model - Basics - Part 3 - Bookings and Financials did not contain any descriptions I will instead describe the bookings and booking financials in this post. Before getting to that though, I will draw up the basic structure that will be used for the inventory datamodel.

Inventory

All types of inventory systems whether for an airline res system tracking seat inventory, or office supply room tracking remaining pencils are plagued by the same basic issue; sometimes inventory movements are incorrect and there will be a mismatch between actual inventory and recorded inventory. Because of this, a detailed audit trail is useful so the source of any discrepancies can be tracked down. This part defines the basic structure of how inventory buckets will be defined as well as the inventory movement tracking.

Starting from the equipment and physical configuration from Data Model Basics Part 1, I will extend with a couple of tables describing the marketing configuration or how the available seats are divided among the different booking classes.

  • market_configuration hangs off the aircraft_cabin_configuration and allows one or more marketing configurations for each physical configuration. This gives more flexibility to change marketing configuration from schedule period to schedule period. The market_configuration table will now also be referenced by the flight_leg_schedule table in Part 1.
  • market_configuration_rbd defines the different base inventory buckets for each market configuration. Market configuration and rbd are identifying but a separate uniqueidentifier PK is used for future tables referencing this table.
  • reseravtion_booking_designator defines the marketing inventory bucket classes, e.g. Y, B, M, K etc.
  • flight_inventory stores the inventory for every flight instance with one record for each valid rbd code (class). Seats assigned and seats available is stored here and this table is where availability etc will find seat count for each flight/class.
  • flight_inventory_movement tracks all inventory movement; initial assignment of seats to a flight/rbd (class). Whenever seats are taken or returned a new record is inserted here to allow a full audit trail of inventory movements.
  • inventory_movement_type defines the types of inventory movement such as initial allocation, booking, releasing booked seats, allocation to T/A, allocation to code-share partner, blocking etc.

Bookings

The booking data model diagram has gone through some minor changes since part 3; some missing attributes have been added. In addition, I will now describe the entities as I didn’t have time to do that when posting part 3.

  • booking is the core entity of storing bookings. It has a uniqueidentifier PK which is referenced by other booking related tables as well as a record locator, alternative locator that will be populated if the booking originates in another system, serial number for those who need a numeric booking reference, status and base currency.
  • booking_passenger links passenger records (defined in part 2) to the booking, defines passenger type (adult, child, infant, unaccompanied minor etc).
  • booking_origin_destination_option is the wrapper for each origin/destination pair; this may be a single segment for direct flights or multiple segments for connections. This origin/destination wrapper is important for itineraries with multiple stops where it may not be obvious from the segments where the passenger makes a stop or just a stopover.
  • odoption_segment defines the segments involved in a booking_origin_destination_option by linking to the flight, rbd code (class), and inventory movement (if any). sort_seq defines the segment order, and booking_segment_status_code references the booking_segment_status table for traditional segment status codes, to be used when communicating with legacy systems.
  • passenger_luggage holds pre-recorded (booking time) luggage information.
  • booking_passenger_ssr stores raw ssr information for bookings originating (or shared with) legacy systems. Internal ssr details will be stored in separate tables similar to the passenger_luggage table; tables defining the different ssr types will be defined later.

Booking Financials

Just as inventory requires a proper audit trail, so do the financial information. “This is a reservation system, not an accounting system” just does not cut it as correct and detailed information to accounting systems can not be generated if the information has not been stored in the first place. I will keep it simple but will still store all financial transactions rather than add/remove information over time.

  • booking_financial_transaction is the core of all financial information pertaining to bookings. This table will store fares, fees, taxes, surcharges, payments, refunds and credits as well as any informational no-value transactions. Passengers and OD options may optionally be referenced for transactions pertaining to a passenger and/or set of segments (e.g. fare) but are nullable for booking-level charges (e.g. booking change fee).
  • financial_transaction_type defines the types of booking financial transactions, e.g. fare, fee, tax, surcharge, payment, refund, credit, discount etc. is_debit, is_credit, is_info determines the implied sign of transactions of this type.
  • invoice defines invoices related to bookings. Every payment against a booking is a payment against an invoice, whether actually invoiced or not there is an invoice defined. This table also doubles for credit notes; a credit note will be stored as an invoice within a different invoice series.
  • invoice_booking_charge links an invoice to the transactions behind the invoice.
  • invoice_other_charge stores non-booking charges that may apply to a specific invoice; credit card charge fees, invoice fees etc may fall in this category if the airline for accounting purposes do not want to link these to bookings.
  • non_booking_charge_type defines the types of non-booking charges.
  • payment_receipt stores receipt information for payments, linked to the underlying invoice.
  • credit_card_payment, transfer_payment, cash_payment are all extension tables to booking_financial_transaction. These tables hold payment specific information for payment transactions and depending on payment form either one of the payment extension tables will hold the relevant details, such as credit card transaction information for credit card payments, or payment processor information for transfers (bank/paypal/mobile phone payment etc).

 

Look out for the next part: fares, fees, taxes and surcharges. This will cover the basics of the pricing tables defining how fares, taxes, fees, surcharges, discounts etc are defined.

14 June 2008

Data Model - Basics - Part 3 - Bookings and Financials

Filed under: Data Model — Kristofer @ 18:43

I’m a bit too busy to write any commentary today but I will publish a couple of data model diagrams covering the draft of the booking and booking-related financials (fares, fees, taxes, surcharges etc). These diagrams are missing all references to the fare/pricing, inventory and most of the customer/agency related details as those functional areas have not been modeled yet. However, they do provide a basic structure for bookings and storing the booking-level financial information. Detailed descriptions will follow…

Bookings

 

Booking financials

13 June 2008

Data Model - Basics - Part 2 - Supporting Tables

Filed under: Data Model — Kristofer @ 15:00

Before moving on to the more interesting parts I will throw in some tables for defining generic things; documents, people, passengers, crew, settings, serial numbers etc. These will come in handy in many other parts of the data model so they need to be defined early on.

Passengers / people / customers

Much information in a reservation system relates to people in one form or another, passengers, customers, users, employees/staff etc so I will start off with some generic tables for these. They will later be expanded with more attributes but for now we’re just defining the basic concepts.

  • person is the core table defining a person. Name is required, all other attributes are optional in the data model but depending on the context may be required at the application level.
  • contact_information is a generic contact table for address, phone numbers, email etc. It may contain contact information for a person or any other entity which is why it is separated from person.
  • passenger defines a person that is also a passenger. Name, contact information etc comes from the person table but any passenger specific information will relate to the passenger record.
  • passenger_document links documents in the document storage system to passengers; documents may be anything such as scanned identification/passport, correspondence (emails). Document storage will be covered in more detail later.
  • customer is a generic table for relating to a customer or potential customer. The customer may be known, in the case of someone who have already made a booking, or an anonymous record relating to someone “shopping around”. This will be useful for tracking user patterns both for actual customers and potential customers. This table will be automatically populated for all web users as soon as they start shopping around, and will be populated with actual name, contact information, login information and related passengers as that information becomes available.
    The customer table will also be re-used for travel agencies etc with some bolt-on tables for the agency related attributes, credit limits and collaterals etc (to be modeled later).
  • customer_passenger ties passengers to a customer record, so that return customers may select passenger details from previously booked or entered names a’la expedia.com.

Crew

Now that we have defined people, throwing in some basic crew details should be easy. Although traditionally not part of res systems it may be neat to have that information at hand for reporting; especially for some international flights where such information may need to be filed with third parties (authorities etc).

The crew functional area reuses the person/contact_information tables previously defined and adds a few tables for crew-related information;

  • crew  identifies crew members; air crew or cabin crew staff.
  • crew_type identifies the type of crew members; cabin crew, pilot, flight engineer etc.
  • crew_document again relates to documents stored in the document storage system; this may be scanned copies of indentification, medical clearance, license documentation, duty rosters, scanned log book pages etc
  • crew_equipment_accreditation will be used to store information on what equipment individual crew members are allowed to operate or work on.
  • crew_accreditation_level identifies the available accreditation levels.

A lot more information can be stored on crew members but as this is supposed to become a res system, not a crew resource management system this should be enough for now; just the basics.

Currencies and exchange rates

Currency and exchange rate definitions will be needed for all pricing and other financial information so this is an important part of the supporting tables.

  • currency defines the currencies available; USD, EUR, THB, SEK, VND etc.
  • country_currency defines in what countries a certain currency is used, defined as a many-to-many relationship to support currencies used in multiple countries or countries using multiple currencies.
  • exchange_rate_source defines the sources where exchange rates are retrieved from; useful if exchange rates are sourced from more than one information provider.
  • currency_exchange_rate holds the actual exchange rates in use, along with validity date/time range for a rate, rounding and optionally also forward dates if the airline uses forward contracts for a currency. Exercise and valuation of such contracts is not covered here; that need to be handled in financial systems such as hedgehog.

Documents, settings, help content etc

The last set of supporting tables for today is a mix covering document storage, application settings, help system content, serial numbers etc.

  • document is central to the document storage system. It is kept simple with name, UNC path to the storage location, remarks, size, original name, type and status of a document.
  • document_type holds a list of document types. This may be changed to a hierarchical table at a later point.
  • document_status defines the statuses of a document; valid/invalid/expired/deleted.
  • reference_table will store a list of all reference tables in the system; this will be used by the maintenance screens for reference data to allow a generic implementation.
  • serial_number is used for generating serial numbers; a series code identifies the type of serial number, e.g. booking number, invoice number, transaction number etc
  • help_topic holds the contents of the help system. Storing the help content in the database makes it easier to adapt and/or localize the help contents.
  • application_setting stores application settings that should be modifiable by users with the appropriate security rights, again better stored in the database than in cryptic configuration files.
Older Posts »

Powered by WordPress