SQL Serverでのデータベース構築ブロックの理解

このブログのような3

Peter Avila November21, 2012

すべての家は、キッチン、少なくとも一つのバスルームとベッドルーム、フロントドア、配管システム、および他のものを持っています。 これらの事は異なった方法でそして異なった数で異なった家を作り出すために整理することができる。 だからそれはデータベースと一緒です。 すべてのデータベースに共通している特定のものがあります。 この記事では、すべてのデータベースを構成するビルディングブロックを紹介し、それらがどのように組み立てられているかを示します。 また、ビルディングブロックを使用するときに従う必要がある3つのルールについても説明します。

この記事で紹介されている資料は、データベースとのあらゆる種類の相互作用を持っている人にとって価値があるはずですが、それは非常に初歩的 データベース設計のより包括的な議論については、私の記事、データベース設計への直感的なアプローチを参照してください。

ビルディングブロックに到達する前に、ミニワールドという用語を理解するのに役立ちますので、少し時間をかけてみましょう。

データベースはミニワールドのモデルです。 ミニワールドは、医療事務所、小売業、図書館、または他の多くのものにすることができます。 ミニワールドに関する情報が必要なときは、それをモデル化するデータベースに目を向けます。

あなたが予約のために医者に行くとしましょう。 あなたが予定を持っていることを受付係に伝えると、受付係はモデル（データベース）であなたの予定を見つけようとします。 モデルがミニワールドで最新の状態に保たれている場合は、予定があることを確認できるはずです。 同様に、ビジネスが過去6ヶ月間に大量の顧客のどれが注文されていないかを知りたい場合、そのミニワールドで最新の状態に保たれていれば、ミニワールドのモデルに目を向けることができます。

ミニワールドは、ビジネス全体であったり、銀行支店や営業部門などのビジネスの一部であったりすることができます。

データベース設計者が最初に行うことは、そのミニワールドのモデルを設計することであるため、ミニワールドを理解することです。 そして、ミニ世界を理解するために、設計者はデータベースの組み立てに入るビルディングブロックを識別することから始

ビルディングブロック

1. 実体

実体とは、ミニワールドに存在し、私たちにとって興味のある特性を持っているものです。 たとえば、学校登録のミニワールドには、学生エンティティ、コースエンティティ、教員エンティティなどがあります。 学生は、名前、住所、Gpa、および私たちに興味のあるその他の特性を持っています。 コースには、タイトル、単位、料金などがあります。 また、講師には名前、住所、資格などがあります。 エンティティは一意です。 それぞれの生徒はユニークな存在です。 各コースは一意のエンティティであり、各インストラクターは一意のエンティティです。

実体は物理的なものである必要はありません。 入学に触れたり、見たり、匂いを嗅ぐことはできませんが、それは入学ミニの世界に存在し、入学日、入学した学生、入学したコース、最終学年など、私たちに関 販売は、物理的なコンポーネントを持たないが、私たちにとって関心のある特性（販売日、顧客、販売員、注文合計、出荷方法、支払い条件など）を持つエンティティの他の例である。).

2. エンティティタイプ

同じタイプのエンティティは、1つのエンティティタイプに属します。 エンティティ型は、その型のエンティティのセットです。 Studentエンティティタイプは、すべての学生のセットです。 コースエンティティタイプはすべてのコースのセットであり、教員エンティティタイプはすべての教員のセットです。

エンティティ型は、この記事の中で最も重要な概念です。 それらはデータベース内のテーブルになります。

3. 属性

エンティティの属性は、私たちにとって関心のあるそのエンティティの特性です。 すでに述べたように、学生の属性には名前、住所、GPAなどが含まれます。 コースには、名前、単位、所属する部門などがあります。 そして、他のエンティティタイプと同様に。

ビルディングブロックの組み立て

これらのビルディングブロックはデータベース内でどのように表現されていますか？ 各エンティティタイプは、データベース内のテーブルによって表されます。 そのテーブルでは、個々の行は一意のエンティティであり、列は属性です。 クレジットカードのエンティティタイプを表すテーブルの例を次に示します:

ビルディングブロックのルール

ビルディングブロックを操作するときは、データベースオブジェクトの操作を容易にするだけでなく、データの異常を防ぐ特定のルールに従うことが重要です(データの異常はこの記事の範囲外ですが、私の記事”データベース設計への直感的なアプローチ”で詳細に説明しています)。

ルール1:各テーブルは1つだけのエンティティタイプを表す必要があります。

上記の学校入学ミニワールドのデータベースには、次の表が必要です: 学生、コース、インストラクター、登録など、そのミニワールドで特定されたエンティティタイプごとに1つ。 医学のオフィスの小型世界のデータベースは医者のテーブル、忍耐強いテーブル、任命のテーブル、薬物のテーブル、および他を必要とする。 エンティティタイプごとに1つのテーブル。

