Table descriptions

The following is a list of the table sin the database. The list is kept as up-to-date as is possible, but there may be some gaps! The tables are laid out in functions and then the order they will appear in the management tool. This can lead to some "out of order" tables, however hopefully by grouping them it will allow users to gain an understanding of functions.

Location Tables

There is duplication in the data held in the Location tables, this is undeniable. The reason for this duplication is that after careful consideration the separation of data around each of the requirements of the location, make for a simpler table structure and also should improve speed of data requests. It would be possible to have one location table, however if you start nesting location datums then the queries can become very complex and hit on performance. By separating (and admittedly duplicating) Location tasks into separate tables, only the levels of abstraction that are required at the time are queried.

Location_Datum

The Location_Datum table allows for locations to be set against a location datum. Rather than calculating everything back from the site datum it allows a user to set another datum and take distance calculations from there. This is useful if your breaking down equipment into sub sections. An example of how this could exist is:

Location_Site (51.50432061281751, -0.076114962011352) (Tower Bridge - South Entrance, Road / Building interface)

Location_Datum (51.506755654920866, -0.07471276106753444) (Tower Bridge - North Tower Ground floor)

If required Datums could be nested by using the Location_Datum_Parent_ID in the Location_Datum table.

Location_Position

The Location_Position table allows a part or other item to be given a location position. The position can be either by reference to a site datum (Location_Site) or a Location Datum (set in the Location_Datum table) or by it's own coordinates. If you used a datum (benchmark) at one side of the site you could find that the MM values are astronomically high (even if you can achieve that value). It may be that in such a case then you can set a Location_Datum and then work positions form there.

Location_Site

The Location_Site table allows users to set a datum that all other values stem from. If you're modelling a Power Station then you may well know that all your measurements will come from a datum point used by the entire site that's the OS Benchmark (for example). This means you can position your site globally. Then all other locations can be taken from that point. The ideal unit is MM.

Materials / Parts / Versions

These tables contain the building blocks for the system and as such most activities will use these tables at some point.

Materials

The Materials table will offer a single point of reference for the materials used in Parts.

Part

The Part table is the most important table in system. The Part is however a very small fraction, as most information resides on the Version table. It's not unheard of that a Part is specified and used initially however upgrades mean that it a part becomes versioned. As each iteration of change is made then whilst the Part is the same it may well be three or four versions away from the starting point.

Version

The Version table is the most important table in the system. The table contains each version of a Part or other Device. Every iteration of a Part will contain a new version. That will also include compliance certificates, specification guides etc.