RFC144 日本語訳
0144 Data sharing on computer networks. A. Shoshani. April 1971. (Format: TXT=13744 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Shoshani Request for Comments: 144 SDC NIC: 6729 30 April 1971
Shoshaniがコメントのために要求するワーキンググループA.をネットワークでつないでください: 144SDC NIC: 6729 1971年4月30日
Data Sharing on Computer Networks
コンピュータネットワークで共有されるデータ
The enclosed is an introductory paper for the meeting which will be held in Atlantic City as part of the ARPA Network meetings. The schedule for the meeting will be published soon by Steve Crocker.
同封はアーパネットミーティングの一部としてアトランティックシティーで行われる会合のための紹介している紙です。 ミーティングのためのスケジュールはすぐ、スティーブ・クロッカーによって発表されるでしょう。
The Agenda of the meeting will include:
ミーティングのAgendaは以下を含むでしょう。
a. Presentation of the introductory paper.
b. Open discussion to exchange comments and ideas.
c. Attempt some recommendations.
d. Possibly set up a committee of interested people.
a。 紹介のプレゼンテーションは. bに紙を張ります。 議論を開いて、コメントと考えcを交換してください。 推薦dをいくつか試みてください。 ことによると関心がある人々の委員会を設立してください。
If you have interest in the subject please plan to attend.
対象への関心がありましたら、出席するのを計画してください。
INTRODUCTION
序論
One of the benefits expected from the use of Computer Networks is the sharing of data among users of the system. This paper is an attempt to classify the issues involved, discuss some approaches that might be taken to achieve the goal of facilitating data sharing and to point out some advantages and disadvantages of these approaches.
コンピュータNetworksの使用から予想された利益の1つはシステムのユーザの中のデータの共有です。 この紙はかかわった問題を分類する試みであり、データ共有を容易にするという目標を達成して、これらのアプローチのいくつかの利点と損失を指摘するために取られるかもしれないいくつかのアプローチについて議論してください。
CONSIDERATIONS
問題
In the process of selecting an approach one has to consider the following issues:
アプローチを選択することの途中に、人は以下の問題を考えなければなりません:
1. Does the approach provide the use of one language to access all
data on the network?
1. アプローチは、ネットワークに関するすべてのデータにアクセスするために1つの言語の使用を提供しますか?
2. Does the approach facilitate sharing of existing data created
and manipulated by existing data management systems?
2. アプローチは、既存のデータマネージメントシステムによって作成されて、操られた既存のデータを共有するのを容易にしますか?
3. Does the approach encourage users to share data and use the
facility provided? How evolutionary is the approach?
3. アプローチは、ユーザが施設が提供したデータと使用を共有するよう奨励しますか? アプローチはどれくらい進化論ですか?
4. Could a failure of one node in the network cause the failure of
the data sharing facility?
4. ネットワークにおける1つのノードの失敗はデータ共有施設の失敗を引き起こす場合がありましたか?
5. Does the approach promote or hinder further development of data
management systems?
5. アプローチは、データ管理システムのさらなる開発を促進しますか、妨げますか?
Shoshani [Page 1] RFC 144 Data Sharing on Computer Networks 30 April 1971
コンピュータネットワーク1971年4月30日に共有されるShoshani[1ページ]RFC144データ
6. What are the implementation considerations?
6. 実装問題は何ですか?
7. What are speed considerations?
7. 速度問題は何ですか?
POSSIBLE APPROACHES
可能なアプローチ
1. Centralized data management system (CDMS).
1. データ管理システム(CDMS)を集結しました。
This approach is consistent with the idea that a Computer
Network eventually will evolve into a collection of specialized
service nodes, where each node would perform a specific
function well. Users will use services on nodes according to
their needs. For example, one node could be a PL/I machine
(possibly a microprogrammed machine to perform PL/I compilation
efficiently), another node could be a "number cruncher" for
parallel-structured problems (ILLIAC IV), etc. In the same way
there will be a node responsible for all data management needs
for the network.
このアプローチはコンピュータNetworkが結局専門化しているサービスノードの収集に発展するという考えと一致しています。各ノードはノードで上手に具体的な機能を実行するでしょう。 彼らの必要性に従って、ユーザはノードの上でサービスを利用するでしょう。 例えば、1つのノードはPL/Iマシン(効率的にPL/I編集を実行することによるとmicroprogrammedマシン)、別のノードが平行に構造化された問題(ILLIAC IV)などのための「数値計算屋」であるかもしれないということであるかもしれません。 同様に、経営者側がネットワークに必要とするすべてのデータに原因となるノードがあるでしょう。
Depending on the assumptions made one of two ways can be
chosen:
2つの方法に加わられる前提によるのを選ぶことができます:
a. As assumption that we must be able to share all data,
implies that the same data management system can create and
manipulate this data, and therefore must perform all the
functions required of a data management system, regardless
of the particular use. It is generally agreed that such a
task is monumental and impractical (if not impossible),
since different data management systems are designed to
perform specific functions well on the expense of degraded
performance of other functions (e.g., fast retrieval of
large files, limited updating capabilities).
a。 私たちがすべてのデータを共有できなければならなくて、同じデータ管理システムがこのデータを作成して、操ることができると暗示して、したがって、働かなければならないという仮定として、すべての機能がデータ管理システムについて必要です、特定の使用にかかわらず。 一般に、そのようなタスクがとてつもない、そして、非実用的、そして、(不可能)であるのに同意されます、異なったデータ管理システムが上手に他の機能(例えば、能力をアップデートしながら制限された大きいファイルの速い検索)の降格している性能の費用に具体的な機能を実行するように設計されているので。
b. The assumption is made that users will share only data from
the same file on a particular data management system. In
this case one can implement different data management
services for different tasks, but put them all on the same
node to provide a data management service to the Network
users. This approach can still use one common language to
access these services. This is apparently the approach
taken by CCA as indicated in NIC memo 5791.
b。 ユーザが特定のデータ管理システムの上で同じファイルからのデータだけを共有するという仮定はされます。 この場合、1つは、異なったデータが異なったタスクのための経営指導であると実装することができますが、それらを皆、同じノードに載せて、Networkユーザへのデータ経営指導を提供してください。 このアプローチは、これらのサービスにアクセスするのにまだ1つの共通語を使用できます。 これは明らかにNICメモ5791にみられるようにCCAによって取られたアプローチです。
2. Standardized data management system (SDMS).
2. データ管理システム(SDMS)を標準化しました。
In this approach a particular data management system is adopted
to be implemented on all nodes. This provides for a
standardized data management language as well as an identical
logical data structures. Alternatively, one can choose a set
このアプローチでは、特定のデータ管理システムは、すべてのノードの上で実装されるために採用されます。 これは同じ論理的なデータ構造と同様に標準化されたデータ管理言語に備えます。 あるいはまた、人はセットを選ぶことができます。
Shoshani [Page 2] RFC 144 Data Sharing on Computer Networks 30 April 1971
コンピュータネットワーク1971年4月30日に共有されるShoshani[2ページ]RFC144データ
of data management systems to be implemented on all nodes, then
be able to share information manipulated by the same data
management system on different nodes. This approach has many
drawbacks as will be discussed later.
すべてのノードで導入されるデータ管理システムでは、その時、異なったノードの上で同じデータ管理システムによって操られた情報は共有できてください。 このアプローチには、多くの欠点が後で議論するようにあります。
3. Integrated data management system (IDMS).
3. 統合データ管理システム(IDMS)。
This approach suggests the integration of local (to the node)
data management systems and local data (files) through the use
of appropriate interfaces and a common data management
language.
このアプローチは適切なインタフェースの使用と一般的なデータ管理言語を通してローカル(ノードへの)のデータ管理システムとローカルのデータ(ファイル)の統合を示します。
Under this category there may be different approaches depending
on the function of the interfaces:
このカテゴリの下では、インタフェースの機能に依存する異なるアプローチがあるかもしれません:
a. There is an interface module in every node for every local
data management system. The interface performs a dual
function: on the way out--it issues requests in the common
language to remote nodes; on the way in--when a request in
the common language is received, the interface performs
translation from the common language to the local data
management language. From a single request the translation
might produce a series of commands in the local language
(for example, suppose that the local language permits the
specification of one quantifier only, such as "age<_41."
Suppose that the request received in the common language
specifies "list all names where age<_41 and children _>5."
The translation will produce a series of commands of the
form: "list all names where age <_41," "save the list
temporarily," "list all names in temporary file where
children>_5").
a。 あらゆるローカルのデータ管理システムのためのあらゆるノードにはインタフェース・モジュールがあります。 インタフェースは二元的な機能を実行します: 廃れかかって、共通語における要求を遠隔ノードに出します。 共通語における要求が受信されているとき、中への途中では、インタフェースは共通語からローカルのデータ管理言語までの翻訳を実行します。 ただ一つの要求から、翻訳は一連のコマンドを現地の言葉で作成するかもしれません; 例えば、現地語が1つの数量詞だけの仕様を可能にすると仮定してください、「<_41歳」 Supposeなどのように。受け取って、共通語では、「リストは時代<_41と子供_>5とどこをすべて命名すること」は指定しています。(翻訳が形式の一連のコマンドを作成するという要求: 「リストは時代<_41とどこをすべて命名すること」が「一時リストを保存する」、「リストが中で一時ファイルどこ子供>を_5インチとすべて命名するか、)、」
b. Move all local interfaces which were described above into
one central node. This node is now the service node. It
accepts a request in the common language and produces a
series of commands to all nodes involved, in their local
data management languages.
b。 上で1つの主要なノードに説明されたすべての局所界面を動かしてください。 現在、このノードはサービスノードです。 それは、地元のデータ管理言語にかかわるすべてのノードに、共通語で申し込みに応じて、一連のコマンドを作成します。
c. The local interface accepts the name of a local file (or
relevant portion of the file), and sends this file to the
requester after performing a translation of the data. The
data can be translated using a technique such as the "Form
Machine" (described in NIC 5772). The file is translated
from the local data management data structure to the
requesters data structure, so that the requester can perform
the desired function using his local data management system.
c。 局所界面は、ローカルファイル(または、ファイルの関連部分)の名前を受け入れて、データに関する翻訳を実行した後に、このファイルをリクエスタに送ります。 「フォームマシン」(NIC5772では、説明される)などのテクニックを使用することでデータを翻訳できます。 ファイルはローカルのデータ管理データからリクエスタデータ構造まで翻訳されます、リクエスタが地元のデータ管理システムを使用することで必要な機能を実行できるように。
Shoshani [Page 3] RFC 144 Data Sharing on Computer Networks 30 April 1971
コンピュータネットワーク1971年4月30日に共有されるShoshani[3ページ]RFC144データ
4. Unified data management system (UDMS).
4. 統一されたデータ管理システム(UDMS)。
This approach suggest the use of a standard interface which is
to be part of every data management system on the Network. The
interface has three ends. One to the user language, one to the
particular physical system used and one to the Network. The
interface should be global enough to permit separation of
system decisions from user language decisions. If this
interface is standardized on a Network, it will facilitate
communication between local data management systems in a
unified way, while permitting the development and evolvement of
different local data management systems. (This is a rough
description of the approach taken by Barry Wesseler in Utah.)
このアプローチはNetworkにあらゆるデータ管理システムの一部であることである標準インターフェースの使用を示します。 インタフェースには、3つの端があります。 ユーザ言語への1、使用される特定の物理的なシステムへの1、およびNetworkへの1。 インタフェースはユーザ言語決定からシステム決定の分離を可能にするほどグローバルであるべきです。 このインタフェースがNetworkで標準化されると、それは異なったローカルのデータ管理システムの開発と展開を可能にしている間、統一されたやり方でローカルのデータ管理システムのコミュニケーションを容易にするでしょう。(これはユタでバリーWesselerによって取られたアプローチの荒い記述です。)
THE COMMON LANGUAGE
共通語
It is well known that the design of a language involves a compromise between the ease of use of the language and its capability to express the functions desired. A try to merge two languages usually results in the worsening of one or both of these considerations.
言語のデザインが言語の使いやすさと望まれていた機能を言い表すその能力の間の感染にかかわるのは、よく知られています。 通常、2つの言語を合併するトライは1の悪化かこれらの問題の両方をもたらします。
For the purpose of having a common language for data management it may be desirable to separate between the above mentioned considerations. Use natural-language for ease of use, and a formal intermediate language powerful enough to express any functions desired. This is the approach taken in the development of CONVERSE in SDC [1]. The intermediate language can be as complex as one likes since it is invisible to the user.
データ管理のための共通語を持つ目的のために、上記の問題の間で分離するのは望ましいかもしれません。 使いやすさ、および望まれていたどんな機能も言い表すほど強力な正式な中間言語に自然言語を使用してください。 これはSDC[1]でのコンバースの開発で取られたアプローチです。 ユーザにとって、それが目に見えないので、中間言語は好きなように同じくらい複雑であることができます。
DISCUSSION
議論
Predictions for future use of computers (and therefore computer networks) point out that "in 1975 we will process mostly data" [2]. Therefore, the problem of sharing data on a computer Network, as well as accessing data from remote nodes in some common language are extremely important.
コンピュータ(そして、したがって、コンピュータネットワーク)の今後の使用のための予測はその「1975年に、私たちはほとんどデータを処理するつもりである」[2]を指摘します。 したがって、コンピュータNetworkに関するデータを共有するという問題、アクセスと同様に、何らかの共通語の遠隔ノードからのデータは非常に重要です。
If all that is desired is the sharing of data in a file by more than one user, then the CDMS approach is appropriate. Approach la is impractical, but lb can provide a valuable service. Selecting this approach does not permit the sharing existing data which was created with existing data management system, unless a restructuring of the data for the CDMS is performed. This approach does not easily permit the development of new data management systems since the CDMS should stay stable for the Network use. It does not involve translation of data or languages and therefore should provide good access speed.
望まれているすべてが1人以上のユーザによるファイルで、データの共有であるなら、CDMSアプローチは適切です。 アプローチlaは非実用的ですが、lbは貴重なサービスを提供できます。 このアプローチを選択する場合、既存のデータマネージメントシステムで作成された既存のデータは共有に可能にしません、CDMSのためのデータの企業再構築が実行されない場合。 CDMSがNetwork使用において安定しているままであるはずであるので、このアプローチは容易に新しいデータ管理システムの開発を可能にしません。 それは、データか言語に関する翻訳にかかわらないで、したがって、良いアクセススピードを提供するべきです。
Shoshani [Page 4] RFC 144 Data Sharing on Computer Networks 30 April 1971
コンピュータネットワーク1971年4月30日に共有されるShoshani[4ページ]RFC144データ
The SDMS approach has many drawbacks. Selecting it implies the imposition of a particular data management system on all nodes. It inhibits further development. It does not permit the sharing of existing information. The main advantage would be the modularized structure so that the failure of one node cannot cause the failure of the entire system. Also, because of the standardized approach sharing of data from different nodes does not involve any translation.
SDMSアプローチには、多くの欠点があります。 それを選択すると、特定のデータ管理システムのすべてのノードへの賦課は含意されます。 それはさらなる開発を抑制します。 それは既存情報の共有を可能にしません。 主な利点は、1つのノードの失敗が全体のシステムの失敗を引き起こさない場合があるためのmodularized構造でしょう。 また、標準化されたアプローチのために、異なったノードからのデータの共有は少しの翻訳にもかかわりません。
The main advantage of the IDMS approach is that it permits the continued use of existing data management systems with existing data bases associated with them while permitting the sharing of data among the network community of users. Since it permits the continued use of local data management systems it is the most evolutionary approach and most likely to be accepted by a user of an existing data management system. There are applications where users on each node on the Network perform mostly local access of data, and less often find it desirable to be able to share data with other nodes. For example, if hospitals are connected to nodes of a Computer Network, then most of the data about patients is accessed locally, but sometimes it is necessary to access information from other hospitals, such as global statistical information. The same situation exists for criminal files, local branches of banks, credit bureaus, warehouses, etc. Approach 3a permits the advantages of modularization, but 3b is easier to implement since no additional interfaces are necessary in the different nodes. Approach 3c seems hard to implement and can introduce inefficiencies since it involves translation from one data structure (which might be designed for efficiency) to another data structure (which may not be as sophisticated). It also involves the shipment of large amounts of data across the network.
IDMSアプローチの主な利点はユーザのネットワーク共同体でデータの共有を可能にしている間それらに関連している既存のデータベースがある既存のデータマネージメントシステムの継続的な使用を可能にするということです。 ローカルのデータ管理システムの継続的な使用を可能にするので、それは、最も進化論のアプローチであって既存のデータマネージメントシステムのユーザによって最も受け入れられそうです。 利用がNetworkの上の各ノードの上のユーザがデータのほとんど地方のアクセスを実行して、よりしばしば他のノードとデータを共有できるのが望ましいのがわかるところにあります。 例えば、病院がコンピュータNetworkのノードにつなげられるなら、患者に関するデータの大部分は局所的にアクセスされますが、時々、他の病院から情報にアクセスするのが必要です、グローバルな統計情報などのように。 同じ状況は前科者名簿、銀行の地方支店、信用調査所、倉庫などのために存在しています。 アプローチ3aは変調の利点を可能にしますが、どんな追加インタフェースも異なったノードで必要でないので、3bはより実装しやすいです。 1つのデータ構造(効率のために設計されるかもしれない)から別のデータ構造(同じくらい洗練されていないかもしれない)までの翻訳にかかわるので、アプローチ3cは実装しにくいように見えて、非能率を導入できます。 また、それはネットワークの向こう側に多量のデータの出荷にかかわります。
The UDMS approach permits the continued development of local systems while facilitating a unified way for Network communication of data requests. It is not clear at this point whether this approach is practical.
UDMSアプローチはデータ要求に関するNetworkコミュニケーションのための統一された方法を容易にしている間、ローカルシステムの継続的な開発を可能にします。 ここに、このアプローチが実用的であるかどうかは、明確ではありません。
Other important issues concerning sharing of data on a Computer Network, and which are mentioned in [3] are overlap of information in different files and the possibility of the same information to be contradictory, security and privacy problems, sponsors of a file vs users of a file, and others.
コンピュータNetworkでのデータの共有に関する他の切迫した課題とどれが[3]で言及されるかによる異なったファイルでの情報のオーバラップと、相容れなくなる同じ情報の可能性と、セキュリティと、プライバシー問題と、ファイルのスポンサー、対ファイルのユーザと他のものです。
Shoshani [Page 5] RFC 144 Data Sharing on Computer Networks 30 April 1971
コンピュータネットワーク1971年4月30日に共有されるShoshani[5ページ]RFC144データ
ACKNOWLEDGMENT
承認
Discussions with the following people were very valuable: Al Vorhus, Peggy Karp and others in MITRE, Barry Wesseler in Utah, Gerald Levitt, N. Cohen and others in RAND, Clark Weissman, and Charlie Kellogg in SDC, Richard Winter of CCA.
以下の人々との議論は非常に貴重でした: SDC(CCAのリチャードWinter)のアルVorhus、ペギー・カープ、斜め継ぎにおける他のもの、ユタのバリトンサックスWesseler、ジェラード・レビット、N.コーエン、底ならし革の他のもの、クラーク・ワイズマン、およびばかケロッグ。
REFERENCES
参照
1. Kellogg, C. "A Natural Language Compiler for Online Data
Management." Fall Joint Computer Conference Proceedings, Vol. 33,
part I, 1968. pp. 473-492
1. C. ケロッグ、「オンラインデータ管理のための自然言語コンパイラ。」 フォール・ジョイント・コンピュータ協議会Proceedings(Vol.33)はI、1968ページを分けます。 473-492
2. Clamons, Eric H. "Introductory Remarks to Data Base Management
Seminar." Proceedings of Workshop on Networks of Computers (NOC-
1969) NSA pp. 89-90
2. Clamons、エリック、H. 「データベースの管理セミナーへの前置き。」 コンピュータ(NOC1969)NSAページのNetworksにおけるWorkshopの議事 89-90
3. Hicken, George "Data Base Confrontation in an Information
Network." Proceedings of Workshop on Networks of Computers (NOC-
1969). NSA pp. 99-115.
3. Hicken、ジョージ、「データは情報網で対立を基礎づけます」。 コンピュータ(NOC1969)のネットワークにおけるワークショップの議事。 NSAページ 99-115.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Ryan Kato 6/01]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ライアン・加藤6/01によるオンラインRFCアーカイブへの]
Shoshani [Page 6]
Shoshani[6ページ]
一覧
スポンサーリンク
