• Articles
• admin

はじめに

データはデータベース内のテーブルに格納されます。 これは、単一のテーブル(図2.1に示すようにフラットデータベースと呼ばれます)または複数の接続されたテーブル(図2.2に示すようにリレーショナルデータベースと呼ばれます)に格納することができます。

各テーブルは、フィールドとレコードで構成されています。 フィールドは、データを記録するカテゴリです。 たとえば、上記の音楽テーブルには、Title、Artist、Duration、Albumなどのフィールドが含まれています。 レコードは、キャプチャされる実際のデータを参照し、各レコードには単一のアイテムのデータが含まれます。 たとえば、Songテーブルでは、各レコードは単一の曲を表し、その曲に関連するすべての情報（アーティストや期間など）が含まれています。

各テーブルには、データベース内の各レコードの一意の識別子を含む主キーと呼ばれる必須フィールドが1つあります。 これにより、テーブル上の特定のレコードを、1つのエントリのみを参照できるように参照できます。 テーブルの既存のフィールドをキーフィールドにすることは可能ですが、データベース作成者は通常、この目的のために新しいフィールドを作成します。 これにより、重複がないことを確認できます。

データベースに異常がある場合がありますが、これらの異常を取り除く方法を学びます。

この章では、リレーショナルデータベースを設計して作成します。 データベースに異常がある場合もありますが、これらを取り除き、正常化に達する方法を学びます。

データベース一言で言えば

データは、原則として1と0に格納されます。 コンピュータは、これらの1と0がどのように編成され、どのように解釈されるべきかを知る必要があります。 これを行うために、コンピュータは、組織されるデータのための特定の順序を記述するデータ構造を利用する。 これにより、コンピュータは、データの異なるビットがどのように関連しているかを理解し、データを正しく解釈することができます。

アルファベットの各文字が文字を表していることがわかります。 あなたが一緒に十分な文字を追加すると、彼らは概念を表す単語（’オレンジ’や’愛’のような）を形成します。 したがって、2人以上の人々の間で有用な情報の通信を可能にする–でも、距離を越えて。

データと命令を通信するために、数字、文字、文字、特殊記号、音/フォニックス、画像などのデータは、コンピュータ可読形式（バイナリ）に変換されます。 このデータの処理が完了すると、人間が読める形式に変換され、処理されたデータは意味のある情報になります。 情報は知識になり、異なる目的のために人間によって理解され、使用されることができます。

UNIT2.1優れたデータベースの特性

すべての優れたデータベースは、貴重なメタデータとデータから始める必要があります。 第1章では、貴重なデータの特性とそのデータの管理方法について説明しました。 これらは、下の図2.3に示されています:

それでは、優れたデータベースの特性を見てみましょう:

• データベースは、関連するすべてのデータと要件を格納するのに十分な強さでなければなりません。
• は、従業員が特定の部門に関連するように、従業員が部門のために働くなど、関係を使用してデータベース内のテーブルを関連付けることができるはずです。 データベース内の任意の2つのエンティティ間のこのような関係を定義できるはずです。
• 複数のユーザーが、他のユーザーに影響を与えることなく、同じデータベースにアクセスできるようにする必要があります。 たとえば、複数の教師が学習者のマークを同時に更新するためにデータベースで作業することができます。 教師はまた、他の科目のマークを変更することなく、自分の科目のマークを更新することが許可されるべきです。
• 単一のデータベースは、異なるユーザーに異なるビューを提供し、彼の役割に応じて、ユーザーに複数のビューをサポートします。 たとえば、学校のデータベースでは、教師は学習者のマークの内訳を見ることができますが、親は自分の子供のレポートのみを見ることができます–したがって、親のアクセスは読み取り専用になります。 同時に、教師はすべての学習者の情報と評価の詳細に変更権限でアクセスすることができます。 これはすべて同じデータベースで発生する可能性があります。
• データ整合性とは、データベース内のデータがどれほど正確で一貫性があるかを指します。 情報量が多く、誤った情報を持つデータベースは、データの整合性が低いと言われています。
• データ独立性とは、データとそれが使用されているアプリケーション（またはアプリケーション）との間の分離を指します。 これにより、アプリケーション全体を再コンパイルすることなく、アプリケーション内のデータを更新することができます（スペルミスの修正など）。
• データの冗長性とは、データベース内の異なる場所にまったく同じデータがあることを指します。 データの冗長性は、データベースのサイズを増加させ、整合性の問題を引き起こし、効率を低下させ、異常につながります。 データは、複数のテーブルで繰り返されないように格納する必要があります。
• データセキュリティとは、データベース内のデータがクラッシュ、ハッキング、偶発的な削除からどれだけ保護されているかを指します。
• データメンテナンスとは、データベース内のエラーを修正し、異常の発生を防ぐために実行される毎月、毎日、または時間単位のタスクを指します。 データベースの保守は、エラーを修正するだけでなく、潜在的なエラーを検出し、将来のエラーの発生を防止します。

