2012-06-19 7 views
9

私の質問はちょっと変わって見えるかもしれませんが、私はあなたのほとんどがこの段階を経てきたと確信しています。既に開発されたデータベースを理解するには?

私は現在、FoxProからSQL Serverへのデータベース移行プロジェクトを行っています。移行されているDBは膨大で、このプロジェクトでは新しくなっています。そのようなデータベースを理解する簡単な方法はありますか?どのようにテーブルが関連し、どのようにモデル化されたかのように。このDBには適切な文書がありません。

私はそれがどのように構築されているかを理解することで、新しいクエリ/ストアドprocsを書くのがはるかに簡単になると思います。ショートカットを知りたいだけの方には興味があります。

ありがとうございました。

+0

データベースダイアグラムツールを使用しようとしましたか?通常、これらのツールはデータベース構造を視覚的に表しますが、これは理解しやすいものです。 SQLサーバーは、FoxProについてよく分からないかなり良いデータベースの図式作成ツールを持っています – DSharper

+0

いいえ、簡単な方法はありません。アプリケーションを実行して何が起こったのかを登録し、コードを調べて、テーブルがどのように使用されているかを調べる必要があります。 –

+0

フリーテーブルまたはデータベースコンテナ? – canon

答えて

13

私は、これらの大規模な文書化されていないデータモデルに着目し、それらを理解しようとしていることから、私は自分のキャリアを作ったので、ここでは答えが見つからないことを実際に期待しています。しかし、それは価値がある:

  • 私は自動化されたデータモデラー/電子モデラーが嫌いですが、これは個人的な意見かもしれません。私の好みは、ホワイトボード(または紙)を見つけて手でデータモデルを描くことです。あなたがkinaestheticラーナー(参加者に手を借りて学ぶ)であれば、私はこれを新しいデータベースに慣れさせる最善の方法であることを発見しました。自動化されたシステムがデータベースを読むことは素晴らしいものです。あなたが手で描くときにあなたが何をするかを学ぶ。

  • データモデリング手法は限られていますが、さまざまな方法で組み合わせることができます。あなたのような大規模なデータベースでは、複数のプログラマーが作成しているので、同じデータベースで複数のテクニックが使用されている可能性があります。過去に私は、顧客情報セクションが非常にストレートフォワードスターデザインであった間に、データ回路用の情報を格納するために繰り返し自己に結合された単一のテーブルとして保存された回路情報を持つシステムを見つけました。プログラミングスタイル、おそらく2人の別個の開発者。私は後で、データ回路セクションと同じスタイル(おそらく同じプログラマー)であると認識していた、アプリケーションの電話回線セクションに冒険しました。通常、開発者はビジネス部門に関連する論理部門に割り当てられます...同様のセクションのパターンを監視します。

  • 物理的なデータベース構造は、データを生成してデータベース(データウェアハウス?)にロードする方法です。あなたのデータが何であり、どのように作成されているのかを理解することは、読み込まれた後にデータベース内で何を探しているのかを知る第一歩です。

  • データがデータベースに格納された後...データがどのように消費されているか(ユーザーが使用しているか)を理解することで、そのデータがどのように使い果たされているのか、また、 。 Fromステートメントとして既存のレポートを生成するために使用されたスクリプティングを手に入れることができるなら、追加ポイントは既存のテーブルの使用方法を理解するのに役立ちます。

  • 特にユーザーのインタビューを忘れないでください。特に、システムの初期展開のためのものを見つけることができます。社内で設計されている場合は、システムの初期要件の一部を提供し、それらに話をするのは、システムを設計した人々が要件収集に入ったときに最初に聞いたことを知ることができるということです。あなたの会社の論理的な部門(カスタマーケア対オペレーション対ビリングvsなど)は通常、あなたのデータモデルに従います。

  • 最後に...再生!開発環境やQA環境が利用可能な場合は、クエリの作成を開始し、戻ってくるものを参照してください...あなたのステートメントを変更して、もう一度やり直してください。

あなたが避けたいと思う最大の愚かさは、テーブルがどのように配置されているかに焦点を当てていると思います。データの内容、生成方法、消費方法を理解する。あなたの会社、それがどのように配置され、どのように機能するかを理解する。それが格納される方法(データモデリング)は、この理解に二次的です。

+0

うわー@Twelfth!素晴らしい情報..ありがとう! – rock

+2

細部にのみ焦点を当てるのではなく、大きなイメージを念頭に置いてください。 – smwikipedia

-1

エンティティリレーションモデルを作成するためにSQL Server Management Studioを使用すると、dbテーブル間の関係を簡単に表示できます。基本的には、管理スタジオのdbフォルダの中に「データベースダイアグラム」という名前のフォルダがあります。右クリックして、 "New Database Diagram"を選択してください。

+0

私はSQLでそれを見ましたが、foxproでそのようなツールを見つけることができませんでした.. – rock

+0

ああ、私はあなたがすでにSQLサーバにdbを移行したと思いました。 – bnvdarklord

+0

いいえ@bnvdarklord ..あなたの提案にも感謝! – rock

1

私は最近同じプロセスを経ました...私が最も助けたと思うのは、自分のデータベースダイアグラムを作成することでした。無料のツールwwwsqldesignerを使用しました。それはかなり簡単だった、私が持っていた唯一の問題は何らかの理由でChromeでは動作しないだろうが、Firefoxはうまくいきました。私はたくさん使っているテーブルを置くだけで、何か新しいことをする必要があるときに私は頻繁にそれを参照することができます。

