背景
1970 年代、企業のデータ処理は階層型・ネットワーク型 DBMS やファイルベースが中心だった。スキーマ変更は重く、問い合わせはアプリごとに手続き的に書かれ、データの再利用と統合はコストの高い作業だった。
一方、IBM の E.F. Codd が提唱した関係モデルは、表と宣言的問い合わせでデータ独立性を高める理論として知られ始めていた。IBM 自身は System R などの研究を進めていたが、製品としての広く売られるリレーショナル DBMS はまだ市場を定義していなかった。エリソン（および Bob Miner、Ed Oates）は、この理論を企業の基幹処理に載せられる製品に変える余地を見た。
制約・常識
常識は「リレーショナルは研究・デモ向きで、本番のトランザクションや性能には向かない」だった。階層型製品は導入実績と運用ノウハウがあり、顧客もベンダーも既存スキーマとバッチ処理の延長で考える。
制約は資金と組織にもある。スタートアップは大規模 R&D 予算も、IBM 級の営業網も持たない。SQL 標準も未成熟で、互換性・性能・信頼性の証明責任は売り手側に偏る。「理論を実装した」だけでは調達担当は動かない、という市場の摩擦が残っていた。
非連続な一手
エリソンらは Codd の論文と公開情報を手がかりに、関係モデルに基づく DBMS を商用製品として出荷する道を取った。のちの Oracle となる製品は、研究機関の成果物の延長ではなく、企業顧客に売れるソフトウェアとして位置づけられた。
これは既存階層型の微改善でも、自社専用ファイル形式の連続改良でもない。データアクセスの単位を「手続きで辿るレコード」から「宣言的に問い合わせる関係」へ移し、不可能と見られがちだったリレーショナルの商用化を先に市場へ出した点が非連続である。大企業が理論を社内に閉じている間に、小さなチームが製品と価格と納期を顧客の前に置いた。
どう Resourcefulness が現れたか
Resourcefulness は、他人の理論（関係モデルと SQL 系の公開知）と、容赦のない営業・契約・製品化の実行力を融合し、ほぼゼロの資産から企業向け RDBMS 市場を一気に占めた点にある。理論の出典を自前で発明し直すのではなく、既にある知的資産を実装と差別化に変換した。
資金・人材・ブランドが薄い段階では、研究の完全性より「動く製品・売れる約束・導入の物語」に資源を寄せる。競合が研究・社内利用に留まっている時間差を、製品版と顧客接点で埋めた。結果として、後発の大企業製品が出る前に標準とマインドシェアを取りにいく構造になった。理論を借り、実行と市場接触で独占に近いポジションを積み上げたのが資源の使い方である。
積み重ね可能な目標との接続
「企業の基盤をデータ中心に変える」は、単一のアプリや単一顧客の導入では完結しない。データを関係として蓄積・問い合わせ・統合できる層が標準になると、業務アプリ・分析・のちの ERP/CRM が同じ基盤の上に積み上がる。
エピソードとしては、不可能とされたリレーショナル DB の商用化が、そのレールを企業 IT に敷いた局面として読める。理論と営業の融合で市場を占めた結果、データの中心性は特定のハードや部門ファイルではなく、共有可能な DB 層に移っていく。以降のエンタープライズ・ソフトウェアの拡張も、同じ目標への積み重ねとして位置づけられる。