6月、1本の論文がarXiv（物理学や数学などの論文プレプリントサーバ）に公開された。タイトルは「A Family of Non-Periodic Tilings, Describable Using Elementary Tools and Exhibiting a New Kind of Structural Regularity」。著者のMiki Imura氏（以下、Imura氏）は、学術機関に所属する研究者ではなく、普通の会社員だ。
日本の会社員が発見、数学界を賑わせた「新図形」とは？ 論文も5日間で執筆、arXivにも掲載：Innovative Tech（1/2 ページ） - ITmedia NEWS
Imura氏は趣味でプログラミングを使ったタイリングパターンの生成を楽しんでいた。Facebookには「Mathematical Tiling and Tessellation」（数学的タイリングと平面充填）という12万人以上のメンバーを擁する専門的なコミュニティーがあり、そこに自作のパターンを投稿していたという。
日本の会社員が発見、数学界を賑わせた「新図形」とは？ 論文も5日間で執筆、arXivにも掲載：Innovative Tech（1/2 ページ） - ITmedia NEWS
このタイリングパターンの数学的背景を解説してほしいというコメントがある中、Imura氏は自身の発見をきちんとした形で残したいと考え、arXivへの投稿を決意した。ハンガリーでポスドク研究をしている数学者の協力を得て、有給休暇を活用しながら約5日間で論文を書き上げた。
日本の会社員が発見、数学界を賑わせた「新図形」とは？ 論文も5日間で執筆、arXivにも掲載：Innovative Tech（1/2 ページ） - ITmedia NEWS
⇧ amazing...
どの分野にも天才としか思えないような人がおられますな...
ORM（Object Relational Mapping）
Wikipediaによりますと、
オブジェクト関係マッピング（英: Object-relational mapping, O/RM, ORM）とは、データベースとオブジェクト指向プログラミング言語の間の非互換なデータを変換するプログラミング技法である。オブジェクト関連マッピングとも呼ぶ。実際には、オブジェクト指向言語から使える「仮想」オブジェクトデータベースを構築する手法である。オブジェクト関係マッピングを行うソフトウェアパッケージは商用のものもフリーなものもあるが、場合によっては独自に開発することもある。
批評
オブジェクト関係マッピングは、オブジェクト指向と関係モデルのインピーダンス・ミスマッチ問題の対症療法にすぎないとも言われている。関係データベースの原則から見れば、オブジェクト指向はデータ操作には不十分であり、パラダイム全体として問題がある。現状のオブジェクト関係マッピングのマッピングは間違っているとも言われ、正しくは型 (定義域) とオブジェクトを対応させるべきとも言われている。
⇧ とあり、他に方法ないので妥協案的な技術と見なされている模様。
イメージとしては、
ORM general, relational, and non-relational high-level architecture
⇧ 上図のような感じで、
- アプリケーション
- API
- ORM（Object Relational Mapping）
- Database Driver
- Database
といった構成で利用されるような感じになるっぽい。
いろいろと情報が必要ってことですな。
PythonのORMでSQLModelというものが登場しているらしいが...
で、「Python」用の「ORM（Object Relational Mapping）」はというと、
⇧ おそらく、「SQLAlchemy」が有名っぽい気がする。
上記は、「ORM（Object Relational Mapping）」の分類になってい無さそうなのだが...
で、
PythonのORMではまだまだSQLAlchemyが主流ですが、FastAPIの作者が作っていること、またSQLAlchemyのラッパーであり移行が簡単なので、今からWatchしておくといいかと思います。
⇧ とのこと。
なのだが、「レイヤー」を横断する時の「項目数」の差分については言及されていらっしゃらない...
外部からのリクエストが持つデータと、「データベース」の「テーブル」の構成が異なるから「DTO（Data Transfer Object）」が必要になってきてしまうのだが、そのあたりについての話が触れられていないのよね...
「DTO（Data Transfer Object）」が増え過ぎて管理が煩雑になってしまう、俗に言う「DTO explosion」の問題についての解は無さそうですかね...
改良はされているとは思うのだが、根本的な問題の解決には至らないといった感じなんですかね...
「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
🧠 SQLModel が解決できること・できないこと
✅ できる／強い点
-
SQLModel のモデルは Pydantic モデルなので、API 入出力時のバリデーションやシリアライズが楽になる。
-
response_modelに SQLModel の Pydantic モデルをそのまま指定すれば、JSON シリアライズが自動的に行われる。 -
しかも ORM モデルを
.from_orm()で Pydantic に変換できるので、簡単な DTO 作りは手間が減る。
❌ できない／弱い点
しかし 外部 API などで受け取るデータ構造とテーブル構造が異なる場合、SQLModel 単体では
という制約があります。
これは SQLModel の制約というより、Pydantic と ORM の役割分離の原則によるものでもあります。
🧩 結論
SQLModel は DTO の “定義と検証” を楽にしてくれるけど、外部 API のデータ構造と DB の構造が異なる場合の自動マッピングまではやってくれません。 そこは API 用 DTO を別に定義し、必要に応じて自前でマッピングする設計 が必要になります。
う～む...、未だに進展は無さそうな感じですな...
とは言え、「Python」用の「ORM（Object Relational Mapping）」を利用するとなった場合は、消去法で「SQLModel」に移行していく感じになるんかな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
