Re: RM of [Organizational] Data

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Tue, 19 Apr 2005 08:16:40 GMT
Message-ID: <I739e.16429$5F3.13730_at_news-server.bigpond.net.au>


"erk" <eric.kaun_at_gmail.com> wrote in message news:1113855391.909117.63020_at_f14g2000cwb.googlegroups.com...
> mountain man wrote:
>> Whatever theory exists of the data, and the data model,
>> and the database management system, that theory should
>> be aware of the implication that the data relates to an
>> organisation, and has ownership by that organisation.
>>
>> Codd's 12 rules, for example, do not reveal any
>> expression of this implication, and are restricted
>> to a focus that is purely technical wrt the dbms.
>>
>> From the perspective of the theory, if certain specific data
>> related commonalities can be shown to exist across the spectrum
>> of all organisations, then one might expect a theory (of data) to
>> address such issues.
>
> Possibly, but what would you expect it to say? I think common relations
> defining a system catalog are a good idea, and therefore you could
> include authorization in that catalog. Beyond that, what would you
> expect to see?

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.

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.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Tue Apr 19 2005 - 10:16:40 CEST

Original text of this message