効率的なデータベースを構築するためのアプローチ

Question

経験豊富なデータベースデザイナーに引き付けることができるのだろうかと思っていました。私はデータベースを構築する経験はあまりありません。私は設定された時間（2〜3ヶ月）以内に完了するプロジェクトを持っています。要件は、それを第3正規形にすることです。

私が始めようとする最良の方法はなんですか？私は先に進んで、できるだけ効率的になるよう努力して、改善しなければならない部分をリファクタリングするか、あるいはある程度の正規化を最初から確実にするための方法論があるでしょうか？

Answer 1

後で元に戻って正規化する目的でデータベースを構築しないでください。データベースはアプリケーションコードと同じように簡単にリファクタリングすることはできません。また、別の方法では、3つ目の標準フォームに従う必要がありますので、最初からやり直す必要はありません。 3番目の正規形でデータベース設計を修正するためのショートカットはありません。 deisgnを始める前にそれが何であるかを明確に理解するだけです。

3番目の正規形式のデータベースdsignに精通していない場合は、数日間データベース設計に関する読書をしてください。データベースのパフォーマンスチューニングについて1日かそれ以上の時間を費やしています。最初からデータベースをうまく実行するように設計すると、時間を大幅に節約できます。何をすべきか、何を避けるべきかを知ったら、パフォーマンスの低いデータベースを設計するよりも時間がかかりません。だから私の最初のアドバイスは、あなたが始める前にいくつかの大きな太った本を手に入れ、深く読んでいくことです。あなたがこれをやって過ごす時間は、プロジェクトの残りの部分を通してより良いことをするあなたの能力に十分に返済されます。

Answer 2

このデータベースレイヤーの上には、多くのレイヤー（DAL、BAL、UI）が書き込まれます。下位レベルの変更はすべて上向きになり、データベースレイヤーよりも多くの再作業が発生します。

私はすべてのデザインを行い、最初に異常を起こさずにデータを保存するために必要な/必要な最高の正規化をデータベースに取得する必要があると思います。

Answer 3

フロントサイドプログラミングとは異なり、使用中にデータベース構造をリファクタリングするのは苦しいだけでなく実用的ではありません。

バックエンド右の構造を前面にすることを強くお勧めします。良いニュースは、第3の正常な形態は一般的に達成することが困難ではないということです。実際には少し実用的になると、それらの用語でデータを考えるのは第二の性質になります。

第3正規形では、表内の単一レコードの各構成要素が、そのレコードのキーに対して一意であることが基本的に示されています。検討：

tblPerson： PERSONID PK 氏名 姓 MiddleName DOB SSN IncomeSource IncomeAmount

表上で定義した収入源がに固有ではないので、thrid正規形でありません実際にテーブルのPersonの発生率は、その人の人生を通して変化する可能性があります。次のように代わりに、一方が（過度に単純換算）上記の構造になる：

をtblPerson PERSONID PK 氏名 姓 MiddleName DOB SSN

tblPersonIncome PersonIncomeID PK PERSONID FK tblPerson IncomeSourceID FK tblIncomeSource IncomeAmount AsOfDate

いくつかは、上記の自動インクリメントIDフィールドの私の使用について議論することを

tblIncomeSource IncomeSourceID IncomeSource

注 - これらは、第三正規形に違反していないものの、彼らはまた、自然キーを利用しません。

バックエンドがジャンプから正常に正規化されている場合、エンティティを追加または拡張する方が処理がはるかに簡単で、追加する前に作成するフロントエンドに与える影響はずっと小さいでしょう。

とにかく、フロントエンドを正しく設計してください。そうしないと、後で構造変更を実装する必要があります。そうしないと、あなたの新しい家の土台を注ぎ、それを構築しながら後であなたのニーズに合わせてフロアプランを変更する計画に少し似ています。