New
over 2 years ago

Item Types: Foreign Key or Relationship

I have two Item Type definitions: Area Features and Doors.  I can tag an office, for example, as an Area Feature; and I can tag a door cell as a Door.  Here's an illustration...

Now I want to relate one to the other.  You can see that Door 102 belongs to Room 102, but MicroStation cannot deduce that relationship.  I'm looking for suggestions on how I might establish what a relational database designer would call a table's foreign keyDoor 102 should have something that links it to Room 102.  What should that something be?

My goal would be to define a Report that lists, for example, Rooms and the Door(s) that belong to each Room...

While all offices have a single door, the meeting rooms each have two doors.

  • MicroStation contains powerfull EC data / EC Framework technology including relevant API. It already allows to define both EC instanaces and EC relationship instances.

    Contrary to it ItemTypes are simplified users oriented tool, supported also by API. Internally ItemTypes are based on particular EC schema, which ensures all EC based tools are able to work with ItemTypes automatically (because technically ItemTypes are EC data).

    To complain that ItemTypes do not allow to defined relations is in my opinion not problem of ItemTypes design and implementation, but a proof that wrong tool was used to solve a particular problem.

    To add more and more features to ItemTypes both will break original concept "simple modern replacement of tags" and will duplicate functionality already available in base technology.

    Because of that, I downvoted the idea.

    Regards,

      Jan