0

解決すべき問題： 私はデータベースに不慣れで、テーブルに変更を保存する最良の方法を見つけようとしています。これは、いくつかのステータスの毎日のスナップショットです。"hotel_room_rentals" テーブル (20 列あり - すべて変更可能)。選択した日のそのテーブルを生成できるようにしたい (例: 本番環境で変更された内部のデータなので、別の場所に保存する必要がある)、または他の変換を実行できるようにしたい (例: 期間内の平均レンタル日数)

私の理論的な例 - 詳細: ホテルの DB を作成しているとしましょう。本番システムには、ホテルの 10,000 室すべての情報を表示するテーブルがあります。これは毎日のスナップショットです。テーブルが 1 日に 1 回更新されると仮定しましょう。

ルームの一部の属性は頻繁に変更されます。customer_number, rate_usd. あまり頻繁に変更されない属性もあります。たとえば、disabled_room、room_color、type_of_furniture などです。Room_number は明らかに変化しません (主キー)

ここで、このテーブルの変更を追跡する最善の方法を見つけたいと思います。この表に基づいて統計を作成し (例: 期間中の平均賃貸日数)、選択した日付 (例: 2013-01-01) の表を生成できるようにする最良の方法

私の考え: データベースについて何も知らないので、「DB_dump_date」(日付付き) という名前の列を 1 つ追加して、テーブル全体を毎日コピーすることを考えています。これは非常に単純なアプローチですが、おそらく多くのスペースが必要になります。私の 10,000 部屋のテーブルから、1 年に 365 回コピーする必要があります。

その他 の解決策: 他の Web サイトで、次の 2 つのテーブルを作成するように勧められました: 「予約」テーブルと次の列: Startdate Enddate Room Rate Occupant_name 次に、このテーブルを FactReservations テーブルに変換します: Date Room Is_占有率 Occupant_nameこれは私を助けてくれます...実際、20の中間テーブルを作成し、次に20のファクトテーブルを作成する必要があると思います(データベースに20の列があるため)。

質問: このような問題に対処するための推奨される方法は何ですか? ユーザーが魔法の ETL を作成せずに、それに対処する準備ができている DB スキーマはありますか? (例えば、それ自体で問題を最適化できる DB) 代替手段は何ですか? 頭の良い人なら、これをどのように行いますか? （できればMS Access...またはいくつかのフリーウェア技術で）

編集： もう1つ-部屋の予約だけでなく、すべてがテーブルで変更される可能性があります。変更を追跡できるようにしたい

4

4 に答える 4

2

要件に焦点を合わせ、そこから開始する必要があります。これまでのところ、私が見ている要件は次のとおりです。

-選択した日のそのテーブルを生成します

- 期間中の平均レンタル日数

設計の 2 つの両極端を考えると、より複雑な端では、部屋への変更を追跡する SCD テーブルを備えたデータマートが考えられ、単純な端では、既に述べたように、ある種のログ テーブルが考えられます。

行間を読むと、特定の日の部屋の属性を知るための要件は実際にはありませんが、過去の取引を分析する必要があることがわかります。

したがって、データベースの設計を開始する前に、要件について十分に検討することをお勧めします。

これを自動的にカバーする魔法の設計はありません。次元設計は、簡単に分析できるようにビジネス データをモデル化する標準的な方法ですが、要件を超える可能性があります。

于 2013-03-24T23:51:59.847 に答える
2

停止 - 速度を落として - 息を吸ってください。

しない - 毎日テーブルのコピーを作成しないことを繰り返します。このアプローチはベースから外れています。

あなたの問題は正規化の問題です。あなたが示すように-正規化する方法について他の提案があります-これがあなたが行きたい方向です。

あなたの目標は、あなたの質問に答えることができる SQL ステートメントに対応する構造を見つけることです (そして、まだ考えていないもっと多くのことを願っています)。これは、テーブルが変更されたりコピーされたりしない 1 つの静的モデルになります代わりに静的であり、変更されるのはテーブル内のデータだけです。（理想的には、更新はほとんどまたはまったくなく、挿入のみ）

ROOM テーブルと CUSTOMER テーブルが必ず必要であり、それらの間のリレーションはおそらく RESERVATION です。

これらはいっぱいになる可能性があります-そして、コピーや実体化などを一切行わずに、提起した質問に対するすべての答えを得ることができます..SQLだけです。

于 2013-03-24T22:57:57.803 に答える
1

データベースの世界へようこそ！そのことを念頭に置いて、Excel について知っていることのほとんどすべてを窓から放り出してください。Excel では、ワークブックの 2 つのシート間の関係を定義し、それらの 2 つの異なるシートからレポートを作成することははるかに難しいため、ほとんどの場合、同じデータを 1 つのシートに単純にコピーする方が簡単です。 Access またはその他のリレーショナル データベース。

通常、いくつかの正規化されたテーブルを作成し、それらの間の関係を定義します。次に、ビューのクエリを実行するときに、テーブル間を簡単に結合して、必要なデータを取得できます。

したがって、これを構築するのは簡単なレポート作成のためであり、プロパティ管理システムを作成するためではないという前提に基づいて作業します (それを検討している場合は、Micros などの業界のプレーヤーを検討することをお勧めします)。または Agilysys)、業界での私の経験に基づいて、次のテーブル レイアウトをお勧めします。

  • 予約 – 予約情報 (ゲスト名、到着日、出発日、チェックイン日、チェックアウト日、混合料金を使用する場合の料金など) が保持されます。
  • 客室 - ラックに関する情報を保持します (番号、ウィングコード、最大宿泊人数、ベッド数、喫煙/禁煙、ビュー、タイプなど)。
  • 部屋のステータス – 部屋が予約/保留中/OOO/OTM であるかどうかを追跡する必要がある場合のみ (ステータスの種類、開始日、終了日)
  • 部屋のステータスの種類 – 部屋のステータス保持の種類と在庫への影響 (タイプ、在庫切れフラグ)
  • 料金 (混合料金を使用しない場合) – 1 泊 1 予約につき 1 エントリ (ゲスト、料金)

個人的には、一意の識別子に代理キーを使用することの熱烈なファンです。なぜなら、ビジネス プロセスで何かが変更され、以前は一意だった自然キーが突然複製されてしまうことがよくあるからです。その意味では、各テーブルには代理キーがあり、結合は次のようになります。

  • 予約 – 部屋 (多対一)
  • 部屋 – 部屋のステータス (1 対多)
  • ルーム ステータス – ルーム ステータスの種類 (多対 1)
  • 予約 – 料金 (1 対多)

Access でリレーションシップ (つまり、他の DBMS の外部キー リレーションシップ) を適切に定義すると、クエリ (他のほぼすべての DBMS でビューと呼ばれる) またはレポートを作成するときに、それらを自動的に使用して結合が構築されます。

データベースについて学習するには、以下を確認することをお勧めします。

于 2013-03-25T19:47:58.910 に答える
0

既存のテーブルを使用する必要がある場合、以下は適用されません。データを新しいスキーマに移行できる場合、これは容易に課題に対処できます。TRE は、開発に現在のビュー パラダイムを使用するアプローチですが、データの時間次元を完全にサポートします (システム時間 = データがデータベースに入る時間と有効時間 = データに適用されるビジネス時間)。TRE の現在のビュー アプローチで作業することにより、この種の問題は簡単です。見てみましょう: - http://youtu.be/V1EcsuJxUno

于 2013-03-29T13:10:57.933 に答える