3

I'm having a problem with my students using multi-valued fields in access and getting confused about normalisation as a result.

Here is what I can make out. Given a 1-to-many relationship, e.g.

Articles    Comments
--------    --------
artID{PK}   commID{PK}
text        text
            artID{FK}

Access makes it possible to store this information into what appears to be one table, something like

Articles
--------
artID{PK}
text
comment
   + value

"value" referring to multiple comment values for the comment "column", which access actually stores as a separate table. The specifics of how the values are stored - table, its PK and FK - is completely hidden, but it is possible to query the multi-valued field, e.g. in the example above with the query

INSERT INTO article( [comment].Value )
VALUES ('thank you')
WHERE artID = 1;

But the query doesn't quite reveal the underlying structure of the hidden table implementing the multi-valued field.

Given this (disaster, in my view) - my problem is how to help newcomers to database design and normalisation understand what Access is offering them, why it may not be helpful, and that it is not a reason to ignore the basics of the relational model. More specifically:

  • Are there better ways, besides queries as above, to reveal the structure behind multi-valued fields?
  • Are there good examples of where the multi-valued field is not good enough, and shows the advantage of normalising explicitly?
  • Are there straightforward ways to obtain the multi-select visual output of Access multi-values, but based on separate, explicit tables?

Thanks!

4

6 に答える 6

4

この機能を使用したことがないため、この機能の使用についてアドバイスすることはできません。ただし、使用しない理由を説明できます。

  • 自分のしていることを完全にコントロールしたい。これは多値フィールドには当てはまらないため、使用しません。

  • この機能は拡張できません。たとえば、コメントに日付フィールドを追加したい場合はどうしますか?

  • Access (バックエンド) データベースを「大きな」データベース (SQL Server、Oracle) にアップサイズする必要がある場合があります。これらのデータベースには、そのような機能はありません。多くの場合、どのデータベースを使用する必要があるかを決定するのは顧客です。最近、クライアントが Oracle サーバーを削除することを決定したため、Oracle バックエンドを使用する Access アプリケーション (フロントエンド) を SQL サーバー バックエンドに移行する必要がありました。したがって、一般的な機能のみを使用するように制限することをお勧めします。

  • ルックアップ テーブルの編集などの一般的なタスクのために、一般的なフォームを作成しました。私の既存のソリューションは、多値フィールドでは機能しません。

  • 開発者のサイトのデータベースの構造の変更をクライアントのサイトのデータベースと同期する (自作の) ツールがあります。このツールは、多値フィールドを処理できません。

  • テーブルに対する SELECT、INSERT、UPDATE、および DELETE 権限を付与したり、それらを取り消したりできるセキュリティ管理ツールがあります。繰り返しますが、管理ツールは多値フィールドでは機能しません。

  • コメント用に別のテーブルを用意すると、(テーブルを開いて) すべてのコメントをすばやく調べることができます。これは、多値フィールドでは実行できません。

  • データベース ダイアグラムでは、記事とコメントの間に 1 対 n の関係はありません。

  • 別のテーブルを使用すると、削除を詳細テーブルにカスケードするかどうかを選択できます。そうしないと、コメントが添付されている限り、記事を削除できません。これは、コメントが誤って削除されないように保護する場合に適しています。

于 2013-01-20T17:12:14.680 に答える
2

技術的な議論は興味深いものです。本当の問題は学生の理解にあると思います。これは Access で利用できるため、学生はそれを使用します。最初は、いくつかの設計上の問題に対する簡単な解決策を提供するでしょう。ネガは、後でデータを使用しようとしたときに発生します。問題を示す単純な例は、一部の学生に多値フィールドの使用を避けるよう説得するでしょうか? おそらく、データを別のより使いやすい形式で保存する例が役立つでしょうか?

幸運を ！

ピーター・ブラード

于 2013-01-21T10:06:37.700 に答える
2

物理的な関係と論理的な関係の違いを理解することが重要です。今日、インターネットおよび Web サービス (SOAP) 全体が、本質的に多値であるデータ形式を実現しています。

リレーショナル データベース (Access など) で多値データを表現する場合、バックグラウンドでは従来の (そして正当な) リレーションを使用しています。そのため、Access での複数値列の使用は、実際には正当なリレーショナル モデルであることを強調することはできません。

テーブルが公開されていないという事実は、この問題を否定するものではありません。実際、請求書 (マスター レコードと繰り返しの詳細) を XML データ キューブとして表すと、次の 2 つのことがわかります。

1) Access のようなリレーショナル データベースを使用してその請求書を作成して表すことができます。2) 正規化されたそのようなリレーショナル データ モデルは、単一の xml 文字列として表すこともできます。3) XML レコード (または文字列) の削除は、子行 (請求書の詳細) のカスケード削除が発生しなければならないことを意味します。

したがって、SharePoint を処理するために複数値フィールドが Access に追加されたのは事実ですが、そのようなデータをリレーショナル データベースにマップできることを理解することが最も重要です (これができない場合、Access はその XML を使用できません)。 ACCESS CURRENTLY DOES RIGHT NOW としてリレーショナル データベース テーブルを使用するデータ)。

XML や SharePoint などの Web では、そのようなデータを消費、管理、および利用する必要性が広まっているだけでなく、実際にはインターネットの基本的な要素になっています。

ますます多くのデータが複雑な性質を持つようになるにつれて、多値データの使用が爆発的に増加することがわかりました。いわゆる「流行」のインターネットを使用した人は、実際には非常に多くの場合 XML であり、本質的に複数の値 (複雑) であるデータに依存し、使用しています。