よく実行されたデータベースを整理することにも多くの人々が関わっています。 これらは:

• 企業のニーズに合うようにデータベースを設計および開発する開発者
• 管理者
• データベースの用途をチェックする
• 他の用途へのアクセスを提供する
• データベースを維持するために必要なその他のメンテナンス作業を提供する現在までの
• は、教師や保護者など、データベースを使用するエンドユーザーです。

ユニット2。2データベースの問題

フラットファイルデータベースの計画が不十分で、非正規化されており、一貫性がない場合、データベース内のレコード(テーブル)を挿入、削除、ま これにより、異常が発生し、データベースの拡張に伴ってデータの処理がますます困難になります。 また、データの整合性を維持することが困難になります。 異常が発生したらデータを一貫させようとすることは非常に困難になる可能性があります。

データベースで発生する可能性のある問題には、次の3つのタイプがあります:

• 挿入異常: データベースは、使用できないデータの別の部分も追加されない限り、必要なデータを追加できないように作成されています。 たとえば、そのメンバーが医師に見られるまで、新しいメンバーの詳細を格納できない病院のデータベース。
• 削除異常:データのレコードが正当に削除されると、必要なデータの一部が削除される可能性があります。 例えば、患者の詳細の一部を削除すると、病院データベースから患者のすべての詳細を削除することができる。
• : 誤ったデータを変更する必要がある場合があり、多くのレコードを変更する必要があり、一部の変更が誤って行われる可能性があります。

例2.1データベースで発生する問題

UNIT2.3異常を取り除く方法

異常を防ぐには、データベース内のデータを効率的に整理してデータベースを正常化する必要があります。
関係データベースの発明者であるエドガー-F-コッドによれば、正規化の目標は次のとおりである:

• データベースからすべての冗長（または繰り返し）データを削除する
• 望ましくない挿入、更新、削除の依存関係を削除する
• 新しいフィールドが追加されるたびにデータベース全体を再構築する必要性を減らす
• テーブル間のリレーションシップをより有用かつ理解しやすくする。

正規化は、データの冗長性と挿入、変更、削除の異常を排除するためにテーブルを分解する体系的なアプローチです。 データベース設計者は、不要な重複を排除し、必要なすべての情報への迅速な検索パスを提供する方法でデータを構造化します。 これは、データを表形式にして、重複したデータをリレーションテーブルから削除するマルチステッププロセスです。 効率的なデータベースを作成するために、テーブル、キー、列、および関係を指定および定義するこのプロセスは、正規化と呼ばれます。

正規化すると、データベースが使用する領域の量が削減され、データが効率的に格納されるようになります。 正規化がなければ、データベースシステムは不正確で、遅く、非効率的になる可能性があります。 彼らはあなたが期待するデータを生成しない可能性があります。

実際には、次の要件が満たされるようにデータベースを変更することを意味します:

