ERP データベースの非正規化とソフトウェア開発への影響: トルトゥーガでの居酒屋の開店

こんにちは！ 私の名前はアンドレイ・セミノフ、スポーツマスター社のシニアアナリストです。 この投稿では、ERP システム データベースの非正規化の問題を取り上げたいと思います。 一般的な条件と具体的な例を見ていきます。それが海賊や船員のための素晴らしい独占酒場であるとします。 そこでは、海賊と船員には異なる対応が必要です。なぜなら、これらの善良な紳士たちの美に対する考え方や消費パターンが大きく異なるからです。

みんなを幸せにする方法は？ このようなシステムの設計と保守に混乱が生じるのを避けるにはどうすればよいでしょうか? いつもの海賊や船員だけではなく居酒屋に来始めたらどうすればいいですか？

すべてがカットの下にあります。 でも、順番に行きましょう。

1. 制限と仮定

上記はすべて、リレーショナル データベースにのみ適用されます。 変更、削除、および挿入の異常という形での非正規化の影響は、インターネットを含めて十分にカバーされていますが、考慮されていません。 この出版物の範囲外でも、パスポートのシリーズと番号、日付と時刻などの古典的な例では、非正規化が一般的な場所にあります。

この投稿では、数学用語を参照することなく、直観的で実際に適用可能な正規形の定義を使用しています。 実際のビジネスプロセス（BP）の検討や産業用ソフトウェアの設計に応用できる形で。

データ ウェアハウス、レポート ツール、および統合契約 (情報の表形式の表現を使用する) の設計は、使いやすさとそれを達成するための意識的な非正規化の使用が整合性よりも優先される可能性があるという点で、ERP システム データベースの設計とは異なると主張されています。保護データ。 私もこの意見に同意します。以下に説明する内容は、ERP システムのマスター データとトランザクション データ モデルにのみ適用されます。

標準形の説明は、ほとんどの読者にとって日常レベルで理解できる例を使用して行われます。 ただし、視覚的な説明として、パラグラフ 4 ～ 5 では、意図的に「架空の」タスクが意図的に使用されています。 これを行わずに教科書の例、たとえばポイント 2 の同じ順序ストレージ モデルを取ると、読者の焦点がプロセスの提案されたモデルへの分解から移ってしまう状況に陥る可能性があります。 IS にデータを保存するためのプロセスとモデルをどのように構築する必要があるかについての個人的な経験と認識に依存します。 言い換えれば、資格のある IT アナリストを XNUMX 人として、XNUMX 人は乗客を輸送する物流担当者にサービスを提供し、もう XNUMX 人はマイクロチップ製造用の機械を輸送する物流担当者にサービスを提供するとします。 自動化された BP について事前に議論することなく、鉄道旅行に関する情報を保存するためのデータ モデルを作成するように依頼します。

各アナリストは慣れ親しんだプロセスとタスクに依存するため、提案されたモデルでは、著しく異なる属性のセットだけでなく、異なるエンティティのセットも見つかる可能性がゼロではありません。 そしてそのような状況では、評価基準がないため、どのモデルが「正しい」かを言うことは不可能です。

2. 通常形

データベースの第一正規形 すべての属性の原子性が必要です。
特に、オブジェクト A に非キー属性 a および b があり、c=f(a,b) となり、オブジェクト A を記述するテーブルに属性 c の値が格納されている場合、データベースの第 XNUMX 正規形に違反します。 。 たとえば、注文仕様書が数量を示している場合、その測定単位は製品の種類によって異なります。ある場合には個数、別のリットル、個数で構成される XNUMX 番目のパッケージ (上記の Good_count_WR のモデル) である場合があります。の場合、データベース内で属性の原子性が違反されます。 この場合、注文仕様書のテーブル クラスターがどのようなものであるべきかを示すためには、IS での作業プロセスの対象を絞った記述が必要です。プロセスは異なる可能性があるため、多くの「正しい」バージョンが存在する可能性があります。

データベースの第 XNUMX 正規形 IS の作業プロセスに関連するエンティティごとに、最初のフォームと独自のテーブルに準拠する必要があります。 1 つのテーブルに依存関係 c=f2(a) および d=f3(b) があり、依存関係 c=fXNUMX(b) がない場合、そのテーブルでは第 XNUMX 正規形に違反します。 上の例では、Order テーブル内の順序とアドレスの間に依存関係はありません。 通りや都市の名前を変更しても、注文の重要な属性には影響しません。

