記録（コンピュータサイエンス）

コンピュータサイエンスにおいて、レコード（構造体、 struct、複合データ型とも呼ばれる）は複合データ構造であり、通常は数と順序が固定された、異なるデータ型のフィールドの集合です。 ^[1]

たとえば、日付は、数値の 年フィールド、文字列として表される月フィールド、および数値の月日フィールドを含むレコードとして保存できます。円レコードには、数値の半径と、x 座標とy座標を含むポイントレコードである中心が含まれる場合があります。

注目すべきアプリケーションとしては、プログラミング言語の レコード タイプと、データベース テーブル、スプレッドシート、カンマ区切り値(CSV) ファイルなどのレコードのシーケンスとして編成されたデータの行ベースのストレージがあります。一般に、レコード タイプの値はメモリに格納され、行ベースのストレージは大容量ストレージに格納されます。

レコード型は、そのような値や変数を記述するデータ型です。最近のプログラミング言語のほとんどでは、プログラマが新しいレコード型を定義できます。定義には、各フィールドのデータ型と、それにアクセスするための識別子(名前またはラベル) の指定が含まれます。型理論では、単純さから一般に積型(フィールド名なし) が好まれますが、適切なレコード型はSystem F-subなどの言語で研究されています。型理論上のレコードには、データに加えて第一級の関数型フィールドを含めることができるため、オブジェクト指向プログラミングの多くの機能を表現できます。

データベースやスプレッドシートなどのストレージの文脈では、レコードは行と呼ばれ、各フィールドは列と呼ばれることが多い。^{[2] [3] [4] [5]}

オブジェクト指向プログラミングでは、オブジェクトは状態とメソッド フィールドを含むレコードです。

レコードは数学的な タプルに似ていますが、規則やプログラミング言語に応じて、タプルがレコードと見なされる場合とそうでない場合があり、その逆もあります。同様に、レコード型は、 2 つ以上の数学的なセットの直積のコンピュータ言語版、または特定の言語での抽象積型の実装と見なすことができます。

レコードは、レコードの要素（フィールド）がレコードの定義によって決定され、異種であっても構わないという点で配列と異なります。一方、配列は同じ型の要素の集合です。^[6]

関数のパラメータは、レコードのフィールドとしてまとめて表示することができ、関数に引数を渡すことは、入力パラメータをレコード フィールドに割り当てることと見なすことができます。低レベルでは、関数呼び出しには、パラメータに加えて、ローカル変数や戻りアドレスなどの他のフィールドを含むアクティベーション レコードまたは呼び出しフレームが含まれます。

レコードの概念は、昔から会計で使われてきたさまざまな種類の表や元帳にまで遡ることができます。明確に定義されたタイプとサイズのフィールドを持つコンピュータサイエンスにおけるレコードの現代的な概念は、バベッジの解析エンジンなどの19世紀の機械式計算機にすでに暗黙的に存在していました。^{[7] [8]}

データ（制御用ではなく）に使用された最初の機械可読媒体は、1890年の米国国勢調査の記録に使用されたパンチカードでした。パンチカード1枚が1つのレコードでした。1880年のジャーナルエントリと1895年のパンチカードを比較してください。レコードは、ほとんどのデータ処理がパンチカードを使用して行われていた20世紀前半に定着しました。通常、データファイルの各レコードは1枚のパンチカードに記録され、特定の列が特定のフィールドに割り当てられます。通常、レコードは外部ストレージ（カードリーダー、テープ、ディスクなど）から読み取ることができる最小単位です。パンチカードスタイルのレコードの内容は、パンチカードのドキュメントの長さが事前に決められていたため、当初は「ユニットレコード」と呼ばれていました。^[9]ハードドライブと磁気テープの使用によりストレージシステムがさらに進歩すると、可変長レコードが標準になりました。可変長レコードとは、レコードのバイト単位のサイズがフィールドのサイズの合計とほぼ等しいレコードです。より高度なストレージ ハードウェアが発明される前は、当時はカードを物理的にマシンに挿入する必要があったため、すべてのパンチ カードがコンピューターが読み取れる所定のドキュメントの長さに適合する必要があったため、これを実現することは不可能でした。

ほとんどのマシン言語実装と初期のアセンブリ言語にはレコード用の特別な構文はありませんでしたが、インデックス レジスタ、間接アドレス指定、自己修正コードを使用することでこの概念が利用可能になり、広く使用されました。IBM 1620などの初期のコンピューターには、レコードとフィールドを区切るためのハードウェア サポートと、そのようなレコードをコピーするための特別な命令がありました。

レコードとフィールドの概念は、IBM のレポート プログラム ジェネレーター (RPG)などの初期のファイルソートおよび集計ユーティリティの中心的な概念でした。

