From: rzepela@hal.hahnemann.edu
Newsgroups: comp.databases.ingres
Subject: One respose to duncan & judith
Date: 14 Sep 92 01:42:31 GMT
Organization: National Radio Astronomy Observatory

At least one other reader (Eric Hughes) seems to think it might be 
an OK topic 4 this group, so I have forwarded to the list my response to 
duncan & judith who solicited "real world" experiences in 
designing _Databases_&_Ethics_ - oriented material for 3rd-yr students.
 
 
duncan & judith - 

Re: your database & ethics query for your third-year students 
(which I assume was posted to your Columbia colleagues, then forwarded 
by one of the same), I offer two topics. First, I would heartily second 
the comments of  alan@curta.cc.columbia.edu (Alan Crosswell) with some
adjustments when he said: 

> How about, "Don't use the power of the relational JOIN to learn things
> that you shouldn't know about people."  JOINing two different databases
> about people (employees, students, customers, etc.) on a common attribute
> like the US Social Security Number is an example of this. 

But since you are teaching people who will not only be the end-users of 
such systems, but also the designers, perhaps you should discuss the 
increasingly touchy area of database access on "open systems".  Many 
people confuse "open systems" with "open data". 

There is a struggle between efforts to provide straightforward access
to networked services and datbases, yet a need to keep sensitive data
secure.  The conundrum is that as the personnel needing such data are 
more valuable/educated (e.g., doctors), the more sensitive the data
and the LESS likely the users are to want to fuss with yet another 
password/access limitation.  I work in a teaching hospital, where 
no one wants to have to log out of their sessions connecting them to 
the clinical laboratory blood workups, on physically accessible terminals, 
much less remember a password. 

While this seems like an interface or data security problem, (and 
one that can be solved with hardware such as  strip readers, software 
time-outs, etc.), and not a database problem, the fact is, it will 
often be up to the database designer what fields to cross-index on, what
kind of information the application managers need to know, how much 
the app designers need to know, how much the end users are allowed 
to see, etc.  Throw in the wild card of open systems, and the mix does 
become an ethical problem:  I know what my team leader is telling me to 
provide, but I am also aware of issues of liability (legal OR moral) in 
providing what is requested of me.   

While it is more a question of legality and pragmatics than ethics, 
you could point out the possible legal liabilities of leaving data
and systems so "open" that some eager snooper could make the case in court 
that data was never really secure in the first place, leaving the liability 
on the shoulders of the DBA.  

Answer this question:  As the DBA, I have to balance  ease-of-access with
security concerns.  When ill-gotten information is obtained via avenues I have
created to ease access,  what exactly is my responsibility? 

 


Topic II: DATA INTEGRITY

The second topic is one that arises when one has to handle or manage 
the conversion of data with known errors.  Again, it sounds like a software
engineering problem (if ya wrote good code, we wouldn't have 50,000 
JOHN DOEs in the database, would we?)  - but I am specifically 
referring to when one is given the responsibility of converting a database
from one product to another.  Given logical errors (101%, numeric fields
represented by text with embedded spaces, etc.), where the DBA does not
have access to original documentation that would reveal the true values, 
what are the valid choices?  Should the person whose task is to provide
meaningful, consistent data after the conversion simply reproduce the 
errors, and consider him/herself an automaton?   Is it beyond the realm of 
consideration to ever alter anything that is found in a database one is 
assigned to simply convert, even when the keying error made originally  
would appear "obvious" to everyone? 

So, when no other sources or authorities are available, what to do? 

Where does the DBA's responsibility end?  In simply reproducing errors?


DISCLAIMER: 
Nothing in this note is meant to imply that our site has not answered
these questions already for ourselves. 

-------------------
Anthony Rzepela    <rzepela@cvi.hahnemann.edu>
"What IS this fascination with Axl Rose? He looks so...unhealthy." - M.C. 1991
-------------------