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

データベースにはかなりの量のデータがあります。整形式のテーブルと、データ間の冗長性を備えたテーブル間の良好な関係があります。しかし、正規化はどこまで行えばよいのでしょうか？正規化が多すぎるとパフォーマンス上の欠点がありますか？

30 performance  learning  normalization 

タイトルはあまり意味がありませんが、この問題に対してより良いタイトルを考えることはできませんでした。 私は次の表を持っています プロジェクト id 名 お客さま id id_project 名 お支払い id id_customer 日付 和 ユーザーがシステムに入ると、特定のプロジェクトにアクセスできます。今、私はそのプロジェクトのすべての支払いをリストしたいと思います、そしてそれはかなり簡単なはずです： SELECT FROM payments where id_customer in (SELECT id from customers where id_project = 5) 私の質問は次のとおりです。この方法でid_project列を支払いテーブルに追加する方が良くない場合、クエリは簡単で高速になります。

30 database-design  normalization 

ソフトウェア開発者向けにテーブルとリレーションを設計するチームがあります。私たちの組織では、彼らは3NF正規化の実施について非常に厳しいです。正直に言うと、私たちの組織の規模と、ニーズやクライアントが時間とともにどのように変化するかを考えると同意します。設計決定の背後にある理由について明確になっていない領域は、アドレスのみです。 これは主に米国の住所に焦点を当てていますが、これはこれを行うすべての国に当てはまると思います。住所の各部分は、住所テーブルの独自の列を取得します。たとえば、この厄介な米国の住所を使用します。 Attn: Jane Doe 485 1/2 N Smith St SW, APT 300B Chicago, IL 11111-2222 次のようにデータベース内で分割されます。 番地：485 ストリートフラクション：1/2 ストリートプレディレクショナル：N（北） 通りの名前：スミス 通りのタイプ：ST（通り） ストリートポスト方向：SW（南西） 市：シカゴ 州：IL（イリノイ州） 郵便番号：11111 Zip4コード：2222 国（米国を想定） 注意：ジェーンドゥ 私書箱：NULL 住居の種類：APT（アパート） 住居番号：300B また、田舎のルートと契約ルートに関連する他の列がいくつかあります。さらに、特定のアプリケーションには、いくつかの国際アドレスが含まれている可能性があります。データモデラーは、国際住所に固有の列を追加すると述べました。これは通常の行1、行2のフィールドです。 最初は、これはWAYオーバーボードだと思いました。オンラインで繰り返し調べるとは、住所1、2、3、場合によっては4を使用してから、都市、地域、郵便番号を分割することです。この粒度が有益な新しいアプリケーションのユースケースが1つあります。ユーザーが重複したビジネスを作成していないことを検証する必要があり、住所の確認は検証の1つです。私たちはできるアドレスライン1と2で動作するようにそれを得るが、それはより困難になるであろう。 特定のアプリケーションに関しては、ビジネスと人々（物理、郵送、出荷など）のために複数の種類のアドレスを保存する必要があります。我々は可能性がある印刷可能な形式の文字を生成する必要がありますが、その要件は、これまで議論されていません。 組織内のアプリケーションがサポートする必要があるその他の事項： 監査（完全な履歴テーブルを使用） 宛名ラベルの印刷 印刷フォームの生成 報告（国および地方政府向け） 私たちのアプリケーションは、他のすべてのアプリケーションが行っていることをすべて行っているわけではありませんが、アドレスを複数のコンポーネントに分割することは、私が働いている企業標準です。アプリケーションがその恩恵を受けるかどうかに関係なく、私たちはこれを強制されます。 半関連のStackOverflowの質問：閉じられた良いアドレスパーサーはどこにありますが、アドレスの解析がどれほど難しいかを示しています。 私が彼らの設計決定をよりよく理解し、アイデアでクライアントを売るために... 住所を個々の列に分割すると、どのような問題が解決しますか？ 問題が発生したため、このようなシステムを実装した人にとってのボーナスポイント。

24 database-design  normalization  best-practices  address 

各親について、1人または0人の子供が「お気に入り」としてマークされる1対多の関係が必要です。ただし、すべての親が子供を持つわけではありません。（このサイトでは、両親を質問、子供を回答、お気に入りを受け入れられた回答と考えてください。）たとえば、 TableA Id INT PRIMARY KEY TableB Id INT PRIMARY KEY Parent INT NOT NULL FOREIGN KEY REFERENCES TableA.Id 私の見方では、TableAに次の列を追加できます。 FavoriteChild INT NULL FOREIGN KEY REFERENCES TableB.Id または、TableBの次の列： IsFavorite BIT NOT NULL 最初のアプローチの問題は、null許容の外部キーを導入することです。これは、正規化された形式ではないことを理解しています。2番目のアプローチの問題は、多くても1人の子供がお気に入りであることを確認するために、より多くの作業を行う必要があるということです。 どのアプローチを使用するかを決定するには、どのような基準を使用する必要がありますか？または、私が検討していない他のアプローチはありますか？ SQL Server 2012を使用しています。