第 XNUMX 正規形データベース 第 4 正規形に準拠し、異なるエンティティの属性間に機能の依存関係がないことが必要です。 このルールは次のように定式化できます。「計算できるものはすべて計算する必要がある」。 つまり、XNUMX つのオブジェクト A と B がある場合、オブジェクト A の属性を格納するテーブルでは、属性 C が明示され、オブジェクト B は属性 b を持ち、c=fXNUMX(b) が存在するため、第 XNUMX 正規形が存在します。違反されています。 以下の例では、注文レコードの数量属性 (Total_count_WR) が明らかに第 XNUMX 正規形に違反していると主張しています。

3. 正規化を適用する私のアプローチ

1. データ ストレージ モデルの作成時に、エンティティと属性を識別するための基準をアナリストに提供できるのは、ターゲットの自動化されたビジネス プロセスだけです。 プロセス モデルの作成は、通常のデータ モデルを作成するための前提条件です。

2. 次の条件の一部またはすべてが満たされる場合、厳密な意味での第 XNUMX 正規形の実現は、ERP システムを作成する実際の実践では現実的ではない可能性があります。

• 自動化されたプロセスが変更されることはほとんどありません。
• 研究開発の期限は迫っており、
• データの整合性に対する要件は比較的低い (産業用ソフトウェアの潜在的なエラーは、ソフトウェア顧客の金銭や顧客の損失につながることはありません)
• 等

記載された条件下では、一部のオブジェクトとその属性のライフサイクルを特定して記述するコストは、経済効率の観点からは正当化されない可能性があります。

3. すでに作成された IS 内のデータ モデルの非正規化による影響は、コードとテストの徹底的な予備調査によって軽減できます。

4. 非正規化とは、人件費をデータソースの調査や業務プロセスの設計段階から開発段階、つまり実装期からシステム開発期に移管する方法です。

5. 次の場合には、データベースの第 XNUMX 正規形を追求することをお勧めします。

• 自動化されたビジネスプロセスの変化の方向性を予測するのは難しい
• 実装チームや開発チーム内での役割分担が弱い
• 集積回路に含まれるシステムは独自の計画に従って開発されます
• データの不整合により、企業は顧客や資金を失う可能性があります

6. データモデルの設計は、対象となるビジネスプロセスとIS内のプロセスのモデルに関連してのみアナリストが実施する必要があります。 開発者がデータ モデルを設計している場合、特に、アトミックな属性を分離するための必要条件である属性値の違いを理解できる程度まで対象領域に没頭する必要があります。 したがって、珍しい機能を引き受けます。

4 説明のための問題

港に小さなロボット居酒屋があるとします。 あなたの市場セグメント: 港に来て休憩が必要な船員や海賊。 船員にはタイム入りのお茶を、海賊にはひげをとかすためのラム酒と骨の櫛を販売しています。 居酒屋自体のサービスはロボットのホステスとロボットのバーテンダーによって提供されます。 高品質と低価格のおかげで、競合他社を駆逐し、港に唯一あるあなたの居酒屋には、船から降りてくる人が皆集まってきます。

居酒屋情報システム複合体は以下のソフトウェアで構成されています。

• 特徴に基づいてクライアントのカテゴリを認識する、クライアントに関する早期警告システム
• ロボットホステス・ロボットバーテンダー向け制御システム
• 倉庫および販売時点までの配送管理システム
• サプライヤー関係管理システム (SURP)

プロセス：

早期警報システムは船から降りる人を認識します。 ある人がきれいにひげを剃っていれば、彼女はその人を船員であると特定し、その人がひげを生やしていることが判明した場合、その人は海賊であると特定します。

居酒屋に入ると、ゲストは自分のカテゴリーに応じたロボットのホステスからの挨拶を聞きます。たとえば、「ホーホーホー、親愛なる海賊よ、テーブル番号に行ってください...」

ゲストは指定されたテーブルに行きます。そこではロボットバーテンダーがカテゴリーに応じた商品をすでに準備しています。 ロボット バーテンダーは、次の配達部分を増やす必要があるという情報を倉庫システムに送信し、倉庫 IS は保管庫内の残高に基づいて、管理システムに購入リクエストを生成します。