このルールには例外があります。 準備をしなさい、ここに脳のツイスターが来る: 2つのエンティティ型が同じ属性を共有し、一方のエンティティ型のエンティティがもう一方のエンティティ型のエンティティでもある場合(一方のエンティティが両方のエンティティ型のメンバーである場合)、2つのエンティティ型を1つのテーブルで表すことができます。 アドバイザーは教授でもあり、同じ属性（教授/顧問名、教授/顧問資格など）を持つため、教授エンティティタイプと顧問エンティティタイプの両方を1つのテーブルで表すことができます。 そして再び: これは、すべてのサブフォルダエンティティもフォルダエンティティであり、同じ属性(フォルダタイトル、フォルダサイズ、フォルダ内のアイテム数、親フォルダなど)を共有しているためです。 Employeesエンティティとmanagerエンティティは同じ属性を持ち、managerエンティティもemployeeエンティティであるため、Employeeエンティティ型とManagerエンティティ型の両方を同 ルールに対するこの例外は、別のブログでより詳細に検討されています：SQL Server–自己結合クエリ。

ところで、このルールは、テーブルに名前を付けるための適切な方法が単数形である理由であることに注意してください。 テーブルは単一のエンティティ型を表します。

ルール2:すべての列はアトミックでなければなりません。

なぜデータベーステーブルにCityとStateの列があり、addressの列が一つしかないのか疑問に思ったことがありますか？ たぶん、あなたはなぜ住所番号の列がないのか疑問に思ったかもしれませんが、住所通りのタイプ（Blvd.、Avenue、等。）、別のアパート番号など。 これらの列は通常、すべて単一のアドレス列にまとめられているのはなぜですか？ これらすべての質問に対する答えは、原子性の理解にあります。

列がアトミックであると言うとき、それ以上細分化することはできず、意味を保持することを意味します。 列を作成し、それを都市と州と一緒に住所を含むMegaAddressと呼びましょう。

しかし、その列の部分（都市による検索、州による並べ替え、住所の部分だけの出力など）で検索、並べ替え、その他の操作を行うため、その列のサブディビジョンには独自の意味があると言うことができます（StreetAddress、City、およびState）。 したがって、MegaAddressはアトミックではありません。 より良いテーブルは次のようになります:

さて、StreetAddress列はどうですか？ それをさらにStreetNumber、StreetName、およびStreetTypeに細分する必要がありますか？ 道路番号を並べ替えたり、すべての道路や道を検索したりしない場合、その細分化で重要なことをしない限り、列はそのままアトミックになります。 しかし、これらのことを行うと、列はアトミックではなく、説明されているように細分する必要があります。

ルール3:列は複数値にすることはできません。

いくつかのエンティティ型には、複数値の属性、または複数の値を持つことができる属性が含まれています。 コーステーブルには、前提条件と呼ばれる属性が存在する可能性があります。 コースエンティティは複数の前提条件を持つことができるため、前提条件属性は複数値属性です。 コースエンティティタイプのテーブルを作成すると、前提条件属性をテーブル内の列として表すことができなくなります。 複数値の属性を適切に表現するには、別のテーブルを作成し、一対多の関係を使用して元のテーブルに関連付ける必要があります（関係については、Interface Tachnical Training SQL100: Transact-SQLとSQL250の概要：開発者のためのTransact-SQLと私の記事では、データベース設計への直感的なアプローチ）。 複数値属性の他の例には、従業員の扶養家族、医師の資格などがあります。

ルール3は、特定のエンティティ（テーブル内の行）に対して、各列には1つの値しか存在できないことを示しています。

概要

この記事では、データベースがモデル化するビジネスやその他の環境の側面としてのミニワールドの概念を紹介しました。 この投稿では、データベーステーブルは、行が同じ型の個々のエンティティを保持し、列がそれらのエンティティの属性を表す単一のエンティティ型を表す テーブルに関する三つのルールを導入した。 ルール1では、テーブルは単一のエンティティ型を表す必要があると述べています。 ルールの例外は、2つのエンティティ型が同じ属性を共有し、1つのエンティティ型のエンティティが他のエンティティ型のメンバーである場合です。 その場合、両方のエンティティ型を同じテーブルで表すことができます。 ルール2では、テーブルのすべての列はアトミックでなければならず、列を細分化することはできず、ミニワールドでは意味を保持することができます。 最後に、ルール3では、テーブル内の列を複数値にすることはできないと述べています。

Peter Avila

SQL Server Instructor–Interface Technical Training

Phoenix,AZ