MetaData Repository Standards (crossposted from comp.databases.ms-access)

I put this up on the other NG, then thought better of it...
---
I'm tasked with developing a enterprise-level metadata tool - starting yesterday
and TB delivered by Jan 30th.
There actually is some small chance of my delivering same - since I've already
done something similar in the context of recording report requirements (field
sources, calculations, and so-forth).
But this time, I'd like to do the architecture the "right" way - i.e. with the
same table structure that some commercially-avaiable tools use.
Anybody know of a reference book that details this sort of architecture? It's
not quite as obvious as it may seem at first because of various recursive
relationships - like fields/calculation components and allowed values/sub
values.
--
PeteCresswellHave you had a look at SQL Server Meta Data Services' Here is what it does:
Meta Data Services is intended to store meta data, and it is designed to be
integrated with other tools and applications. It provides a solution for
storing and managing data warehousing definitions, OLAP definitions, design
data used in development tools, and any other type of meta data used in a
programming environment.
I've not personally worked with this, but maybe it can meet some of your
requirements.
--
HTH,
SriSamp
Please reply to the whole group only!
http://www32.brinkster.com/srisamp
"(Pete Cresswell)" <x@.y.z> wrote in message
news:aeevtvkbg1aae0enkk28pfi5jbchsnl6j2@.4ax.com...
> I put this up on the other NG, then thought better of it...
> ---
> I'm tasked with developing a enterprise-level metadata tool - starting
yesterday
> and TB delivered by Jan 30th.
> There actually is some small chance of my delivering same - since I've
already
> done something similar in the context of recording report requirements
(field
> sources, calculations, and so-forth).
> But this time, I'd like to do the architecture the "right" way - i.e. with
the
> same table structure that some commercially-avaiable tools use.
> Anybody know of a reference book that details this sort of architecture?
It's
> not quite as obvious as it may seem at first because of various recursive
> relationships - like fields/calculation components and allowed values/sub
> values.
> --
> PeteCresswell|||> Meta Data Services is intended to store meta data, and it is designed to be
We're using a product called PACE - implmented here with an Oracle
back end.
It's primary uses are
- As a staging area for data flowing into local systems from
outside vendors
- As a staging area for the reverse: data from local systems
to the outside
- As a historical archive: some systems want to know the state
of, say, a muncipal bond as of a certain day in the past.
Over the years it's grown and grown - becoming slower and more
complex.
The tactical problems at hand are three:
1) That people have used it's "UserField" definition capability
extensively and created many duplicate calulation fields which need to
be identified and coalesced.
2) The owners suspect there are a number of loops: i.e. a field comes
from and outside vendor, goes into local system XYZ, and then gets
harvested back into the staging area unchanged.
3) By now it must contain a number of "orphan" fields: fields that
are not used by any local system.
The tool I'm writing will enable various people to document each field
in PACE: all the places it comes from, all the places it goes, how
often it's refreshed, the properties of each of it's incarnations,
rollup calculations, user calculations, upload
calulations/transformations, and so-forth.
I can think of several data architectures/table designs/whatever to
accomplish this, but I'd *really* like to copy something written for
the same niche that has a proven track record - both for
bulletproofness, and because eventually they'll purchase a "real" tool
and there will be a migration...
Of course, nobody's saying what the "real" tool will be - but I'm
hoping that all the major contenders' developers will have arrived at
similar designs looking at the same requirements...