Defining controlling and dependant associated atributes
Pickie
"The fundamental problem with all of the approaches MV takes to
defining our data schemas with dictionaries is that dictionaries do
not contain enough information for a full schema. Issues such as
controlling and dependent attributes are largely a function of our
programming style and not even directly referenced in the Information
model."
This made me consider how we might define controlling and dependant
associated attributes, and I came up with the following suggestion.
Set up a dictionary definition on the association name - very like PH
but with three attributes:
1 is J (description)
2 is controlling attribute(s)
3 is dependant attributes
I suggest J (for joined) because the one letter alternatives that
sprang to mind immediately (A for association, D for dependancy) were
already defined. As J is a little used letter generally, it's
unlikely to interfere with future usage.
Regards, Keith J(ohnson)
ash.c...@gmail.com
>
> This made me consider how we might define controlling and dependant
> associated attributes, and I came up with the following suggestion.
I've also needed to extend the dictionary meta-data model. These are
my enhancements:-
1. Primary D-Types start with DM (for master). By this I mean the
most important D-Type that defines the Justification, conversion,
length etc. All other synonyms are just ordinary D-types. Martin has
already confirmed that this will not interfere with other parts of QM.
This was part of Tom DeLombarde's PHP development, where he needed to
be able to extract a dataset view.
2. I store a single character in field 8,1 of the dict to denote the
datatype. So far I use B=Boolean, C=Currency amount, D=Date,
F=Floating point number, I=Integer, R=Raw, S=String(utf-8), T=Time,
U=UTC timestamp (AREV/OI format).
3. I define the controlling attribute as the FIRST field in the
association PHrase; All subsequent fields are dependent attributes.
4. I place foreign keys into dict field 8,2 of a D-type. I've made
this multi-sub-valued in case there is a need to join to multiples
files. I usually avoid this though. Arev/OI call this <verifile>.
These are mostly my own methods, and I've tried to make sure there is
little conflict with existing usage. I've parameterised this within
my usage, so that I can change it easily if Ladybridge were to define
an official place for the storage of this meta-data.
Ashley Chapman
dbene...@gmail.com
time to look it up at this moment is fleeting.
In D3, the dictionaries have the structure attribute (4) which allows
for the defining of controlling and dependent attributes within the
same file. This works great, for the most part. I have found that
mostly things go sideways when attempting to do selects without
realizing the inter-dependencies of attributes.
On should RTM for openQM and see how it handles the same. Maybe
Martin will pipe in here.
Regards, Dale
Pickie
So, can we all use DM to define our master definitions? It would be
nice if everyone respected it. Is there any problem with U2 products
if we do this? Reminds me of Dick Pick's "data momma" dm account in
some weird way.
Assuming the first field in the phrase is the controlling attribute is
eminently reasonable. I was trying to cover the Relational Model
fully - perhaps a silly idea! Multi-part keys are the way Pick caters
for more than one primary key and maybe I should have stuck with
that.
Just what do your foreign keys look like in the dictionary? I'm
curiuos about that.
regards, Keith.
On 23 Feb, 20:32, "ashley.chap...@billabong-services.co.uk"
Martin Phillips
> I don't know how QM handles controlling and dependent
> attributes, and time to look it up at this moment is fleeting.
This is one of the few areas where I think Pick did a better job than
Information. In the Information model, all attributes in an association are
of equal importance whereas Pick makes one of them more important than the
rest.
When I teach multivalue training classes, I bring this out in the context of
a simple sales application by pointing out that the customer came into the
shop thinking "I need some part 102, how many shall I buy", not "I'm going
to buy three of something, what will it be".
Because QM is largely based on the Information model, although we support
A/S type dictionary items, the controlling/dependant part of field 4 is
ignored, making all associated attributes of equal importance. It probably
would not be difficult re identify one as controlling but we need a clear
definition of what this should then do. In my 20 years experience of
multivalue, I cannot recall a situation in which I needed to know which
attribute was the controlling one within the associated set.
The query processor does make extensive use of associations in pairing up
items correctly. From a recent thread on this group, we believe that QM is
possibly the only mv product that gets this right down to the subvalue
level.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
dbene...@gmail.com
most in the multi-values that I can think of at this time. Although I
do have a data table or two where there are two sets of controlling
and dependent attributes. And I'm not sure if I ever list data from
the two tables at the same time without producing a report through
BASIC.
The controlling and dependent stuff really is only for listing
purposes. Up-keep of the data in the tables is strictly under program
control.
I will need to do more investigation into all the nuances that D3 can
do and compare that with QM.
Best regards,
Dale
On Feb 24, 1:56 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:
ash.c...@gmail.com
2009/2/24 Martin Phillips <martinp...@ladybridge.com>:
>
> Hi Dale,
>
>> I don't know how QM handles controlling and dependent
>> attributes, and time to look it up at this moment is fleeting.
>
> This is one of the few areas where I think Pick did a better job than
> Information. In the Information model, all attributes in an association are
> of equal importance whereas Pick makes one of them more important than the
> rest.
>
> When I teach multivalue training classes, I bring this out in the context of
> a simple sales application by pointing out that the customer came into the
> shop thinking "I need some part 102, how many shall I buy", not "I'm going
> to buy three of something, what will it be".
It's a good job you never had my wife in your class! The articles she
buys are random, it's just the quantities that are fixed. ;-)
>
> Because QM is largely based on the Information model, although we support
> A/S type dictionary items, the controlling/dependant part of field 4 is
> ignored, making all associated attributes of equal importance. It probably
> would not be difficult re identify one as controlling but we need a clear
> definition of what this should then do. In my 20 years experience of
> multivalue, I cannot recall a situation in which I needed to know which
> attribute was the controlling one within the associated set.
Generally it's not needed, although in the query processor you have to
count up the multivalues in each association to determine the maximum
before you output a record. By having a controlling attribute, I only
need to count up that one, and output from there. A bit helpful with
XML.
The main benefit is that it encourages you to describe the data model
structure. That helps as the system ages, and other people work on
it.
Don't get me wrong, it's something I can live without. It just makes
things a little tidier. Especially where there are a lot of null
multivalues in an association.
--
Ashley Chapman
ash.c...@gmail.com
2009/2/24 Pickie <keith....@datacom.co.nz>:
> Hi Ashley,
>
> So, can we all use DM to define our master definitions? It would be
> nice if everyone respected it.
the PHP module. Ladybridge can decide if they want to formalise this,
or just leave it as a loose convention.
> Is there any problem with U2 products if we do this?
> Assuming the first field in the phrase is the controlling attribute is
> eminently reasonable. I was trying to cover the Relational Model
> fully - perhaps a silly idea! Multi-part keys are the way Pick caters
> for more than one primary key and maybe I should have stuck with
> that.
to stakc up completely. When you consider the mess that SQL makes
over nulls and NaN, you appreciate that it's not always a good idea to
copy Mr Codd. So my aproach is pragmatic, and probably
over-simplistic.
Multipart keys break the above model a bit, although not in
Revelation, which defined them properly in the dictionary.
>
> Just what do your foreign keys look like in the dictionary? I'm
> curiuos about that.
one called JOB the other called CUSTOMER. The customer file has an
@id which is just made up, and F1 is the customer's full name. The
Job file also has a made up @id, F1 is a description of the Job, and
F2 is the customer code. This makes it a foreign key into the CUST
file, as all jobe must be assigned to an already existing customer.
Hope you're still with me!
In the above example, the D-type for F2 would have 'CUST' in field8, value2.
Revelation called this VERIFILE, and used it to verify data entry. I
do the same, just give it the grand name of Foreign-key to sound more
hip and modern!
Ashley Chapman
Martin Phillips
> I guess the pairing will take care of most in the multi-values
> that I can think of at this time. Although I do have a data table
> or two where there are two sets of controlling and dependent
> attributes.
That's fine. With D/I type dictionary records, you give each set of
associated fields a name and there can be any number of such sets. With A/S
type records, we use field 4 to identify the fields in each association and
effectively build an association name of our own so again there is no limit.
The only bit we don't do is to treat one field as being more important than
the others. I have no idea what we would do with this anyway on the context
of a report.
> I will need to do more investigation into all the nuances that
> D3 can do and compare that with QM.
There has been a lot of work in recent releases to improve compatibility. QM
2.8-9, due out in the next few days, adds further improvements.