Re: Generic Modeling

From: James <jraustin1_at_hotmail.com>
Date: 1 Jan 2002 10:16:13 -0800
Message-ID: <a6e74506.0201011016.42738ff1_at_posting.google.com>


> > 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

  Electricity
    Regulated
    Unregulated
    Uninterruptable
etc...

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 - 19:16:13 CET

Original text of this message