データのかたちの歴史 ～行列・レコード・テーブル・DataFrame・Schemaの進化～
要旨
本稿は、情報システム史を、ハードウェアやプログラミング言語そのものの歴史としてではなく、「人間と機械がデータをどのような形で表現してきたか」という観点から整理する試論である。従来のデータ分析教育では、多変量解析や機械学習のアルゴリズムは行列として説明されることが多い。しかし、実務で扱われる顧客データ、購買履歴、アンケート、Webログ、POSデータは、最初から数学的な行列として存在しているわけではない。多くの場合、それらはレコード、テーブル、CSV、RDB、DataFrame、JSON、YAMLなどの形で存在し、分析者はそれらを目的に応じて整形し、ようやく行列やモデル入力に変換する。
この断絶は、学術的なデータ分析と実務的なデータ分析のあいだに大きなギャップを生んできた。大学の教科書では、すでに整った行列 \(X\) が与えられ、そこから回帰分析、主成分分析、因子分析、クラスタリングが始まる。一方、企業実務では、顧客マスタ、購買履歴、商品マスタ、広告ログ、Webログなどを結合し、粒度をそろえ、欠損やカテゴリを処理し、分析可能なテーブルを作る作業が重要になる。本稿では、この「表から行列へ」の過程を中心に、FORTRAN、COBOL、リレーショナルデータベース、S/Rのdata.frame、Python/pandas、そしてYAMLやLLM時代のスキーマ表現までを概観する。
結論として、本稿は、現代のデータサイエンスを「行列を扱う技術」としてだけでなく、「表を行列へ、さらに意味ある判断へ変換する技術」として捉える必要があると主張する。DataFrameは単なる便利なライブラリではなく、行列文化、レコード文化、表計算文化、データベース文化を接続した「表指向」の中核的表現である。そしてLLM時代には、その上位に、Schema、Context、Business Taskを明示する新しい層が必要になっている。
1. はじめに：データ分析はどこから始まるのか
データ分析の教科書を開くと、多くの場合、分析対象はすでに行列として与えられている。回帰分析であれば、目的変数( y)と説明変数行列(X)があり、モデルは
として表される。主成分分析ではデータ行列Xの分散共分散行列や相関行列が扱われ、因子分析でも観測変数間の相関構造が前提となる。数学的な説明として、これは当然である。アルゴリズムは抽象化され、ベクトル、行列、テンソルとして記述されることで、一般性と厳密性を得る。
しかし、現実のデータは最初から行列ではない。たとえばマーケティング実務で扱われるデータには、顧客ID、性別、年代、住所、購買日時、商品ID、ブランド名、価格、キャンペーン接触、広告表示回数、検索流入、アンケート回答、自由回答テキストなどが含まれる。これらは数値だけではなく、文字列、カテゴリ、日付、ID、階層、複数回答、ログイベントなどを含んでいる。行列の各要素(x_{ij})のような無名の数値ではなく、列名を持ち、尺度を持ち、観測単位を持つ。
したがって、実務のデータ分析は、しばしば次のような順序をたどる。
業務システム・ログ・調査票
↓
RDB・CSV・Excel・JSONなどの形式
↓
抽出・結合・集計・コード化・欠損処理
↓
分析用テーブルまたはDataFrame
↓
数値行列・特徴量行列
↓
統計モデル・機械学習モデルこのうち、統計学や多変量解析の教科書が主に扱ってきたのは、後半の「行列になった後」である。一方、企業実務で時間を要するのは、前半の「分析可能な表を作る」過程である。このギャップを理解するためには、情報システムの歴史を、単なる技術史ではなく、データの表現形式の歴史として読み直す必要がある。
2. 数値計算の時代：FORTRANと行列の世界
FORTRANは、科学技術計算を効率化するために生まれた高水準プログラミング言語である。IBMの解説では、FORTRANは1954年に作られ、1957年に商用リリースされたと説明されている。名前の由来は Formula Translation、つまり数式変換である。FORTRANは、科学者、数学者、技術者が、機械語ではなく数式に近い形で計算を記述できるようにした。
この世界で中心にあるのは、数値である。配列、ベクトル、行列、多次元配列が主役であり、対象は微分方程式、物理シミュレーション、気象計算、構造解析、数値最適化などである。プログラムは、現実世界の対象を「数値配列」として表現し、その上で計算を行う。
この文化は、現代のNumPyやMATLAB、さらには多くの機械学習ライブラリにも引き継がれている。NumPyの配列は、同じ型の数値が規則正しく並んだ構造であり、数値計算に適している。画像も、機械学習の内部ではテンソルとして扱われる。テキストも、埋め込みベクトルに変換される。つまり、計算のためには、多くの対象が最終的には数値配列へと変換される。
しかし、ここには重要な限界がある。現実のデータは、必ずしも最初から数値配列として与えられない。顧客の性別、地域、職業、ブランド名、商品カテゴリ、自由回答などは、行列のセルに単純に入れればよいというものではない。それらは尺度水準を持ち、意味を持ち、場合によってはコード化やダミー化、集計、正規化、結合を必要とする。FORTRAN的な行列の世界は、アルゴリズムの説明には強いが、業務データの意味や構造を十分に表現するものではなかった。
3. 業務データの時代：COBOLとレコード
FORTRANが科学技術計算のための言語であったのに対し、COBOLは業務処理のための言語であった。COBOLは Common Business-Oriented Language の略であり、1959年に事務処理や商業計算のために設計された。給与計算、会計、在庫管理、金融取引、保険契約、政府システムなど、大量の定型データを正確に処理することが主な用途だった。
COBOLの中心には、レコードという発想がある。顧客レコード、取引レコード、給与レコード、商品レコードのように、業務上の一件一件を同じ構造を持つデータとして扱う。これは、行列というよりも、現在のデータベースやCSVに近い発想である。
たとえば、顧客データは次のような構造を持つ。
顧客レコード
顧客ID
氏名
性別
生年月日
住所
登録日このとき重要なのは、各値が単なる数値ではなく、項目名を持っていることである。顧客IDは識別子であり、氏名は文字列であり、生年月日は日付であり、性別はカテゴリである。COBOL的な世界では、データは計算対象というよりも、業務上の事実を記録する単位として存在する。
ここで、FORTRAN的な「行列」とCOBOL的な「レコード」の対比が見えてくる。前者は計算のための構造であり、後者は記録のための構造である。科学技術計算では、データは数値配列として抽象化される。一方、業務処理では、データはレコードとして意味を持った項目の集合として扱われる。
この違いは、後のデータ分析に大きな影響を与える。企業の顧客DBやPOSデータは、基本的にレコードの集合である。顧客、商品、店舗、購買、広告接触、Webイベントなどは、すべて何らかのレコードとして保存される。したがって、実務のデータ分析では、まずレコードを理解し、それらを結合し、分析単位に再構成する必要がある。
4. リレーショナルデータベース：キー、テーブル、JOIN
1970年、E. F. Coddは “A Relational Model of Data for Large Shared Data Banks” を発表した。この論文は、リレーショナルデータベースの出発点として広く知られている。Coddが重視したのは、データの論理構造と物理的な格納方法を分離することであった。利用者やアプリケーションは、データが機械内部でどのように格納されているかを知らなくても、論理的な関係としてデータを扱えるべきだと考えられた。
リレーショナルモデルは、データをテーブル、すなわち関係として表現する。各行はレコード、各列は属性である。テーブルにはキーがあり、キーを用いて別のテーブルと結合できる。たとえば、購買履歴テーブルには顧客IDがあり、顧客マスタにも顧客IDがある。この顧客IDを用いて、購買履歴と顧客属性をJOINできる。
SELECT purchase.customer_id, customer.gender, customer.age_group, purchase.amount FROM purchase LEFT JOIN customer ON purchase.customer_id = customer.customer_id;
このJOINは、実務データ分析の中核的な作業である。顧客、商品、店舗、キャンペーン、広告、Web行動、購買履歴が別々のテーブルに格納されている場合、それらを分析目的に応じて結合しなければならない。
ここで、キーは一種の論理的な参照である。C言語のポインタはメモリアドレスを指すが、RDBの主キーや外部キーは、物理的なメモリアドレスではなく、論理的な対象を指す。顧客IDは、顧客マスタ上の一人の顧客を指す。商品IDは、商品マスタ上の一つの商品を指す。つまり、RDBは、メモリ番地ではなく、業務上意味のあるIDによってデータを参照する仕組みである。
この変化は重要である。ポインタが「データはどこにあるか」を扱う技術だとすれば、キーとJOINは「データ同士はどう関係しているか」を扱う技術である。情報システム史は、物理的な場所の管理から、論理的な関係の管理へと進んだのである。
5. 表計算ソフトとCSV：人間が読める表
RDBが業務システム内部のデータ管理を支えた一方で、ビジネス現場の日常的なデータ操作を支えたのは、ExcelやGoogleスプレッドシートのような表計算ソフトである。表計算ソフトは、行と列を持ち、セルに値を入れる。人間は列名や行見出しを見ながら、データの意味を理解できる。
表計算ソフトの強みは、計算と表示と編集が一体化している点にある。利用者は、数式を入力し、集計表を作り、グラフを描き、見た目を調整し、結果を共有できる。プログラミング言語やデータベースを知らなくても、表形式のデータを扱うことができる。
CSVもまた重要である。CSVは単純なテキスト形式であり、カンマでセルを区切る。Excel、R、Python、SQLデータベース、BIツールなど、多くの環境で読み書きできる。CSVは、表形式データの共通語として機能してきた。
ただし、表計算ソフトやCSVは、人間にとって分かりやすい反面、分析上の問題も多い。たとえば、列名が曖昧である、文字コードで文字化けする、カテゴリの表記揺れがある、複数回答が一つのセルに入っている、日付形式が混在している、数値に見える文字列が含まれる、などである。
特にアンケートデータでは、Microsoft FormsやGoogle Formsから出力されたデータに、複数回答が “Twitter;Instagram”のように一つのセルへ格納されることがある。この形式は人間には読めるが、集計や統計分析にはそのまま使いにくい。分析するには、選択肢ごとに0/1のフラグへ変換するか、回答者×選択肢のロング形式に展開する必要がある。
この問題は、表が単に「見た目の形式」ではなく、「観測単位」と「変数」と「尺度」を持つデータ構造であることを示している。表は便利だが、表の意味を明示しないまま分析すると、誤った集計や解釈につながる。
6. 統計言語S/RとDataFrame：行列とリストの融合
統計処理の世界では、S言語とR言語が重要な役割を果たした。S言語はBell Laboratoriesで開発された統計計算環境であり、Rはその影響を強く受けたオープンソースの統計言語である。S/Rの文化は、FORTRAN的な行列計算と、統計家が扱う観測データの世界を接続した。
DataFrameは、この接続を象徴するデータ構造である。S-PLUSの講義資料では、data frameはS言語に1991年に導入された比較的新しい機能であり、Chambers and Hastie (1992) の *Statistical Models in S* で説明されているとされる。data frameは、見た目は行列に似ているが、列ごとに異なる型を持てる点で、行列より一般的である。さらに、data frameは「行列とリストの交差」のようなものとして説明される。
この説明は重要である。行列は通常、すべての要素が同じ型である。数値行列なら、全セルが数値である。一方、DataFrameでは、列ごとに型が異なってよい。年齢列は数値、性別列はカテゴリ、氏名列は文字列、登録日列は日付、満足度列は順序尺度、というように、一つの表の中に異なる種類の変数を保持できる。
つまり、DataFrameは、行列のように二次元でありながら、リストのように異なる型の列を束ねることができる。実装上は「同じ長さのベクトルのリスト」と見ることができるが、利用者には「表」として見える。ここに、DataFrameの強さがある。
統計学において、観測単位は行であり、変数は列である。DataFrameは、この発想を直接表現する。アンケートなら一行が一回答者、POSなら一行が一購買または一明細、Webログなら一行が一イベントである。列は、性別、年代、購買金額、商品カテゴリ、イベント時刻などの変数である。
この意味でDataFrameは、単なるデータ構造ではなく、統計的な世界観を支える表現である。統計家は、行列を操作しているようでいて、実際には「観測単位×変数」の表を扱っている。DataFrameは、この現実に適した構造である。
7. pandasと「表指向」：PythonにおけるDataFrameの市民権
Pythonのデータ分析において、pandasはDataFrameを広く普及させた。Wes McKinneyの *Python for Data Analysis* では、pandasはデータクリーニングや分析のための高速で便利なデータ構造と操作ツールを提供するライブラリとして説明されている。pandasはNumPyと密接に関係しているが、NumPyが同質的な数値配列に適しているのに対し、pandasは表形式または異質なデータに適している。
ここで、pandasを単に「列指向」と呼ぶのは適切ではない。BigQueryのような列指向データベースは、巨大なデータの中から必要な列だけを読み込むことで効率的な集計を実現する。一方、pandasのDataFrameは、ユーザーから見ると、列にも行にもアクセスできる。df[“売上”] で列を取り出すこともできるし、df.iloc[0] で行を取り出すこともできる。groupby()、merge()、pivot_table()、melt() などの操作により、SQLやExcelに近い発想でデータを扱える。
したがって、pandasは「列指向」ではなく、「表指向」と呼ぶ方がしっくりくる。表指向とは、内部実装の話ではなく、人間がデータをどう認識するかの話である。pandasは、Excelのように表を見せ、SQLのように結合や集計を行い、Rのdata.frameのように統計分析へ接続し、NumPyのような数値計算へも橋渡しする。
この「表指向」こそが、pandasが市民権を得た理由である。多くの実務家は、最初からテンソルや行列で考えているわけではない。顧客表、商品表、購買表、広告表、アンケート表としてデータを見る。pandasは、その見方を壊さずに、プログラムによる処理と統計分析へ接続した。
この意味で、pandasのDataFrameは、FORTRAN的な行列文化、COBOL的なレコード文化、RDB的なテーブル文化、Excel的な表計算文化、R的な統計文化の交差点にある。DataFrameは「行列を便利にしたもの」というより、「表を分析可能な第一級市民にしたもの」と捉えるべきである。
8. 表から行列へ：学術と実務のギャップ
学術的なデータ分析では、多くの場合、分析用データセットがすでに存在する。研究者は、調査会社からCSVを受け取り、R、SPSS、Stata、SAS、Pythonなどで分析する。データは、回答者×変数の形式に整えられている。したがって、研究者の関心は、回帰分析、因子分析、SEM、クラスタリング、機械学習モデルなどの手法に向かいやすい。
一方、実務では、分析用DataFrameが最初からあるとは限らない。顧客マスタ、購買履歴、商品マスタ、店舗マスタ、広告配信ログ、Webアクセスログ、アプリ利用ログなどが別々に存在する。分析者は、SQLやETLツール、Python、BIツールを用いて、これらを結合し、集計し、粒度をそろえ、特徴量を作る。
たとえばRFM分析を考える。教科書では、顧客ごとにRecency、Frequency、Monetaryが並んだ表が登場する。しかし実務では、その表は自然に存在しない。購買履歴から、顧客ごとの最終購買日、購買回数、購買金額合計を計算しなければならない。つまり、RFMは統計手法以前に、データベース集計の結果である。
この違いは、大学のマーケティング研究者と企業実務家の会話のズレにもつながる。大学の研究者が「何で分析していますか」と聞くとき、想定している答えはR、SPSS、Stata、Pythonなどである。しかし実務家が「ほとんどSQLです」と答えるのは自然である。実務では、分析手法そのものよりも、まず分析可能な表を作る作業が大きな比重を占めるからである。
このギャップを埋める職能として、データサイエンティストが登場したと見ることもできる。データサイエンティストは、統計学だけでなく、SQL、プログラミング、データベース、可視化、業務理解を横断する必要がある。言い換えれば、データサイエンティストは「表を行列へ変換し、行列から意味ある判断へ変換する人」なのである。
9. キー、ハッシュ、ポインタ：場所から関係へ
データ表現の歴史を考えるうえで、ポインタ、ハッシュ、キーの関係も重要である。
ポインタは、データの物理的な場所を指す技術である。C言語では、変数のメモリアドレスを取得し、そのアドレスを通じて値へアクセスできる。これは、データが「どこにあるか」を直接扱う低レイヤーの技術である。
一方、ハッシュテーブルは、キーから値へ高速に到達するための構造である。Pythonの辞書型で `customer[“age”]` と書くとき、利用者はメモリアドレスを知らない。内部では、キー文字列がハッシュ関数で処理され、格納位置が決まる。ここでは、「名前から場所を探す」仕組みが働いている。
RDBの主キーや外部キーは、さらに論理的な参照である。顧客IDは、物理メモリ上のアドレスではなく、業務上の顧客を参照する。商品IDは商品を参照し、店舗IDは店舗を参照する。JOINは、これらの論理キーを用いてテーブル同士を関連づける操作である。
このように見ると、データシステムには少なくとも次のレイヤーがある。
物理的な場所: ポインタ、メモリアドレス
探索と対応: ハッシュテーブル、辞書、インデックス
論理的な関係: 主キー、外部キー、JOIN
意味づけ: スキーマ、コードブック、設問設計、ビジネス文脈歴史的には、下層の技術が消えたわけではない。ポインタは今でもC/C++やランタイム、データベースエンジン、OS、ライブラリの内部で生きている。ただし、利用者が直接触る機会は減った。現代のデータ分析者が日常的に見るのは、ポインタではなく、列名、キー、DataFrame、スキーマである。
これは、データ処理の関心が、「どこにあるか」から「どう関係しているか」、さらに「何を意味しているか」へ移ってきたことを示している。
10. Schemaの時代：YAML、LLM、意味の管理
DataFrameは、表形式データを扱う強力な表現である。しかし、DataFrameだけでは不十分な場合がある。なぜなら、DataFrameは列名と値を持つが、その列が何を意味するか、どの尺度水準か、選択肢の順序は何か、複数回答か単一回答か、どのような調査意図で作られたかまでは必ずしも明示しないからである。
たとえば、満足度 `5` が高い満足を意味するのか、不満を意味するのかは、データだけでは分からない。”Q3″ という列が複数回答なのか単一回答なのかも、列名だけでは分からない。”Twitter;Instagram” というセルを見れば複数回答らしいと推測できるが、それは推測であり、設問設計上の確定情報ではない。
ここで必要になるのが、Schemaである。Schemaは、データの構造を明示する。列名、型、選択肢、尺度、順序、観測単位、複数回答の扱い、欠損値の意味などを記述する。さらに、マーケティング分析では、Schemaだけでなく、ContextとBusiness Taskも重要になる。設問の意図、分析目的、背後のビジネス課題が明示されなければ、正しい分析計画を立てることは難しい。
YAMLは、このような情報を人間が読みやすい形で記述するための形式として有用である。YAML仕様は、YAMLを「human-friendly, cross language, Unicode based data serialization language」と説明している。YAMLはJSONやXMLよりも人間にとって読みやすく、階層構造を表現しやすい。
LLM時代には、このSchema表現がさらに重要になる。LLMは、データから構造を推定できるが、その推定は仮説である。人間が確認し、修正し、合意されたSchemaとして固定する必要がある。特にアンケートデータ、ログデータ、多値データでは、データの外側にある意味を人間が補完しなければならない。
したがって、現代のデータ分析プロセスは、次のように整理できる。
Raw Data
↓
Schema Reconstruction
↓
Schema Validation
↓
Data Transformation
↓
Analysis Design
↓
Modeling / Interpretation / Decisionこれは、単なるデータ前処理ではない。データの意味を復元し、人間とAIが共有可能な形に固定し、その上で分析を進めるプロセスである。
## 11. データ表現史としてのまとめ
ここまでの議論を、データ表現の変遷として整理すると、次のようになる。
| 時代・系譜 | 代表例 | データの見方 | 主な問い |
| 数値計算 | FORTRAN, NumPy | 行列・配列 | どう計算するか |
| 業務処理 | COBOL | レコード | 何を記録するか |
| データベース | RDB, SQL | テーブル・キー・関係 | どう関連づけるか |
| 表計算 | Excel, CSV | 人間が読める表 | どう見て編集するか |
| 統計計算 | S/R data.frame | 観測単位×変数 | どう分析するか |
| データ分析実務 | pandas DataFrame | 表指向 | どう整形し分析へ接続するか |
| 現代の意味管理 | YAML, Schema, LLM | 構造と解釈 | このデータは何を意味するか |
この表から分かるように、データの表現形式は、技術の制約だけでなく、人間がデータを何として見たいかによって変化してきた。数値計算では、データは行列である。業務処理では、データはレコードである。データベースでは、データは関係である。表計算では、データは人間が編集可能な表である。統計分析では、データは観測単位と変数の組である。LLM時代には、データはスキーマとコンテクストを伴う意味構造である。
この観点に立つと、DataFrameは一つの歴史的な到達点である。DataFrameは、行列のように分析でき、レコードのように観測単位を持ち、テーブルのように結合でき、Excelのように人間が理解できる。まさに、複数のデータ文化を接続する「表指向」の表現である。
しかし、DataFrameも最終形ではない。DataFrameは、列の意味や分析意図を完全には保持しない。したがって、これからのデータ分析では、DataFrameの上位に、Schema、Context、Business Taskを明示する層が必要になる。これは、AIと人間が協働して分析する時代において、特に重要である。
12. おわりに：表から行列へ、そして意味へ
本稿では、情報システム史を「データのかたち」の変遷として整理した。FORTRANは数値計算と行列の世界を開き、COBOLは業務レコードの世界を整えた。Coddのリレーショナルモデルは、データをテーブルとキーの関係として抽象化し、SQLによって実務データの抽出と結合を可能にした。S/Rのdata.frameは、統計分析における観測単位と変数の表現を支え、pandasはその文化をPythonに広く普及させた。そしてLLM時代には、DataFrameの上に、スキーマとコンテクストを明示する必要が生じている。
この歴史を理解すると、データ分析教育の課題も見えてくる。多変量解析や機械学習のアルゴリズムは、行列で説明される。しかし、実務データは表として存在し、そこには文字列、カテゴリ、ID、日付、複数回答、ログイベント、欠損、尺度方向が含まれる。したがって、学生や実務家には、行列の数学だけでなく、表を理解し、表を整形し、表を行列へ変換する力が必要である。
特にマーケティング領域では、顧客、商品、店舗、購買、広告、Web行動、アンケートといった対象が、すべて何らかのデータ表現を通じて観測される。顧客を語るためには、顧客DBの構造を理解する必要がある。購買を語るためには、購買履歴の粒度を理解する必要がある。広告効果を語るためには、媒体、キャンペーン、接触、反応、売上の関係をデータとしてどう表現するかを理解する必要がある。
したがって、これからのデータ分析教育には、「行列の分析」だけではなく、「表の設計」「キーとJOIN」「ワイドとロング」「DataFrame」「Schema」「Context」を含む、データ表現の教育が必要である。それは単なるITスキルではなく、分析結果の妥当性を支える基礎である。
データ分析とは、単に数式を適用することではない。データがどのように生まれ、どのように保存され、どのように結合され、どのように意味づけられ、どのように行列へ変換されるかを理解する営みである。この意味で、現代のデータサイエンスは、表から行列へ、そして意味へと進む学問である。
参考文献・参考資料
基本文献
- Codd, E. F. (1970). “A Relational Model of Data for Large Shared Data Banks.” *Communications of the ACM*, 13(6), 377–387. IBM Research publication page: [A Relational Model of Data for Large Shared Data Banks](https://research.ibm.com/publications/a-relational-model-of-data-for-large-shared-data-banks)
- Chambers, J. M., & Hastie, T. J. (1992). *Statistical Models in S*. Wadsworth & Brooks/Cole.
- Becker, R. A., Chambers, J. M., & Wilks, A. R. (1988). *The New S Language*. Wadsworth & Brooks/Cole.
- McKinney, W. (2022). *Python for Data Analysis, 3rd Edition*. O’Reilly Media. Open edition: [Python for Data Analysis, 3E](https://wesmckinney.com/book/)
- Wickham, H., Çetinkaya-Rundel, M., & Grolemund, G. (2023). *R for Data Science, 2nd Edition*. O’Reilly Media. Online edition: [R for Data Science](https://r4ds.hadley.nz/)
- Wickham, H. (2014). “Tidy Data.” *Journal of Statistical Software*, 59(10). [JSS article](https://www.jstatsoft.org/article/view/v059i10/)
Web資料
- IBM. “Fortran.” IBM History. [Fortran | IBM](https://www.ibm.com/history/fortran)
- Computer History Museum Software Preservation Group. “History of FORTRAN and FORTRAN II.” [History of FORTRAN](https://softwarepreservation.computerhistory.org/FORTRAN/)
- University of Washington lecture notes. “Data Frames in Splus.” [Data Frames in Splus PDF](https://sites.stat.washington.edu/people/handcock/505/Lectures/lec9.pdf)
- YAML Language Development Team. “YAML Ain’t Markup Language (YAML™) revision 1.2.2.” [YAML 1.2.2 Specification](https://yaml.org/spec/1.2.2/)
- pandas documentation. [pandas documentation](https://pandas.pydata.org/docs/)
(了)
