データベースの世界では、正規化があります。設計から始めて、段階を踏んで、最終的には通常の形式のデータベースにたどり着くことができます。これは、データのセマンティクスに基づいて行われ、一連の設計リファクタリングと考えることができます。
オブジェクト指向設計では、SOLID 原則と、優れた設計に向けたさまざまなアドホック ガイドラインがあります。
一連のリファクタリング手順により、手続き型のコード (または不十分にファクタリングされた OO 設計) を正しい (明確に定義された意味で) 式に移行できるように、OO の正規形に相当するものを定義することは可能だと思いますか?同じ機能？
(注: このコミュニティ wiki を作成できて光栄です)
可能性はありますが、可能性は非常に低いです。
環境
まず、リレーショナル モデルが登場した当時、IT 部門で働く人々はより教育を受け、標準を尊重していました。コンピュータ リソースは高価であり、人々は常にそれらのリソースを使用する最善の方法を探していました。Codd や Date のような人々は、人々がハイテクである業界の巨人でした。
Codd は正規化を発明したのではなく、リレーショナルが登場するずっと前から、非リレーショナル データベースを正規化していました。正規化は理論と実践であり、完全正規化の原則として公開されています。私たちはプログラムを正規化していましたが、サブルーチン (メソッド) の偶発的な重複は重大なエラーであると考えていました。今日では、それは「何も複製しない」または「繰り返さない」として知られていますが、最近のバージョンでは、背後にある健全な学術理論が認められていないため、その力は実現されていません。
Codd が (多くのことの中で) 行ったことは、リレーショナル データベース専用の正式な正規形を定義することでした。そして、これらはそれ以来進歩し、洗練されてきました。しかし、彼らはまた、彼らのギアを売る目的で非学者によって乗っ取られました.
Codd と Chen によって考案され、Brown によって完成されたデータベース モデリングには、確固たる基盤がありました。過去 25 年間で、その標準化を達成し、確固たる基盤を持つ他の多くの人々によってさらに洗練され、進歩してきました。
〇〇以前の世界
オブジェクト指向以前のプログラミングの世界を見てみましょう。プログラムのモデリングや、言語およびプラットフォーム固有の実装のために、多くの標準と規則がありました。あなたの質問は、当時はまったく当てはまりませんでした。業界全体が、データベース設計とプログラム設計が 2 つの異なる科学であることを深く理解しており、それらには異なるモデリング方法論と、適用される標準が何であれ使用されていました。人々は、標準を実装しているかどうかについては議論しませんでした。標準にどの程度準拠しているかについて議論しました。彼らは、データとプログラムをモデル化したかどうかについては議論しませんでした。データとプログラムをモデル化した程度について議論しました。それが、特に 1969 年に人類を月に送った方法です。
OOの夜明け
オブジェクト指向が登場し、それ以前に他のプログラミング言語や設計方法論が存在しなかったかのように現れました。既存の方法論を使用して拡張または変更する代わりに、その存在を否定しました。したがって、当然のことながら、新しい方法論をゼロから策定し、成熟していない SOLID とアジャイルのポイントにまでゆっくりと前進させるのに 20 年かかりました。あなたの質問の理由。その間、20 以上のそのような方法論が爆発し、消滅したことは明らかです。
完全な勝者になる可能性があり、あらゆるプログラミング言語に適用可能なUMLでさえ、同じ病気に苦しんでいました. 成熟した方法論が存在することを否定しながら、それはすべての人にとってすべてになろうとしました。
業界の終焉
MS の出現により、「誰でも何でもできる」(意味: 正式な教育や資格は必要ない) という姿勢、つまり専門職としての質と誇りが失われました。人々は今、あたかも地球上で誰もそれをやったことがないかのように、ゼロから物事を発明しています。今日の IT 業界は非常にローテクです。しかし、これらのページを読んでいるほとんどの人は、リレーショナル モデリングの方法論と標準が 1 つずつあることを知りません。彼らはモデルではなく、道具です。その後、再実装します。そして再実装。あなたが言うようにリファクタリング。
オブジェクト指向の支持者
問題は、これらの OO メソッドを思いついた人々が専門家の巨人ではなかったことです。彼らは単に非学問的なロットの中で最も声高だった. 仲間の承認によるものではなく、本を出版したことで有名です。 未熟で無知。ツールキットには1 つのハンマーがあり、すべての問題は釘のように見えました。彼らは正式な教育を受けていなかったので、実際にはデータベース設計とプログラム設計が 2 つの異なる科学であることを知りませんでした。そのデータベース設計は非常に成熟しており、強力に確立された方法論と標準があり、データベースを含むすべての問題にピカピカの新しいハンマーを適用するだけでした.
したがって、彼らはプログラミング方法論とデータベース方法論の両方を無視し、車輪をゼロから発明していたため、これらの新しい方法論の進歩は非常に遅かった. そして、健全な学問的根拠なしに、同様の群衆からの支援を受けて。
今日のプログラムには、使用されていないメソッドが何百もあります。現在、それを検出するプログラムがあります。一方、成熟した方法論では、それを防ぎます。シン クライアントは達成すべき目標ではありませんでした。私たちにはそれを生み出す科学がありました。これで、「汚れた」データを検出して「きれいにする」プログラムができました。一方、データベース市場の上位層では、そもそも「ダーティ」データをデータベースに入れることはできません。
データベースの設計を一連のリファクタリングと見なしていることを認めます。あなたの言いたいことは理解できます。私にとって、リファクタリングの必要をなくすのは科学 (方法論、標準) です。リファクタリングの受け入れでさえ、古いプログラミング方法論が知られていないという大きなシグナルです。現在の OO 方法論は未熟です。オブジェクト指向の人たちと一緒に仕事をするのが面倒なのは、方法論自体がワンハンマーの考え方に自信を持たせてしまう危険性です。システムが壊れると、システム全体が壊れます。修理または交換できる小さな部品ではありません。
スコット・アンブラーとアジャイルを例にとってみましょう。Ambler は、正規化に反対して、データベース業界の巨人たちと 20 年間公然と声高に議論してきました。現在、彼はアジャイルを持っていますが、それは未熟ではありますが、有望です。しかし、その背後にある秘密はノーマライゼーションです。彼はトラックを切り替えました。そして、彼の過去の戦争のために、彼はそれを正直に宣言したり、他の人に正当な信用を与えたりすることができませんでした。
予後
過去 20 年間に OO の世界で証明された小さな進歩を考慮して、私が言うのはそのためです。失敗した 20 ほどの OO 方法論。アプローチが浅いため、現在の OO 方法論が (単一の) データベース設計方法論の成熟と受け入れを達成する可能性はほとんどありません。少なくともあと 10 年、多くの場合は 20 年かかり、OO の代わりに引き継がれるでしょう。
それが可能であるためには、2つのことが起こる必要があります:
オブジェクト指向の支持者は、正式な高等教育を必要としています。プログラミング科学の優れた基礎。確かに、誰でも何でもできますが、素晴らしいことを行うには、優れた基盤が必要です。これにより、リファクタリングは不要であり、科学によって排除できるという理解につながります。
彼らは、他のプログラミング手法や標準に対する否定を打破する必要があります。これにより、その上に OO を構築するか、その基礎を取得して OO にマージするかのいずれかへの扉が開かれます。これにより、堅固で完全な OO 方法論が生まれます。
リアルワールドOO
明らかに私は経験から話します。大規模なプロジェクトでは、成熟した分析と設計の方法論を使用します。1 つはデータベース用、もう 1 つは機能用です。コードカットの段階になると、オブジェクト指向チームが好きなものを好きなように使用できるようにします。オブジェクトは通常、UML を意味します。アーキテクチャ、構造、パフォーマンス、ブロートウェア、One Hammer、何百もの未使用オブジェクトに問題はありません。これらはすべて OO の外部で処理されているためです。その後、UAT 中にバグの原因を見つけたり、必要な変更を迅速に行ったりすることに問題はありません。これは、構造全体が文書化されているためです。ブロックは変更可能です。
私はパウロに完全に同意するだけでなく、さらに一歩進んでいきます。
モデルはまさにそれです-モデルだけです。リレーショナルデータベースで使用される正規化モデルは、データを保存および管理するための1つのアプローチにすぎません。実際、RDBMSはデータ操作操作（標準のCRUD）で一般的ですが、統合、分析、およびレポート用にDataWarehouseを進化させたことに注意してください。そして、それは間違いなくDMLランドに見られる正規化モデルに準拠していません。
これで、BigTableアーキテクチャを備えたGoogleと、Hadoopを備えたApacheも利用できるようになりました。これらの新しいモデリングシステムは、DISTRIBUTEDデータベースのアイデアによって推進された景観の変化を反映しています。このクラブにも正規化を適用する必要はありません。
成功したモデルは、成功しなくなった時点、または設計者のニーズにより適したモデルに取って代わられるまで適用できます。私たち人間が物理学/天文学を通して私たちの宇宙をモデル化した多くの方法に注意してください。目立たない言葉でシステムを説明するためのattmptsのモデリングですが、システムまたはシステムのニーズが変化するにつれて、モデルも変化する必要があります。
OOPは、コンピューターアプリケーションをモデル化するための非常に成功した方法です。ただし、アプリケーション設計者のニーズは、データベース設計者のニーズとは異なります。ほとんどの場合、アプリケーションの設計者は、自分のプログラムが人間によって相互作用されることを考慮しなければならない時点があります。データベース設計者とは異なり、その作業は（ほとんど）他のコードと相互作用することが期待されますが、プログラマーの仕事は、マシンを取得して、はるかにランダムな人間がアクセスできるようにすることです。この芸術は、正規化のような標準にあまりうまく対応していません。
とはいえ、n層、MVC、MVVC、およびその他のパラダイムは、いくつかのガイドラインを確立します。しかし、結局のところ、アプリケーション設計の問題空間は、通常、リレーショナルデータベースのような離散モデリングステップに適合させるのは簡単ではありません。
わお。長さについてお詫び申し上げます。これがここでのエチケット違反である場合は、私に知らせてください。。。
これは興味深い質問だと思います。なぜなら、Codd の標準形が実際には「正しい」設計の定義であると仮定しているからです。そのステートメントでフレーム戦争を開始しようとしているわけではありませんが、私のポイントは、多くのDBが完全に正規化されていない非常に正当な理由があるということだと思います(結合パフォーマンスなど)。スペースはおそらくデザインパターンまたは（あなたが言ったように）SOLIDです。どちらの場合も、ドグマとして奴隷的に従うのではなく、適切に批判的な目で適用する必要がある理想化されたガイドラインについて話している.