Re: RM of [Organizational] Data

"erk" <eric.kaun_at_gmail.com> wrote in message news:1113915836.231378.56970_at_g14g2000cwa.googlegroups.com...
> mountain man wrote:
>> Here are two things I could hope to see in an extended
>> model of [organisational] data and associated processes:
>>
>> 1) Organisational structure: This may vary from organisation
>> to organisation however there are (in a theoretical sense) a
>> small number of finite organisational structure types that would
>> represent a great bulk of the "real world scenarios".
>>
>> The organisational structure assists in defining different
>> work-groups within an organisation. Issues related to
>> business rules and workflow practices often require
>> reference to elements of the organisation. Information
>> if often distributed according to informational need, and
>> a simple table can service to define an organisation's
>> structure.
>
> I don't think it's that simple, at least at companies for which I've
> worked, and in any event a theory should support all possibilities, not
> just the vast bulk (though it can optimize the "bulk" at the expense of
> the uncommon cases).

Organisational structure can be conceptually simplified in order to arrive at a basic overall framework for the structure into which more detailed descriptions of structure may be defined. In this sense, all possibilities are supported.

Large distributed conglomerate organisations undergoing change of ownership of course present a more complex structure to model, but the basic simple principles (above) will always be able to be determined.

>> 2) Application Register: I can think of no exception to
>> the premise that every database will also run an associated
>> series of - or suite of - (database) application software.
>>
>> From the theoretical perspective, it should not matter what
>> type of application it is, what it is written in, how many or
>> how few distinct program objects it consists of. In the end
>> there will be an associated register of program objects (or
>> indeed modules) in service alongside the dbms, that have
>> to be managed and change-managed.
>>
>> Combining reference to both the above items, common
>> menu and security access follows the mapping of the
>> elements of structure of the organisation (eg: workgroups)
>> to the (database) applications available.
>
> Often the mapping is more complex - it's not just "access type A" (i.e.
> CRUD: create/read/update/delete) to "program module M". Rather, it can
> be a join of modules to access types to an arbitrary selection of
> attributes across any number of relations.

Of course, I provided a simple example.

> This mapping can be as rich
> and complex as the data itself - indeed, this is just another aspect of
> the relational design.

The matrix can be a detailed as you wish, of course.

> I have yet to meet a "security system" that was
> generic across applications without severe limitations on granularity,
> excessive maintenance costs, or both.

You will note that the "security system" is mentioned above only as a corrolary of implementing: 1) organisation structure
2) application register

IMO by implementing these things within the model of the [organisational] data, there may be expected to be a far greater use and utility of the model, because both these items are dynamic and require management (and admin, and wages, etc) alongside every single instance of the data (model) ---- without exception.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Wed Apr 20 2005 - 10:34:14 CEST