COBOLはレコード型をサポートする最初の普及したプログラミング言語^[10]、そのレコード定義機能は当時としては非常に洗練されていました。この言語では、任意のサイズと精度の英数字、整数、小数フィールドを持つネストされたレコードの定義が可能で、割り当てられた値を自動的にフォーマットするフィールド（通貨記号、小数点、桁区切りの挿入など）も定義できます。各ファイルは、データの読み取りまたは書き込みが行われるレコード変数に関連付けられています。COBOLには、MOVE CORRESPONDING2つのレコードの対応するフィールドを名前に従って割り当てるステートメントもあります。

FORTRAN ( FORTRAN IVまで) やALGOL 60など、数値計算用に開発された初期の言語ではレコード型がサポートされていませんでしたが、 FORTRAN 77やALGOL 68などの後のバージョンではレコード型が追加されました。オリジナルのLisp プログラミング言語にもレコードがありませんでした (組み込みのcons cellを除く) が、S 式が適切な代替手段を提供しました。Pascalプログラミング言語は、レコード型を他の基本型と完全に統合して論理的に一貫した型システムを作成した最初の言語の 1 つでした。PL/I言語は、COBOL スタイルのレコードを提供しました。C言語は、 を使用したレコードの概念を提供します。Pascal の後に設計されたほとんどの言語 ( Ada、Modula、Javastructなど) もレコードをサポートしていました。

レコードはもはや元のコンテキスト（つまり、データを格納するためだけに使用される）で使用されることはあまりありませんが、レコードは新しいオブジェクト指向プログラミング言語やリレーショナルデータベース管理システムに影響を与えました。レコードはデータの格納および処理方法においてより高いモジュール性を提供したため、言語でデフォルトで提供されているプリミティブデータ型よりも複雑で現実的な概念を表現するのに適しています。これは、プログラミングの同じモジュール性ニーズに対応するC++、Python、JavaScript、Objective-Cなどの後の言語に影響を与えました。 ^{[11]これらの言語の} オブジェクトは基本的に、メソッドと継承が追加されたレコードであり、プログラマはレコードの内容だけでなく、データの動作方法を操作できます。オブジェクト指向言語にはレコードの機能をはるかに超える機能があるため、多くのプログラマはレコードを今では時代遅れと見なしています。一方、多くのプログラマは、オーバーヘッドが低く、アセンブリ言語でレコードを使用できることから、抽象化のレベルが低いプログラミングではレコードが依然として重要であると主張しています。今日、プログラミング言語の人気度を示すTIOBE インデックスで最も人気のある言語は、オブジェクト指向であるという事実により、何らかの形でレコードの影響を受けています。^[12] SQLやObject Query Languageなどのクエリ言語も、レコードの概念の影響を受けています。これらの言語を使用すると、プログラマーはデータのセット (基本的にはレコード) をテーブルに格納できます。^{[13]このデータは、}主キーを使用して取得できます。テーブル自体もレコードであり、外部キー (別のテーブルのデータを参照するキー) を持つことができます。   

レコード タイプに対する操作には次のものがあります。

• 各フィールドの位置、型、および（場合によっては）名前を含むレコード型の宣言
• レコードの宣言。レコード型として型指定された変数
• レコード値の構築。フィールド値の初期化を伴う場合もある。
• レコードフィールド値の読み取りと書き込み
• 2つの記録の同等性の比較
• レコードの標準ハッシュ値の計算

一部の言語では、レコードのフィールドを列挙する機能が提供されています。この機能は、デバッグ、ガベージ コレクション、シリアル化などの特定のサービスを実装するために必要です。ある程度の型ポリモーフィズムが必要です。

レコードのサブタイプ化をサポートするコンテキストでは、操作にはレコードのフィールドの追加と削除が含まれます。特定のレコード型は、特定のフィールド セットが存在することを意味しますが、その型の値には追加のフィールドが含まれる場合があります。したがって、フィールドx、y、zを持つレコードは、フィールドxとyを持つレコードの型に属し、フィールドx、y、rを持つレコードも同様です。その理由は、 ( x 、 y ) レコードを引数として期待する関数に ( x 、 y 、 z ) レコードを渡しても、その関数は必要なすべてのフィールドをレコード内で見つけるので、機能するはずだからです。プログラミング言語でレコードを実際に実装する方法の多くは、このような可変性を許可することに問題がありますが、この問題は、より理論的なコンテキストでのレコード型の中心的な特性です。

ほとんどの言語では、まったく同じレコード タイプ (同じフィールド タイプと名前、同じ順序を含む) を持つレコード間の割り当てが許可されます。ただし、言語によっては、別々に定義された 2 つのレコード データ型は、まったく同じフィールドを持つ場合でも、異なる型と見なされる場合があります。

一部の言語では、フィールド名が異なるレコード間での割り当ても許可されています。各フィールド値は、レコード内の位置によって対応するフィールド変数と照合されます。たとえば、フィールド と と呼ばれる複素数をreal、フィールド と を持つ2Dポイントimagレコード変数に割り当てることができます。この代替方法では、2 つのオペランドは同じフィールド タイプのシーケンスを持つ必要があります。一部の言語では、対応するタイプが同じサイズとエンコーディングを持つことも要求されます。これにより、レコード全体を解釈されないビット文字列として割り当てることができます。他の言語では、この点でより柔軟で、各値フィールドを対応する変数フィールドに正当に割り当てることができることのみを要求する場合があります。たとえば、short 整数フィールドをlong 整数フィールドに割り当てることができ、その逆も可能です。 XY

