Re: RM of [Organizational] Data

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sat, 16 Apr 2005 10:07:16 -0400
Message-Id: <mri7j2-sms.ln1_at_pluto.downsfam.net>


mountain man wrote:

> The issue of the ownership of data is possibly worth exploring.
> Here we are restricting consideration to data held in a database.
>
> Using the following list of roles associated with any database

>> ==================================
>>    DATABASE SYSTEMS ROLE-TYPES
>> ==================================
>>
>> --------------- Internal to the organisation:
>> I01 - business owner(s)
>> I02 - business executives and managers
>> I03 - general organisation work-groups/end-users
>> I04 - DBA (for SQL-DBMS)
>> I05 - IT manager
>> I06 - internal programmers
>> I07 - specialised development teams
>> I08 - Operations & help desk personnel

>
>> ---------------  External to the organisation:
>> E01 - contractors and consultants (in any roles defined above)
>> E02 - contract programmers (or software house(s))
>> E03 - consultants and suppliers (of selected RDBMS software)
>> E04 - consultants and suppliers (of other software & hardware)
>> E05 - business, management and financial consultants
>> E06 - consultants in Models of Data

>
>
> All other roles apart from I01 (buiness owner(s)) are what
> might be termed custodians (of varying degrees) of the data,
> whereas the actual ownership of the data resolves to the
> owner of the organisation. Any diasagreements here?
>

nope.

>
> Consequently, implicit in any model of the data should be
> the understanding that the data ultimately belongs to the
> business owner.

...not sure where you are going...

>
> Thus, implied in the phrase "RM of the data" is the
> expanded form "RM of organisational data", because
> data is always associated with an organisation (treating
> an individual as a minimal organisation) without
> exception.

...ok, I think I see the point, maybe. As far as a database model goes, it need not be concerned per se with data as it may be handled by other owners after exports or before imports. It would define boundaries which are crossed by import/export, but is free to enforce its own design ideas for a particular owner without considering the design ideas of other owners.

This would be important because it means the RM never needs to "include XML" (must put that term in quotes because it is utterly meaningless) just because other db owners may use it. Rather, a particular db implementation must only be able to translate that format.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Sat Apr 16 2005 - 16:07:16 CEST

Original text of this message