22 sql-server  database-design  foreign-key  normalization  relational-theory 

最近、正規化について学び、新しいスキーマを実装するときにそれがどれほど重要かを理解しました。 データベースが2NFまたは3NFに準拠しているかどうかを確認するにはどうすればよいですか？ 手動レビューは確かなオプションですが、ここでは自動化されたツールを探しています。 私は、ポイントアンドクリックツールを探しているのではなく、テーブル3NFを準拠させるために可能な最適化を強調するものを探しています。良いサンプルデータやカラム名のセマンティック分析に基づいた統計を使用するかもしれないと思います。

20 database-design  schema  database-recommendation  normalization 

私はデータベース設計が比較的新しいので、練習用に独自の仮想データベースを作成することにしました。ただし、多くの多対多（M：N）の関係があると考えているため、モデリングと正規化に問題があります。 一般的なシナリオの説明 このデータベースは、ゼルダシリーズで働いたさまざまな人々に関するデータを保持することを目的としています。私はのトラック維持したいコンソール（S）というゲームがで再生することができ、従業員に参加を持っていたゲーム開発をジョブズ従業員は、（多くの持っていた従業員が異なる上で働いていたジョブズ複数にわたるゲームなど、） ビジネスルール 複数の従業員が複数のゲームで作業できます。 同じコンソール上に複数のゲームを配置できます。 複数のコンソールを同じゲームのプラットフォームにすることができます。 複数の従業員が同じジョブを持つことができます。 アン従業員は複数持つことができますジョブを。 A ゲームは複数持つことができる従業員を。 ゲームは、複数の種類持つことができるジョブのそれの発展に 複数のゲームに同じタイプのジョブを添付できます。 A コンソールは複数持つことができます人々はそれに取り組んで。 A 人は複数で作業することができますコンソール。 属性名とサンプル値 FirstとLastに分割できる従業員名（「John」と「Doe」など） ゲームのタイトル（たとえば、「Ocarina of Time」） 役職（たとえば、「レベル設計」、「ディレクター」、「構成」、「レベル設計者」、「プログラマー」、「ローカリゼーション」など）。 コンソール名（「Game Boy Advance」など） 問題 これまでのところ、データの冗長性と、関心のあるエンティティタイプ間のM：N関係が至る所にあるように設計されているようです。しかし、データベース設計者は常にこの種の問題に遭遇しなければならないので、解決策が必要だと感じています。 注：テーブルを満たすデータを見つけることはできますが、問題は、正規化された形式のテーブルを持つデータベースにデータを整理することです。

16 database-design  normalization  denormalization  many-to-many 

私はこのBBCニュースの記事を読んでいて、次の抜粋が私の注目を集めました。Always On可用性グループまたは高可用性ミラーリングのように聞こえますが、セキュリティが自動的に含まれている場合があります。 ブロックチェーンは、トランザクション量の多い最新のアプリケーションにとって実行可能なデータベースソリューションですか？ 個人の医療記録のような少量のトランザクションに価値があることは簡単にわかりますが、大量のデータベースについてはどうでしょうか？ ブロックチェーンとは何ですか？ ブロックチェーンは暗号化に依存しており、中央のアクターを必要とせずに一連のコンピューターがグローバルレコードを変更できるようにします。 仲介者を削除すると、ほぼすべての部門でコストが削減されます。 ブロックチェーンは、「ブロック」として知られるデータのコレクションに発生するすべてを時系列または「チェーン」で記録する台帳です。 通貨としてこれは重要な機能です。これにより、ユーザーは自分のデジタルマネーが種類の1つであることを確認できるため、ウォレット内の各紙幣が一意であるのと同じです。 「ブロックチェーン技術は、コピーせずにデジタル情報を転送できるため、私たちが資産を作成する方法になります」と、ブロックチェーンネットワークを構築するChain.comのCEO、Adam Ludwin氏は述べています。 ブロックチェーンは、あらゆる種類の情報の履歴を追跡し、その価値を維持するために使用できます。たとえば、医師はそれを使用して医療記録を更新できます。 ブロックチェーンへの各変更はネットワーク全体で同時に行われるため、情報が失われることはなく、変更を元に戻すことができないため、システムはその透明性を維持します。各ブロックを変更するには特別なキーが必要なので、個人はそのキーを保護することで記録を安全に保つことができます。

16 database-design  normalization  distributed-transactions 

