ASTM F2017-00(2006)
(Guide)Standard Guide for Database Structure of Electronic Data Interchange Between Ship Owner and Shipyard for Contract Administration (Withdrawn 2015)
Standard Guide for Database Structure of Electronic Data Interchange Between Ship Owner and Shipyard for Contract Administration (Withdrawn 2015)
SCOPE
1.1 This guide provides the database structure of electronic data interchange (EDI) information between ship owner and a shipyard for contract administration. Ship owners (hereinafter referred to as owners) and shipyards may each have unique software programs to manage their respective portions of a ship repair period. There is information that must be exchanged between the parties during the contract period. This standard has been developed to establish common field lengths, names, and types such that the exchanged information can be used directly by the respective software programs without scanning, typing, or redundant keying of information.
WITHDRAWN RATIONALE
This guide provides the database structure of electronic data interchange (EDI) information between ship owner and a shipyard for contract administration.
Formerly under the jurisdiction of Committee F25 on Ships and Marine Technology, this guide was withdrawn in January 2015 in accordance with section 10.6.3 of the Regulations Governing ASTM Technical Committees, which requires that standards shall be updated by the end of the eighth year since the last approval date.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: F2017 − 00(Reapproved 2006) An American National Standard
Standard Guide for
Database Structure of Electronic Data Interchange Between
Ship Owner and Shipyard for Contract Administration
This standard is issued under the fixed designation F2017; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope 2.1.6 INTEGER—a number that has no fractional part and
its precision (maximum number of digits) depends on the
1.1 This guide provides the database structure of electronic
specific SQL implementation.
data interchange (EDI) information between ship owner and a
shipyard for contract administration. Ship owners (hereinafter 2.1.7 owner—in this case, the recognized authority for
referred to as owners) and shipyards may each have unique contracting ship repair work.
softwareprogramstomanagetheirrespectiveportionsofaship
2.1.8 Request for Proposal—an owner-generated document
repair period. There is information that must be exchanged
asking the shipyard to add, modify, or delete work to the
between the parties during the contract period. This standard
existing package. It may or may not be related to a shipyard
has been developed to establish common field lengths, names,
initiated CFR.
and types such that the exchanged information can be used
2.1.9 shipyard—in this case, the principal party to a contract
directly by the respective software programs without scanning,
with a ship owner.
typing, or redundant keying of information.
2.1.10 SQL compliant—an industry standard data
2. Terminology
sublanguage, specifically designed to create, manipulate, and
2.1 Definitions of Terms Specific to This Standard:
control relational databases. SQL-92 is the latest version of the
2.1.1 BLOB—short for binary large object, a collection of
standard.
binary data stored as a single entity in a database management
2.1.11 tests and trial agenda—the agenda provided by the
systems (DBMS). BLOBs are used primarily to hold multime-
shipyard, which details the planning schedule for all testing
dia objects such as images, videos, and sound, though they can
events to be conducted during a dock or sea trial.
also be used to store programs or even fragments of code. Not
all DBMSs support BLOBs.
3. Significance and Use
2.1.2 CHAR(XX)—character data, alphanumeric where XX
3.1 Intended Use— Compliance with this guide will allow
represents the maximum number of characters permitted and
the sharing of electronic data between contracting parties that
SQL fills the remaining spaces with blanks if fewer than the
is normally done by hard copy. This can only be used when
maximum are entered.
both parties use a database-derived software package to man-
2.1.3 Condition Found Report (CFR)—a report generated
age their contracts. Specifically, it will:
by the shipyard to inform the owner of conditions found,
3.1.1 Eliminate the duplication of manual entry of data into
deficiencies with the specification, or any other pertinent
each party’s contract administration software package and
information regarding a particular work item.
3.1.2 Allow for wide access of the data to all authorized
2.1.4 Condition Found Report Response—the owner’s re-
parties.
sponse back to the shipyard’s Condition Found Report. It may
be a simple acknowledgement of receipt or a lengthy response
4. Database Structure
and reference to a Request for Proposal.
4.1 A shipyard contract management database, or an owner
2.1.5 DATE—stores the year, month, and day values of a
contract management database, may contain hundreds of tables
date. The length of a DATE is ten positions, as in 01/31/2000
and fields and thousands of records. Much of the data is
(for 31 Jan 2000).
business-sensitive and must remain under the control of the
party. However, there is data that is shared and common to both
This guide is under the jurisdiction of ASTM Committee F25 on Ships and
parties in a ship repair contract.
Marine Technology and is the direct responsibility of Subcommittee F25.05 on
Computer
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.