Re: RM of [Organizational] Data

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).

> 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. This mapping can be as rich and complex as the data itself - indeed, this is just another aspect of the relational design. I have yet to meet a "security system" that was generic across applications without severe limitations on granularity, excessive maintenance costs, or both.

• erk