他の言語 ( COBOLなど) では、フィールドと値が位置ではなく名前で一致する場合があります。

同じ可能性は、2 つのレコード値の等価性の比較にも適用されます。言語によっては、個々のフィールドの比較に基づく辞書式順序を使用して、順序比較 ('<' および '>') も許可される場合があります。 ^{[引用が必要]}

PL/I では、前述の両方のタイプの割り当てが許可されているほか、次のような構造式a = a+1;も許可されます。ここで、「a」はレコード、つまり PL/I 用語では構造です。

Algol 68 では、 がPtsレコードの配列で、各レコードに整数フィールドと がある場合X、のすべての要素のフィールドで構成される整数の配列を取得するようにY記述できます。その結果、およびのステートメントは同じ効果を持ちます。 Y of PtsYPtsY of Pts[3] := 7(Y of Pts)[3] := 7

Pascalでは、 コマンドは、レコードのすべてのフィールドが変数として宣言されているかのようにwith R do Sコマンド シーケンスを実行します。 C#などのオブジェクト指向言語で別の名前空間を入力するのと同様に、フィールドにアクセスするためにレコード名をプレフィックスとして使用する必要はなくなりました。 したがって、 と書く代わりに、と書くことができます。 SRPt.X := 5; Pt.Y := Pt.X + 3with Pt do begin X := 5; Y := X + 3 end

メモリ内のレコードの表現は、プログラミング言語によって異なります。多くの場合、フィールドは、レコード型で宣言されたのと同じ順序で、連続したメモリ位置に格納されます。この結果、2 つ以上のフィールドが同じメモリ ワードに格納されることがあります。実際、この機能は、システム プログラミングでワードの特定のビットにアクセスするためによく使用されます。一方、ほとんどのコンパイラは、マシンによって課されるアラインメント制約 (たとえば、浮動小数点フィールドは 1 ワードを占める必要がある など) に準拠するために、プログラマにはほとんど見えないパディング フィールドを追加します。

一部の言語では、レコードをフィールド (および場合によってはフィールドの名前や型) を指すアドレスの配列として実装する場合があります。オブジェクト指向言語のオブジェクトは、特に複数のクラス継承を許可する言語では、かなり複雑な方法で実装されることがよくあります。

自己定義レコードは、レコードタイプを識別し、レコード内の情報を見つけるための情報を含むレコードの一種です。要素のオフセットを含むことができるため、要素は任意の順序で格納することも、省略することもできます。^[14]自己定義レコードに格納される情報は、レコードのメタデータとして解釈できます。これは、ファイルに関するUNIX メタデータに期待されるものと同様で、レコードの作成時間やレコードのバイト単位のサイズなどの情報が含まれます。あるいは、要素識別子を含むレコードのさまざまな要素が、任​​意の順序で単純に続くこともあります。

レコード、特に行ベースのストレージのコンテキストでは、コレクションのレコードにインデックスを付けることができるキーフィールドが含まれる場合があります。主キーは、格納されているすべてのレコードを通じて一意であり、このキーは 1 つしか存在しません。 ^[15]言い換えると、どの主キーも重複して存在することはできません。たとえば、従業員ファイルには、従業員番号、名前、部門、給与が含まれます。従業員番号は組織内で一意であり、主キーになります。ストレージ メディアとファイル構成によっては、従業員番号にインデックスが付けられる場合があります。これは、検索を高速化するために別のファイルに格納されます。部門コードは必ずしも一意である必要はありません。インデックスが付けられる場合もあります。その場合は、セカンダリ キーまたは代替キーと見なされます。^[16]インデックスが付けられていない場合は、特定の部門のすべての従業員のリストを生成するために、従業員ファイル全体をスキャンする必要があります。キーは通常、1 つのキーに複数の値がマッピングされる可能性を最小限に抑える方法で選択されます。たとえば、多くの従業員が同じ給与を受け取る可能性が高いため、給与フィールドは通常、キーとして使用可能であるとは見なされません。

• ブロック（データストレージ）  – 最大所定サイズのビットまたはバイトのシーケンス
• 複合データ型 - プログラミング言語のプリミティブデータ型と他の複合型を使用してプログラム内で構築できる任意のデータ型フォールバックとしてウィキデータの説明を表示するページ
• データ階層 – 小さなコンポーネントと大きなコンポーネントの関係を示す階層形式でデータを体系的に整理します。フォールバックとしてウィキデータの説明を表示するページ
• オブジェクトの構成 – コンピュータプログラミングにおいて高レベルのオブジェクト型を形成する方法
• パッシブデータ構造 – レコードの別名
• ユニオン型 – 複数の異なるデータ型のいずれかの値を許可するデータ型