Point me to Area of Database Theory?

I am looking for research on the following type of (database) problem
- data used outside the domain under which it was created.

For example, take a company which uses social security number as their
"employee identification number" in their human resources database.
This might work initially (as all employees may have SS#'s), but
companies will run into problems when they hire people w/o social
security numbers - e.g. foreign employees.

The reason they run into problems (I believe) is that social security
number is defined over a particular domain (the set of all individuals
issued numbers by the US social security administration) which may
overlap significantly, but is distinct, from the domain of "employees
of company X".

I believe that this type of problem can be generalized -- whenever you
use data outside of the domain under which it was strictly defined,
you will run into problems. (Thus, I am not looking for a solution to
the SS# example I gave -- it is just an illustration of a larger
problem).

I am looking for research that talks about this type of issue (cross
domain usage of data), the problems caused by using data in this way,
and perhaps a set of principles for addressing and avoiding such
issues.

It has been suggested to me that this might be the old "primary key including meaning" problem, but I think this applies even to fields that are not primary keys. An example might be an "expense" table that needs a list of currency codes to demark the currency of the expense. A designer in a hurry might look around, and use an available currency table created for the purpose of reporting currency trading prices just because it already exists and seems similar to what is wanted. This might work for a while, but say the owner of the currency table splits one currency into two currencies for *trading* purposes (e.g. when the Euro was introduced for trading, before it was being used in reality), but that is irrelevant for *expense* purposes. Because the designer is using the currency field in the expense table to mean something different than the currency trading table, they will run into problems when you reach the boundaries of the similarities between the two uses.

Wow, this one's a thinker... =)

It sounds like this is more of a systems architect role than a database architect role. There comes a time in every project where sacrifices must be made; often poor decisions are used in order to follow company protocol. It is impossible to create one system that is flawless. Something as simple as a phone number field - or the social security number in your example - when unexpected anomalies occur, can wreck your system's integrity.

The idea you hint upon is what I've known as 'globalization'. The best way to plan for the unexpected is to define the scope of your system. All these issues should be raised in the pre-development of the system, instead of when it's in production and being used as the primary application.

As for links and resources, I can't say I know of any off-hand. Sounds like more of a Google solution than any one set of articles or tutorials.

I just felt like adding my two cents =)

looks like more of a design issue than a DB theories (hierachy model, RDBM or network model)

This is true that it is a design issue, but there is a part of database theory dealing specifically with design issues. I'm looking for these theoretical design principles. Thanks for the comment - much appreciated.