問題タブ [database-normalization]

データベースを設計するとき、繰り返しデータセットを別のテーブルにシフトする傾向があることに気づきました。たとえば、私が人々のテーブルを持っていて、各人が州に住んでいるとしましょう。次に、これらの繰り返し状態を別のテーブルに移動し、外部キーで参照します。

ただし、州に関するデータをこれ以上保存していなかった場合はどうなりますか。次に、StateIDとStateが入ったテーブルを作成します。このアクションは正しいですか？状態はusersテーブルの主キーに依存しているので、それを独自のテーブルにシフトすることは何かに役立ちますか？

ありがとう、

複数のデバイスからの 1 秒あたり 500 の測定値を保存する必要があります。各測定値は、タイムスタンプ、数量タイプ、およびいくつかのベクトル値で構成されます。現在、測定ごとに 8 つのベクトル値があり、この数はプロトタイプ プロジェクトのニーズに対して一定であると見なすことができます。HNibernate を使用しています。テストは SQLite (メモリ内ではなくディスク ファイル db) で行われますが、本番環境はおそらく MsSQL になります。

Measurement エンティティ クラスは、単一の測定値を保持するもので、次のようになります。

ベクトル値は個別のテーブルに格納されるため、それぞれが外部キーを介して親の測定値を参照します。

生成された SQL が (合理的に) 効率的であることを確認するために、いくつかのことを行いました。ID の生成に Guid.Comb を使用し、1 回のトランザクションで約 500 項目をフラッシュし、ADO.Net バッチ サイズを 100 に設定しますSQLIte はバッチ更新をサポートしていないと思いますか? しかし、後で役に立つかもしれません)。

問題

現在、1 秒あたり 150 ～ 200 の測定値を挿入できます (これは十分な速度ではありませんが、これは私たちが話している SQLite です)。生成された SQL を見ると、(予想どおり) 単一のトランザクションに挿入されていることがわかります。

• 1 タイムスタンプ
• 1回の測定
• 8 つのベクトル値

これは、実際には 10 倍以上の単一テーブルの挿入を行っていることを意味します: 1 秒あたり 1500 ～ 2000 です。

すべて (8 つのベクトル値すべてとタイムスタンプ) を測定テーブルに配置すると (9 つの専用列を追加)、挿入速度を最大 10 倍に上げることができるようです。

SQLサーバーに切り替えるとパフォーマンスが向上しますが、現在のデータベースの編成方法に関連する不要なパフォーマンス コストを回避する方法があるかどうかを知りたい.

[編集]

インメモリ SQLite では、約 350 アイテム/秒 (3500 の単一テーブル挿入) が得られます。これは、NHibernate で得られるものとほぼ同じであると考えています (この投稿を参考にしてください: http://ayende.com/Blog/archive/ 2009/08/22/nhibernate-perf-tricks.aspx )。

しかし、SQL サーバーに切り替えて、物事を想定するのをやめたほうがよいのではないでしょうか。テストしたらすぐに記事を更新します。

[アップデート]

私は SQL サーバーに移行し、階層を平坦化しました。3000 回/秒の測定値を数時間保存してテストしたところ、問題なく動作しているようです。

データのセットがあるとします。データと関係スキーマが与えられた場合、データのセットはいずれかの形式で正規化されていると想定できます。私の意見では、与えられた生データは何らかの形式に正規化する必要があります。しかし、友人との話し合いの結果、ここでこの質問をするようになりました。

質問をさらに詳しく説明すると、リレーションまたはテーブルの機能的な依存関係のセットが与えられた場合、テーブルが少なくとも 1NF にあることが保証されていると言えます。

問題は、非常に大きな関係があるため、正規化した後、実際には外部キーである20個の主キー（複合キー）のようなものになることです。

これらは、関係を一意に識別するために主キーとして宣言する必要があります。これは正しいです？

次の表の SName は繰り返しグループと見なされますか?

SName フィールドにリストされている各サブジェクトは、個別のセルにあります。私の知る限り、繰り返しグループは、セルに複数の値が含まれている場合です。したがって、被験者は別々のセルにいるため、わかりません。

City フィールドを持つ 1 つのテーブルがあり、予想どおりこのフィールドが繰り返されるため、別のテーブルに分離するだけで概念を正規化できますか? フィールドが 1 つしかない分離されたテーブルは意味があり、パフォーマンスの向上に役立つということですか?

私はデータベース設計に不慣れで、正規化についてかなり読んでいます。宿泊施設、駅、空港の3つのテーブルがある場合。各テーブルにアドレス列がありますか、それとも他のテーブルから参照されるアドレステーブルがありますか？過剰正規化のようなものはありますか？

ありがとう

2 つの物質を混合できるかどうかを説明する mySQL テーブルがあるとします。

最初のステップは、次のように変換することです

しかし、重複した情報があります。(例: A が B と混合できる場合、B は A と混合できます)、したがって、いくつかの行を削除して取得できます。

小さなテーブルでは最後のステップは非常に簡単でしたが、大きなテーブルでは手動で行うと非常に時間がかかります。MEANING が重複しているが内容が同一ではない行の削除を自動化するにはどうすればよいでしょうか?

ありがとう、私はまだデータベースを学んでいるので、私の質問が理にかなっていることを願っています

これがBCNFにあるかどうかはわかりませんが、先生はINSTRUMENTがBCNFにあると教えてくれました。彼は私をいじっていますか？先生は何が正しくて何が間違っているのか私の心を混乱させ続け、私を不安にさせます。彼は私がすでに考えていることをはっきりと言い続けており、私は彼が言っていることすら理解していません。

INSTRUMENT（InstrumentID,InstrumentType、Tune、Performer、Adr、Phone、Availability） 注（TitleNr,Tune,Composer、Copies、Title、Performer）

それで、これは正規化されていますか？BCNFで：

Instrument（InstrumentID、InstrumentType、Tune、Availability、PerformerID *）
注（TitleNr, Title,Tune、Composer、Copies、PerformerID *）
PERFORMER（PerformerID、Name、Adr、Phone）

TuneはINSTRUMENTとNOTESの両方にあります。それは両方にあることができますか？

この質問は、前のトピック「MySQL - フラット テーブルから第 1 正規形への移行」( http://bit.ly/9pvS0Y )に直接関連しています。新しいトピックを開始するのが最善だと考えました。

以下は私の最初の正規形スキーマであり、私の目的には十分にしっかりしていると確信していますが、間違っている場合は修正してください。

これを 2 番目と 3 番目のフォームに移行する方法を知りたいのですが、私のテーブルが 2NF と 3NF ルールによってどのように影響を受けるかについての指針は本当に役に立ちます。

関係

-活動と場所の関係 = 1 対多 - 1 つの活動は 1 つの場所を持つことができ、場所は多くの活動を持つことができます (活動の FK としての場所 ID)

-アクティビティと週の関係 = 1 対多 - 1 つのアクティビティに 1 週​​間、1 週間に複数のアクティビティを含めることができます (アクティビティの FK としての WeekID)。

-ユーザーとアクティビティ= 多対多 - 1 人のユーザーが多数のアクティビティを持つことができ、1 つのアクティビティが多数のユーザーを持つことができます