In message <4bc5e280.5070...@advantos.net>, Bill Haskett
<wphask...@advantos.net> writes
Wol:
What do you consider properly normalized and what example would you
give for designing a new mv FILE as a set of nested tables?
Basically, use relational theory. Okay, mv design isn't as clear as for
a RDBMS (they force everything into two dimensions - imho a very stupid
idea), but the underlying maths provides a solid foundation.
The way I'd do it is to do an EAR (Entity/Attribute/Relationship). Each
entity I would aim to put into an individual FILE. All the associated
attributes and relationships, I'd analyse using relational theory, then
recombine them in NFNF using values and sub-values as required.
This is where the fact that MV is not fully multidimensional can be an
advantage, or can be a pain if you need more levels than provided by
sub-values. But my rule-of-thumb is that if your FILE primary keys are
equivalent to real-world keys, then your design is about right. If you
need what looks like a SQL complex key, chances are you're falling into
Einstein's "too simple" trap.
That said, I have had some exposure to accounts systems, and doing an
EAR on them is likely to be "interesting", let's say ... most of my
experience has been in other stuff like bill-of-materials, and
statistical analysis of prices.
Thanks,
Bill
Cheers,
Wol
--
Anthony W. Youngman <pi...@thewolery.demon.co.uk>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