論理的な (物理的ではない) リレーショナル データ モデルが保持されている限り、多値列を使用してそのようなデータを表すことができます。これはまさに Access が行っていることです (リレーショナル データ モデルを複雑なモデルにマッピングしています)。複雑な (xml) データ モデルは必ずしも本質的にリレーショナルである必要はないことに注意してください。ただし、そのようなデータを Access にマップする場合、複雑な多値モデルはリレーショナル データ モデルに準拠する必要があります。

これはまさに Access で起こっていることです。

このような正確で正当な数学リレーショナル モデルが公開されていないという事実は、ここではほとんど問題になりません。Excel は使用されているバイナリ コードを公開していないため、ユーザーはコンピューターについて決して学ばないのではないでしょうか? あるいは、コンピューターがどのように機能するかを正しく学ぶために、アセンブラーでプログラミングする必要があるかもしれません。

結局のところ、誰が気にし、なぜこれが問題になるのでしょうか? 今日、人々がオートマチック車を運転しているという事実は、その車を操作するために異なるギアを使用しているという概念を捨てるものではありません. 誰かがオートマチック車を運転したり、この場合は複雑なデータを使用したりするために、社会全体を閉鎖するという考えは、私たちにとっては銀河系のばかげたものです。

そのため、多値データをクエリするための SQL の拡張機能が Access に存在することを覚えておいてください。ただし、前述のように、そのようなテーブルを公開するには、カスケード削除を変更したり混乱させたりしないようにする必要があります.そのようなデータを表す関連テーブル。

つまり、関連するテーブルを使用して複雑なデータ モデルを表すことができます。ユーザーが参照整合性オプションを操作する機能を削除する必要があります。RI オプションは、非表示のテーブルに設定されたままにしておく必要があります。そうしないと、そのようなデータは、それが消費された XML または複雑なデータ モデルに戻ることができなくなります。

前述のように、ガソリンが酸素とどのように反応して自動車の運転を学習するか、ワード プロセッサを使用してリレーショナル モデルを学習し、基礎となるテーブルを公開することをユーザーに教えられることに関しては、ここではほとんど意味がありません。

ただし、このようなテーブルが公開されていることに関してここで述べられている点は、正当な懸念事項です。

本当の問題は、SQLサーバーとOracleなどは、アクセスがそのようなデータを消費できる一方で、その複雑なデータを消費または表現できないことです。

前述のように、複雑なデータ船はずっと前に出航しました! XML、soap、およびインターネットの基本技術は、この複雑なデータ モデルに基づいています。

実際、SQLサーバー、Oracle、およびほとんどのデータベースは、ユーザーがリレーショナル形式でそのようなデータを作成およびモデル化する必要なしに、この多値データを消費することができず、それを表すことができません.これは、SQLサーバーなどの大きな欠点です.

Access は、このデータを消費する能力において単独で存在します。

したがって、スマートフォン、iPad、または Web を使用していた人は、複雑なデータを使用して構築された基本的なテクノロジを使用していることになります。これは、Access によって可能になったものです。

ますます多くのデータが本質的に複雑になっていることを考えると、業界の他の企業もそれに追随しなければならなくなる可能性があります。データベース業界が変わらなければ、主流の従来のリレーショナル データベース システムは、そのようなデータの保管場所にはなりません。

現在、関連するテーブルにデータを保存しない傾向が急速に進んでおり、SharePoint のような製品や Google ドキュメントでさえ、この概念を証明しています。そのため、Access は市場の圧力に反応しているだけであり、他のデータベース ベンダーもそれに追随するか、インターネットと呼ばれる「流行」の一部であることを単にあきらめなければならない可能性があります。

XML と複雑なデータ構造は現在、業界の定番であり、事実です。これは、私たち全員が逃げるべき問題ではなく、実際に受け入れるべき問題です。

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
于 2013-01-21T01:35:48.000 に答える
1

MS Access は、データベース管理を簡素化し、多くの複雑さを抽象化するという素晴らしい仕事をしています。ただし、これにより、dbms の概念の学習が少し難しくなります。MySQL (または sqlite) などの他の「標準」dbms ツールを使用してみましたか。学習の観点からは、それらの方が優れている可能性があります。

于 2013-01-20T16:32:06.473 に答える
0

この投稿が古いことは知っています。しかし、このトピックに関して私が見た他のすべての投稿とまったく同じではありません。これには、複数の値を持つフィールドを使用するための良いケースを作っている人がいます...

Access について理解しようと懸命に努力している者として、Multi Valued Fields の使用に賛成または反対する議論は非常に苛立たしいものだと思います。

私はそれをすべて整理しようとしていますが、誰もが反対する場合、代替方法は何ですか? すべての検索結果で、誰もが多値フィールドとコントロールの使い方を教えているか、それらがどれほど恐ろしく、どんな間違いであるかを教えているようです。多くの人がそれらの代替案を参照していますが、「ここに例があります」と言う人は誰もいません。私はこれらのことについて学ぶためにここにいます。これらのフォーラムの多くの人にとって、これはより単純な概念であることはわかっていますが、実際にいくつかの例を使用して確認することができます.

進路を決めなければならないところに来ています。複数の値を持つフィールドと代替手段を使用する例と、コントロールを使用して複数の値を選択する例を比較するのは素晴らしいことです。

複数の項目を選択できるコンボボックスの機能は、Access でしか利用できないのでしょうか?

于 2015-03-03T17:59:38.220 に答える