タグ付けされた質問 「normalization」

大規模なクエリを高速化し、より良い結果を得るには、リレーショナルデータベースで（FOREIGN KEY制約定義を介して）関係の強制を取り除く方が良いと言うので、私は私が働いている会社の開発者と恒久的に話し合っています。パフォーマンス。 検討中のプラットフォームはMySQL 5.xであり、FOREIGN KEYがセットアップされておらず、関連するテーブルの一部のPRIMARY KEY制約が欠けていても、少なくとも私にとっては妥当ではありません。多分彼らは正しいのですが、私は間違っていますが、私はこの状況について議論するのに十分な議論がありません。 これは3年間、推奨されるアプローチでした。私はこの会社の新人です（わずか1か月）が、製品が「機能する」ため、データベースを拡張するのにためらいがあります。それにもかかわらず、最初に気付いたのは、1ページの読み込みに1分（はい、60秒！）かかっていることです。 現在の状況の背後にある主張の1つは、「非正規化された」データベースは正規化されたデータベースよりも速いということですが、私はそれが本当だとは思いません。 関連するクエリのほとんどにJOIN操作が含まれているため、大量のデータがあると非常に遅くなります（データベースには数百万の行が含まれます）。 通常、「CRUD」操作の処理は、アプリケーションプログラムコードレベルで実装されます。たとえば、FROMからデータを削除するには、次のようにしましょうTableA： との行の間に何らかの関係があるかどうかをその場で最初に確認する必要がTableAありますTableB。 上記の関係が「検出」された場合、アプリプログラムコードは関連する行の削除を許可しませんが、 何らかの理由でアプリのプログラムコードが失敗した場合、関連する行とテーブルに関係があるかどうかに関係なく、DELETE操作は「成功」します。 質問 議論を深めるために、私が良い、正確で確固とした答えを詳しく説明するのを手伝っていただけませんか？ 注：たぶん、このようなものは以前に尋ねられた（そして答えられた）かもしれませんが、Googleを使用して何も見つけることができませんでした。

10 mysql  database-design  normalization  relational-theory  denormalization 

私は自分のリーグではないデータベース設計の問題に出くわしました。そして、私の頼りになるDBAの第一人者が消防訓練に出かけています。 本質的に、私は次の主キー（簡潔にするためにPK）を持つテーブルを持っています。 child_id integer parent_id integer date datetime child_idそして、parent_idエンティティテーブルへの外部キーです。「子」テーブル自体にも「親」テーブルへの外部キーが含まれています。loはそれぞれ、child_id常にparent_id上記のテーブルで想定されているものと同じものを参照します。実際、この2つを同期させるための追加のコードがあることがわかります。 これにより、この熱狂的な正規化の初心者は「代わりに冗長性を削除する必要があります！」と言います。 私は次のように分解します。 Table_1 PK: child_id integer date datetime Table_2 PK: parent_id integer date datetime Table_3: (already exists) child_id integer PRIMARY KEY parent_id integer FOREIGN KEY そして、これらの人たちを自然な方法で結合すると、元のテーブルが回復します。この5NFを作ったのは私の理解です。 しかし、今ではビジネスルールが隠されていることに気づきました。 通常、特定child_idのに関連付けられている日付は、対応するに関連付けられている日付のサブセットである必要がありますparent_id。最初のテーブルがこのルールを適用していることがわかります。 日付が大きくなりすぎるまで自由に表1に追加できるため、私の分解ではルールを適用しません。 これは私をここに導き、次の質問があります： この分解は5NFですか？私はそれが挿入異常を許可すると言うだろうが、また次のそれ自体、Wikiの例に従うように見えるこのガイドを。「私が強調したもの」というフレーズは、「3つの別個のレコードタイプからなる正規化された形式からすべての真の事実を再構築できる」という特別な休止を与えますTable_1。 この分解が気に入らないとしましょう（気に入らない）。テーブルとコードをそのままにしておくことが実際的な解決策であることを私は自由に認めます。しかし、理論的には、最初のテーブルから離れてビジネスルールを保持するように制約を分解または追加する方法はありますか？

10 database-design  schema  normalization  relational-theory  best-practices 

