仅是一点考虑，不成熟也不足为借鉴？希望大家参与讨论。
在创建数据库的时候经常遇到实体之间存在继承关系。
对于简单的继承在处理的时候往往不考虑这一点，最常见的就是人员信息管理，以教学管理系统为例，并不抽象出人，而是直接将学生、教师作为不同的实体。同时也不区分出男人和女人。
然而在有些地方，不考虑实体间的继承关系则会带来信息的冗余。比如煤矿地质信息中钻孔、见煤点和夹矸三类数据之间存在着继承关系，钻孔数据具有坐标位置；煤矿设备设施管理数据库中采购设备信息（库存设备）与正在运行设备、检修设备、报废设备存在继承关系，而正在运行设备则具有空间位置信息。这是两类很典型的情况。后者更为复杂，设备存在一个生命周期，改变设备的使用状态将产生一个事务。举例来说将当正在运行设备出现故障需要检修时，需要删除正在运行设备表中的信息，在检修设备表中增加信息
建立和使用空间数据库的传统观点“这个地方有什么”，基于空间位置和几何图形；而对象数据库则考虑的是“什么在什么地方”，将空间位置和几何图形仅作为它的属性。这在数据编辑的时候表现出明显的差异，基于空间位置和几何图形的空间数据库以图形作为编辑的中心，属性添加在图形产生之后。而基于对象的方式思考则是先产生对象后有位置。
继承关系可视为一种特殊的依赖关系，在建立表的时候，对象的构造过程类似，必须首先构造父类对象，对父类所具有的属性赋值，再对子类的属性赋值。
目前常见的管理方式是将空间数据和非空间数据分开存储。将井下正在运行的设备设施存储为GIS的图层数据，以属性表的方式管理相关信息。在程序端实现数据的整合，在给图层数据编辑的时候调用相关的非空间数据库信息，通过这种方式来实现空间和非空间数据的一致性。增加空间信息相对容易，但是在删除空间数据的时候操作就显的很复杂。多数情况下还需要手动更新相关的非空间数据库信息。造成工作的重复。
因此设备设施管理中空间和非空间数据一体化管理和简化数据编辑工作的需求非常迫切。煤矿部门用户的计算机水平普遍低，因此数据的重复录入是难以接受的。基本思想史载父表中进行设备的状态的修改，同时自动更新相应的子表，比如将备用设备的状态更改为检修设备，同时需要更新备用设备表和设备检修表。这样是用空间数据库和关系数据库一起用的解决方案。可以充分利用关系数据库事务处理的强大功能。
还有一种思路是用户在编辑数据库产生事务（操作多个关联表）的时候并不采用自动更新，而是记录相关的事务序列，提升用户必须完成相应的事务，保持信息的同步。参照完整性可以保证删除时候表信息的一致性。事务日志表应该记录下面的信息：用户操作，操作类型，对象表，事务状态，执行时间，用户。对用户的操作类型要做一些分类和细化。
这里还没有考虑这样一个问题，如何查看运行设备、检修设备历史信息？上面的都是现阶段的使用状态。