RE: Design shift of view

[Joe Teff <jteff19@xxxxxxx>]

> It's interesting that a debate on DDS and display files turns to database
> modelling. However I don't think the "design shift of view" has really
> shifted too far from our current modelling practices. Why should "changing
> a record structure" on the fly be an issue. If we want a real design shift
> we need to stop thinking in terms of files and record formats and more in
> terms of the relationships that exist between individual data components.
> And yes James you're right - the way we store information has to change.
>
> We've based our database structure on the physical appearance of business
> documents as they were printed on paper. Now that we've replicated this
> "paper" document into an electronic form and stored it in our database, we
> create a slew of programs to query this information in a 100 different
 > ways. What we need to recognize is that a business document means different
> things to different people in an organization - what the CFO and the
> assembly line supervisor need to see from a purchase order are two
> different things. The separation between business documents as implemented
> in most databases tends to be reflected in most workflow processes. Why do
> we separate "invoices" from "P.O's"? In reality it's just the
> "representation" of the same data that changes. The presentation of
> information (call it the GUI) on my screen should reflect my needs and my
> role within an organization - it should not be a basis for how the data is 
>stored.
>
> Rob Dixon's earlier thread attempted to fire up a debate on the subject of
> new database models. Given such an "encapsulated" business database we
> could focus on providing tools that would allow people to access
> information through more intuitive methods (such as function) than having
> to specify fields in records in files. We could all be looking the same set
> of data in entirely different ways - there would be no purpose or need in
> having fixed screen presentations and the DDS debate would be moot.  

I'm interested in this topic of a new data model, but as of yet I haven't heard
anything that I can "sink my teeth into". I don't understand how this database
would look. Could you elaborate. I'm not much of a theory person - I like
pictures, examples and analogies. Thanks.

Joe Teff
Information Technology Consultant
IBM Certified Specialist - AS/400 RPG Programmer
Quality Data Systems
Minneapolis, MN

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---