早期警告システムは社内の IT 部門によって開発された可能性がありますが、バー ロボット管理プログラムは外部請負業者によって特別にあなたのビジネスのために作成された可能性があります。 また、倉庫やサプライヤーとの関係を管理するシステムは、市場からカスタマイズされたパッケージ ソリューションです。

5. 非正規化の例とソフトウェア開発への影響

ビジネスプロセスを設計する際、インタビューした対象分野の専門家は、世界中の海賊がラム酒を飲み、骨の櫛でひげをとかし、船員はタイム入りのお茶を飲み、いつもきれいに剃っていると口を揃えて述べた。

クライアント タイプのディレクトリが 1 つの値とともに表示されます: 2 - 海賊、XNUMX - 船員。会社の情報回路全体に共通です。

クライアント通知システムは、画像処理の結果を、認識されたクライアントの識別子 (ID) とそのタイプ (船員または海賊) として直ちに保存します。

認識されたオブジェクトID
クライアントカテゴリ

100500
海賊

100501
海賊

100502
船乗り

もう一度注意しましょう

1. 私たちの船員は実は坊主です
2. 私たちの海賊は実際にはひげを生やした人々です

この場合の構造が第 XNUMX 正規形を目指すためには、どのような問題を取り除く必要があるか:

• 属性の原子性違反 - クライアント カテゴリ
• 分析された事実と結論を XNUMX つの表にまとめる
• 異なるエンティティの属性間の固定機能関係。

正規化された形式では、XNUMX つのテーブルが得られます。

• 確立された特徴のセットの形での認識結果、

認識されたオブジェクトID
顔の毛

100500
はい

100501
はい

100502
ノー

• 確立された特性を解釈するために IS に組み込まれたロジックを適用してクライアントのタイプを決定した結果

認識されたオブジェクトID
識別ID
クライアントカテゴリ

100500
100001
海賊

100501
100002
海賊

100502
100003
船乗り

正規化されたデータ ストレージ組織は、どのようにして IP コンプレックスの開発を促進できるでしょうか? 突然新しい顧客を獲得したとします。 ひげはないかもしれないが、オウムを肩に乗せて歩く日本の海賊、そして環境活動家の海賊は、グレタさんの左胸の青い横顔で簡単に識別できます。

環境侵害者は当然のことながら、骨の櫛を使用することはできず、リサイクルされた海洋プラスチックから作られた類似品を要求します。

新しい入力に従ってプログラムのアルゴリズムを作り直す必要があります。 正規化ルールに従った場合は、一部のシステムの一部のプロセス ブランチの入力を補足し、顔の毛が問題になるケースおよび IS にのみ新しいブランチを作成するだけで済みます。 ただし、ルールが守られていないため、クライアント タイプ ディレクトリの値が使用されている回路全体のコード全体を分析し、ある場合にはアルゴリズムが専門家の意見を考慮する必要があることを明確に確立する必要があります。クライアントの活動やその他の物理的特徴。

という形で シークする 正規化すると、運用データを含む XNUMX つのテーブルと XNUMX つのディレクトリが得られます。

• 確立された特徴のセットの形での認識結果、

認識されたオブジェクトID
左胸にはグレタさん
肩に鳥が乗っている
顔の毛

100510
1
1
1

100511
0
0
1

100512

1
0

• クライアントの種類を決定した結果 (ディレクトリからの説明が表示されるカスタム ビューとする)

検出された非正規化は、新しい条件を満たすようにシステムを変更できないことを意味しますか? もちろん違います。 すべての情報システムが 1,5 つのチームによってスタッフの離職率ゼロで作成され、開発が十分に文書化され、情報が損失なくチーム内に転送されると想像すると、必要な変更は無視できるほど少ない労力で行うことができます。 しかし、問題の元の状況に戻ると、共同協議の議定書を印刷するためだけに 0,5 台のキーボードが消去され、調達手続きを処理するためにさらに XNUMX 台のキーボードが消去されることになります。

上の例では、XNUMX つの正規形がすべて違反されています。これらを個別に違反してみます。

第一正規形の違反:

居酒屋に所属する 1.5 トンのガゼル XNUMX 匹を使用して、商品がサプライヤーの倉庫から倉庫に配送されるとします。 ご注文のサイズはサプライヤーの売上高に比べて非常に小さいため、生産を待つことなく常に XNUMX 対 XNUMX で完了します。 このようなビジネス プロセスには別のテーブルが必要ですか: 車両、車両の種類、撤退したサプライヤーへの注文において計画と事実を分離する必要がありますか?

以下のモデルを使用してプログラムを開発する場合、プログラマーがどれだけの「追加」接続を作成する必要があるか想像してみてください。

提案された構造が不必要に複雑であると判断したとします。この場合、注文レコード内の計画と事実の分離は冗長な情報であり、生成された注文仕様は、入荷した商品の受け入れ結果に基づいて書き換えられます。 - 品質が不十分な商品のグレーディングおよび到着は、IS の外で決済されます。
そしてある日、居酒屋のホール全体が憤慨した不細工な海賊たちで満たされていることに気づきました。 どうしたの？

ビジネスが成長するにつれて、消費も増加したことがわかりました。 かつて、ガゼルの体積や重量が過積載になった場合（これは非常にまれですが）、サプライヤーは飲み物を優先して荷物を優先するという経営判断が下されました。

未配達の商品は最終的に次の注文となり、新たな便で出発しましたが、居酒屋の倉庫には最低限の残高があったため、商品の不足に気付かずに済んだのです。

最後の競技者が港で閉店し、ガゼルの過積載によるパンクのケースは、車両の最低限のバランスが十分であるという仮定に基づく優先順位付けと車両の定期的な不足積載によって回避されることが一般的になりました。 作成されたシステムは、理想的には、組み込まれたアルゴリズムに従って機能し、計画された注文を履行するための組織的な失敗を追跡する機会が奪われます。 評判が損なわれ、顧客が不満を抱いている場合のみ、問題を検出できます。

注意深い読者は、セクション 2 とセクション 5 の注文仕様 (T_ORDER_SPEC) の注文数量が、第 XNUMX 正規形の要件を満たしている場合と満たしていない場合があることに気づいたかもしれません。 すべては、選択された商品の品揃えを考慮して、本質的に異なる測定単位が同じ分野に分類されるかどうかによって決まります。

第 XNUMX 正規形の違反:

ニーズが高まると、さまざまなサイズの車両をさらに数台購入します。 上記の文脈では、車両ディレクトリの作成は冗長であると考えられ、その結果、配送と倉庫のニーズに対応するすべてのデータ処理アルゴリズムは、サプライヤーから倉庫までの貨物の移動を 1,5 トンの車両のみの飛行として認識します。ガゼル。 そのため、新しい車両を購入する際にも車両ディレクトリを作成しますが、それを完成させる際には、貨物の移動を参照するすべてのコードを分析して、それぞれの特定の場所で特性への参照が暗示されているかどうかを確認する必要があります。ビジネスが始まったまさにその乗り物。

第 XNUMX 正規形の違反:

ロイヤルティ プログラムの作成を開始すると、ある時点で常連顧客のレコードが表示されます。 たとえば、ロイヤルティ プログラムの開始時に、顧客が興味を持っているすべての情報を顧客の記録に記録できるのであれば、レポート作成や分析システムへの転送に使用するために、個々の顧客への売上に関する集計データを保存するマテリアル ビューの作成に時間を費やす必要はありません。 ? そして確かに、一見しただけでは意味がありません。 しかし、新しい販売チャネルなど、ビジネスがつながるたびに、アナリストの中にはそのような集計属性が存在することを覚えている人がいるはずです。

たとえば、インターネットでの販売、共通のロイヤルティ システムに接続された販売代理店を通じた販売など、それぞれの新しいプロセスを設計するときは、すべての新しいプロセスがコード レベルでデータの整合性を確保する必要があることを念頭に置く必要があります。 XNUMX のテーブルを持つ産業用データベースの場合、これは不可能な作業のように思えます。

もちろん、経験豊富な開発者は上記の問題をすべて阻止する方法を知っていますが、私の意見では、経験豊富なアナリストの仕事は問題を明らかにすることではありません。

この出版物の準備中に貴重なフィードバックをくださった主要な開発者 Evgeniy Yarukhin に感謝の意を表したいと思います。

文学

https://habr.com/en/post/254773/
コノリー・トーマス、ベッグ・キャロライン。 データベース。 設計、実装、サポート。 理論と実践

出所： habr.com