• 各テーブルには主キーが必要です
• 各レコードには単一値の属性/列（アトミック）が必要です
• 繰り返しの情報グループはありません。

キーは、テーブル間のリレーションシップを確立および識別したり、テーブル内のデータのレコードまたは行を一意に識別したりするために使用されます。 キーは、単一の属性または属性のグループ（compositeprimaryキー）であり、組み合わせがキーとして機能する可能性があります。 キーは、データの任意の行を識別するのに役立ちます。

データベースを設計する場合、次の四つのタイプのキーフィールドがあります:

• 主キー:テーブル上の各レコードを一意に識別するためにデータベース作成者によって選択されたフィールド。 たとえば、音楽データベース内の各曲には、”song_id”という主キーフィールドがある場合があります。
• 代替キー: 主キーとして使用できるが、現在は主キーとして設定されていない一意の値を含むフィールド(例:artist_id)。
• 外部キー:別のテーブルの主キーフィールドの値を含むフィールド。 外部キーは、異なるテーブル間の関係を表示するために使用されます。 たとえば、音楽データベース内の各曲には、”artists”テーブル上の特定のアーティストに曲をリンクする”artist_id”という外部キーフィールドがある場合があります。
• 複合キー: song_idやartist_idなど、テーブル上の各レコードを一意に識別する複数のフィールドの組み合わせ。

この例を使って、主に4つのタイプのキーを理解しましょう:

正規化ルールは、次の正規形に分かれています。

最初の正規形(1NF)

最初の正規形になるテーブルについては、次の四つの規則に従う必要があります:

• 各列には、個別のフィールド/属性が必要です。 テーブルの各列には複数の値を含めるべきではありません。 たとえば、Facebookのステータスの更新のためのデータベース、特に”いいね”に関連するテーブルを想像してみてください。 レコードを分割できないようにするには、それぞれのlikeを別々のレコードに格納する必要があります。 このようにして、各レコードは発生しているか、発生していないかのいずれかになります。 同じようなもののほんの一部しか発生しなかったと言う方法はありませんが、別の部分は発生しませんでした。 ただし、ステータス更新のすべての「いいね」が1つのレコードに格納されている場合、一部の「いいね」が発生している可能性があり、他の「いいね」が発生していない可能性があるため、レコードは割り切れます。
• 列に格納されている値は、同じ種類またはタイプ（ドメイン）である必要があります。 各列に格納される値は、同じ種類または型である必要があります。
• テーブル内のすべての列には一意の名前を付ける必要があります。 テーブル内の各列には、データの取得時や格納されたデータに対するその他の操作の実行時の混乱を避けるために、一意の名前を付ける必要があります。 たとえば、子の名前と親の名前を指定します。’Name’を使用しないでください。
• データが格納される順序は関係ありません。 例えば

• 列名は一意であり、格納されているデータは正しい順序であり、列には異なるタイプのデータが混在していません。 ただし、テーブル内の学習者は複数の科目を選択しています。 このデータは、単一の列にサブジェクト名に格納されています。 1NFごとに、各列には単一の値が含まれている必要があります。

第二正規形(2NF)

第二正規形になるテーブルの場合:

• 最初の正規形にする必要があります。
• そして、それは部分的な依存関係を持つべきではありません。

これは、テーブル内の属性が主キーの一部のみに依存し、キー全体には依存しない場所です。 たとえば、テーブルには、主キーがstudent_idおよび各学習者のsubject_idとして記録されます。 教師の名前だけが主題に依存します。 だから、subject_id、そしてstudent_idとは何の関係もありません。

第三正規形(3NF)

テーブルは、次の場合に第三正規形であると言われます:

• それは第二の正規形です。
• 推移的な依存関係はありません。 推移的な依存関係は、属性/フィールドが主キーに依存するのではなく、他の属性/フィールドに依存する場合に発生します。

これは、同じテーブル内の値間の間接的な関係です。