Data Dictionary

[Jeff Childers]

Derek,

Has any kind of data dictionary or data structures definition been started
yet? If not, I have a concept that I've been using over the last couple
years in our development that seems to really shorten development time.
Basically, it works like this (lots of detail left out of course):

Define Possible Properties (think fields in this case) of Objects (think
tables) as one of a few pre-defined types:

1- Primary key (one per object, user-invisible)

2- Surrogate key (user-visible object key e.g. customer, item, vendor "ID"
number. All characters allowed, read/write)

3- Local value ("data"; e.g. units ordered, contact phone no, company name,
etc)
        - list/option values can be set and edited right in data dictionary
for combo/list fields 
          this can be a list of values or a SQL statement that returns the
list
        - generic data types (char, int, date, logical, etc.)
        - meta-types: e.g. phone number, zip code, currency, etc.

4. Composite value (i.e. "calculated field". The dictionary stores the SQL
used to calculate this field at runtime for any time it is used or
displayed. Logic in the object class handles calculating the value on the
fly whenever the property for this field is accessed from the object.
Nothing is actually stored in the table - this is a logical field with no
physical counterpart). Examples: line item subtotal, order total, order tax,
order freight, A/R account distribution total for invoice, inventory on-hand
quantity, etc. So ALL subtotal or aggregated fields are calculated on the
fly. It becomes very easy to edit / maintain the calculations at the data
dictionary level, and avoids many data integrity errors.


Now you add default logic to your base classes for data entry controls that
determine behavior when the control is created on a form depending on the
data type. The only property you are required to set locally is the field ID
- the control looks up the typing and other information from the data
dictionary.

TYPE                    BUILT-IN BEHAVIOR
================
====================================================================
Primary keys    Never shown, only possible behavior is set self to read
only)

Surrogate keys  Implement lookup logic when in edit mode via right click
menu or 
                        create a small lookup button next to field on init
etc). E.g. 
                        Order No control on Invoice form lets you "lookup"
the 
                        original order form. Customer no control lets you
"lookup" the
                        customer card and/or select a different customer. 
                        Implement optional search logic to trigger lookup
form/utility.

Local value     Set all properties for control from base data type
definition:
                        E.g. "list" fields get a combo box, "phone no"
fields have their 
                        input mask set to system default, general
validations are set, etc.

Composite value Read only at runtime. However, right click or runtime-level
control
                        allows "drill down" to the records that are used to
calculate the 
                        value. E.g. right-click on AR Debit balance field
and see all the 
                        individual postings that make up the figure. You can
do a lot more
                        with this.

You could define a couple more types (e.g. true "drill-down" and "drill-up"
types) but you get the idea. Here's where the advantages start:

1) The data dictionary becomes the central place where much application
behavior and logic can set set or modified (think end-user customizations
like the ability to change list values easily). 

2) Data dictionary can now be used to enforce core validations at all levels
of the application. E.g. you can open the entire table for browsing in a
grid -- each individual cell control relies on the dictionary settings to
validate, calculate, format, etc. 

3) Adding controls to forms requires only to set the field ID to enable the
majority of functionality that you typically want. There could be a single
control that even includes the object's caption (from the data dictionary).
Designers could just use that single control when building forms and not
have to worry about 10 different widgets - the control will self-select the
appropriate widget.

4) Upgrading the base control class can upgrade application-wide behavior.

5) Key modules such as lookup forms, drill-down and drill-up become
automated and can be maintained in a single place.

Detail record entry (e.g. sales order lines) can be easily handled in a grid
where each cell is a baseclass control. If the wxPython grid widget isn't
working sufficiently well to handle this we can create our own grid control
without enormous effort I think.

What do you think? If you like it, I could flesh it out into something more
tangible for peer review and comment.


Regards,

Jeff Childers


-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of Derek
Neighbors
Sent: Friday, August 16, 2002 4:25 PM
To: J. Childers
Cc: address@hidden
Subject: Re: Supply Chain Spec Volunteer


Yes we woudl love it, the source of that pdf is in cvs and is actually
in docbook (xml).  You can submit patches to it via address@hidden or
address@hidden

Neil Tiffin was heading up specs, but has other committments now, so
sending to the core will work until we find a new 'head' of application
speficication.  It's really a great job, in fact it even pays well, a
200% increase per day is *GUARANTEED*.  (assuming one is foolish enough
to believe 0*200 = something valuable)

-Derek
On Thu, 2002-08-15 at 14:22, J. Childers wrote:
> Hey, do you guys want somebody to start fleshing out the SupplyChain.pdf
document? I assume that
> it's a spec of sorts...
> 
> I would love to work on that. I have lots of detailed ERP product
experience (from coding to
> implementation) and tons of opinions :).  Who's in charge of specs anyway?
> 
> Regards,
> 
> Jeff Childers
> 
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com
> 
> 
> _______________________________________________
> Gnue mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue
> 




_______________________________________________
Gnue mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnue