Q&A
やろうとしてる事がイマイチよくわかんないけど、スキーマの設計の話という事で良いんですか？
機械学習云々はこの話で必要な要素？
「外部キーがないので…」というのは、必要であれば外部キーを持てばいいだけでは？
どの部分が悩みなのかよくわかりません。
以下の2ケースにおいて、E-R図でどのように表現したらよいかわかりません。
ご教示願います。
1.異常が発生したら通知先アドレスに通知する。
それぞれにサロゲートキー（NO）があって、外部キーがないので
リレーションを表現することができません。(異常履歴←通知マスタみたいな。。)
異常コードは共通してありまして、異常履歴に異常コードが書き込まれたら
該当する異常コードがある通知先マスタの通知先アドレスを読み込むようにしたいです。
そもそもこういったケースは、リレーションを張らないものでしょうか？
---------------------------------------------------------------
5/6 追記
従属関係がないから、リレーションを張る必要がないと言い切れなくて質問に至りました。
なぜなら、異常履歴にE001が入ると123@gmail.comが決まるので
| これをどうE-R図で表現するのかが質問の意図です。 |
|---|
| 異常履歴 | ||
|---|---|---|
| No | 1 | シーケンシャルな番号 |
| 発生日時 | 2020/5/5 13:00 | IoT機器からの異常通知 |
| 異常コード | E001 | コード定義 |
| 通知先マスタ | ||
|---|---|---|
| No | 1 | シーケンシャルな番号 |
| 通知先アドレス | 123@gmail.com | 一致したときのメール送信先 |
| 異常コード | E001,E002 | 異常履歴の異常コードと一致すれば |
2.天気と売り上げの相関関係を見たいです。
特に日時を持つイベント系テーブルのリレーションの張り方が
わかりません。
| 気象実績 | ||
|---|---|---|
| No | 1 | シーケンシャルな番号 |
| 発表日時 | 2020/5/5 14:00 | 気象会社のHPより1日1回取得 |
| エリア | tokyo | |
| 天気 | hare |
| 売上 | ||
|---|---|---|
| No | 1 | シーケンシャルな番号 |
| 売上日時 | 2020/5/5 14:05 | posシステムのデータ |
| 売上金額 | 5,000円 | posシステムのデータ |
外部キーをそもそもこういったケースで追加すべきか。追加するならどこに挿入すべきか。
２は、相関関係をみたいので機械学習とは違うかもしれませんが傾向を把握するために
リレーションを張るべきかを確認したいです
そもそも「異常コード」「通知先アドレス」がどんなものが入り、どのように利用されるのかを提示しないと、第三者に判断できませんが。
いまの作りだとどちらもマスタとして登録されるということは、「通知先アドレス」ごとに「異常コード」が振られているという意味ですよね？
そこら辺のモデルの説明がないとアドバイスなんて無理ですよ。
特に混乱するのが、冒頭「E-R図でどのように表現したらよいかわかりません。」と書きながら、結局聞きたいことは外部キーが必要なのか否かという話に変わってると思うんで、そこら辺もうちょっと整理して質問文書いてみてください。
あとサロゲートキーってただの主キーでしかないので、それが有ることで何を迷うのかも全然よくわかりません。
機器idとか物件idとか従業員番号とかが主キーならそのまま外部キーとして使えるかと
思いました。つまり、キー自体に意味があり紐づけが可能かと。。
サロゲートキーっつーのはナチュラルキーと違って「テーブル内で一意」である以外に意味を持ちませんよ。
例えばテーブルAをテーブルBから参照するための外部キーなら、テーブルBにテーブルAのキー（id）を持たせて、外部キー制約を張ればいいだけです。
なので意味とか紐付けとか、どこで悩んでるのかよくわかりません。
「通知先マスタ」の「異常コード」はひとつのカラムにカンマ区切りで複数の値が入るんですか？
それならちょっと設計としてどうかと思いますが。
回答1件
0
ベストアンサー
とりあえず２はリレーション云々は関係ありません。
モデル同士に直接の関係がないので。
１はテーブル設計がよくわかりません。
「異常履歴」というのはトランザクションデータだと思いますが、トランザクションデータの追加をトリガーにしてマスタを書き換えるというという意味？
「異常履歴」側がマスタの情報を参照してるわけじゃないのなら、これもリレーションは関係ありませんが。
投稿2020/05/05 15:30
総合スコア8947
1に関しまして少し違います。
「異常履歴」にトランザクションデータが追加されるとその中の異常コードを見て
（トリガーにして）通知先マスタの異常コードと一致すれば通知先マスタの通知先アドレスに
連絡するということです
その「連絡する」というのは、基本的にはそのDBを参照するアプリ側の話ですよね。
スキーマの定義には直接関係のない話です。
DBに限定して話すのであれば、組み込みのトリガー等の機能を使ってINSERTされたタイミングで通知先マスタを参照してその「連絡先」に何らかの手段で通知を行えばいいだけなので、その履歴がマスタへのリレーションを持っている必要はありません。
トリガーで何が出来るのかについては使ってるDBMS次第なので、そちらのリファレンス等を読んでください。
あと低評価押してるヤツはこの質問文の文脈読みとって回答してやれ。
書いてる内容をそのまま解釈したらどっちもリレーションは関係ない。
おっしゃる通りです。やっぱりトリガーですよね。。
異常履歴と通知先マスタは、直接のリレーションはない。
ニュアンスがむずいんですが、一方が決まれば他方が決まるわけではない？
う～ん。異常履歴に挿入されたレコードによって間接的には、通知先がわかる。
>その「連絡する」というのは、基本的にはそのDBを参照するアプリ側の話ですよね。
>スキーマの定義には直接関係のない話です。
>DBに限定して話すのであれば、組み込みのトリガー等の機能を使ってINSERTされたタイミングで通知>先マスタを参照してその「連絡先」に何らかの手段で通知を行えばいいだけなので、その履歴がマスタ>へのリレーションを持っている必要はありません。
仮に外部キーが存在するとすれば、異常発生時に異常履歴にデータが入るのと同時に、それがどの「通知先」に結びついたのかという結果を表すキーぐらいでしょう。
現状の「通知先マスタ」の構造が意味不明なのでアレですが、例えば
・通知先(ID, アドレス）
・異常履歴（ID, 発生日時, 異常コード）
というテーブルが基本にあったとして、「通知先」は複数の「異常コード」に結びつく（通知先を跨いだ異常コードの重複はない）のなら、これは別テーブルで
・通知先_異常コード(通知先ID(FK, ref(通知先)), 異常コード)
という関係テーブルを作り、
・異常履歴(ID, 発生日時, 異常コード(FK, ref(通知先_異常コード))
みたいになるとか。
あと異常コードがそもそも何を表しているのかわかんないから、それなら異常を表すマスタを用意して
・異常（コード, 説明）
みたいなテーブルに大して外部キーを張るとか、そういうのならわかりますけど。
成程。ありがとうございます。
通知先→通知先_異常コード→異常履歴
にして、異常履歴にデータが入れば、
通知先_異常コードから通知先を拾えるということですね。
関係テーブルがいるとかの勘所がないです。。
あなたの回答
tips
プレビュー