ユーザーが投稿したりブログを書いたりする小さなプログラムを作っています。これらの投稿では、他のユーザーがFacebookのように投稿を高く評価したり、低く評価したり、Stackoverflowのように投稿に賛成または反対票を投じたりできます。一般的に使用されている適切なデータベース構造と、プログラムがその構造で効率的に機能することを知りたいのですが。2つのオプションがあります 最初 役職： id head message datepost likes dislikes 1 ab anchdg DATE 1,2,3 7,55,44,3 上記のようにid、postidです。「いい1,2,3ね！」列には、投稿またはブログを高く評価したか賛成したユーザーのIDを指定します。7,55,44,3投稿またはブログを低評価または反対票を投じたユーザーのIDです。 二番目 役職： id head message datepost 1 ab anchdg DATE いいね： id postid userid 1 1 1 2 2 2 嫌い： id postid userid 1 1 7 2 1 55 このように、私は投稿のいいねを取得するために、いいねと嫌いのために2つの個別のテーブルを作成する必要があります。このようにして、テーブル、つまりLikes＆Dislikesは非常にいっぱいになります。これにより、テーブルが重くなり、処理が遅くなる場合があります。 それで、私はこのタスクを達成するためのより良い標準的な方法がどれであるか知りたいですか？

10 mysql  database-design  normalization  string 

講義では、講師が主キーのないテーブルを見せてくれました。質問したところ、彼は3NFで推移的な依存関係を削除するときに、主キーのないテーブルがあっても問題ないと述べました。 ただし、主キーがないということは、機能上の依存関係がないことを意味しますが、3NFは推移的な依存関係の削除であり、すべての機能上の依存関係のため、各テーブルには正規化のための主キーが必要であると教えられました。 主キーなしでテーブルを作成することは完全に可能ですが、そのテーブルが存在する場合、そのデータベースは正規化されていると見なされますか？ 追加する必要があります。テーブルには「一意のキー」、プライマリ、コンポジット、外部はありません。 表示されているテーブルには3つの属性があり、どれもプライマリまたは一意としてラベル付けされていません。私はそれが間違いかどうか尋ねました、そして彼はそれがなくても大丈夫だと言いました。この表の情報を一意に特定できないため、私はその発言に疑問を投げかけ、彼はこのようにしてよいと主張しました。これは私が正規化について教えられたことに反しています。

9 database-design  normalization  relational-theory 

第一正規形とは何かの決定版を取得しようとしています。私が読んだものはすべて、少し異なるスピンを持っています。 日付などの多くの当局は、定義によって関係は常に第1正規形であると言いますが、他の当局は要件のリストを提供します。つまり、1NFの要件は0から多くあります。 違いは、テーブルとリレーションの間の違いだと思います。テーブルは完全に混乱する可能性がありますが、リレーションシップは特定の制限に従います。したがって、リレーションがSQLでテーブルとして表されるという事実により、混乱が生じます。 SQLデータベースに関連するため、特に1NFに焦点を当てています。問題は、テーブルが最初の正規形であることを保証するために必要なプロパティは何ですか？ 多くの当局は、表が関係を表す場合、それはすでに1NFにあると示唆しています。これにより、1NFの定義が関係の定義に戻ります。 1NFのテーブルのいくつかのプロパティは次のとおりです。 列の順序は重要ではありません[1] 行の順序は重要ではありません すべての行は同じ長さです（つまり、行データは列ヘッダーと一致します） 重複行はありません（これは代理主キーを使用して保証できますが、PK自体は必要ありません） 繰り返し列はありません 各列には単一の値（アトミック）が含まれています [1]技術的には属性は順序付けされていませんが、テーブルでは、行データは列ヘッダーと同じ順序である必要があります。ただし、実際の順序は重要ではありません。 上の複数のデータ： アトミックデータの概念は、アイテムをさらに分解することはできないということです。この概念は、技術的にはすべて吐き気を分解することができますが、問題のデータは、データの使用方法によっては、実際にはそれ以上分解できないという点で評価されています。 たとえば、通常、完全な住所または完全な名前はさらに分解する必要がありますが、名前や町の名前などのコンポーネントは、文字列として使用できるという事実にもかかわらず、おそらくこれ以上分解すべきではありません。 列を繰り返すように、それが持っている貧弱な設計カラムでほぼ等列、繰り返しphone1、phone2一般に等、繰り返されるデータは、追加の関連テーブルの必要性を示しています。 依存 同じヘッダーに準拠していることを除いて、行間に関係があってはなりません。 列の間にも関係があってはなりませんが、それがより高い正規形の主題であると私は信じています。 問題は次のとおりです。1NFの定義には上記のどれくらいが含まれていますか？独立した行ビットもそれに含まれますか？

