Re: Structuring attributed data-fields

From: Angus Monro <ajmonro_at_ingennia.com.au>
Date: Thu, 14 Dec 2000 17:44:01 +1100
Message-ID: <3A386C31.B5A25EF_at_ingennia.com.au>

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.

Jan Hidders wrote:

> Angus Monro wrote:
> > Hi there,
> >
> > I'm working on the database design behind a system that renders the data
> > across many display types and formats and audiences. In an airport,
> > actually.
> >
> > What we have is a table of flight-related info. [...]
> >
> > I'd like to know what people think about this. I'd like to know, too,
> > if there are any other approaches that we've missed - maybe even we're
> > misusing the database? Not sure!
>
> I get the impression that you are doing things backwards. You are
> talking about all kinds of implmentation details, but it is not really
> clear to me that you have pinned down exactly what the data is. So, do
> you have a description of the data in something like an ER-model or ORM
> or UML or whatever? I say this because if you don't know what your data
> looks like, then it is very hard to decide what the best way is to store
> it.
>
> --
> Jan Hidders
Received on Thu Dec 14 2000 - 07:44:01 CET