Re: Structuring attributed data-fields

Are you talking about changing the display _format_ for each attribute based on a particular 'context' (audience, etc.) or the display _content_ ?

From the example below, the table for 'Flight' has field 'Port of Departure', etc.
So then, for the 'Public' context, we display "Houston", but for the worker's context we display "IAH" ? That would be like translating the _content_ based on the audience?

Or are you saying that for the above field, if the value changed within the hour, we change the _format_ to a blinking or red background?

At first I was thinking you could make a separate table, say 'DisplayFormat' , whose fields are like: ContextID (audience), FieldName (Table.Field), and maybe 'ScreenID', then 'RegularFormatID' (Background Color, Hidden, etc), and 'RecentChangeFormat' (Color, Blinking, etc).

(Would the "Recent Change" aspect be an additional "Context" like audience, or be a modifier for each audience?)

But this got me dizzy thinking of the possible implementation woes -- I guess the current system does it already, though. I think this is a great strategy and a 'needed' strategy for this industry and a few others. Do you anticipate any "resistance" in selling the plan to the others?

Let us know how it goes,
Thanks
Lee

In article <3A386C31.B5A25EF_at_ingennia.com.au>,   Angus Monro <ajmonro_at_ingennia.com.au> wrote:
> OK, you're half-right! I'm dealing with a legacy system whose
 persistence is
> managed by a non-relational database, and those responsible for the
 legacy
> system have prefered to do the analysis in their head. For the
 record, we are
> moving the system to a relational db and I've managed to slip into
 the project
> plan a sizeable slab of time for analyzing, re-modelling and
 documenting the
> data. Nevertheless, the data and the relationships are pretty well-
 known.
> e.g.
> A Flight has n:1 relationship with an Airline.
> A Flight has n:1 relationship with an Aircraft.
> A Flight has various attributes, including:
> port-of-departure
> port-of-arrival
> estimated date/time of departure
> estimated date/time of arrival
> status (boarding, locked-up, en-route, landed, ...)
> At any given time, a Flight has a 0..1:n relationship with a
 Parking Bay
> (at the port of departure).
>
> An Airline has a name and a designation.
> An Aircraft has a mfr, type, designation and owner.
> A Parking Bay has an identifier.
>
> At present, there's a scarey amount of data that's in 0NF (such as
 most of the
> above data) -- again, I'm looking forward to re-working that!
>
> All of the above data (and more) is required to be available for the
 display
> systems. The software that drives the displays makes the decisions
 about how
> to render the data (e.g. highlight certain data is they've changed
 recently;
> don't display a certain datum on the public displays if it has not
 yet been
> tagged as being public data).
>
> At present, the system already has attributes similar/related to the
 ones I've
> discussed in my earlier posting, and these have been implemented in
 the
> database schema by the double-the-width-of-the-table method that I
 mentioned.
>
> Anyway, I feel that even with the "mini-schema" I've sketched above,
 the
> question of my original posting still remains, and I'd appreciate your
> thoughts.
>
> TIA.
>
> - Angus Monro.

Sent via Deja.com
http://www.deja.com/ Received on Thu Dec 14 2000 - 16:57:05 CET