Continental.  The book starts with a case about Continental and how databases have contributed to a turn around.  Clearly airlines are operations intensive businesses.  The tiniest flaws in their operations will disrupt their ability to attract and keep customers.

Think about what all airlines must be keeping data, that hopefully becomes information, about.

• flights
  • staffing flights
  • stocking flights
    • gas
    • food
    • baggage
  • planes used for flights
  • schedules for flights
  • passengers for flights
    • payment issues
    • food issues
    • how much business the customer generates

Obviously, this list goes on and on.

But airlines need to be able to adapt as quickly as they can adapt to things like changes in weather, problems with planes, delays and even illnesses in their crews.

Somehow the data needs to be reliable and accessible.  Decision making can be terribly complex when faced with so many fast happening operational impacts.

While living in Missoula, Montana I was required to fly either Delta or Northwest.  Missoula has a pretty small airport.  At some point, even though I was probably flying about 20,000 miles a year with Northwest, they started treating me like I wasn't a customer who was giving them enough business so they would no longer assign me seats until just before boarding.  In fact I was told this by an agent at the counter.  I knew from talking to other passengers that I was actually flying more than most everyone around me.  And they all had assigned seats!  I made sure to contact Northwest and they just brushed it off.  Needless to say I now avoid Northwest now that I can.

Introduction.  The introduction in HPM expends quite a bit of effort convincing the reader that a study of databases is worthwhile.  Too often our education doesn't tie back into the competitive needs of the organizations we will be working for.  I see the HPM discussion as focusing on how databases improve and organization's abilities to compete.

Obviously there are all kinds of data, that should become information, that organizations should be collecting.  They should have data on

• their customers
• their vendors and suppliers
• their internal operations and resources
• their products and services
•  

Obviously, this list can go on and on and should.

HPM doesn't directly deal with issues of who should be collecting and controlling the data and information.  But lately, for a number of reasons, this is becoming more and more centralized.  Some of the advantages of centralizing these sorts of operations are

• expertise required to run the database systems
• helping to ensure commonalities among systems for ease of operations
• centralized should/can help make the information available to everyone, not just available in particular arms of an organization
  • though obviously centralized control might also be used by certain people to limit access to information to their own advantage
•  

Then HPM goes through some fairly common jargon relating to databases.  The high points , as I see them, being

• database - an organized collection of logically related data
  • one hopes there is much logic in the collection
  • one hopes there is much organization in the collection
  • databases are not necessarily computer based, but there are more and more
• data - stored representations of objects and events that have meaning and importance in the user's environment
• information - data that has been processed in such a way that the knowledge of the person who uses the data is increased as intended by the processing
• metadata - data that describe the properties or characteristics of end-user data and the context of that data
• DBMS - database management system - a software system that is used to create, maintain and provide controlled access to user databases
• data models - capture the nature of and relationships among the data and are used at different levels of abstraction as a database is conceptualized and designed
  • enterprise data models - for the entire enterprise
  • project data models - for a more specific project
• entity - a person, place, object, event or concept in the user's environment about which the organization wishes to maintain data
• relationships - the database needs to reflect the relationships between different entities
  • customers and their purchases
  • vendors and their products
  •  
• relational databases - a database that represents data in a collection of tables in which all data relationships are represented by common values in related tables
  • not hierarchical databases
  • not multi-dimensional databases
  • not flat file databases
  •  

Most of these notions and jargon words will be somewhat abstract for a while.  But we will have plenty of examples that are intended to help you give much more meaning to the words.

I am leaving out the discussion of traditional file processing systems for a number of reasons.