新しいデータベースの作成
新しいデータベースは、作成するすべてのテーブル、フォーム、レポート、クエリ、マクロ、およびモジュー Access2010では、リボンの”ファイル”タブをクリックして新しいデータベースを作成できます。 次に、”新規”コマンドをクリックします。 次に、”利用可能なテンプレート”セクションで”空白のデータベース”の選択肢を選択します。 Access2007では、”Microsoft Accessの使用開始”ようこそ画面の”新しい空白のデータベース”セクションの”空白のデータベース”ボタンをクリックするだけで、新しい空白のデータベースを 画面の右側に表示される”空白のデータベース”ペインで、”ファイル名：”テキストボックスにデータベースの名前を入力できます。 データベースファイルが保存されるデフォルトのフォルダを変更する場合は、”ファイル名：”テキストボックスの右端にある小さなフォルダボタンをクリ このダイアログボックスを使用して、新しいデータベースファイルに名前を付け、ファイルを保存する場所を選択します。 準備ができたら、”OK”ボタンをクリックしてダイアログボックスを閉じます。 次に、「作成」ボタンをクリックして新しいデータベースファイルを作成します。 これが完了すると、新しい空のデータベースがメインアクセスインターフェイスに表示されます。
データベースのフローの概要
データベースは、その設計においてシンプルで論理的で簡単でなければなりません。 一般に、フォームを使用してテーブルに情報を入力します。 その後、データはこれらのテーブルに格納され、これらのテーブルは必要に応じて相互に関連しています。 クエリを使用して、データベース内のテーブルから特定の情報を取得できます。 クエリは、多くの場合、あなたが要求した情報を表示することができますレポートの基礎を形成します。 このシステムが整ったら、マクロとモジュールを使用してデータの入力、保存、取得に関連するプロセスを簡素化し、合理化することで自動化できます。 これが、データベースを使用する主な理由です：データの入力、保存、および取得。
データストレージ
アクセスの’Flat-File’メソッドは、リレーショナルデータベースアプリケーションです。 では、リレーショナルという用語は何を意味し、これはどのように重要ですか？ リレーショナルという用語は、データベーステーブル内にデータを格納するために使用される方法を説明します。 ただし、データストレージのリレーショナルモデルを、より使い慣れた別のストレージ方法である’flat-file’メソッドと対比することで、理解する方が簡単な場合があ
情報は大きなフラットファイルに頻繁に格納されます。 たとえば、会社の顧客情報を格納するデータベースファイルを作成するとします。 まず、記録する顧客のさまざまな属性をリストすることから始めます。 “名”、”姓”、”会社名”、およびその他の関連する情報のような顧客情報を記録することができます。 おそらく、Microsoft Excelのようなアプリケーションでテーブルを作成し、記録する情報ごとに列を作成することができます。 その後、列の下の行に各顧客の情報を一覧表示して、基本テーブルを作成できます。 次の例のように見えると仮定します。
多くのタイプのデータベースでは、前のページに示されている構造がうまく機能します。 これは’フラットファイル’リストまたはテーブルです。 このタイプのデータベースを使用するときに行っていることは、単一のエンティティ（この例では顧客）に関する「姓」、「姓」、「住所」などの単一の情報を記録するこ このタイプのデータ構造がこの例でうまく機能する理由は、各エンティティ（顧客）に対して、エンティティと”1対1″の関係を持つ情報のみを記録してい
だから、エンティティ（顧客）とあなたが記録しているデータ（”名”、”姓”など）との間のこの”1対1″の関係の意味は何ですか？)? これが意味するのは、各エンティティまたはサブジェクト（この場合は顧客）について、そのエンティティに関する情報を記録しているだけで、”答えは1つしかない”ということです。 たとえば、各顧客には1つの「名」と1つの「姓」しかありません。”彼らは唯一の会社のために働くだろう”。「したがって、「1対1」という用語は、テーブルの対象（顧客）とエンティティについて収集されるデータとの関係を指します。 各（1つの）顧客について、列に記録する可能性のあるデータは1つしかないため、データとエンティティの関係は「1対1」であると言います。「これが作成しようとしているデータベースのタイプであれば、単純なMicrosoft Excelテーブルがうまく機能します。
問題は、”販売”のような、より複雑なエンティティまたはサブジェクトをモデル化するために”フラットファイル”アプローチを使用しようとすると発生し始”たとえば、販売データを含めるために、最後の”フラットファイル”データベースから顧客データベースを拡張するとします。 ここで、すでに収集されている情報に加えて、顧客によって行われた各注文も記録したいとしましょう。
まず、記録したい各販売に関するデータを一覧表示することから始めます。 この例を単純にしておくと、「販売日」、「購入した品目」、「購入した品目の数量」、および各品目に対して支払われた「金額」を記録することにしたと仮定します。 次の列を’flat-file’データ構造に追加することもできます。
これは一見するとうまくいくように見えるかもしれません。 ただし、ファイルにレコードを入力し始めると、すぐに問題が発生し始めます。 まず、顧客が購入するたびに、「姓」、「姓」などをすべて再入力する必要があります。 再び情報。 これだけでは十分に刺激されます。
この時点でよく提案される解決策の1つは、購入されたアイテムごとに別の行（すべての冗長情報を含む）を1回入力することです。 しかし、あなたはすぐにこのファイルは、テーブルの下に非常に迅速に成長することがわかります,あなたはまた、購入した各項目のための冗長な顧客デー これはエレガントな解決策ではなく、必然的にデータ入力を実行する人の時間と労力の両方を無駄にします。
この時点でよく提案される別の解決策は、追加の列を作成することです（”Item1″、”Item2″、”Item3″、”Quantity1″、”Quantity2″、”Quantity3″など）。）代わりに、情報の追加の行を入力する必要があります。 これは良い代替ソリューションのように見えるかもしれませんが、誰かが100個のアイテムを購入したときに何をしますか？ 購入したアイテムごとに3つの列（「アイテム」、「数量」、「金額」）のセットを実際に作成し、300列を超えるテーブルを作成しますか？ 人が1つの項目だけ発注すれば貴重な記憶空間を無駄にするそれらを単に空白に残すか。 このソリューションでは、縦方向の成長（下方向）を柱状の成長（横方向）に置き換えるだけです。 これはエレガントな解決策でもありません。
では、なぜ今、以前に問題がなかったのですか？ 答えは、ファイル内の「1対1」のデータ関係をモデル化しようとしていないことです。 販売情報を記録することは、顧客情報を記録することよりも単純に複雑です。 あなたが今記録しようとしているのは、「1対多」の関係と呼ばれるものです。 基本的に、各エンティティ（顧客）について、顧客ごとに複数回発生する可能性のある列（たとえば、注文された「アイテム」）にデータを記録しようとしています。 各顧客が単一の項目だけを購入できれば残念な状態にある。 販売では、各顧客が多くのアイテムを注文する可能性があるという事実を許可する必要があります。 顧客と購入したアイテムとの関係は、”1対多”の関係です。 “1対多”の関係をモデル化しようとしていることがわかったら、記録するすべての情報を単一のテーブルに配置しようとするデータストレージの”フラットファイ