9 database-design  normalization  relational-theory 

User_FriendList次の特性を持つと呼ばれるテーブルがあるとします。 CREATE TABLE User_FriendList ( ID ..., User_ID..., FriendList_IDs..., CONSTRAINT User_Friendlist_PK PRIMARY KEY (ID) ); また、上記の表に次のデータが含まれているとします。 + ---- + --------- + --------------------------- + | ID | User_ID | Friendlist_IDs | + ---- + --------- + --------------------------- + | 1 | 102 | 2：15：66：35：26：17：| + ---- + --------- + --------------------------- + …

9 database-design  foreign-key  normalization  relational-theory 

簡単に説明できる人がいoverlapping candidate keyますか？何でoverlapping名前が示すように？ 以下の関係を検討してください R(L,M,N,O,P) { M -> O NO -> P P -> L L -> MN } 上記の機能の依存関係のどれが上記の関係で重複する候補キーをもたらしていますか？ ディスカッションを依存関係に制限しましょう。現時点ではBCNFには興味がありません。

8 database-design  normalization  dependencies 

次のシナリオのデータベーススキームを作成しています。 ユーザーがいます ユーザーには役割があります（「開発者」や「CEO」など） ロールにはアプリケーションがあります（「Topdesk」など） アプリケーションには権限があります（「ナレッジベースの更新」など） ロールがアプリケーションへのアクセス権をすでに持っている場合、ロールは権限を持つことができます 高性能環境がない（速度を最適化する必要がない）と仮定すると、このスキーマを実装する最良の方法は何でしょうか？データベース環境には、MySQL、MSSQLを使用できます。リレーショナルデータベースの設計が重要です。 私自身は次のことを考え出しました： もちろん、最も不確かな部分は、Applications_Permissions_Rolesテーブルです。これは、リンクテーブルですの上に別のリンクテーブル。これまで使用したことも、見たこともありません。それを行う別の方法は、それを役割と権限の間のリンクテーブルで置き換え、次にコードまたは制約を使用して必要な関係を確認することです...しかし、それは私にとって良い解決策のようではありません。これらのことは、コードレベルではなく、可能な限り（可能であると思われる場合）データベースレベルで実施する必要があります。 次に、Permissions.ApplicationとApplications.Idの間のリンクが必要ですか？Roles_Applicationsに行がない可能性があるため（新しいアプリケーションを追加した直後など）、どの権限がどのアプリケーションに属しているかを判別することができないため、これを使用します。また、権限が属するアプリケーションを検索するための単一の参照ポイントでもあります。これは正しいと思いますが、それはまた、データベース設計において円を描くものです。ON_DELETEまたはON_UPDATEをカスケードに設定しようとすると、MSSQLエラーが発生します。 何か提案、またはこれはどのように行われることになっていますか？命名規則などに関するその他の提案も（おそらくコメントとして）歓迎されます。 ありがとう、 Luc 編集：タイトルを変更しました。以前のものはより包括的でしたが、おそらく複雑すぎます。

8 database-design  normalization  relational-theory 

私はデータベース作成の初心者です...採用Webアプリケーション用に作成する必要があります。 私のアプリケーションは、スクリーニング、試験、および面接をスケジュールし、結果をデータベースに保存する必要があります。 私のデータベーススキーマは次のとおりです。 私の問題はapplicant_id、他のテーブルに含まれていることです...試験、面接、試験の種類など。 正規化ルールに違反していますか？もしそうなら、私のデザインを改善するために何をお勧めしますか？

8 normalization  database-design