Version 21 (modified by gordonrachar, 15 years ago) |
---|
TracNav menu
- An Introduction to ISO 15926
-
What is ISO 15926
- How Information Exchange is Supposed to Work
- How Information Exchange Actually Works
- How Information Exchange Works with ISO 15926
- How ISO 15926 Works
- A Bit of History
- Long Tail
-
Areas of Current Work
- Norwegian Continental Shelf
- MIMOSA
- JORD
- iRING
- Development of Standards
- Educational Material
- Getting Started With ISO 15926
- Other ISO 15926 Resources
-
Introduction to ''An Introduction to ISO 15926''
- ISO 15926 is Like a Babel Fish
- ISO 15926 is Like HTML
- ISO 15926 is Like English on Your Cell Phone
- About the Author
- ISO15926Primer_DiagnosticPage
Mapping Databases to Each Other is Expensive
Status of this document: Ready for Cold Eyes Review
This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will need a login to post in the forum.
Contents
Abstract
When we want to exchange information between two software applications, the traditional way is to map the respective databases together. We preserve context by examining the terms in each data base to determine which are equivalent. This is expensive and only done in high-value situations.
Mapping In a Perfect World
Let us say that you are an engineer working for a construction company planning the erection of some piping spools. Part of your job is to plan the hydrotesting of all the pipelines before commissioning the plant. So, along with a great deal of other information, you need to know the design temperatures and pressures of all the pipelines in the project. Fortunately, the design engineer has given you a Line List, a list of all the pipe line numbers and their critical attributes.
Your first job, then, is to simply get the design engineer's line list into a form you are used to dealing with--your company's construction management software. You might decide to bite the bullet and just rekey the information manually. But this gets old really quickly and after a few dozen lines you will be wondering why you can't just download the data from the engineer's design software into your construction software automatically. After all, the design engineer did not (in this day and age) have a secretary type the line list onto a piece of paper with a typewriter and fax it to you; it almost certainly exists in an electronic database somewhere.
Now it is in the design engineer's best interest to make sure that the construction contractor has the correct information, so it is easy to imagine that "your IT folks" and "their IT folks" get together to give you a connection over the Internet to just "suck in the data." And since the "lexical scope" of a Line List is only a few terms, it is easy to imagine that the data will "go right in".
"Artificial intelligence is the study of how to make real computers act like the ones in the movies." - Port 2000 Newsletter, The Information Technology Newsletter for Port Washington Educators, Dec. 96
In a perfect world, everyone developing an application for some part of plant design would use the same column names, and ensure the meaning of the contents of the columns were the same. (In database jargon, the "schemas" would be the same.) Figure 1 shows what this would look like.
Figure 1 - A Perfect World