自動的に生成されたデータベースダイアグラムを使用することができれば、それは良い方法ですが、私は個人的には動作させることができませんでした(私はSQLサーバーを使用しています)。

幸運を祈る!

+0

ありがとうKreg ..あなたが提案したツールが私のために働くかどうか試してみるよ! – rock

0

移行後に古いFoxproサーバーと新しいSQL Serverが共存するのですか?もしそうでなければ、断片的にシステムを解読しようとするべきです。停滞した未使用コードに時間を費やす必要はありません。ノートと図は、データの流れの一般的な感じを取得し、掘り出しを開始するだけです!

+0

笑..この掘り出し物はラウンドロビンのようなものです!この移行が成功すると、foxproはゴミ箱になります。 – rock

+1

それはまったく楽しいとは言えません。私はsqlの移行にいくつかのmdbをやったことがあり、それを楽しむことはありませんでした。 –

+0

私は完全に同意します! – rock

3

何百ものテーブルと何百万ものレコードを持つ大規模なSQL Serverデータベースにジャンプすると、私はそれをすべて理解し、 "メイン"テーブルを見つけ出して特定のテーブルに絞り込み、列。

--Query to show list of tables ordered by number of records in each table 
    SELECT 
     t.NAME AS TableName, 
     SUM(p.rows) AS [RowCount] 
    FROM 
     sys.tables t 
    INNER JOIN  
     sys.indexes i ON t.OBJECT_ID = i.object_id 
    INNER JOIN 
     sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id 
    INNER JOIN 
     sys.columns c on t.object_id = c.object_id 
    WHERE 
     i.index_id <= 1 
    GROUP BY 
     t.NAME, i.object_id, i.index_id, i.name 
    ORDER BY 
     SUM(p.rows) DESC 



--Query to show any columns or table names like what I'm looking for 
SELECT 
    c.name, t.name 
FROM sys.columns c 
    INNER JOIN sys.tables t ON c.object_id = t.object_id 
WHERE c.name LIKE '%#ColumnName%' OR t.name LIKE '%#TableName%' 
0

こんにちは次のスクリプトが役に立ちます。開発したデータベースでこれを使用すると、少なくともテーブルの関係を知ることになります。

SELECT 
fk.name 'FK Name', 
tp.name 'Parent table', 
cp.name, cp.column_id, 
tr.name 'Refrenced table', 
cr.name, cr.column_id 
FROM 
    sys.foreign_keys fk 
INNER JOIN 
    sys.tables tp ON fk.parent_object_id = tp.object_id 
INNER JOIN 
    sys.tables tr ON fk.referenced_object_id = tr.object_id 
INNER JOIN 
    sys.foreign_key_columns fkc ON fkc.constraint_object_id = fk.object_id 
INNER JOIN 
    sys.columns cp ON fkc.parent_column_id = cp.column_id AND fkc.parent_object_id = cp.object_id 
INNER JOIN 
    sys.columns cr ON fkc.referenced_column_id = cr.column_id AND fkc.referenced_object_id = cr.object_id 
ORDER BY 
tp.name, cp.column_id 
0

FoxProには2つの異なる種類のデータオブジェクトがあります。
"データベース"に含まれていない無料のデータテーブル(DBF、CDX、IDX、FPTファイル)を表示している可能性は非常に高いです。
また、Foxproには、データテーブルを含むことができるデータベース(DBCファイル)があり、関連条件で「保持」することができます。

ただし、Foxproのデータテーブルは、通常、インデックス式に基づいて動的に関連するアプリケーションで必要となるまではまったく関連しません。

インデックスは、アプリケーションのニーズを満たすために動作する式(例:Fld1 + Fld2またはAccount_IDなど)を使用してデータテーブル上に構築されます。
これらのインデックスは、インデックスが作成された任意のデータテーブルに必要なときに「アクティブ化」されます。

関連テーブルには、子テーブルがインデックスをアクティブ化し、親が子インデックスの式に一致する独自のフィールドの値によってその子に関連する親/子関係があります。

SQL Serverに移動した後のデータの利用方法は、アプリケーションで使用しているものによって異なります。

アプリケーションでFoxproを使用している場合は、SQL Serverを照会してレコードをメモリカーソルに戻すことができます(データテーブルとほぼ同じです)。複数のSQL Serverクエリカーソルを取得すると、式を使用して索引を作成し、必要に応じて表を関連付けることができます。

アプリケーションを他の言語(VB.netやC++など)に変更する場合は、SQLクエリ構文を使用して独自の「リレーション」を作成する必要があります。

データテーブルを移動することはそれほど大きな問題ではありません。
しかし、アプリケーションの言語を変更することは大きなディールであり、個々のタスクにどのようにアプローチするかは、別々に処理する必要があります。
英語から中国語への翻訳のように考えることができます - Everything HAS TO CHANGE。

Foxproとアプリケーションのソースコードが不明確な場合や、アプリケーションのソースコードがない場合は、コンサルタントを探すことを検討することをお勧めします。 。

また、プロジェクトがビジネスクリティカルである場合は、コンバージョン費用を考慮する必要はありません。

幸運

関連する問題