| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: Generic Modeling
> > 3 tables: things, properties and relationships.
> > Provided the flexiblity but the performance was insufficient.
>
> Was the performance bad no matter what you did?
Below were the tables used to model utility consumption of mfg
facility.
Only the significant fields are shown.
T_Obj
objId
objId_class
objId_parent
obj_name
T_Prop
propId
objId
prop_name
T_ObjProp
obj_prop_id
objId
objId_prop
op_value
T_ObjLink
objId_1
objId_2
In order to represent data in a very general manner, it seemed I wanted to eventually represent every thing with a unique id (objId). This gave much flexibility to represent complex data. However putting the information back together took considerable time even though nearly all the searches were based on clustered PKs. For example, in a normal design, John and his Age would be in a single row, but in the general design these two pieces of information would be in two rows, the second of which can only be looked for after finding the first. I think representing data in a very general manner in rdbs is closely related to representing hierarchal structures in a few tables.
> > Alternatively, XDb is a simple oodb that provides the type of
> Have you personally used this system for any projects?
It was the pursuit of a generic model and the insufficient performance of rdbs that led me to develop an oodb. It is simple and currently lacks the security/crash recoverability of the mature rdbs and thus is not yet appropriate for many applications. However it does allow one to create very complex and flexible data structures that which would be difficult in rdbs. Here is an example:
How do you model the utility requirements of various manufacturers (ie GM)? Each Manufacturer has operations in various Regions of the world (North America). Each Region has various countries (USA). Each Country has various states (Michigan). Each State has various cities (Detriot). Each City has various manufacturing complexes (Vortex Engine Complex). Each Complex has various plants (Plant1). Each Plant has various floors (Floor1). Each Floor has various manufacturing areas (Piston Area). Each Area has various cells (Forging Cell). Each Cell has various production lines (Line1). Each Line has various equipment (Equip1). Each Equipment has various standard components (Comp1). Each Component has various point of connections (ePoc1). Each ePoc has a utility requirement (Elec=400W). Each ePoc can connect to a utility source point of connection (sPoc)
Equipment are utimately powered by utility sources. A Source routes its utility via laterals that fan out like the branches of a tree. Each Lateral has a maximum capacity rating. Each Lateral has various Point of Connections (sPoc). Each Utility Source Point of Connection (sPoc) can connect to various Equipment Point of Connections (ePocs).
Although an equipment is typically placed on a production line, it can be at any level between Manufacturer and Line inclusive. Allow location levels (ie Cell, Area, Floor, Plant, etc) to be omitted. Although a Utility Source is typically located at the plant level, it can at any level between Complex and Line inclusive.
Sub class utilities as shown below:
Utility
Gas
Air
Nitrogen
Liquid
Water
Ultra Pure
Cold
Hot
Allow any class (or sub class) of utility to be rolled up for any part to tree.
The above can be modelled in 15 minutes with XDb. See www.xdb1.com/Example/Ex046.asp Received on Tue Jan 01 2002 - 12:16:13 CST
 |
 |