Date post: | 27-Feb-2018 |
Category: |
Documents |
Upload: | roberto-rivera |
View: | 214 times |
Download: | 0 times |
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 1/16
aper No.
66
COIRROSIONc L
The
NACE
International Annual Conference and
Exposition
TECHNICAL DATABASE DESIGN
Mereditl~ Angwin
Fourth Floor IIatabases, Inc.
261 Hamilton Avenue, Suite 315
Palo Alto, CA 94301
J. Lawrence Nelsm and Barry C. Syrett
Electric Power l~esearch Institute
3412 Hillv .ew Avenue
Palo Alto, CA 94303
ABSTRACT
After a brief introduction to the nature of teclmical databases, the following five database desig
characteristics are discussed: data verification proce~ures, structure and presentation of data, data ouq
and choice of software and hardware. The first two areas, types of data and data verification procedul
are of more importance for scientific databases than :;or non-technical databases.
In this paper, three corrosion databases are discussed in terms of how they address the five desi
characteristics, whether they include decision tools, Z.ndwhat sophistication level they require from the
users. It is noted that, of the five characteristics, onl Ythe last one (choice of software and hardware) i
subject to occasional drastic changes: the other characteristics, grounded in the user’s needs, will evoh
with the database. As long as the first four characteristics continue to satisfy the user’s needs, the
database will be worth porting periodically to new improved platforms that provide enhanced features.
Keywords: corrosion, databases, data quality, def:ision tools
INTRODUCTION
All databases provide the users with the ability to store, locate, and output data. However,
technical databases for scientific or engineering applications offer unique challenges for the database
developer. Data modeling and user interface desig Drequire that the developer have a good understand
It
s,
n
lg
Copyright
(31996 by NACE International. Requests for permission to publish this Im;muscript In any form, in part or in whole must be made in writing to NACE
International, Conferences Division, PO. Box 218340, Houston, Texas 77218-8340, The material presented and the views expressed in this
paper are solely those of the author(s) and are not necessarily endorse, j by the Association. Printed in the U.S.A.
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 2/16
of both the data and the goals of the end user. In rn:my cases, data from various sources must be
normalized and imprecise or missing data must be d[)alt with in a logical fashion. In addition, the
potential for incorporating the database into softwan~ applications which provide tools for helping user;
make decisions (e.g., decision support systems or cxpert systems) must be taken into account.
This paper discusses the issues developers oi’technical databases are likely to encounter. These
issues are divided into tlve crucial aspects of techn ical database design and development:
Data Types
Data Verification
Data Structure and Presentation
Data Output
Software Development Tools
The discussion is supplemented with a comparison clf three corrosion-oriented databases.
Data Types
Databases must be limited to certain data ty~es. For example, a database may contain data about
each component in a system, or only components of a certain type in a system. The possibilities are
endless, but the most useful databases are those whi(:h make very clear choices about what is included
and what is not. This should be part of the design specification for any database.
Once the general content of the database is k ~own, the next step is determining how completely
the data will be described, and what data quality will be required. Data quality decisions include
determination of how complete the data must be, ani whether or not data must be taken with standard
methods to be included in the database.
Decisions about data types include an assesslnent of the level of detail required to describe the
data. For example, one database containing informs ion on metals might require a field for UNS numbers
(the international system for defining alloy types) and another field for a descriptive name of the final heat
treatment (mill annealed, thermally sensitized, etc.). A second database, containing information about
similar materials, might require much more detail: temperature of the final treatment, yield strength,
ultimate tensile strength, analyzed chemical content (If the alloy, percentage cold work, information on
the history of the alloy (outside storage, pickling process). There area huge number of possible fields
which could describe a material or corrosion process in a database.
The first step is deciding what information is needed by the database users. Database users will
query the database in search of answers to specific types of questions. In the database design process, the
most important questions that the users are likely tc}:Lskshould be defined and their complexity carefully
assessed. Without this careful review, the database could contain fields for information that “might” or
“should” be interesting or important, but that will ne~er be queried. On the other hand, it might not
contain information that is central to many queries.
Availability and quality of information must :dso be considered. For instance, having a field for
the percentage cold work of an alloy would not be useful if the information is rarely available.
Another question must be addressed: how good must information be in order to be included in the
database? (Here, the term “good” is used because dt:finitions of quality data can vary so much with
circumstances.) The answer depends on the intendetl use of the database.
In databases of field service information, usu:dly all information is “good” enough to be includecl.
Only limited data may be available about the mate~ial and its environment. The database should include
these data, even if they are of “poor quality”, because it is the only data available, and will be the basis for
366/2
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 3/16
any decisions. On the other hand, in a database meant for design engineers, material property data might
be carefully reviewed by a panel of experts before icelusion. Partial or partially-erroneous data on a
material would be worse than no data at all. In other cases, only data taken using standard procedures is
appropriate to include; other data may be too mislca~ing.
In databases of research results, since differe nt investigators may have different approaches, in a
sense, each set of data may be incomplete. For exan~ple, some investigators may record the pH of a
solution before a corrosion process begins, some rm.y record the pH before and after the test, and others
may have continuous pH recording. Do all of these numbers get recorded in a field labeled “pH” or are:
several fields available for entry of pH data? These decisions should be made at the design stage,
whenever possible, rather than being made ad-hoc al data entry time. Review of typical data should take
place at the design stage, in order to resolve these is roes.
Data Verification
A datum can be a single measurement in a :research paper, or it can be a thermodynamic constant,
derived through a meticulous review process of many data points and curves. In any case, this datum
must be entered into the database without gaining or losing any accuracy in the process.
This is the area of data verification. In genelal, there are three levels of data verification. In the
first level, the datum is simply entered directly intc the database by the people charged with this task. In
many cases, the data entered is spot-checked by ano:her person, generally a supervisor at the same
company. This method is sufficient for many databa ses. It has the virtues of simplicity and low cost, and
errors in data entry are usually few enough to be talcrable.
In the second level of data entry, the data, as entered, are printed out and sent to the data
originators, such as the research author or field inspector, for their verification. This is particularly useful
when the person inspecting the data also has access :0data which have not yet been provided. For
example, if a database has a field for “carbon content of the alloy,” and the author of the paper did not
report the carbon content of the alloy, in “verifying” the data, he or she may also add missing information
and augment the data significantly. This level of data verification is used in some corrosion databases and
tends to improve the quality of the data significantly,
At the final level, only data that have been iound acceptable by a board of peers is entered into the
database. This level of data verification can be useful when the database contains scientifically
controversial information. For example, a database {~fnuclear crevice chemistry thermodynamics
depends on the ability to understand chemical reactions in high-temperature, pressurized water, with high
salt content. These reactions cannot always be verified in the laboratory. In other cases, contradictory
data may have been collected by various researchers In these situations, a board of peers is convened to
review the data and select only the “best” for inclusion in the database. The information may be updated
once a year or so as new research becomes available This is the most expensive type of data verification
and is only justified when relatively unsophisticated users will use the database to verify choices of action
which have important safety or economic consequences.
Data Structure and Presentation
In this area, technical databases come closest to non-technical databases in their requirements in
that they both need to have non-redundant (or, at tht worst, minimally-redundant) data structures that
reflect the organization of the data itself. Display of data is constrained by ease of use for the end-user.
3f16,3
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 4/16
Cluttered screens and uncertain navigation between screens can be just as bad for a scientist as for an
inventory clerk.
There is, however, one facet of scientific dat:ibase development which is different from that of
business database development. In most business databases, data are generally expected to be one-
hundred-percent correct. A business inventory data~ase will show that there is, in stock, a certain part,
with a certain part number, supplier and price. Once in a while, an inventory check will determine
whether the database is accurate, but there is never [my doubt, in the database, about the part number,
supplier and price.
On the other hand, in a scientific database, there is automatic uncertainty about the value of any
given number. Numbers are measured; they have sif;nificant figures, or they have various measures of
ranges of accuracy. A measurement can be reported as a single value, or when the same parameter has
been measured several times, it maybe reported as a range, or with a standard deviation. Some fields
useful in a database, such as total neutron fluence experienced by a given part in a reactor, are only
educated guesses. Such data can be reported in man y formats such as “minimum and maximum probable
fluence” or simply “fluence.” In the latter case, it could be appropriate to indicate that values are only
correct to a limited number of significant figures.
Other quantities are capable of being measur~d accurately, but are not always measured at all.
For example, if a sample of steel is chemically analy:~ed for specific constituents ( chromium, for
example), this analysis could be placed in the datake. However, if the type of steel is named, but the
individual heat is not analyzed, should the database contain the analysis provided in the UNS
specifications for that steel? This would allow eas:y comparison with other steels, but the UNS
specification generally contains a range of chromium contents, rather than a single value. Perhaps such
values should be marked in a special way in the database so that they are not confused with measured
quantities. All these issues should be decided at the “display and organization of data” stage, rather than
wait until the problems present themselves during clata entry.
Yet, while the issue of quantification is uniq~le to scientific and technical databases, the approach
used is common to all types of databases: careful understanding of the ways the users will want to see the
data, what questions they will ask of the data, what answers will be helpful, and what will be misleading.
Data Output
Data output or reporting relates to data projection. Some software applications consist only of a
database acting as a repository of data with an ability to locate data which meet specific criteria. More
sophisticated applications may incorporate a database with other analysis tools, with built-in analysis
engines, such as Weibull projections. Again, the act ~al approach depends not only on the user’s needs,
but also on the user’s sophistication. For some databases, it takes a sophisticated user to input reasonable
search criteria. In other cases, the database is really (idecision-making tool and data analysis is essential.
The choice of output is dependent on the needs of the database user. In general, the less
sophisticated the user is assumed to be, the more complete the decision tools of the application must be
for it to be useful. Researchers maybe happy with merely the facts, while plant operators generally want
to know what to do, or at the very least, the likely olltcome of observed events. However, databases
with built-in decision tools must be carefully constructed, so that the decision tools do not outrun the
scientific knowledge. Weibull curves for prediction ~f through-wall cracking, for example, can be an
excellent decision tool because the curves give the pl-obability of failure for a selected operating time,
rather than a specific time to failure.
366’4
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 5/16
Software Development Tools
This is the most rapidly evolving area of scientific database design and development. In the past,
databases were, for the most part, stored on mainfrzne computers and difficult to access. More recent [y,
good relational databases have become available on PCs, and CD-ROM has allowed easy distribution of
even large databases. Simple databases can still be built on flat-file systems, and many people store their
personally-built databases on spreadsheets or flat-fib: databases.
Ease of use and types of accessibility vary Ixtween these database management systems.
Spreadsheets and flat-file databases are often the srarting point for good databases, but they quickly
become overwhelmed by complex or extensive dala These tools depend on one-to-one
correspondences, and handle more complex data by duplication. Relational databases can contain many
related files and many-to-one correspondences, without duplication.
Other choices of database management systems are dictated by the needs of the user. For
instance, networked databases may be selected when the data must be shared by many people in a singla
organization, and CD-ROMs could be chosen where data is sent to several organizations on a batch basis.
The operating system preferred by the end user also partially determines the software choices. Many
excellent commercial database management systems exist on these platforms; each system has its
strengths and its drawbacks. Some commercial data base management systems have cross platform
capability. Such a database may have two or more J’ersions that will work well together over a network.
If the data are well organized, accurate and useful, the database will outlive its original platform,
and resources will be available for database migratic n to a newer system. If the database was not useful,
it will die when its original platform is outmoded, or even before. Much of the concern about choosing
exactly right software and hardware is needless, thollgh, of course, the designer should not choose
something that is already outmoded. The developrn(mt of a good database should rely more on the firsl:
four characteristics areas, discussed above. In computer platforms and operating systems and database
management systems, the technology is always adv~ricing. The race goes not to the newest, but to the
best database design.
DISCUSSION OF S1,MPLE DATABASES
In this section, three examples of corrosion -oriented databases are compared in terms of the five
design characteristics described earlier.
Database 1
Database 1 is EDEAC-PC (Cracking of Structural N/aterials in Nuclear Environments)(l)
Data Tvpes and Structure. Database 1 is a compilation of laboratory crack growth data for alloys
in simulated nuclear power plant environments. It is a personal computer (PC) version of a database
resident on a mainframe computer. Although the clata are for nuclear environments, the database does
not have fields for tracking the effects of irradiation on crack growth in the materials. Nevertheless, data
‘l)EDEAC-PC is a trademark of the Electric Power FLesearch Institute. This program is available for
EPRI member utilities through the Electric Power S{]ftware Center. For others, the program is available
through NACE International.
3E6/5
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 6/16
entered into the database are otherwise quite compk te: there are very few empty fields. All data are
classified by test type and come from the open literature.
Data Verification. Database 1 has the most f:omplete data verification procedures of the three
databases. There were originally three levels of verification:
(1) in-house verification. Data obtained from open literature is entered into the database without
outside verification.
(2) verification by the authors. Authors of the original data verify the data as it has been entered
into the database.
(3) verification by research-committee. A research committee reviews the data and verifies its
quality.
When the database was moved from the mainframe database to the PC version, only level 2 and
level 3 data were moved.
Data Presentation. The data are displayed i.nthe same manner as their underlying organization
(Figure 1). One excellent feature is the accessible :pop-out data dictionary, which gives the definition of
every field (Figure 2).
Data Outmt. For most databases, including this one, reporting consists of two steps. The first
step is selection, in which the user defines the required subset of the database contents (e.g., only tests of
rolled steels or only tests in water). The second stq is outputting the selected subset in the form of
reports or graphs.
This database has good selection tools which lead the searcher through the necessary choices
(Figures 3 and 4). After a set of data have been sele:ted, two types of graphs are available to chart the
data: crack length (a) versus number of cycles (N),
and
crack growth rate (da/dN) versus stress intensity
range (delta K) (Figure 5). The designers of the dau lbase have made the (probably correct) assumption
that the searchers will want to compare the crack growth rate or crack length for specific alloys, under
specific environmental conditions. In this database, data type and data reporting fit together quite well.
Software Development Tool. This database was fiist developed using a proprietary package on a
mainframe. It has since migrated to EPRIGEMS(2) a graphical package on a PC. It is evidence that
useful data will move from an outmoded platform 1:0a newer platform.
Database 2
Database 2 is SCC/IGA-600, Stress Corrosion Cracl:ing and Intergranular Attack of Alloy 600 in Steam
Generators(3) .
‘2)EPRIGEMS is a trademark of the Electric Power ILesearch Institute.
‘3)SCC/IGA-600 is a trademark of the Electric Powe.- Research Institute. This program is available for
EPRI member utilities through the Electric Power Software Center. For others, the program is available
through NACE International..
366,’6
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 7/16
Data Type
s and Structure. This database provides laboratory test data on stress corrosion
cracking and intergranular corrosion of Alloy 600 in secondary side environments of nuclear steam
generators. All data are derived from articles in the open literature.
Another special feature of Database 2 is the database structure it provides to allow users to track
the number of tube failures as a function of operatin qcycles in the user’s own steam generator. It also
allows users to input their own laboratory test data. to supplement the Database 2 data. During the data
selection process, clear distinctions are made betwet,n areas of mandatory input such as test type
(selected from a choice list), and areas of optional input (e.g., the boron content of the material tested).
Data Verification. The database developer had standard in-house procedures for checking the
accuracy of the data, but no effort was made to cent act the authors for review and verification of data
input.
Data Presentation. The data are organized ir a very clear manner. The main tables are: material,
environment and stress, and test type. The hierarch~’ also contains several related sub-tables (such as test
procedures and chemical composition of the materials) containing various fields. For searches, some of
these fields must be specified, or the database will Ireject the search; these fields are clearly labeled as
“input mandatory” (Figure 6). The search mechani sln automates the search by leading the user through
the selection criteria screens (Figure 7).
One of the mandatory inputs is the chemical make-up of the water near the crack. While the
chemical composition of the bulk solution may be lmown, the composition beneath a sludge pile or other
creviced region may not be so obvious. In these cas>s, a more accurate composition may be derived by
first running a water chemistry program, such as MIJLTEQ-REDOX(4) , which predicts pH and
precipitation in concentrated high temperature solutions. Recognition of the need to run a chemistry
program in these cases implies a certain level of sop’listication on the part of the user.
Ret)ortin~.
Database 2 contains only laboratory data; the user can also input his own laboratog
data in the same format. These laboratory data can be outputted either in graphical or tabular form. The
graphical outputs include crack growth rate versus pH, growth rate versus temperature, crack depth
versus pH, and crack depth versus temperature. A djfferent type of reporting is used to track the number
of tube failures in the user’s own steam generators. ~f the user inputs the number of new failures detected
during each outage, the program can plot these data on a Weibull distribution curve, which shows the
probability of a failure as a function of operating time (Figure 8).
Platform. The platform is the same as for th~~previous database. In the future, a move to a
graphical user interface based system might be considered. However, the plots are an effective graphical
device within the limitations of the current package.
Database 3
Database 3 is IASCC (Irradiation Assisted Stress Ccmosion Cracking)(s).
‘4)NluLTEQ-REDOX is a trademark of EPRI, avaik.ble for license through the Electric Power Software
Center.
‘5)ASCC database is co-funded by EPRI and an internahonal consortium of organizations.
3E6/7
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 8/16
Data Tv~es and Structure. This database co~tains both laboratory and field data. Much of the
data is from the open literature, while some of the d:lta (mostly field data) is proprietary. The private
data are referred to as “Private Communication 1.“
This database is designed to track the effect of irradiation on stress corrosion cracking of varioLN
structural alloys employed in nuclear power plants, rminly stainless steels and nickel-base alloys. In order
to understand the effects of irradiation on cracking, he database also contains data from unirradiated
specimens for comparison purposes.
In many cases, the exact level of irradiation is not known, especially for field (as opposed to
laboratory) data. Therefore, the database contains fields for ranges of irradiation.
Like Database 2, this database was designed to allow end-users to add their own proprietary data
into their individual copies. This capability has led to some programming complexities which must be
addressed early in the development process. For ewmple, the entire group of database users receive
periodic data updates which must not over-write the proprietary data which individual users have entered.
A well-structured data import program handles this issue.
Data Verification. At the minimum, data
zre
entered by one person at the developer’s company,
and then a printed output from the database is check ad against the original source material by a second
person. The second person checks not only for quarltitative accuracy, but also that the data have been
entered into the appropriate fields (especially important in this database, in which both irradiated and
unirradiated information is stored for similar materials).
In many cases, the printouts from the databa ;e are sent back to the original authors for
verification of the information and requests for fun.htr information. Currently, there is no way for the
user to identify author-verified data. Verification of proprietary data entered into the database is the
responsibility of the owners of that data.
Data Presentation. Because the database wa J built for Windows(b) and Macintosh(n which have
graphical user interfaces, data display can be more graphically oriented than the databases described
‘8)for both platforms,
arlier. This is a multi-platform database, built with the same structure on FoxPro
The data are organized into main tables that l;orrespond to clearly-defined data types: material
class, material heat, data reference, plant/laboratory, part, and specimen (Figure 9). The forms for these
main tables also display data from related supplemer tary tables. The data are displayed in a clear fashion,
despite the complexities of the underlying relational database structure.
Specifically, the database incorporates a Roadmap describing the structure of the database and
where particular data types can be found. In addition, the Roadmaps provide easy access to related
records in different tables of the database. For exarr ple (Figure 10) if the database user is looking at the
form for a part, the “Part” button of the Roadrnap wi11be highlighted. To move to the related Material
Heat form, the user simply clicks the Material Heat lmtton on the Roadmap.
Two of the main tables, Part and Specimen, ‘vere designed to solve a problem which arose in
tracking this particular data. Irradiated materials arc so scarce and costl y to deal with that irradiated
parts are often subsequently machined into one or mxe test specimens. These specimens may, in turn, be
‘c)WindOws
is a
trademark of Microsoft Corporaticm.
‘7)Macintosh is a trademark of Apple Corporation.
‘8)FoxPro is a trademark of Microsoft Corporation,
36(/8
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 9/16
machined into additional specimens, The database is able to track the history of a part or specimen, thus
retaining vital information about multiple exposures which could affect material properties.
Data Reference records are available for
all
tlata. Each record contains a complete bibliography,
as well as descriptions of the types of information reported in the reference (Figure 11)
Data Outuut. Because this database was bui .t using a relatively recent database management
system, data searching can be very straightforward and flexible. A single screen (Figure 12) allows the
user to build queries using any of the significant fields in the database, instead of being led, screen by
screen, through a mostly pre-arranged search. Critelia can be added or modified, including choosing
numeric ranges, and searches can be saved by name.
In this filtering function, the user can make choices
at will in fields throughout the database. Another Ilery powerful aspect of the searching or “filtering”
function in Database 3 is the capability to locate nclt only records in a single table, but also all related
records in each of the other main tables. These resu ts are then displayed on the Main Roadmap screen,
giving the user a good understanding of the quantilit:s of specific data types in the database
Reporting is simple: pre-formatted tabular :~eports are available for the results of the searches.
There is no graphical capability within the database. The database is primarily intended for use by
researchers, and the subjects of their searches cannel be easily predicted. Therefore, flexibility is of great
importance. Thus, Database 3 has a simple data ex~ort function which allows users to plot data in their
favorite spreadsheet or graphics program.
Software Development Tool. Originally developed for 4th Dimension(9), the database was rebujlt
using a database management system which has cross-platform compatibility. Again, the platform move
shows that a good database can migrate as compute] technology evolves.
CONCI.US1ON
Discussion of the Databases
Each of the databases discussed above was designed to fit a perceived need. Two of the
databases have migrated from one platform to anolh x, showing that the usefulness of a database can
outlast the processes of rapidly changing computer technology.
Among the goals of a database are the abilitj~ to be a repository of organized data for later
analysis and user-relevant comparison of technical data from various sources. This means that one
challenge faced by all technical database developers is the choice of data to include, in terms of both data
types (fields in the database) and the data quality. Another challenge is verifying that data are correctly
and appropriately entered. These challenges were rcsolved in various ways for the three databases.
discussed in this paper. One included all data, inclu(ling sparse field data. Two others included only
laboratory data. For two of the databases, data ente-ed into the databases went back to the original
authors for verification. In one of the databases, sinl:e all the data was in the public domain, author
verification was not considered necessary. In two o t the databases, users can also enter their own data,
and therefore, they are responsible for verification o; these particular data.
The three databases are quite different in the level of sophistication required by the users. In
man y ways, Databases 1 and 2 required less sophistication from the users than that required by Database
‘9)4thDimension is a trademark of ACI US.
366/9
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 10/16
3.
In the first two databases searches are preformatt~d, and comparatively limited. Database 3, in giving
the user a wide choice of searches, also requires the user to have a clearer idea of what he or she wants to
find. On the other hand, with its water chemistry input requirements, which may include the user runni lg
a water chemistry program, Database 2 is geared for a sophisticated user. Also, the Weibull curves
plotting feature was designed for users who know h[)w to use this life prediction tool appropriately.
Using these predictions in too simplistic a fashion w(mld be unwise.
Discussion of the Database Design Characteristics
Most database design standards are concerm d with issues of “data type.” The standards list the
fields which should be in the database for completeness. However, as noted above, there is a second
aspect to data type: the issue of the quality of data allowed in the database. Only data taken with
standard methods could be allowed, or all field data sould be allowed. For each database, this quality
criteria should be spelled out directly, if possible. k would aid the user in understanding the use and
limitations of the database.
Similarly, data verification is an important aspect of the database. Are the data verified by the
original authors? Again, this is information which shwld be available to the database users, if possible.
On the other hand, data organization and disl)lay varies so much with the intended user (and the
preferences of the designer) that standards are not really possible. There is no correct way, but there am
many ways that will work, and some ways are bett’a than others. In general, the closer the data display is
to the user’s way of thinking about the data, the easier the database will be to use.
In data reporting, a decision should be made at the beginning of the design stage as to whether the
application will be a decision tool or a database wilh Outdecision capabilities. This depends on the quality
of the data, and the sophistication and needs of the user. After that decision is made, setting up the
reporting in a simple and useful fashion should be ~st-aightforward. Whether or not the database includes a
decision tool, it should function well as a database; tlat is, be a reliable and usable repository for scientific
data.
As mentioned above, platform choices lootn large at the outset, but turn out to be less important
in the long run: a good, well-used database will be pm-ted as necessary.
In conclusion, recommendations are that app lications inform the user of
The data quality criteria that determines WI~ichdata are to be included in the database
c The data verification procedures
The limitations for the use of the data (if [he data will be incorporated into a decision analysis
tool which could be misleading).
All these choices are really predictions of tilt needs of the users of the database. There are no
right and wrong approaches to design that are valicl for all databases. However, the approach chosen will
determine whether or not the database will be valuable enough to survive technology changes. Technical
databases are different from more ordinary accounl.ing and inventory databases. And yet, in all database
design, understanding the needs of the users is paranlount.
366’10
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 11/16
------ .-
. ---- . . ..
Wk
-, -iv,
q Uiew ma ,
Field M axiptiom
1;+
Material Idenli:lca-tion Fields
FHmJ No FIELD Nf lW FIEJI Ml FIELD RfME
20 ~
m
TENSILE YIELD STRENGTHHPal
21
CM DITION il TENSILE YIELD STRENGTHHETIKID
22 HfUWIWXURER
S2 COHPRESSIUEYIELD STRmGTH [HPal
23
HERTMJHBER ;3
YsWHPRESSIUEETtNJD
24 SPECIFIC13TILMS i4
CYCLICYIELDTSEffiTH (HPal
25 F(IRH
;5 YS CYCLICHETHOD
26 CtMPOSITIffl
,% ULTIHfiTE TmSILESTRENGTHHPal
27 PROCESSINGHISTORY 70
TEST TF34PERRTURECl
23 GliRIN SIZE ‘? IIEDWTIONIN I?RER(z)
35 HF)TERIfILID?XiT. RF31RIWS ?2
ELIXWiTICHi
‘w HfIRDNESS ?3
MGE LmGTH (ml
41 SCRLE ?4 YOIKIG’ tNJDULUS(HPal
42
TmPEMTtJREC1 ‘?5 HECHflNICRLSOP RMfMIRS
~~
c:back-up; +11+:moue cursor; Enter: se lect
—
Figure 1. Organiz ~tion of Data Fields
EDEfM PC
‘~’=’ipti ’
The metallurgical grain size. It him been assumed that the R3TH
procedures for determining grain si::e will be used. If this is the
case, the grain size was entered.
[f a different standard prmxdure
has been used, it is specified in REHIWWSField 35).
—
Figure 2. A Sample from the Data Dictionary
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 12/16
Figure 3. Selection for Alloys
Figure 4. Test Res dts Selection Screen
366/12
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 13/16
Stai71ess Steel
Envlrarment: PL4R WITER
.01
1 I
A Ims 530400, Rcc: 102Ez3< T
25 C, R, O, OEiO, F,
L. OEIOEr 02 . 10
PPM
UNS S7J04F10> REI=: 10ZEZ4, T .?5 C, ? O.5Ei0, F: L.0E3aEl, OZ, . 10 PPM
- 4 uH5 Z3&Wjn, RK, :X KK?5, T .
25 <:, R E) ?rmr r, :. W3QM, m, a. ID ?Fm *
al
.001~
u
m
?
: .0001:
/
{ ;
z /0
:
~ lE-57
J“
~ +’
,>
lE–6
I
1
10
1Da
DELTFI < MPa sqt-t [ml
X–key :
Exit graph, Esc :
Bat< up,
Spacebar: continue
—
Figure 5. Graph [JfSelection Results
Figure 6. Selection with Mandatory Inputs
3E6,13
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 14/16
Figure 7. Selection for Test Types
<Esc:
Ilai n Menu>
<Enter: Show
xl~
<Fl: Get HcIP> <Flf3: Exc’d Data>
99.9:
.
Weibu[t plot / /
PI
10-20-9S 22:(?1:31 “–
+j
WEIP1-OT: IOEIUOIO
—– ftLE Line
//
c Shape Fact: 0.99
e
Sca[e Fact: 1.06E+0Z
n
I
—
/
H
fidelice Bancl
P~bability: 90k
F]
----- ---- -------------................/
i
1
..
d
~ ,1
~—..-.
.-...--——....-—.——._—....———..—-..+
—
+
+“
Tinle,’Cycles
1:
—
2
5
10 2CI 5 2 5 1000
—
Figure 8. Weibull Plot (Time toFailure)
366’14
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 15/16
Figure 9. Dat:,base Roadmap
Service rODefatinal Parametew:
Rt suits:
.-.
Part
Type Control od sheathlhandle1,~
serviceLocation ~
Operating Tempera ture (C] m
Operating T ime [Hrs] ~U~
Operating Time (EFP’r’s] -
Estimated Ma,. Load [N) ~~
Max. Engineering Stress [MPa) =
IE st mated Strain Rate (Ilsec) ~
—
“ack’d’
EIa
CrackDetection
Method
I?
~“m~:;:::;: R
Time to Crack Detection [Hrs) -
Ttne to Cfa.1. Detection [EFPYs] m
Fracture Type No fracture observed
1%
Fractography Method
[
[*
Percen t Intergranu lar SCC ~
—
Figure 10. Part Record in Database
365/15
7/25/2019 Technical Database Design
http://slidepdf.com/reader/full/technical-database-design 16/16
Figure 11. Data Reference Record
48. ;3
FilterNamz 1304/cERTlwaIed> 270
m
Fiker TypQ Specjmen
=13 -1
Fil terDescr iption CERT tests for 304SS inw:= [T>
270C
“jig . “’
:.:.:mw+tl
To
add nw Criterion.
select Field from list belw:
—
Specimen.Specimen ID Code
Specimen.Test Classification
-3
HzQzzzI
SpecimenLocation inOriginalReference
Specimen.Test Type
Specimen.Test Environment
Spec,men.T[test]
:+
—
TO mmfifgtdelete an xisting C ituicm.
select Ctitericm from list below:
7“–
3
Radiatmn Exposure.Reference Fluence > 1 [xIO-?0p/cm”2]
“ -
Specimen.lest Type equal CERT
Spec(men.Test Environment equal Water ~
+:
—
%
Figure 12. Selec RionUsing Filters
366/1 6