-1

各アカウント/メーターの過去のすべての使用状況を追跡しながら、水道局のオンラインシステムのデータベースを設定しようとしています。
データベースは、その日のすべての読み取り値を含むcsvファイルを受け取ります。私が受け取ったcsvには、次のデータがあります。

  • アカウント番号（1つのアカウントに複数のメーター/アドレスがある場合があります）
  • 住所
  • メーターID（アパート、商業ビルなどのために複数のポートがある場合があります）
  • ポート番号
  • 読書（数値）
  • 読み取り日（文字列）
  • メーターのシリアル番号（メーターIDに関連）
  • インストール日（メーターIDに関連）

私はDBのセットアップについて考え始めていました、そしてこれは私が得た限りです：

  • メーター情報
    • メーターID（主キー）
    • メーターシリアル
    • インストール日
    • 住所
    • ポートの数
  • メーターの使用法（私のメーターIDというタイトル）
    • 読書日
    • 読む

各メーターには、メーターIDという名前の独自のテーブルがあると考えていました。これにより、1メートルの過去のデータに簡単にアクセスできますが、ポートによる分離の問題が発生します。

以下では、meter＃000003のポートをどのように区別しますか？ 1つのアイデアは、ポート番号をメーターID番号の最後に追加することでした 。つまり、0000031と0000032があります。

したがって、私の主な問題は、複数のポートを持つ可能性のあるメーターと、複数のポートを持つ可能性のある複数のメーターを持つアカウントを処理することです。

これは私がセットアップした最初の非疑似データベースになるので、皆さんの助けを大いに歓迎します。

4

2 に答える 2

1

@Rogerの思考プロセスを進めると、ポート番号を個別のアカウント番号に分割できない場合、ポート番号は必要ありませんが、アカウント番号がPKであり、メーターテーブルが好きなアカウントテーブル、おそらくアドレスが必要ですただし、メーター テーブルにアドレス テーブルを使用することを計画している場合は、複雑になる可能性があります。また、私が正しければ、メーターのシリアル番号は一意である必要があるため、自動インクリメント PK を作成する代わりに、それを主キーに使用できます。また、メーターの使用ごとに新しいテーブルが必要になるとは限りません。単に MeterUsageTable を持つことができますUsageID と呼ばれる Auto inc PK、メーター ID を含む MeterID、測定日、測定値、および単純なクエリにより、すべての履歴を取得できます。ただし、会社の完全な使用履歴を入力すると、膨大な量のデータになります。編集: データベースをこのようなものにしたいと思います。必要なものと不要なものを微調整できますが、AccountNumber から使用法に移行するために必要と思われる関係を次に示します。 考えられる解決策

于 2012-08-09T03:56:50.923 に答える
0

コメントに基づいて、次のことを提案します。

アカウント

メートル

id account_id serial_number installation_date アドレス

meter_ports

meter_id

測定値

meter_port_id reading_date reading

住所に関する限り、複数の都市、州、郵便番号をサポートするかどうかはわかりません. 必要に応じて、特定の郵便番号や都市などでグループ化できるように、それを正規化することも検討してください。

于 2012-08-09T03:38:41.157 に答える