Technical Database Design

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.



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



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



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



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



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



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



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



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



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



------ .-

. ---- . . ..

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



Figure 3. Selection for Alloys

Figure 4. Test Res dts Selection Screen

366/12



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



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



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



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

Documents

Technical Database Design