データベース構造のチーム開発の組織

最近、Oracleデータベースのデータスキームのチーム開発（約10人）の問題が、私たちの組織で非常に緊急になっています。 3.5.xファミリーの有名なErwin製品で昔ながらの方法で作業しましたが、当面はファイルを集中バージョン管理システムに配置し、必要に応じてブロックすることでその機能に完全に満足し、並行開発の衝突を回避しました。 しかし、すべてが流れ、すべてが変化し、チームが成長し、21世紀は庭にあるので、より現代的な手段を使用することにしました。 実際、以下はスキームを新しいフォーマットに移行するプロセスについての話です（同じメーカーですが）、集合的な開発とバージョン管理のサポートのためのツールの編成は、製品全体に関する議論と特に私たちの仕事でそれを使用するパターンで薄められています。 説明されたプロセスには落とし穴がなかったわけではないので、そのような移行の経験は誰かに役立つでしょう。

物語の計画：

• 製品に関する議論、使用パターンのトピックに関するコメント、フォーマットの乱用。
• 準備作業、データベース内のシャーマニズム。
• チーム開発の組織、パフォーマンスの最適化。

製品に関する議論、使用パターンのトピックに関するコメント、フォーマットの乱用

データベーススキーマの順序を維持することは重要です。特に、実際の開発が行われている場合、テーブルの数とそれらの関係が増大し、構造の階層全体を覚えている人はいません。 これは誰にとっても明らかであり、Oracle向けの開発を開始したときは明らかでした。 それは長年の出来事であり、お気に入りは当時のプラチナ企業のErwin 3.5.2と呼ばれる設計ツールでした。 このツールは、大学のデータベース専門家およびデータベース開発者のコ​​ースで研究されました（ところで、まだ研究されています-知人からの学生によって認識されました）。 ある程度の人気を得ているのはこのバージョンです。 Windows'98と同年齢であるため、非常に効率的で、適切なサイズスキームに対応し、マクロのおかげで柔軟に構成され、最新バージョンのOracle用の正しいスクリプトを生成しますが、バージョン8専用に設計されていますが、データベースからのリバースエンジニアリングにも対応しています。 最近まで使用していましたが、特別な失敗はありませんでした。 ただし、欠点もあります。 第一に、何らかの理由で、彼はネットワークプリンターにまったく馴染みがありません。 ネットワークプリンターがデフォルトプリンターとして構成されている場合、回路の初期読み込みは非常に遅くなります。プリンターがマシンに直接接続されている場合、または仮想プリンターが使用される場合、同じ回路の読み込みははるかに速くなります。 第二に、私が言ったように、それはOracle 8で動作するように設計されており（データベースの選択はそれほど大きくなく、MySQLまたはPostgreeは原則的にはありません）、したがって、パーティションを使用するなど、新しいバージョンのテーブル構造の微調整は不可能です。 第三に、チーム開発のサポートを構成できませんでした。 ModelMartのサポートは既にこのバージョンにありますが、一度に面倒な人はいませんでした（チーム自体は2人でした）が、後で個別の製品としては見つかりませんでした。 繰り返しますが、ModelMartツールの機能（現在はModel Managerと呼ばれています）は、データベースに回路を保存することです。 この製品の古いバージョンがデータベースの新しいバージョンとどのように友であるかは別の質問です。 残りの欠点は定義されていませんが、もちろんそれらは時々現れ、非常に迷惑です（たとえば、名前によるサブモデルの検索は最初の文字と最初の出現によってのみ可能です。サブモデルに追加するテーブルの検索は物理レベルの名前によってのみ可能ですが、レポートでは、生成される論理レベルのみが表示される場合があります。権利の制限は、回路ファイルへのアクセスのレベルでのみ可能です;グリッド上のオブジェクトと他のニュアンスの配置はありません）。



あるターニングポイントが来ました。そして、最新バージョンのアーウィンに切り替える必要性が確実にありました。 経営陣は製品の購入にも同意しましたが、それ自体では古いバージョンは販売されていません。 しかし、移行の重要な条件は、すべての古い開発をサポートする必要があることです。 古い開発-これは、データスキーム全体を含む1つのファイルです（約20 MBおよび7年間の開発）。 構造のモデリングには常に純粋にErwinを使用しましたが、作業の論理はそこまで行きません。 したがって、プログラムから生成されたスクリプトを使用してベースをゼロから展開することは、タスクの価値がありません。新しいインスタンス、構造、ロジック、およびすべての技術設定を含む参照ベースを展開します。 ロジックを維持すると、バージョンの更新の問題ははるかに早く現れます。これは、8番目のバージョンのpl / sqlと10のpl / sqlが大きく異なるためです。 その結果、瞬間を遅らせることができました。 構造と関係のみに関心があるため、さまざまな「ガベージ」からダイアグラムをクリーンアップします（リバースエンジニアリングを使用する場合、テーブルに関連付けられたトリガーはダイアグラムに分類され、Entity Reports-> Entity / Trigger options reportで簡単に見つけることができます）、開発者のWebサイトからトライアルをダウンロードしますバージョン7.3は「試用中」であり、スキームが新しい形式で開くことを期待しています（実際、もちろん、誰も簡単だとは思っていませんでした）。 しかし、いいえ、7番目のバージョンには3番目のバージョンのER1形式は表示されません。



