[
Lists Home |
Date Index |
Thread Index
]
Ah. In that case the topic maps are doing
the job of an extended form of the data
dictionary table that includes bibliographic
references and mapping fields. That makes
sense. In this particular data dictionary,
the field descriptions are part of the meta-
field definition. A data dictionary that
would have initially three tables:
tables
Column Data Type Description
TABLE_ID Int 4 Unique identifier for table being described within tables.dbf.
Used in tables.dbf and fields.dbf to link records.
TABLENAME Char 32 Name of table
SHORTDESC Char 252 English description of table (HTML)
TABLETYPE Char 32 Code list value for the
CAPTION Char 48 Short English title for table
ALIAS Char 2 Two character code
NEW Logical 1 Boolean set to .T. by Schema Manager the first time the table is in a release.
OBSOLETE Logical 1 Boolean set by schema author for tracking old and now unused tables.
RESERVED Logical 1 Boolean set by schema author to indicate a table that is reserved for
future use or only used by IPS developers.
VERSION Char 10 The version number for the first release of the table. Can be
used to track changes among versions.
fields
Column Data Type Description
TABLE_ID Int 4 Unique identifier for table. Used in tables.dbf and fields.dbf to link records.
FIELDNO Int 4 Field Number. ID for field. Unique within the set of fields for the table
being documented. Non-unique for tables.dbf. Uniquely identifying a field
requires a join on the Table_ID and the field number.
FIELDNAME Char 32 Name for field.
FIELDTYPE Char 1 Code for I/LEADS field types
FIELDWIDTH Int 4 Width of field
SHORTDESC MEMO 4 English description of field. (HTML format).
FIELDVALUE MEMO 4 Example of field value
CAPTION Char 48 English title for field.
NEW Logical 1 Boolean set to .T. by Schema Manager the first time the field is in a release.
OBSOLETE Logical 1 Boolean set by schema author for tracking old and now unused fields.
RESERVED Logical 1 Boolean set by schema author to indicate a field that is reserved for
future use or only used by developers.
NULLORNOT Logical 1 Boolean to indicate if field can be null.
ISKEYTYPE Char 10 Code to indicate if the fields is a key and what type.
VERSION Char 10 The version number for the first release of the field. Can be used to track
changes among versions.
joins
JOIN_ID Int 4 Unique ID for the join condition
FROMTABLE Char 16 Name of table where join originates
FROMFIELD Char 16 Name of field used for Join
JOINTYPE Int 4 Code value for join type
TOTABLE Char 16 Name of table to be joined to
JOINEXPR Memo 4 Join expression
KEY Char 2 RESERVED
This is enough to generate the document for the application.
It could be extended with new fields for bibliographic
references.
A Query Builder uses these as source data and adds tables for
creating and tracking the query constructs.
We have a concept in the application
that the data dictionary documents. That
concept in called involvements and it is
a means for the user to get a view of the
application data that when traversed returns
a document view containing the anchors. I've
experimented with that using a topic map construct.
It seemed the most natural application. In
the application implementation, it resolves to a
query so that is why I asked.
Thanks for the answer.
len
-----Original Message-----
From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]
I think that as long as you want to stay within the traditional limits
of what a data dictionary of the type you describe is and does it
would be just a stylistic preference and not much else. Similar to
deciding whether to use CSV files or XML.
You'd begin to get benefits from topic maps when you wanted to do more
than just drive a GUI with the dictionary, for example by connecting
the dictionary to related information from other sources. That might
be definitions of the fields, background documents, mappings to XML,
etc etc
|