私はテーブル設計シナリオを持っていますが、非DBAタイプとして、よりスケーラブルな意見を求めています。 メトロエリアの家に関する情報を記録するように求められたとします。小さな近所（200の家）から始まり、最終的には5000000以上の家に成長します。 基本情報を保存する必要があります：ID＃（一意のインデックスとして使用できる一意のロット番号）、Addr、City、State、Zip。素晴らしくシンプルなテーブルがそれを処理します。 しかし、毎年、すべての家に関する追加情報を記録するように求められます-そして、何の情報は毎年変わります。したがって、たとえば、最初の年には、所有者の姓と面積を記録するように求められます。2年目は、姓を残すよう求められますが、面積を捨てて、代わりに所有者の名の収集を開始します。 最後に-毎年、追加の列の数が変更されます。余分な2つの列から始めて、来年は6に、その後2に戻すことができます。 そのため、テーブルのアプローチの1つは、ハウステーブルの列としてカスタム情報を追加して、テーブルが1つだけになるようにすることです。 しかし、私は誰かがこれのためにテーブルを次のようにレイアウトする状況を持っています： 「House Table」列：ID、Addr、City、State、Zip-家ごとに1行 ID Addr City State Zip ------------------------------------------- 1 10 Maple Street Boston MA 11203 2 144 South Street Chelmsford MA 11304 3 1 Main Avenue Lowell MA 11280 「カスタム情報テーブル」列：ID、名前、値-テーブルは次のようになります。 ID Name Value 1 Last Name Smith 2 Last Name Harrison 3 Last …

16 database-design  normalization  architecture  table 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私は古い学校に育ちました-アプリケーションのビジネスレイヤーの前にデータベーススキーマを設計することを学びました（または他のすべてにOOADを使用しました）。私はスキーマ（IMHO :)の設計にかなり長けており、不必要な冗長性を削除するためだけに正規化しましたが、速度に影響を与える場所ではありません。つまり、結合がパフォーマンスに影響した場合、冗長性はそのまま残されました。しかし、ほとんどそうではありませんでした。 RubyのActiveRecordやActiveJDBCなどのいくつかのORMフレームワークの出現により（覚えていないが他にもいくつかありますが、たくさんあると確信しています） 「メール」-2NFを完全に破壊します。さて、あまり理解していませんが、これらのORM（またはプログラマー）の一部が1-1または1-0 | 1（つまり、1対0または1）を認識しないと、（ほとんど）緊張します。彼らは、nulls 「今日のシステムがそれを処理できる」という大量の情報がある場合でも、すべてを1つの大きなテーブルとして保持する方が良いと述べています。 メモリの制約は正規化と直接的な相関関係があることに同意します（他の利点もあります:)が、今日の安価なメモリとクアッドコアマシンでは、DB正規化の概念はテキストに残されていますか？DBAは3NF（BCNFではない場合）への正規化を実践していますか？それは重要ですか？「ダーティスキーマ」設計は本番システムに適していますか？それがまだ関連している場合、どのように「正規化」のためにケースを作るべきか。 （注：設計の一部/必要性として冗長性を備えたデータウェアハウスのスター/スノーフレークスキーマについてではなく、たとえばStackExchangeのようなバックエンドデータベースを備えた商用システムについてです）

16 database-design  normalization 

他のデータベース設計者と正規化について興味深い議論をしています。この例では、GameTitlesテーブルがあり、各レコードにはゲームがリリースされた年が含まれている必要があります。彼は、2NFはすべてを正規化することを義務付けているので、準拠するには、GameTitlesテーブルによって参照される独自のプライマリキーを持つYearYフィールドをReleaseYearsテーブルに分割する必要があると言います。GameTitlesテーブル自体のフィールドとして残す必要があると言います。 これに対する私の主張は、年はその性質上静的な単なる非プリミティブ数値であるということです（つまり、2011は常に2011です）。このため、独自の識別子として機能し、それが何であるかを参照する必要はありません。また、テーブルを参照するためだけに新しい年をテーブルに追加する必要があるため、追加のメンテナンスも導入されます。テーブルに長い年数を事前に入力すると、それらへの参照をまったく持たない可能性のある追加のレコードがあります。これにより、余分なテーブル、レコードのオーバーヘッド、および年自体の追加の主キーがあるため、データベースサイズも増加します。GameTitlesテーブルのフィールドとして年を保持すると、この追加のメンテナンスとオーバーヘッドがすべてなくなります。 これについての考え？ 編集： StackOverflowでこれを投稿することを意味します。誰かがこれを削除するか、注意を喚起するために投票できますか？

16 normalization 

データベースの正規化スキルを磨きたい。質の高い初心者から上級者向けのエクササイズ（ソリューションを含む）は、Webのどこで見つけることができますか？

