どうかわかりません。私はこのトピックについていくつかの読み物をしましたが。私が知っているのは、データベース内のデータをより効率的で扱いやすくするために使用されるということだけです。また、ディスク容量を節約するためにも使用できます。最後に、正規化を使用した場合。さらにテーブルを生成する必要があります。
今、私は尋ねたいことがたくさんあります。まず、正規化は、ディスク領域またはデータベースが占有する領域を節約するのにどのように役立ちますか。次に、1 つのクエリのみを使用して複数のテーブルにデータを追加することは可能ですか。助けてください、私はあなたから学びたい初心者です。ありがとう。
わかりました、いくつかのこと：
非正規化データ: この段階では、データは真の表形式 (「リレーショナル」) ではありません。表形式が実際に何を意味するかについては多くの議論があり、専門家は互いに意見を異にしています。しかし、ほとんどの人は、複数の値を持つ属性 (= 1 つの行に値としてリストを含むことができる列) がある場合、または繰り返しグループ (= 同じものを格納するための複数の列または列の複数のグループ) がある場合、データが正規化されていないことに同意します。データの種類)
複数の値を持つ列の例: person (first_name, last_name, phonenumbers)
繰り返しグループの例: person(first_name, last_name, child1_first_name, child1_birth_date, child2_first_name, child2_birth_date..., childN_first_name, childN_birth_date) ここで、person テーブルには、その人の子供を格納するためのいくつかの列ペア (child_first_name, child_birth_date) があります。
order (shipping_address, billing_address) のようなものは繰り返しグループではないことに注意してください: 請求先住所と配送先住所は似たようなデータかもしれませんが、それぞれが注文に対して独自の役割を持っており、どちらも注文の異なる側面を表しているだけです。child1 から child10 はありません - 子供には特定の役割がなく、子供のリストは可変です (事前にいくつのグループを予約する必要があるかわかりません)。
多値列と繰り返しグループのどちらの場合でも、基本的に「ネストされたテーブル」構造、つまりテーブル内のテーブルがあります。これらのいずれも発生しない場合、データは 1NF (第 1 正規形) であると言われます。
1NF は、構造特性に関するものです。つまり、データの表形式です。後続のすべての正規形は、冗長性の排除に関係しています。冗長性は、同じ情報が独立して複数回格納される場合に発生します。冗長性は悪いです: ある事実を変更したい場合、複数の場所で変更する必要があります。それらのうちの 1 つをチャンスにするのを忘れると、データに矛盾が生じます。データ自体が矛盾しています。
冗長性を排除できる多くのプロセスがあり、それぞれが 1nf から 6nf まで、より高い正規形につながります。ただし、通常、ほとんどのデータベースは 3nf (または、boyce-codd 正規形と呼ばれる BCNF と呼ばれるバージョンの lsight バリエーション) で適切に正規化されています。2nf と 3nf を検討する必要がありますが、原則は非常に単純です。
機能依存性とは、列の値が別の列から派生できることを意味します。簡単な例:
order_item (order_id、item_number、customer_id、product_code、product_description、amount)
(order_id, item_number) がキーであるとしましょう。product_code と product description は機能的に相互に依存しています。ある特定の product_code については、常に同じ製品説明が見つかります (製品説明が product_code の関数であるかのように)。問題は次のとおりです。特定の製品コードの製品説明が変更されたとします。その製品コードのすべての注文を変更する必要があります。1 つだけを忘れると、データベースに一貫性がなくなります。
これを解決する方法は、(product_code, product_description) をキーとして (product_code) を持つ新しい製品テーブルを作成し、すべての製品フィールドを順番に格納する代わりに、製品テーブルの行への参照のみをorder_item レコード (この場合、order_item は product_code のみを保持する必要があります。これは、product テーブルの行を検索して product_description を見つけるのに十分です)
ご覧のとおり、このソリューションを使用すると、実際にスペースを節約でき (製品を注文する各 order_item にこれらすべての製品説明を保存しないことにより)、より多くのテーブルを取得できます (order_item から製品を分割します)。これは、ディスク容量を節約するためではなく、冗長性を排除してデータの保守を容易にするためです。説明を変更するには、製品テーブルの 1 つの行を変更するだけでよいためです。
StackOverflow については、すでに同様の質問がたくさんあります。
それらの束については、右側の関連サイドバーを見てください。これで始められます。
具体的な質問について:
正規化により、冗長なデータ ストレージが削減され、ディスク スペースが節約されます。これには別の利点があります。データベースに特定のエンティティ属性の複数のコピーがある場合、それらが同期しなくなる可能性がありますが、正規化されたデータベースがあり、参照整合性を使用している場合、これは発生しません。
INSERTステートメントは 1 つのテーブルのみを参照します。挿入ステートメントの ATRIGGERは、他のテーブルに行を追加できますが、トリガーを生成したテーブル内の列以外のデータをトリガーに提供する方法はありません。
親テーブルに行を挿入した後に従属行を挿入する必要がある場合は、関数を使用して、セッションの最後のステートメントLAST_INSERT_ID()の自動生成された主キー値を取得します。INSERT
データベースのスキーマの作成を開始するときに、これを学習すると思います。
データベースの別の場所に存在するフィールドを追加する場合は、逆に考えてください。
逆に言えば、フィールドを変更する必要がある場合、いくつのクエリを実行する必要があるかを自問してください。おそらく、列の内容を変更するには、クエリを 2 回または X 回実行する必要があるという答えが得られます。シンプルにしてください。つまり、データベースで複製した各コンテンツに ID を割り当てます。
たとえば、列を取るaddress
これは良くない
update clients set address = 'new address' where clientid=500;
update orders set address = 'new address' where orderid=300;
良いアプローチは
create a addresses table
//and run a single query
update addresses set address = 'new address' where addressid=100;
そして、データベーステーブルのどこでもアドレス ID 100 を外部キー参照 (clients+orders) として使用します。このようにして、ID 100 は変更されませんが、アドレスの内容を更新すると、すべてのリンクされたテーブルが取得されます。変化する。
今回はレベル 3 のノーマライゼーションで十分です。
正規化は一連のルールです。フォローすればするほど、データベースの正規化の「レベル」が高くなります。一般に、レベル 3 が求められる最高レベルです。
正規化されたデータは、理論的には、正規化されていないデータよりも「純粋」です。これにより、合理化が容易になり、冗長性がなくなり、データが同期しなくなる可能性が減少します。
ただし、実用的な観点からは、たとえ理論上であっても、正規化されたデータが常に最適な設計であるとは限りません。細かい点がよくわからない場合でも、正規化されたデータを目指すのはそれほど悪い考えではありません。
質問 2 へ: いいえ、1 つのクエリで複数のテーブルにデータを挿入することはできません。INSERT構文
を参照してください。
他の回答に加えて、ここでSOで正規化を検索して、たとえば次の質問を見つけることもできます: MySQLでの正規化