回答編集履歴
9
コメント修正
answer
CHANGED
|
@@ -165,7 +165,7 @@
|
|
|
165
165
|
, p."修正日"
|
|
166
166
|
FROM
|
|
167
167
|
"機械マスタ" m
|
|
168
|
-
/* パラメタ未登録の機械
|
|
168
|
+
/* 以下テーブル群はパラメタ未登録の機械も表示要なら結合方法は「LEFT JOIN」へ */
|
|
169
169
|
INNER JOIN "機械別パラメータ" p
|
|
170
170
|
ON m."ID" = p."機械ID"
|
|
171
171
|
INNER JOIN "機械別文字列パラメータ" p_char
|
8
モデル・ビュー定義の修正
answer
CHANGED
|
@@ -77,8 +77,8 @@
|
|
|
77
77
|
を許容する必要は出てきます。
|
|
78
78
|
|
|
79
79
|
以下は概念データモデル設計のほんの一例を記載します。
|
|
80
|
-
`機械マスタ（ID, 機械名, ... , 登録日, 変更日`
|
|
80
|
+
`機械マスタ（ID, 機械名, ... , 登録日, 変更日)`
|
|
81
|
-
`機械別パラメータ（ID, 機械ID, 連番, パラメタ名, データ区分）`
|
|
81
|
+
`機械別パラメータ（ID, 機械ID, 連番, パラメタ名, データ区分, 修正日）`
|
|
82
82
|
` 機械別文字列パラメータ (ID, パラメタ値)`
|
|
83
83
|
` 機械別数値パラメータ (ID, パラメタ値)`
|
|
84
84
|
` 機械別論理値パラメータ (ID, パラメタ値)`
|
|
@@ -165,6 +165,7 @@
|
|
|
165
165
|
, p."修正日"
|
|
166
166
|
FROM
|
|
167
167
|
"機械マスタ" m
|
|
168
|
+
/* パラメタ未登録の機械があれば結合方法は「LEFT JOIN」へ */
|
|
168
169
|
INNER JOIN "機械別パラメータ" p
|
|
169
170
|
ON m."ID" = p."機械ID"
|
|
170
171
|
INNER JOIN "機械別文字列パラメータ" p_char
|
7
更に補足事項
answer
CHANGED
|
@@ -110,6 +110,11 @@
|
|
|
110
110
|
数値パラメータはnumeric型やnumber型などを利用すると、
|
|
111
111
|
整数・少数どちらでも管理可能です。
|
|
112
112
|
|
|
113
|
+
あとグラフ化なども行うとのことで、
|
|
114
|
+
要件次第ですが例えば全機械の電圧のみをグラフ表示するとかがあるなら、
|
|
115
|
+
数値パラメタテーブルに更に種別などをもたせて・・・、
|
|
116
|
+
など集計の切り口は詳細テーブル内でも与えられるのかなとは思われます。
|
|
117
|
+
|
|
113
118
|
尚、**主キーはIDとなり親テーブルの機械別パラメータのIDと同一値**が入る想定です。
|
|
114
119
|
データ整合性の観点から各種パラメータ詳細テーブル全てのIDには、
|
|
115
120
|
**機械別パラメータのIDを参照する外部キー制約を定義**すると尚良いでしょう。
|
6
追記
answer
CHANGED
|
@@ -174,4 +174,10 @@
|
|
|
174
174
|
```
|
|
175
175
|
|
|
176
176
|
また、上記だと結局パラメタ値は全て文字となってしまうので、
|
|
177
|
-
数値パラメタのみだけに特化したビューなどを検討するのもありかもしれません。
|
|
177
|
+
数値パラメタのみだけに特化したビューなどを検討するのもありかもしれません。
|
|
178
|
+
|
|
179
|
+
#追記
|
|
180
|
+
ただし今回のケースだと上記のようなRDBのルールに厳密に則って、
|
|
181
|
+
手間をかけて設計するメリットが薄い気がするので、
|
|
182
|
+
「**EAV**」の設計パターンの対策として上記のような手法がある、
|
|
183
|
+
程度に抑えておくだけで良いかと思います。
|
5
蛇足部に追記
answer
CHANGED
|
@@ -171,4 +171,7 @@
|
|
|
171
171
|
INNER JOIN "機械別論理値パラメータ" p_bln
|
|
172
172
|
ON p.ID = p_bln.ID
|
|
173
173
|
AND p."データ区分" = '3'
|
|
174
|
-
```
|
|
174
|
+
```
|
|
175
|
+
|
|
176
|
+
また、上記だと結局パラメタ値は全て文字となってしまうので、
|
|
177
|
+
数値パラメタのみだけに特化したビューなどを検討するのもありかもしれません。
|
4
表現修正
answer
CHANGED
|
@@ -17,8 +17,8 @@
|
|
|
17
17
|
以下のような懸念が払拭できない場合は、
|
|
18
18
|
個人的には**今回の設計方針が一番妥当**とは考えます。
|
|
19
19
|
|
|
20
|
-
0. 機械情報(機械A)の登録数は今後も増加していく
|
|
20
|
+
0. 機械情報(機械A、機械Bなど)の登録数は今後も増加していく
|
|
21
|
-
0. 機械情報に付随するパラメタ値は増減恐れが高い
|
|
21
|
+
0. 機械情報に付随するパラメタ値は増減する恐れが高い
|
|
22
22
|
0. 機械情報に付随するパラメタのデータ型も今後増減する恐れがある（論理値、実数、文字以外が加わるなど）
|
|
23
23
|
|
|
24
24
|
上記の課題がある場合は、
|
3
誤字・表現修正
answer
CHANGED
|
@@ -6,8 +6,8 @@
|
|
|
6
6
|
**「EAV」アンチパターンとされる設計技法**とされています。
|
|
7
7
|
|
|
8
8
|
DB設計などについては「**SQLアンチパターン**」という書籍にて、
|
|
9
|
-
そのアンチパターンに陥りやすい背景、
|
|
9
|
+
その**アンチパターンに陥りやすい背景**、
|
|
10
|
-
及び
|
|
10
|
+
及び**どのように改善すべきか**までまとめられているため、
|
|
11
11
|
当方としては是非ご一読してほしい書籍の一つです。
|
|
12
12
|
|
|
13
13
|
#要件に対する設計是非について
|
2
レイアウト修正２
answer
CHANGED
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
maisumakunさんの回答の通り、
|
|
6
6
|
**「EAV」アンチパターンとされる設計技法**とされています。
|
|
7
7
|
|
|
8
|
-
DB設計などについては「SQLアンチパターン」という書籍にて、
|
|
8
|
+
DB設計などについては「**SQLアンチパターン**」という書籍にて、
|
|
9
9
|
そのアンチパターンに陥りやすい背景、
|
|
10
10
|
及びではどのように改善すべきかまでまとめられているため、
|
|
11
11
|
当方としては是非ご一読してほしい書籍の一つです。
|
1
レイアウト修正
answer
CHANGED
|
@@ -60,8 +60,7 @@
|
|
|
60
60
|
まったくオススメは出来ません。
|
|
61
61
|
|
|
62
62
|
#EAVを用いない設計方針として
|
|
63
|
-
「**EAV**」を回避し、
|
|
64
|
-
RDBらしく課題解決に拘るのであれば、
|
|
63
|
+
「**EAV**」を回避しRDBらしく課題解決に無理に拘るのであれば、
|
|
65
64
|
一例としてあげるなら以下のようなデータモデリングとなる気がします。
|
|
66
65
|
下記のような設計とすると、
|
|
67
66
|
恐らくですが、新規テーブル定義追加リスクは発生しません。
|
|
@@ -88,13 +87,13 @@
|
|
|
88
87
|
先ずは機械マスタですが、
|
|
89
88
|
こちらは機械共通の属性情報を管理します。
|
|
90
89
|
今後、**機械一覧検索などが必要になった際に一覧表示する情報はここで管理**するとよいでしょう。
|
|
91
|
-
尚、主キーはIDの想定です。
|
|
90
|
+
尚、**主キーはID**の想定です。
|
|
92
91
|
|
|
93
92
|
次に機械別パラメータですが、
|
|
94
93
|
こちらは各種パラメータ詳細テーブルの親テーブル、つまり汎化したものに当たります。
|
|
95
94
|
（**※オブジェクト指向の抽象クラス・派生クラスをイメージするとよいかも**）
|
|
96
95
|
こちらでは**機械別パラメータの一覧だけを管理**します。
|
|
97
|
-
尚、主キーはIDで、機械ID、連番に対して複合一意キーを付与する想定です。
|
|
96
|
+
尚、**主キーはIDで、機械ID、連番に対して複合一意キーを付与**する想定です。
|
|
98
97
|
|
|
99
98
|
ポイントは上記テーブルでは、
|
|
100
99
|
- パラメタごとのデータ区分を管理する
|
|
@@ -111,7 +110,7 @@
|
|
|
111
110
|
数値パラメータはnumeric型やnumber型などを利用すると、
|
|
112
111
|
整数・少数どちらでも管理可能です。
|
|
113
112
|
|
|
114
|
-
尚、主キーはIDとなり親テーブルの機械別パラメータのIDと同一値が入る想定です。
|
|
113
|
+
尚、**主キーはIDとなり親テーブルの機械別パラメータのIDと同一値**が入る想定です。
|
|
115
114
|
データ整合性の観点から各種パラメータ詳細テーブル全てのIDには、
|
|
116
115
|
**機械別パラメータのIDを参照する外部キー制約を定義**すると尚良いでしょう。
|
|
117
116
|
（**※設計段階で親子関係を明示する意図でも有用です**）
|