2

最初の正規形は、行の順序は重要ではないことを示しています。これは、キーの一部として日付が含まれるテーブルが1NFではないことを意味しますか？たとえば、日付/時刻がPKの一部であるティッカー価格の表を考えてみます。この場合、データを日付順に並べ、上位1行を選択することで、最終価格を取得します。これは、1NFを満たすために、テーブルを次のように分割する必要があることを意味します：1）TickerCurrentPrice（ティッカーごとに1行）2）TickerHistoricalPriceありがとう

4

4 に答える 4

4

1NFテーブルそのものではなく、関係を表すテーブルの側面です。

あなたの関係がticket HAS price、それは違反であると言っている場合、単一のレコードを見て、か か1NFを判断することはできません。このチケットのすべての価格を取得し、最後に選択する必要があります。これは の に違反します。ticket HASHAS NOTpricenon-ordering rule1NF

あなたの関係が と言うならticket HAD BEGUN TO COST price ON date、それは1NF大丈夫です。なぜなら、各レコードはそれが言うことを言っているからです: this ticket cost this price from this date .

したがって、このテーブルは、最初の関係を表す1NFときは準拠していませんが、2 番目の関係を表すときは準拠していると言えます。

もちろん、テーブル自体は同じままです。

ただし、テーブルを分割する必要があるという意味ではありません。

の要点は、あるリレーションを別のリレーションに変換するためにrelational databases使用できることです。relational operators

relationの観点からは何RDBMSですか？これは、この関係にあるすべての可能な値のすべての組み合わせを示す表です。

たとえば、 から1まで5の自然数で等式関係を構築する必要がある場合、次の表があります。

1 1
2 2
3 3
4 4
5 5

この表に表示されるすべてのペアは対等な関係にあります。表示されないペアはすべて表示されません。またはは等しくないため、(2, 3)ここには表示されません。(4, 5)

ただし、ペア全体をデータベースに保持する必要はありません。代わりに単一の値を保持し、クエリを記述します。

SELECT n1.number, n2.number
FROM number n1, number n2
WHERE n1.number = n2.number

、同じ結果が得られます。

実際には、通常の形式を使用すると、データベース内に可能な限り単純なSQL関係テーブルを保持し、クエリを使用してそれらからより複雑な関係を構築できます。

あなたの場合、次の方法でクエリを作成 (またはビューを定義) すると:

SELECT ticket, price
FROM mytable
WHERE (ticket, date) IN (
  SELECT ticket, MAX(date)
  FROM mytable
  GROUP BY
    ticket
  )

、あたかもテーブル全体をデータベースに保持しているかのように、 ( ticket HAS price) からリレーション ( ) を取得します。ticket HAD BEGUN TO COST price ON date

于 2009-02-16T16:32:14.073 に答える
2

つまり、データの順序（日付など）を記録する場合は、日付列などに明示的に記録する必要があります。間違っているのは、ディスク上の行の物理的な順序にのみ暗黙的な順序を設定することです（とにかくそれを制御できると仮定します）。つまり、データをその順序に戻すには、いくつかの列でORDERBYする必要があります。

于 2009-02-16T17:56:55.757 に答える
2

いいえ、「select... order by...」は 1NF に違反しません。1NF に違反する行 (および列) の順序付けは、「select * from XYZ; 次に、上から 3 行目、左から 4 列目を選択する」という行に沿った状況に関するものです。はい、そのような DB 設計を見たことがあります。

于 2009-02-16T16:31:08.397 に答える
0

いいえ、それは本質的な秩序がないことを意味します。最後の価格の日付が必要な場合はselect max(date)、テーブルから取得する必要があります。

于 2009-02-16T16:27:50.930 に答える