TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Usage of "mapping" From:Gwen Thomas <gthomas -at- PAYSYS -dot- COM> Date:Mon, 28 Jun 1999 12:55:14 -0500
In software development, "mapping" often has two very specific meanings.
1. When "mapping" is used as shorthand for "data mapping," it is usually referring to the process of comparing two sets of data and associating like data fields. This often takes place as part of a data migration process. For instance, Name/Address Table 1 may call the last name Surname and allot space for 30 characters. Name/Address Table 2 may call the last name LastName and allot space for 25 characters. In order to migrate data from Table 1 to Table 2, you need to map Surname to LastName, and develop a policy/process for dealing with those pesky extra 5 characters.
2. More generic meaning: Associating 2 related data fields. Take for example a hypothetical database of those who attended the recent International STC conference. Suppose we stored session evaluations in a table, with each evaluation listed by the evaluator's Social Security number (no name). We'd also have name and address data for each attendee/evaluator in another table. If we mapped (associated) the s.s.n. to whatever data is the "key" in the name/address table, then we'd have a new, larger set of data that is much more that the sum of its parts. We could run reports of session preferences by attendee's zip code or STC region, for instance - information we could never have known by looking at each set of data independently. We could add another simple 2 column table - s.s.n. & last year's salary - and now we could easily evaluate session preferences by salary level and home town. And so on.
By the way, the ability to leverage related sets of information in such a manner is one of the strongest arguments for using a database approach to Single Sourcing of certain kinds of documentation.
Gwen Thomas
Knowledge Management Consultant
CIBER Information Services, Inc.