13 normalization 

2番目の正規形（2NF）に問題があり、Googleを使用して解決することができませんでした。私は教師であり、生徒に間違ったものを教えたくないので、それは私を夢中にさせています。 5つのフィールドを持つテーブルを作成しましょう。 成績= {StudentName、SubjectCode、SubjectName、#Exam、Grade} 依存関係は次のとおりです。 StudentName、SubjectCode、＃Exam-> Grade SubjectCode-> SubjectName SubjectName-> SubjectCode したがって、候補キー1は{StudentName、SubjectCode、#Exam}であり、候補キー2は{StudentName、SubjectName、#Exam}です。 プライム属性は{StudentName、SubjectCode、SubjectName、#Exam}であり、非プライム属性はGradeです 2番目の標準形式の定義によれば、非プライム属性は候補キーの一部に依存できません。唯一の非プライム属性（グレード）は候補キーの一部に依存しないため、この表は2NFにあるように見えます。 問題は、何かがおかしいと思うことです（そして、私は間違っているかもしれません）。被験者は自分のテーブルを持つべきだと思います。 成績= {生徒名、件名コード、＃試験、成績} サブジェクト= {Subject Code、SubjectName} しかし、2NFはこれを生成しません。3NFは非プライム属性間の依存関係に関するものであるため、これも生成しません。しかし、冗長性がないため、これは正しい結果であるように思えます。 非プライム属性が「候補キーではない属性」として定義されている場合、2NFが望ましい結果を生成すると思います。しかし、私はこれを何度もチェックしており、非プライム属性は「候補キーに一致しない属性」として定義されています。 私は何を間違えていますか？

13 database-design  normalization  relational-theory 

レコードの統計データの大規模なセットがあると考えてください。例：20〜30 INTカラム。セット全体が1つのレコードに属しているため、セット全体を1つのテーブルに保持するか、1対1の関係で接続された別のテーブルを作成する方が良いでしょうか。 前者の利点はJOIN、対応するレコードのすべての統計データを回避して迅速にアクセスできることです。 後者の利点は、カラムを整頓することです。最初の列は読み取り中心で、2番目の列は書き込み中心です。もちろん、行レベルのブロッキングでInnoDBを使用しているので、パフォーマンスに大きな影響はないと思います。 一般に、1つのレコードに対して異なるデータセットを分離することが実用的かどうか知りたいですか？

12 mysql  database-design  innodb  normalization  relational-theory 

2週間ごとに、システムは会社の請求書を生成します。 会社は毎月1日と16日に請求書を受け取ります。（2週間ごとにCron Jobを介して実行されます。注文テーブルをスキャンし、「請求書」テーブルに追加します。別の方法はありますか？） 表には顧客の注文のリストがあり、ordersそれが所属する会社も示しています（orders.company_id） invoiceテーブルには、からの注文の総コスト計算orders表を。 私は、合理的な請求書追跡を設計する方法を理解しようとしています。会社によっては料金を送ってくれる場合もあれば、料金を送ってくれる場合もあります（invoice.amount） 次のもので請求書を追跡する必要があります。 会社が私に金額を送ったとき いつ会社に送金しましたか 会社から受け取った金額 会社にいくら送ったか 全額を受け取りましたか（受け取っていない場合、DBで何を更新する必要がありますか？） 請求書のステータス（送信済み、キャンセル済み、受領済み金額、送信済み金額） ここに私が思いついたデータベース設計があります： 会社のテーブル mysql> select * from company; +----+-----------+ | id | name | +----+-----------+ | 1 | Company A | | 2 | Company B | +----+-----------+ 顧客は私のウェブサイトから会社を選択できます。 注文表 mysql> select * from orders; +----+---------+------------+------------+---------------------+-----------+ | id …

11 mysql  database-design  normalization  transaction 

履歴を追跡したい特定のフィールドと、履歴を追跡したくない特定のフィールドを持つオブジェクトがあるとします。正規化の観点からは、次のスキーマで問題ありません。 CREATE TABLE MyObject AS ( MyObjectId INT IDENTITY NOT NULL PRIMARY KEY, MyObjectField1 VARCHAR(100) NOT NULL, MyObjectField2 VARCHAR(100) NOT NULL, MyObjectField3 VARCHAR(100) NOT NULL, MyObjectTrackedField1 VARCHAR(100) NOT NULL, MyObjectTrackedField2 VARCHAR(100) NOT NULL, MyObjectTrackedField3 VARCHAR(100) NOT NULL, ) CREATE TABLE MyObjectHistory AS ( MyObjectHistoryId INT IDENTITY NOT NULL PRIMARY KEY, …

11 database-design  normalization