Data Dictionary Concept

[J. 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 or 
object name 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


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com