[thelist] information architecture question (non technical)
Luther, Ron
Ron.Luther at hp.com
Tue Dec 12 14:00:32 CST 2006
Matt Warden asked about IA:
>>This question does not require any specific technical knowledge to
answer.
Whew! Good thing for me! ;-)
>>Suppose you are trying to present summary level data about [stuff]
>>How would you model this data, hopefully keeping the same
>>structure for both the individual worker view and the organizational
view?
Hi Matt,
Well ... I've done some very similar kinds of reporting and the way
I've set that up is to have my hierarchy data set off in a second table.
You've got your 'transactional data'; worker number, job/task number,
due date (or number of days). [If you really have 'task type' I would
argue that should be set that off in a separate hierarchy / attribute
table and linked in as a categorical control. E.g Select all 'painting'
tasks.]
I would set the data rollup hierarchy off in a separate table. Worker
--> supervisor --> department --> plant --> division --> State /
Province --> Region --> Planet --> Galaxy ... Etc.
Now set up your report as if reporting for an individual worker bee.
Link the worker bee back into the hierarchy table and add report
controls to let users report at whatever level they want. Done.
[Visually folks often use a collapsed/expanded folder control where
you initialize the report at 'all' and let users drill into the
lower levels with the control. E.g.
- All Apparel
- Sweaters
- Overcoats
- Shoes
- Running Shoes
- Hiking Shoes
- Boat Shoes
+ Shirts]
Same kind of structure works well for geographic hierarchies,
or product hierarchies, or organizational hierarchies.
{This is similar to past due purchase order reporting where you
can either link the individual buyer back to a 'buyer org' to a
supervisor to an organization / location / etc ....... or you can
link the part number back to a product or commodity hierarchy.
Past due sales order reporting has similar hierarchical linkages.}
Now ... If you have LOTS of data and really want your reporting
to fly ... {I wasn't completely sure if you were asking about
structure or about speed} ... then you might want to think about
preprocessing an aggregate table and running your reporting off
that. E.g. at the end of the day sum up and write out a single
'level zero' record that has sums for *all* 0-10 day late tasks,
11-20 day late tasks, etc. Then write out the 'level one' records
by plant or division. Then write out the 'level two' records by
supervisor and the 'level three' records by worker. Make that a
control in the report and things will move pretty fast. (A user
wanting the world-wide view is retrieving exactly one record ...
even with tricky caching strategies it don't get much faster
than that!)
HTH,
RonL.
* I used to get into some _really_ neat arguments with a co-worker in
Cali
about 'Federated' versus 'Non-Federated' data models and whether that
hierarchical reference data should be managed in a stand alone
environment
or whether it should flow through the transactional systems along with
the
raw data. Fun!
More information about the thelist
mailing list