[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