フォーマットについて議論する時が来ました。 Erwin 3.5.xは、単一の.ER1ファイル（およびバックアップ.BK1）に回路を保存します。 これは、表示用に開くと閉じたバイナリ形式です。よく知られた文字がありますが、それ以上はありません。 Erwin Data Modelerの7番目のバージョンは特定の形式.ER1を理解しますが、これは3番目ではなく4番目のバージョンの形式であることに注意してください。 これはおそらく、プラチナ製品がComputer Associates（または現在正式に指定されているCA）によって買われ過ぎたのが4番目のバージョンからであったという事実によって引き起こされます。 Erwin 4.1.xは公式には配布されておらず、試用版が見つからない（さらには購入されていない）ため、このトリックに行かなければなりません。 ですから、明確な良心をもって、海賊版をダウンロードできる場所からダウンロードしてください。 一般に、このような有名で高価な製品に対して、CAがバージョン形式間で変換するユーティリティを提供しなかったことは奇妙です。 再変換は、メモリを開いた直後に発生します。 最初、ファイルは約20 MBかかり、変換には数分かかりました。 この操作の後、ファイルの重量が60 Mbになり始めました。 ただし、敬意を払う必要があります。この場合の読み込みは、3番目のバージョンよりも速いようです。

準備作業、データベース内のシャーマニズム

次に、Erwin Data Modeler 7.3（Erwin Model Navigation 7.3にバンドル）をインストールしてから、Erwin Model Manager 7.3を個別にインストールします。 インストール自体は問題を引き起こしませんが、ModelMartを最初に起動する前に、erwinスキームのすべてのオブジェクトが保存されるデータベースを構成する必要があります。 CA社がこれを担当し、配布キットには2つのガイドがあります-実装ガイドに興味があります（2つ目は、管理者ガイドは特に興味深いものではありません）。 モデルを格納するためのテーブルスペース、インデックステーブルスペース、モデルをインストールするユーザーのロール、モデル管理者ユーザー（このユーザーにはインストールロールも指定できます）およびロールModel Managerのユーザーの場合（ところで、これらのユーザーにdbaを与え​​ることを忘れないでください）。 実際、Model Managerの管理部分を最初に起動すると、管理者としてログインし、データとインデックス用のテーブルスペースを指定し、プログラムが作業に必要なテーブルとプロシージャを作成するのを待つ必要があります。 初期化に問題はありませんが、必要に応じて、作成された設定を削除します（すぐに動作するバージョンではありません）。エラーが発生し、グリッチが発生しました。その後、エラーメッセージでModel Managerに接続できません（同じナンセンスがライセンスが更新されようとしています-モデルが既に試用版で作成されている場合は、試用版から機能します。 次のように扱われました-モデル管理者のすべてのユーザーオブジェクトを削除し、SQL NavigatorでMMartInit.oraスクリプトをプログラムフォルダーから実行し、エラー無視モードで実行しました。 このスクリプトで何かが発生し、何かが欠落していますが、モデルマネージャー管理コンソールを起動した後、プログラムは少なくともデータベースに接続でき、何かがあると言っていると報告しましたが、破損しており、復元できます。 私の側で確認した後、テーブル構造が新たに再作成され、すべてが機能しました。 現時点ではCAを非難する必要があります。当然、このような高価な製品を購入する前に、完全な機能を備えた試用版がメーカーから直接入手できるため、組織はビジネスプロセス全体を事前にテストしたいと考えています。 そしてもちろん、すべてを構成してテストした後、フル機能のライセンスを更新するプロセスで問題が発生することはありません。



仕事の拠点の選択について、いくつかの言葉を言う必要があります。 新しいモデルを作成することをお勧めします。大規模なモデルではインデックスが大きくなり、モデル自体を管理する操作は非常にリソースを消費するためです。 したがって、最も重要なのは、モデルをライブラリから削除することです。 一般に、Model Manager以外の追加の負荷を持つデータベースインスタンスを使用しますが、もちろんこれは運用サーバーではありません。



