Hi,
I have the following issue (I hope I post the right group):
I'm thinking to write a tool for Interface Requirement Specification
(IRS).
Then I'm wondering about the db data model.
I identified the following entities:
-System
-Interface (between systems, interface have directions)
-Message
-Datafield
I then identified the following relations:
A system can have zero or more interface.
An interface can have zero or more message.
A message can have zero or more datafield with an ordered position.
A datafield can be a simple one (like integer, float, etc) or composed
by other datafield.

The following is a first raw sketch I thought:
SYSTEM_SCHEMA={IDsys, Name, Desc}
INTERFACE_SCHEMA={IDitf, Name, IDsysSource, IDsysDest, Desc}
MESSAGE_SCHEMA={IDmes, IDitf, Name, Description}
FIELDOFMESSAGE_SCHEMA={IDfom, IDmes, Position, IDtyp, Name, Desc}
TYPE_SCHEMA={IDtyp, Name, isNative, Desc}

The "isNative" flag identifies simple type from composed type.

I'd appreciate comments and suggestion about that.

Thanks in advance for the interest.

LC

Are you wanting your data to describe sample data shown below?
If so, I think your schema is appropriate.

System1
Interface1
Interface2
Msg1
Msg2
Field1 (simple)
Field2 (simple)
Field3 (complex)
Field100 (simple)
Field101 (simple)
Field102 (complex)
Field200 (simple)
Field201 (siimple)

To handle the sample data in prior post, your schema might look like
this:

T_System
T_Interface
T_Msg
T_Field (... isNative? ...);
T_ParChildField

Managing fields which can be composed of fields could become
interesting.

LC wrote:
The ID attributes shows you are thinking of TABLES too early in the
design process. Try to avoid that. You may end up using ID's later, but
that's a physical design issue, not a logical design issue.

Now since this has a lot of the character of a language, consider a
slightly reversed view of messages:
-- a message is a set of fields where each field is a fundamental
type or another message.

Your fields entity would still need the type attribute. But this
recursive definition simplifies the description of composite fields.
Then you only need one more field type. And this follows the way
progrmmers would develop these messages.


Another high level issue: are messages allowed to have optional fields?
how yould you document that? Once you allow optional fields, then
there arise the conflicting options. So what if optional field B should
not be included if field A is included? just more things to consider.

Ed