Object-oriented thinking in SQL context?

I have a problem with wrapping my mind into the 'right' wrinkles. I need to come up with a database design in SQL/MSAccess, since that's the tool that is available to me. The subject of the database is an inventory of electronic instruments, and the objective is to maintain a status log of these instruments.

The naive idea is:

• Instrument ID
• Instrument status (active / stand-by / inactive)
• Instrument location (room / shelf / position)

The above ought to be valid for all instruments. Then there are a few instruments that need to be calibrated before use. These need to have some additional fields:

• Calibration status ( OK / not calibrated )
• Calibration data ( varies with type of instruments )

The problem is the latter two fields. Only a few instruments need to be calibrated at all; and the calibration data varies with the exact type of instrument. A microphone might need a gain factor from sound pressure to voltage; a GPS position sensor might need an (x,y,z) location plus orientation along three axes.

The above would be almost trivial to implement in an object-oriented context (well, this si my first attempt at databases at all - my experience is with OO programming), but I don't see how to come up with a table-based database design.

Any general ideas on how to design a SQL database around such constraints?

Dr. C. Received on Mon Jun 08 2009 - 17:46:03 CEST