これで、すべてのプリセットが完了しました。 次のステップは、回線を7.xバージョンに転送することです。 このプロセスは驚くほど非常に長く、RAMを非常に要求します。 ただし、夜通し仕事を辞めるだけでも失敗します。 Erwinは定期的に作業結果を報告し、あらゆる種類のささいなことを要求します（たとえば、古いスキームはOracle 8で機能し、新しいスキームはOracle 10/11をサポートしているため、プログラムからの避けられない質問は「新しいものに移行しますか、それとも他のものを選択しますか？」など）そのような）。 だから、我慢してください。 作業の結果、検出されたエラーのログファイルが回路で生成されました（私はそれらの多くは持っていませんでした-いくつかの複製オブジェクトと無効な外部キーは、変換後に簡単に修復されます）。 新鮮なアーウィンは検証を非常に真剣に受け止めていることに注意する必要があります-彼は以前のバージョンでは気づかなかった「varchar（50）（型定義の閉じ括弧の欠如）」の精神でさまざまなジャムを見つけました。最終的なスキームは拡張子.erwinを引き継ぎ、サイズが大きくなりました112 Mb。最終的な増加は初期サイズの約6倍であり、このビジネスは平均速度でロードされ、もちろん高速ではありませんが、非常に遅くはありません。

チーム開発の編成、パフォーマンスの最適化

次に、すべてのために、大体、データベース内のストレージにスキームを転送し、チームワークを編成することから始めました。 これを行うには、Erwinでスキーマファイルを開いて、adminユーザーでモデルマネージャーに接続し、[モデルの保存]アイテムを選択します。 モデルライブラリの階層スキームでオブジェクトの場所を選択すると、そのスキームがデータベースにロードされます。 繰り返しますが、すべてが予測可能です-プロセスは高速ではありません。 しかし、遅かれ早かれ、それは実行され、今や私たちのスキームはすでにデータベースに保存されており、チーム開発の準備ができています。 ただし、作成されたモデルから最初にサブモデルを開こうとすると（最初にモデルの作成元のファイルを閉じることを忘れずに、そうしないと機能しません）、30分間フリーズします。これは確かにオプションではありません。 データベースに接続し、モデル管理者のスキームを確認します（マニュアルのように、EADMINとしましょう）。 テーブルは作成され、インデックスは作成されますが、テーブルの統計は収集されません。 その結果、DBMS_STATS.GATHER_SCHEMA_STATS（「EADMIN」）。 次に、テーブルを扱います。 実際には、m7objectとm7objectpropertyの2つが最大です。 名前が示すように、最初はオブジェクト（実際にはすべてのエンティティ、テーブル、サブモデルを階層順に格納します）、2番目はプロパティです。 プロパティテーブルのデータを見ると、stringvalueフィールドに「以前のバージョンのERwinからインポートされました」という値のエントリがかなりありました。 丁寧にクリーニングすることはできますが、サイズは何度も縮小されることはありませんが、それでもです。



元のスキームは多くのサブサーキット（3番目のバージョンの表記の対象領域）に分割され、各サブサーキットは理論的には独立して開くことができました。 ただし、今回は回線レベルでのみブロッキングが可能です。 変更をリポジトリに保存してマージするとき、スキーム全体をロードする必要があります。これらは2つです。 そして最後に、回路全体を開くには、別のサブ回路を開くよりも多くの時間（および少し多くのメモリ）がかかります。これらは3つです。 そのため、別のサブサーキットで作業する能力をすぐに忘れることができます。 合計で、約700 mbのRAMがロードされた回路によって占有されています。 これまでのところ、すべてが暗いです。 ただし、可能性は確かに優れています-ここでは、リポジトリとの詳細なマージ、保存されたバージョン間のロールバック、データベースとのハワードエンジニアリングとリバースエンジニアリング、別のスキームまたはファイルを使用して、すべての比較とスクリプト生成設定をスキームに直接保存するなどを見つけることができます。



1つのマイナスは作業速度です。 基本および設定に関するすべての不正は、プロセスをわずかにスピードアップすることのみを許可しました。 彼らはデータベースでの作業を監視しました-すべてのクエリはプリミティブですが（わずかに非論理的ですが）、テーブル自体は大きいです。 問題の目に見える仮説を特定するために、ロシアの公式販売代理店にアドバイスを求めました。 その結果、古いモデルをErwinに転送する際のパフォーマンスの問題に対するユニバーサルソリューションの新しいバージョンはないという回答を受け取りました。 その結果、優れた機能と低いパフォーマンスの岐路に立たされている間、苦労し続けていますが、競合他社の製品をすでに検討しています。